- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 15 Aug 2006 00:34:39 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 14 August 2006 17:34:39 UTC