[whatwg] [WF2] Readonly and default pseudoclass matching

[Matthew Raymond]

Boris Zbarsky wrote:
> 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.

   Let's look at the specs again to see if clarification is needed:

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

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

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

| An element whose contents are not user-alterable is :read-only.
| However, elements whose contents are user-alterable (such as text
| input fields) are considered to be in a :read-write state. In typical
| documents, most elements are :read-only. However it may be possible
| (e.g. in the context of an editor) for any element to become
| :read-write.

   This redefinition was hostile to XForms 1.0 Appendix F. Anyone using
Appendix F to determine how to style XForms when using it in an XHTML
document may use :read-only and :read-write in ways that cause
unintentional styling of XHTML elements. Granted, this section is
non-normative, but as shown clearly above, the new states were added
under the pretext of supporting styling for XForms 1.0.

   Personally, I think CSS3-UI should be rewritten so that stylesheets
using the XForms definition of :read-only and :read-write don't break.
WF2 should just define which elements are considered read-only form
controls in HTML. Instead, 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.

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

   At the very least, Ian should have done 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 other elements defined by this specification that are defined as
| read-only under the CSS3 Basic User Interface Module.

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

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

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

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

   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?

   Personally, I don't thinking we should be styling around the editing
capabilities of user agents unless that editability is defined as part
of HTML. Editors can apply their own styling for editing, so I see no
point in giving authors the ability to change the way elements look in
an editor. It would only serve to confuse people using the tool.

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

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

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

   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.

> 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. Note that :link and :visited,
which are dependent, are not defined for all elements.

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

   That's only in situations where there is no distinction between
disabled and read-only. You can't automatically assume that such
distinctions don't exist on an arbitrary user agent and platform.

> None of which addresses my question.  We agree that the checkbox should match 
> :disabled.  Why should it not also match :read-only?

   Because it's not read only.

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

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

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

>  If you meant to say that _you_ don't think in those terms, then 
> I'll accept that on faith.  ;)

   The smiley doesn't alter the fact that the above is an insult.

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

   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.

   (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.)

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

   You can do that already using "[contenteditable] *" or similar
techniques in your stylesheet. Furthermore, such editing is so rare that
the use of |id| or  |class| is not a significant burden.

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

   I've actually considered something like :form-control, but what I
was thinking about would allow you to select certain classes of widgets:

| :form-control(date) { /* Styling for a date picker. */ }

   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.

   Also, it leads to CSS defining features of the language rather than
the language specification defining how certain CSS properties and
selectors apply to the language. 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|?

   Then again, perhaps it doesn't matter if it's slanted towards
specific languages. We have CSS properties for lists, after all.

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

   I have yet to hear a use case for a :read-only pseudo-class not tied
to some sort of "readonly" attribute. There may be a use case for
:read-write and non-control elements thanks to contentEditable, but only
under circumstances where you'd want to toggle contentEditable.
(Otherwise, you could style based on "[contenteditable] <element>".)