[css3-ui] Problems with :read-only and :read-write (was [WF2] Readonly and default pseudoclass matching)

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

   Actually, I think I outright said it later in the message.

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

   Yes, normative text from a CR that contradicts non-normative text in
a recommendation.

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

   Couldn't the :read-only and :read-write sections be informative?
(Seriously, that's a question. I'm not being rhetorical here.)

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

   What is the purpose of overriding editing UI of an HTML editor or
providing a styling for the page you're editing that won't match the
styling on most browsers? Sounds like we're empowering webmasters to
confuse the heck out of other webmasters using CSS.

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

   It stands to reason that a pseudo-class has some kind of higher
meaning that applies to all languages, or else it's just a bunch
namespace-specific CSS properties that happen to have the same name.

   Also keep in mind your Amaya example. If XForms support was added to
Amaya, and Amaya implements the CSS3-UI versions of :read-only and
:read-write, then the CSS3-UI definitions actually contradict XForms 1.0
Appendix F _DIRECTLY_.

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

   Then shouldn't we have pseudo-classes specifically for editors

>>   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@w3.org.

   Done.

>>Editors can apply their own styling for editing
> 
> Amaya.

   Huh?

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

   Consider this proposed to www-style, then.

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

   Only because of the context. For instance, obviously you can change
whether or not an <input> element is read-only in an editor. So if you
consider elements in an editor DOM to be "read-write", then <input
readonly> is selected by :read-write, even though it's semantically
read-only.

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

   In that case, :active wasn't a very good example of a pseudo-class
having its definition expanded to include all elements.

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

   Actually, in the HTML 4.01 spec, they have properties that are
mutually exclusive.

For |disabled|:
| * Disabled controls do not receive focus.
| * Disabled controls are skipped in tabbing navigation.
| * Disabled controls cannot be successful.

For |readonly|:
| * Read-only elements receive focus but cannot be modified by the user.
| * Read-only elements are included in tabbing navigation.
| * Read-only elements may be successful.

   You are correct that nothing explicitly states that they are mutually
exclusive. However, since they are defined as having semantics that are
conflicting, it suggests that at the very least they _should_ be
mutually exclusive, even if it doesn't forbid it outright.

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

   I am unable to find any features by which a user can edit the
contents of an <iframe> or any other element in IE when
|contenteditable| is not set to true.

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

   Are you sure? If :enabled and :disabled where so poorly defined in
CSS3-UI, I suspect we'd be having the same conversation. While the two
pseudo-classes could, in theory, apply to any element, but look how the
Selectors spec defines it:

| It should be noted that most elements will be neither enabled nor
| disabled. An element is enabled if the user can either activate it or
| transfer the focus to it. An element is disabled if it could be
| enabled, but the user cannot presently activate it or transfer focus
| to it.

   It doesn't specifically state that the elements have to be controls,
but one can easily tell that it only applies to elements with the
semantics of having enabled and disabled states.

   (Personally, I could live with :read-only and :read-write not
specifically being for form controls if they were defined in a similar
way as :enabled and :disabled.)

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

   Actually, I don't feel that's necessary. It's fairly clear what they
mean. Similarly, I don't think people would have a conceptual problem
with :read-only and :read-write as only applying to elements with
read-only/read-write semantics.

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

   No, but :editable is.

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

   I was referring to editing via |contenteditable|.

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

   Well, :form-control(widget) would allow you to style elements
differently based on whether the widget is supported. For instance, if
you use <input type="widget"> in your markup, and a browser doesn't
support it, you can define different styles for each scenario:

| input { /* Fallback styling */ }
| input:form-control(widget) { /* Styling specific to the widget */ }

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

   Hmm. I'll go along with that for now.

Received on Monday, 1 August 2005 00:17:43 UTC