[whatwg] [WF2] Readonly and default pseudoclass matching

[Matthew Raymond]

Boris Zbarsky wrote:
> Matthew Raymond wrote:
> 
>>Take a look at the following URL:
>>
>>   http://www.w3.org/TR/2003/REC-xforms-20031014/sliceF.html#id2644859
> 
> That has no bearing on how :read-only is to be applied outside the context of 
> the XForms namespace.  Like to HTML, say.  Which brings us back to WF2, which is 
> working with HTML...

   "WF2" stands for "Web Forms 2". Why would it even define :read-only
for non-forms elements? Now that I'm thinking about it, if you want
:read-only to apply to non-control elements, you should extend the
selection of the pseudo-element in WA1, since such a suggestion has
nothing to do with web forms.

>>   So, clearly, when :read-only was first introduced for XForms, it was
>>meant to be used only with form controls that are not only set to
>>read-only, but are actually capable of being set to read-only in markup.
> 
> Which makes some sense in the context of XForms, where form controls are what 
> you care about styling.  Outside of that context, that seems like a very 
> unreasonable restriction.

   Outside of form controls, the only time an element isn't read-only is
when it's within an element that has |contentEditable| set, which will
probably be defined in WA1, not WF2. So :read-only is never useful in
the context of HTML 4.01 + Web Forms 2.0.

   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.

   Thought for WA1: Allow :read-only to work for elements with a
|contenteditable| attribute defined but the .contentEditable property
set to false. It could work like this...

HTML:
| <div id="x303" contenteditable><p>The quick red fox...</p></div>

CSS:
| div p { /* Styling for a standard paragraph in a div. */ }
|
| #x303:read-write p {
|   /* Styling for an actively editable paragraph. */
| }
|
| #x303:read-only p {
|   /* Styling for a potentially editable read-only paragraph. */
| }

   Note that the actual <p> child element cannot be selected directly
using :read-only.

>>   The XForms spec clearly states :read-only selects a form control, so
>>if :read-only is a "way to style elements which are in the respective
>>states as defined by XForms", then it can't apply to a non-control element.
> 
> Sure it can, if the non-control element is not in the XForms namespace (if 
> nothing else, you can then just style XForms-namespace content that matches 
> :read-only, if desired).

   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?

>>>WF2 is claiming to be doing exactly such clarification, if you note.
>>
>>   WF2 can suggest how styling should be handled, as XForms did, but it
>>needs to ultimately be defined by CSS.
> 
> Actually, no.  CSS defers to document languages on a number of issues; HTML5 and 
> specifically the Web Forms 2 part of it is such a language.  XForms is another 
> language.  CSS just defines that a :read-only psuedo-class exists and leaves it 
> up to the document language to define what is matched by it.  XForms has such a 
> definition.

   Then it really doesn't matter what CSS3-UI says? 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.

> So does Web Forms 2, but the Web Forms 2 definition seems 
> inadequate to me in the context of HTML5.  If Web Forms 2 were somehow separate 
> from HTML5 that might be OK, but it's not.

   I see nothing inadequate about the current definition, nor do I see
any useful purpose that is served by changing it.

>>   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. Disabled controls may be
enabled, and therefore must have styling to indicate that the contents
are only temporarily inaccessible. Also, read-only controls are more
likely to have their values changed by the program (for instance, if
it's used for a subtotal), where as disabled controls usually have their
values fixed while they are disabled.

> Again, this comes back to the basic question of "what does :read-only select?" 
> Is it "read-only elements" or "form controls that have a readonly attribute in 
> the DTD and have it set"?

   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, so you may not think of that
being selected by :read-only, especially when dealing with
pseudo-classes that where originally created specifically for a forms
language.

> The former seems more useful to me from a general
> user-interface basis.  You seem to be convinced that it should be the latter, 
> with "that's what XForms does" as the argument.  I think that this is a case 
> where HTML5 shouldn't copy XForms.

   I don't see ANY usefulness to having :read-only apply to non-control
elements. It would mean that you can't use :read-only for
language-independent styling of read-only form controls. I'd have to do
read-only control styling on a per namespace basis. What's worse, if
someone decides to put a |readonly| attribute on something that doesn't
have the attribute, many user agents will still style the element when
you use "[readonly]" (and possible "[readonly]:read-only" as well), so
you can't rely on that to determine if it's a read-only form control in
HTML.

   Personally, I'd rather keep :read-only defined as is so I can do this:

| :read-only { /* Styling for all read-only form controls. */ }

   If the user wants to select all elements that are not read-write form
controls, they can simply use ":not(:read-write)".

>>>You seem to be confusing the "readonly" attribute and the :read-only CSS 
>>>pseudo-class...
>>
>>   Not at all. See the following URLs:
>>
>>http://whatwg.org/specs/web-forms/current-work/#readonly
>>http://www.w3.org/TR/html4/interact/forms.html#adef-readonly
> 
> Those both talk about the "readonly" attribute.  They don't have any mention of 
> :read-only.  I stand by my original statement.

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