[whatwg] [WF2] Readonly and default pseudoclass matching

[Matthew Raymond]

Ian Hickson wrote:
> 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.

   Yeah, after looking at the section in question, it's of limited use
if it can't define how HTML interacts with CSS3-UI specifically...

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

   I'll bring that up in www-style as a reason to change the spec, then. ;)

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

   Well, what's worse is that "user alterable" is a subset of the
definition of "read-only" as it is defined in HTML 4.01. A read-only
element in HTML is submittable and focusable unless it is also disabled.
The :read-only pseudo-class as defined in CSS3-UI, which is defined in
terms of user alterability, would include content that is not
submittable, and therefore apply to elements not considered read-only in
HTML 4.01.

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

   It's possible that a group of fields could be read-only, especially
if you don't have security access to change them, so this does need to
be considered. Very true.

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

   I think you're confusing "mutually exclusive" with "orthogonal".