cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
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.
>>    
>>
>
>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.
>  
>

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

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message