[whatwg] [WF2] Readonly and default pseudoclass matching

[Boris Zbarsky]

Matthew Raymond wrote:
> From CSS3-UI (emphasis added):
> | Specifically, these new states (except for :default) are provided as a
> | way to style elements which are in the respective states _AS DEFINED
> | BY XFORMS_.

This is informative text, not normative.  You do realize that, right?

> From XForms 1.0 (emphasis added):
> | :read-only & :read-write -- Selects any _FORM CONTROL_ bound to a node
> | with the model item property _READONLY_ evaluating to true or false
> | (respectively).

This is normative text.

>    Of course, the CSS3-UI spec then turns around and redefines
> :read-only to be virtually nothing like the way XForms defines it...

It's not clear whether that text is normative or informative, actually...  Would 
be nice if that were clarified too.  ;)

>    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?!?

Why are you excluding HTML editors, exactly?  And again, see Amaya.

>    I don't think WF2 should contain ANYTHING that is specifically in
> violation of the original XForms definition of :read-only and :read-write.

I don't see why XForms should have a monopoly on these pseudo-classes.  XForms 
can define how these apply to XForms content; it's up to other languages to 
decide how they apply to nodes in those namespaces.

>    What's the use case for editor-specific presentation (especially when
> there's no such media as "editor", so far as I know)?

You'd have to ask one of the editor developers (I won't claim to know the 
details), but they definitely want to be able to style things specially in an 
editor, based on their past demands on the core Gecko code.

>    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. 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?

Good question.  Might want to ask this on www-style at w3.org.

> Editors can apply their own styling for editing

Amaya.

>    I'm wondering if a new pseudo-class named ":editable" wouldn't be a
> better idea, actually.

Possibly, yes.

>    Uh, no, they don't make sense because "read-only" and "read-write"
> typically applied so something that has a read/write state. A block of
> static text doesn't need a read/write state because it's a bloody block
> of text.

Which you may or may not be able to edit.  Sounds like read/write state to me.

>    Pseudo-classes :hover and :active aren't dependent on the semantics
> of the language

It's not clear that this is true for :active -- the definition of :active 
somewhat depends on whether the element can be activated, last I checked.  Which 
is a semantic issue.

>>  It's not like the two are
>> ever claimed to be mutually exclusive.
> 
>    Actually, they're mutually exclusive in markup. When are you ever
> going to have <input readonly disabled>?

Any time I want. There's nothing preventing me from having that markup.

>    Considering the fact that greater than 90% of browser users don't
> even have a browser that can edit otherwise static content

IE has very nice document-editing features that you can apply to any iframe. 
What am I missing?

>    Without knowing the details of how :hover came to be, I may be
> setting myself up on this one, but I'll bet that it wasn't originally
> defined in something like an HTML spec as only applying to links, then
> was redefined to apply to all elements after the fact.

It was defined in CSS1 to apply to links and then broadened in scope in CSS2.

>    (BTW, there ARE pseudo-classes that apply specifically to links, such
> as :link and :visited. So selectors specific to markup that accomplishes
> a specific function is unheard of.)

Sure.  Note that those names are much more specific than :read-only (though not 
specific enough, as experience shows).  If the pseudo-class were 
:read-only-form-control we wouldn't be having this discussion.  And yes, 
:visited would be better as :visited-link and :link would be better as 
:unvisited-link.  Not repeating past mistakes would be good, imo.

>> One example: you can select editable parts of a document for special styling so 
>> the user can see which parts he can edit.
> 
>    You can do that already using "[contenteditable] *" or similar
> techniques in your stylesheet.

This is not document-language-independent, which is a desirable goal as you've 
repeatedly pointed out.

> Furthermore, such editing is so rare

Amaya.  Or any page that wants to dynamically make parts of itself editable.  I 
think the capabilities of client editing are just starting to be used on the 
web, hence my concern with these issues.

>    The problem with that is that you have to define default widget
> values, which are invariably slanted towards a specific language, like
> XHTML or XForms.

True.  Just :form-control is pretty language-independent, though.

> For instance, is <object> a form
> control? It can be, but what happens if you're just using <object> to
> display an image? You could say that it's not a form control if |name|
> isn't defined, but what if you have an <input> without a |name|?

These are all to be defined by the language in question (HTML, in this case).

-Boris