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

Boris Zbarsky wrote:
> Matthew Raymond wrote:
>>   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?
> 
> Editors may want to only allow editing of part of the document at a time too... 
> In which case it helps to style different parts of the document differently.

   When do people only edit part of a document in an HTML editor while
other parts are uneditable? Furthermore, would you even want editor
presentation to be identical to the presentation of
|contenteditable|-type editing? This is why I feel that if you want
editor-specific presentation, there should be specific pseudo-classes
for the context of a true HTML editor.

>>   Then shouldn't we have pseudo-classes specifically for editors
> 
> Possibly.  As things stand in CSS3-UI, those are :read-only and :read-write.

   Which apply differently solely based on what kind of program loads
the markup. (Editor or browser.) Do I need to load my web page in a
browser to see what it really looks like?

>>>>Editors can apply their own styling for editing
>>>
>>>Amaya.
>>
>>   Huh?
> 
> Are you suggesting that all styling of editable content in Amaya be done via UA 
> extensions to CSS in the UA stylesheet?  That's what it sounded like.

   Not necessarily UA extensions. I'm talking about a system that allows
CSS to specifically apply to editors, and not just pseudo-class that
apply differently based on the loading application.

   It would be nice to have an editing UA stylesheet, I suppose...

>>   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.
> 
> Semantics depend on the context, of course.  In an editor, an <input> is not so 
> much an <input>, even (for example, forms don't submit in an editor).

   In an editor, you want to see what the page is going to look like in
a browser. The only exception is when you're looking at a specific view
(which give you a good idea of how complex this could actually get).

>>>>  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.
> 
> Yet the DTD doesn't prevent both being set.  If both are set, UAs just have to 
> deal somehow, assuming that one or the other takes precedence for the items you 
> listed.  So HTML 4.01 is not a very complete specification.  Nothing new there....

   Well, that's a discussion for WHATWG, really. It does point out,
though, that languages should specify semantics such as enabled/disabled
and read-only/read-write. That doesn't mean that they should define the
nature of of CSS selectors, but if a selector is referencing a feature
of the language, it should be the language that defines the feature, not
CSS.

>>   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.
> 
> http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/designmode.asp

   If you have to use Jscript to access the feature, you're not talking
about a feature for users, you're talking about a feature for web
developers. It's really nothing more than a full page/frame version of
contentEditable.

>>   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.
> 
> Which is an issue, since any HTML element can be receive focus in a modern 
> browser if it just has a tabindex attribute set (not per HTML spec, but it's the 
> de-facto standard).  So you get the same problem, and it's been raised with the 
> CSS WG before.
> 
> Oh, and overflowing elements with overflow:anything-but-visible are focusable 
> (so you can tab to then and scroll around).

   That doesn't address the fact that neither |tabindex| nor "overflow"
can change whether or not you can activate an element. Therefore, the
above definition still holds, because it can be disabled if it can't be
focused _OR_ if it can't be activated.

>>   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.
> 
> Not quite; being focusable does not imply having enabled and disabled states...

   No, not entirely, but a |disabled| attribute does. In that case, does
not being editable imply a read-only state? If ability to focus doesn't
define "disabled", perhaps editability doesn't define "read-only".

>>> 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.
> 
> It's clear that :link only matches some links but not others?  Sorry, but it's 
> not....

   Oh, I see what you mean. One might think ":link:visited" is valid.

>>   No, but :editable is.
> 
> Sure.  If that existed, then I could see a much narrower definition for 
> :read-only and :read-write, given that we're unfortunately stuck with the 
> over-general names...

   If you understand that the pseudo-classes only apply to elements that
can be specifically set to a semantic read-only/read-write value in
markup, then it's not that over-general. There may be some mild
confusion, but the bottom line is that at some point the webmaster is
going to have to know how something is defined before they use it. For
instance, if someone doesn't connect "hover" with a mouseover event,
what are they going to think when seeing :hover in a stylesheet?


>>>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|.
> 
> As I said, I think it will become much more common in the near future.

   Which is why I'm pushing a separate pseudo-class :editable.

   I'm still not sure whether :editable should be for everything you can
edit (including controls), or just for |contenteditable|-type content.
If the former, it wouldn't be to hard to select the latter:

| :editable:not(:read-write) {
|   /* Styling for editable non-control content. */
| }

   Just having it apply to |contenteditable|-type content is easier from
a selector complexity standpoint...

| :editable { /* Styling for editable non-control content. */ }
|
| :read-write { /* Styling for editable control content. */ }
|
| :editable, :read-write {
|   /* Styling for all editable content. */
| }

...but it's mildly harder to understand conceptually due to the name.
(Note that by "control" I mean elements that are specifically defined as
having read-only/read-write states that can be set in markup, and not
necessarily form controls. It's just harder to write a one-line comment
to that effect.)

   Hmm. Looking at it now, I prefer the second example. It's a lot
cleaner, and there's really nothing useful about the overlap in the
first example.

Received on Tuesday, 2 August 2005 15:28:17 UTC