[whatwg] False orthogonal nature :read-only and :disabled in WF2
Ian Hickson
ian at hixie.ch
Wed Feb 11 00:20:42 PST 2009
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list