cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: CONTRIBUTION: forms-calendar-styling defect when widget disabled
Date Fri, 18 Mar 2005 11:21:52 GMT
Linden H van der (MI) wrote:

>>Reading the HTML spec [1], the difference between disabled and readonly are:
>>- readonly is only available on <input> and <textarea>. disabled is available
on all controls
>>- readonly sends back the value to the server, which is of no use if the widget is
not active
>>- readonly inputs receive focus and are includes in tab navigation. 
>>What's the purpose of this is the value can't be changed?
>The only purpose I can think of is accessibility: I can imagine that reading out loud
text vs a readonly input field/textarea is different. And it can also have a shortcut key,
which output widgets displayed as
>"plain" text don't have, for quick(er) navigation.
>>The HTML disabled state seems to me to match closely with the CForms disabled state,
as it applies to a wider range of controls and doesn't send back the value to the server.
>>Now if people want to use HTML readonly, they can do it on active widgets (which won't
loose their value because it's sent back) by adding a <fi:styling readonly="readonly"/>.
This works because the stylesheets copy verbatim their unknown attributes to the produced
HTML element.
>Agree. The only point in the discussion was that they liked different styling based on
the presence/absence of the "readonly" attribute.
>>Now from a security POV, using HTML readonly is risky as nothing 
>>prevents the value to be modified before being sent back, 
>>either by some injected javascript (very hyped nowadays to hack gmail and google maps)
or some forged request.
>:-( Good point.
>So, to sum it up: "readonly" as attribute is supported in the current
>version of the styling XSL files, but there will be no widget support
>for this due to security issues. If treatment of the "readonly"
>attribute should differ from the current situation, it is up to the user
>to modify the styling XSL files.

Exactly. Very good summary!

Furthermore, the choice between readonly/disabled is IMO really a 
presentation concern, and not an application concern. That's why I 
consider that distinguishing them at the widget level by introducing an 
additional state would be useless.


Sylvain Wallez                        Anyware Technologies  
Apache Software Foundation Member     Research & Technology Director

View raw message