[whatwg] [WF2] Readonly and default pseudoclass matching
ian at hixie.ch
Sun Jul 31 08:10:29 PDT 2005
On Sun, 31 Jul 2005, Matthew Raymond wrote:
> Ian has sadly chosen to change the text to this:
> | 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 elements defined by this specification that are not form controls
> | (namely form, label, datalist, option, optgroup, and fieldset
> | elements).
> First of all, he shouldn't mention "elements...that are not form
> controls" in the first place, because he's saying that they can be
> specifically selected by :read-only when the whole point should have
> been to eliminate anything that might conflict with CSS3-UI, and
> obviously if we change CSS3-UI to use the XForms definition of
> :read-only, this will conflict.
Note that the text above was reviewed by the editor of the CSS3 UI spec
and given the all-clear.
CSS3 UI is pretty clear about the fact that pretty much all elements match
either :read-only or :read-write, for example is a document is loaded in
an editor (say, Amaya), all elements become :read-write.
> Second, why would I need :read-only on things like <label>, <option>
> and <optgroup>? Outside an HTML editor, how would I even edit something
> like that?!?
The HTML editor is a major use case, as is contentEditable.
> I don't think WF2 should contain ANYTHING that is specifically in
> violation of the original XForms definition of :read-only and
XForms is irrelevant here. Its section is non-normative, and its working
group has no authority over CSS (at best it can do what we're doing,
namely, defining how CSS3 UI maps to XForms).
CSS3 UI is what matters, not XForms. (I'm a member of the CSS working
group and we worked closely with the XForms working group as far as CSS3
UI goes, for what it's worth.)
> What's the use case for editor-specific presentation (especially when
> there's no such media as "editor", so far as I know)?
N|vu, e.g. (Why would it be a media? The media is "screen", typically.)
> My concern is that CSS3-UI has expanded the definitions of :read-only
> and :read-write to the point where they serve no useful purpose.
I recommend sending your comments to www-style. As far as WHATWG goes, we
have to take CSS3 UI as gospel and work from there. (Where that is
possible. In the case of :in-range/:out-of-range I admit to taking a
> If your user agent is both a browser and an editor simultaneously, and
> you can actually edit even <input readonly> elements, then even a
> read-only input in markup is potentially :read-write. Does <input
> readonly> match :read-only if it's inside a |contenteditable| element?
No idea, haven't specified contentEditable yet. Anne?
> > The same reason that :hover and :active, originally destined for just
> > links, were greatly expanded.
> Pseudo-classes :hover and :active aren't dependent on the semantics of
> the language, and select based on pointer state rather than any
> attribute or property of the element.
Well, :active is an open issue. We (the CSSWG) haven't yet decided how it
should work, sadly.
> Actually, they're mutually exclusive in markup. When are you ever going
> to have <input readonly disabled>?
When the control which would otherwise be readonly is irrelevant. It could
be readonly because it's being used much like an <output> field (but one
that will submit). It would be disabled when its value is not relevant,
e.g. because that part of the form is not being used.
> Considering the fact that greater than 90% of browser users don't even
> have a browser that can edit otherwise static content
editable in IE. (Untested, I might have the wrong syntax.)
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg