[whatwg] [WF2] Readonly and default pseudoclass matching

[Boris Zbarsky]

Matthew Raymond wrote:
>    "WF2" stands for "Web Forms 2". Why would it even define :read-only
> for non-forms elements?

It shouldn't.  That was the point of my original mail, which you seem to have 
missed.  The current text is ambiguous -- either it's not talking about non-form 
elements at all, or it's defining :read-only to NOT ever apply to them.  I would 
like the text clarified to the first interpretation, at which point for non-form 
elements implementors can do whatever CSS3 UI or other relevant spec says 
without worrying about it conflicting with WF2.

>    Outside of form controls, the only time an element isn't read-only is
> when it's within an element that has |contentEditable| set

Or when the whole document is in an editor, as opposed to a browser.

> So :read-only is never useful in the context of HTML 4.01 + Web Forms 2.0.

Again, my concern is with WF2 specifying things that affect behavior outside of 
its context.

>    I agree that how :read-only behaves with respect to elements in a
> |contenteditable| container needs to be defines. However, it doesn't
> need to be defined in WF2.

Precisely my point.  The current WF2 phrasing defines it to not match, if read 
literally.

>    Your argument doesn't make any sense. XForms defines pseudo-classes
> for use with XForms elements, which are by definition all form elements.
> Why expand pseudo-classes obviously intended for form elements to
> non-form elements?

Because they make sense and are useful for more than just form elements?  The 
same reason that :hover and :active, originally destined for just links, were 
greatly expanded.

>    Then it really doesn't matter what CSS3-UI says?

It matters when it explicitly says something.  It also matters to suggest a 
course of action in cases when the document language doesn't explicitly address 
styling.

> In that case, we can
> just leave the spec unchanged, as it clearly defines what :read-only
> applies to, and doesn't prevent us from expanding how we can use it later.

Actually, it does prevent us from expanding.  That would be the problem.

>>>   The width of the checkbox is 100 pixels. You should have used the
>>> :disabled pseudo-class from CSS3-UI:
>> I realize :disabled would match there.  The question is why :read-only should 
>> not match -- the checkbox is readonly in this case; the user can't change its value.
> 
>    No, the checkbox is disabled. Read-only controls are typically
> inaccessible for the life of the application.

That's not the case in a lot of applications I've seen where controls are 
actually switched from read-only to read-write...

None of which addresses my question.  We agree that the checkbox should match 
:disabled.  Why should it not also match :read-only?  It's not like the two are 
ever claimed to be mutually exclusive.

>    Clearly, if you're looking at markup and want to know what :read-only
> selects, and you see an element of the form <[element] readonly>, you'd
> expect that to be selected. By contrast, you don't think of a simple
> paragraph in terms of read-write access

A lot of people sure do.  Ever tried using Amaya?  Or any other browser that 
supports editing (most of them at this point, though not to the extent that 
Amaya does)?  If you meant to say that _you_ don't think in those terms, then 
I'll accept that on faith.  ;)

> so you may not think of that being selected by :read-only

So the problem where people were using *:hover and assuming only links would match?

I think this can be prevented if the very first time :read-only is shipped in 
browsers it already has the final behavior.  Given that we're attempting to 
implement :read-only right now, I would like to pin this behavior down for 
precisely that reason -- so that we don't ship something in Gecko 1.8 and then 
change it majorly a year later in 1.9.

>    I don't see ANY usefulness to having :read-only apply to non-control
> elements.

One example: you can select editable parts of a document for special styling so 
the user can see which parts he can edit.

> It would mean that you can't use :read-only for
> language-independent styling of read-only form controls.

That's true.  Perhaps we need a :form-control pseudo-class to address this 
issue?  Not something XForms would have introduced, since it's all form 
controls, but in the context of HTML5 and CSS3 UI it might be useful.

>    But "8.2. Relation to the CSS3 User Interface module" specifically
> defines that, and you even state to the effect that it /should/ be
> defined there, so what's your point? Besides, I was also reacting to the
> fact that your example didn't use "readonly".

Precisely.  I see no reason to tie :read-only to the "readonly" attribute, which 
you seem to want to do very badly.

-Boris