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 Thu, 17 Mar 2005 22:18:18 GMT
Linden H van der (MI) wrote:

>>Ok. He can add whatever attribute to his styling, the stylesheets are 
>>built for this, but I don't want to see this "readonly" attribute 
>>handled in the stylesheets, as we have other mechanisms for 
>>this, namely widget states.
>Agree, however, "readonly" is part of the HTML textarea specification.
>IIRC there is a slight difference between "disabled" and "readonly". The
>first one is addressed by widget states, the latter is not.

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 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.

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.



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

View raw message