[whatwg] [WF2] Readonly and default pseudoclass matching

Ian Hickson wrote:
> 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.

   Of course he gave it the all clear. He's the one who wrote the
disputed portion of the spec in the first place.

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

   And if it's changed later, say in a CSS3-UI Revision 1, you'll have
to change the language in WF2 to follow suit, because WF2 deliberately
reiterates parts of the current CSS3-UI.

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

   No, the latter has a use case, one that I have suggested an
alternative to (:editable). No one has properly explained why the former
is a use case, because you'd potentially want consistent styling with
regard to editor-specific presentation.

>>I don't think WF2 should contain ANYTHING that is specifically in 
>>violation of the original XForms definition of :read-only and 
>>:read-write.
> 
> 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.)

   Some kind of pseudo-class would probably be better, since the editor
could potentially be using media. That doesn't explain why :read-only
and :read-write should be used for editor-specific presentation.

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

   Even so, you could simply refer generally to CSS specifications
without restating their content. By restating content, you make the spec
potentially incompatible with future revisions of the CSS3-UI spec.

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

   In a script-free scenario, you might as well be using <span>. In a
scenario with script, when would you disable the <input readonly>
element specifically and in markup rather than disabling a parent
<fieldset>?

>>Considering the fact that greater than 90% of browser users don't even 
>>have a browser that can edit otherwise static content
> 
> Just visit javascript:document.designMode=true to make any document 
> editable in IE. (Untested, I might have the wrong syntax.)

:editable.

Received on Sunday, 31 July 2005 18:11:20 UTC