[whatwg] [WF2] Readonly and default pseudoclass matching

On Sun, 28 Aug 2005, Matthew Raymond wrote:
> > 
> > Ok, I'm glad you agree that it reinforces CSS3 UI and doesn't conflict 
> > with it. That is what was intended. We can't really do anything else, 
> > since CSS3 UI isn't one of the specs WHATWG is doing.
> 
> Sure you can. You can change the language is a way that doesn't make WF2 
> depend so completely on a portion of the specification that is clearly 
> in dispute.

Should the CSS3 UI spec change, WF2 would change with it. However, I don't 
see how we can make a clarification of intent for another specification 
not depend on that specification.


>>>| Matches form control elements that have the readonly attribute set,
>>>| and to which the readonly attribute applies (thus radio buttons will
>>>| never match this, regardless of the value of the attribute), as well
>>>| as other elements defined by this specification that are defined as
>>>| read-only under the CSS3 Basic User Interface Module.
> 
> Actually, looking at the first part (which is pretty much identical to 
> what you have), it's in conflict with CSS3-UI, because <input 
> type="radio" disabled> technically matches the CSS3-UI definition 
> :read-only selector.

I discussed this with some CSSWG members, and our conclusion was that 
:read-only and :disabled being orthogonal was the most useful, which is 
why I wrote the WF2 spec the way I did.


> With regard to the entire section, note that :enabled, :disabled, 
> :checked and :indeterminate are defined by CSS3 Selectors, not CSS3-UI. 
> The latter spec only defines some details of the :active pseudo-class. 

Good catch, fixed.


> > The whole point of the section is to say which elements defined by WF2 
> > match the definition of CSS3 UI.
> 
> CSS3-UI is quite clear about that. Anything, and I mean ANYTHING, that 
> is not "user-alterable" is :read-only under CSS3-UI. Even disabled 
> <input> controls are user-alterable. That's why any implication that a 
> disabled radio button is not :read-only would be a contradiction of the 
> CSS3-UI specification.

Since that was apparently not the intent of the specification, it isn't as 
clear as we might have hoped! :-) Hence the much more specific definitions 
here. (What does "user alterable" mean? With the Mozilla DOM Inspector I 
can "alter" anything in any DOM.)


> > One possibility would be viewing a database view where the user has 
> > rights to edit a field on some records but not others (e.g. allowed to 
> > edit the customer's start date but only if the customer hasn't started 
> > yet). As you flip through records, the field becomes read-only or not. 
> > It's not disabled, because the data is still relevant, even though it 
> > can't be edited. (Indeed in XForms "enabled" is spelt "relevant", 
> > IIRC.)
> 
> Are you suggesting we expand <fieldset> to include |disabled| and
> |readonly| properties that are inherited by child controls?

Disabled is already done. "readonly" I'm less sure about, but I have added 
it to the list of things to consider for WF3.


> That may not be such a bad idea. (BTW, I've already reconsidered my 
> position on whether |disabled| and |readonly| are mutually exclusive. 
> They are not.)

I think they are. :-) If they were not, why would they be independent 
attributes? Even in XForms the two concepts are separated.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 29 August 2005 03:01:11 UTC