[whatwg] False orthogonal nature :read-only and :disabled in WF2
Ian Hickson
ian at hixie.ch
Mon Aug 14 17:34:39 PDT 2006
On Tue, 21 Feb 2006, Matthew Raymond wrote:
>
> In the Web Forms 2.0 spec, under "8.2. Relation to CSS selectors"[1],
> there is the following statement:
>
> | :read-write
> | Matches form control elements that do not have the readonly
> | attribute set (including password fields, although technically
> | they should be called "writeonly"), or to which the attribute
> | doesn't apply (such as radio buttons). A disabled field can still
> | match this pseudo-class; the states are orthogonal.
>
> Note the last sentence stating that :read-only/:read-write and
> :enabled/:disabled are orthogonal. This is contrary to CSS
> specifications. As defined in currently available specifications,
> :disabled and :read-only are _NOT_ orthogonal. See the description of
> :read-only and :read-write in the CSS3-UI spec[2]:
>
> | 4.1.6. :read-only and :read-write
> |
> | An element whose contents are not user-alterable is :read-only.
> | However, elements whose contents are user-alterable (such as text
> | input fields) are considered to be in a :read-write state. In typical
> | documents, most elements are :read-only. However it may be possible
> | (e.g. in the context of an editor) for any element to become
> | :read-write.
>
> As you can see, anything that's not user-alterable is :read-only. But
> "disabled elements" in HTML are clearly not user-alterable, as you can
> see here [3] (with emphasis added by me):
>
> | In this example, the INPUT element is disabled. Therefore, it _CANNOT_
> | _RECEIVE_USER_INPUT_ nor will its value be submitted with the form.
>
> The Selectors specification[4] also fails to define the states as
> orthogonal:
>
> | The :enabled pseudo-class allows authors to customize the look of user
> | interface elements that are enabled — which the user can select or
> | activate in some fashion (e.g. clicking on a button with a mouse).
> | [...]
> | Similar to :enabled, :disabled allows the author to specify precisely
> | how a disabled or inactive user interface element should look.
>
> Logically, the user cannot alter the contents of an element or form
> control if the user is unable to select or activate that control. In
> other words, :disabled is always a subset of :read-only. Therefore, your
> claims regarding the orthogonal nature of the :read-only and :disabled
> states are supported by neither CSS3-UI nor Selectors.
I understand (and agree) that WF2 disagrees with CSS3UI and Selectors
here. I believe the error is in CSS3UI and in Selectors.
Having them be orthogonal is far more useful to authors. For example,
imagine the following stylesheet:
:read-only::after { content: ' (Read-only)'; }
:disabled { color: gray; }
You wouldn't want all the :disabled fields to suddenly say "read-only"
just because they weren't relevant. You wouldn't want to have to say:
:not(:disabled):read-only { ... }
...every time you wanted to style the fields which, when enabled, still
can't be edited.
I'll see if I can get Selectors updated.
> There is a clear double standard here. I had a problem with the way
> :read-only was defined, that it applied to elements that did not have a
> |readonly| attribute, but you made it clear that I would have to go
> through www-style to get it changes in the CSS3-UI specification before
> getting a related change made in the WF2 spec.
Well, :read-only has always been intended to apply to everything. There's
a difference between the basic concept of the pseudo-class and the exact
definiton of the pseudo-class.
> Yet when you have a problem with the definition of the
> _EXACT_SAME_PSEUDO-CLASS_, you just change the WF2 spec to produce
> orthogonally where none existed in the collective W3C specs.
>
> Perhaps you can explain to me how you justify this.
I'm trying to make the specs be useful to authors.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list