> 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. Agreed. > 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. WDYT? Bye, Helma
