[whatwg] False orthogonal nature :read-only and :disabled in WF2

On Tue, 15 Aug 2006, Matthew Raymond wrote:
> Ian Hickson wrote:
> > I understand (and agree) that WF2 disagrees with CSS3UI and Selectors 
> > here. I believe the error is in CSS3UI and in Selectors.
> 
>    I would agree with that, although I think we disagree as to what the
> error is.
> 
> > 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.
> 
>    Please go back and address the concerns that I posted on www-style in
> detail when you update Selectors.

It turns out this is (now?) only in CSS3 UI, which doesn't have a 
maintainer right now.


> >> 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.
> 
>    That's the point. The :read-only pseudo-class should never have been
> defined as applying to everything. It should apply to markup that has a
> defined read-only state. The text-based input of a control is not
> comparable to a |contenteditable| region of HTML. For instance, if you
> can't edit the markup of an <input> element, but you can edit the text
> in the control, then at the markup level, the control is read-only, but
> the actual control contents are read-write. Conversely, what if you have
> an <input readonly> control as the child of an element with
> |contenteditable| enabled? In this case, the markup actual says
> "readonly", but it might still be considered read-write because the
> markup can be changed.

I agree that I was applying a double standard here (I am following CSS3 
UI when it comes to it saying that :read-only applies to everything, and 
not following it when it comes to saying that :read-write doesn't apply 
to disabled controls).

I've made HTML5 say that :read-write doesn't apply to disabled controls.


> >> 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.
> 
>    Having to style control elements using selectors like
> "html|input[readonly]" as opposed to ":readonly" doesn't strike me as
> more useful for authors. Also, note that for stuff like XForms, you can
> end up in a situation where there's no clear way of styling a
> "read-only" control, since the "read-only" property may not exist
> directly on the element. Of course, if we start talking about other XML
> languages here, we're getting off topic...

Yeah. I'm not really sure what to do about this.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 11 February 2009 00:20:42 UTC