Linden H van der (MI) wrote:
Ok. He can add whatever attribute to his styling, the stylesheets are
True.
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
[1] http://www.w3.org/TR/html401/interact/forms.html#h-17.12
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
