[whatwg] [WF2] Readonly and default pseudoclass matching
mattraymond at earthlink.net
Mon Aug 29 15:04:48 PDT 2005
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
> 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
> 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
> 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
submittable, and therefore apply to elements not considered read-only in
>>>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",
>>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".
More information about the whatwg