[whatwg] [WF2] Readonly and default pseudoclass matching
ian at hixie.ch
Mon Aug 29 03:01:11 PDT 2005
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg