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

Boris Zbarsky wrote:
> Matthew Raymond wrote:
> 
>>   When do people only edit part of a document in an HTML editor while
>>other parts are uneditable?
> 
> Not much so far.  Again, I expect this to happen more in the near future.

   I don't. Then again, I suspect you're thinking .contentEditable and
.designMode rather than N|vu or MS Frontpage when I way "editor".

>>Furthermore, would you even want editor
>>presentation to be identical to the presentation of
>>|contenteditable|-type editing?
> 
> How are the two different?  I don't see a difference.

   Things like |contenteditable| may not allow true HTML editing, but
rather something more similar to a rich text box that converts to HTML
in the background. For instance, I don't expect to be able to set the
value of an element's |style| attribute to "-moz-border-radius: 5px".

   Nutshell: Editing page content != editing HTML.

>>>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
> 
> Except Amaya is also a browser.  You seem to be saying that there are editors 
> and there are browsers and the two should have different CSS apply.  The point I 
> keep trying to make is that there are programs that are both.

  But that's just it. If there's no distinction between the browser and
the editor, then everything's always editable, everything matches
:read-write, and the pseudo-classes :read-only and :read-write become
useless. Why would I, as a webmaster and stylesheet writer, want that?

>>   In an editor, you want to see what the page is going to look like in
>>a browser.
> 
> No, you want to see a view of a page that allows easy editing...  Most of the 
> time editors have a not-quite-what-it-would-render-as presentation, with a 
> "preview" option (which often actually uses a browser) for when the user really 
> wants to see what it would look like.

   That's not entirely the case. For instance, N|vu's normal view allows
selection of specific elements, but otherwise shows the page exactly as
it would look in the Gecko rendering engine. Views only need to differ
from the presentation of a browser in ways that are useful, and to avoid
confusion, the way the presentation differs needs to be consistent
between web pages for usability reasons. Editor-specific presentation
that can differ from page to page undermines usability in a true HTML
editor.

>>   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.
> 
> Of course you can trivially create a bookmarklet that does that and users can 
> easily add it to their bookmarks.

   Things to point out:

1) Support for bookmarklets, to my knowledge, is not a requirement for
CSS, HTML or Javascript standards compliance.

2) Some browser don't even support Javascript.

3) In some circumstances, bookmarklets and/or Javascript may be disabled
for security reasons.

4) Bookmarklets are not available "out of the box", and the typical user
doesn't even know what "Javascript" is.

   Stop trying to make a Javascript-accessible editing feature into a
true editor mode. Most users will NEVER edit the page unless it's
designed by the webmaster for them to do so. Besides, the best the
person can do is save the edited version to their hard drive, not the
web, so they'd have to have the web developer's cooperation in the first
place.

>>It's really nothing more than a full page/frame version of
>>contentEditable.
> 
> True, but the point remains that in that mode it's an editor.  Which is what we 
> were discussing.

   In many cases it may be the equivalent of an RTF editor that converts
to HTML in the back end. That's not an HTML editing mode for the
application.

   In fact, so far as I can tell, |contenteditable| in IE doesn't even
provide an interface to do anything beyond what you can do in WordPad.
(Perhaps not even what you can do in WordPad. I can't even figure out
how to insert an image or link without resorting to Javascript.)

>>   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.
> 
> Per the above definition, since any element could be focused (if its overflow 
> were set appropriately, which is something you can't tell when doing rule 
> matching), any element would have to match :enabled or :disabled (the former if 
> it really can be focused, the latter if it can't).

   I don't believe CSS defines "overflow" as affecting focus. Therefore,
 this is a rather innocent inconsistency that evolved from UA
implementation rather than the CSS and HTML specifications. One solution
to fix the definition would be to simply drop the language regarding
focus and to require that any element matching the selector must be able
to be toggled between semantic enabled and disabled states.

   Pseudo-classes :read-only and :read-write could be similarly defined:

| The purpose of the :read-write pseudo-class is to allow authors to
| customize the look of user interface elements which have a
| markup-explicit writable state - which the user change the contents of
| in some fashion (e.g. editing the contents of a text box). There is a
| need for such a pseudo-class because there is no way to
| programmatically specify the default appearance of say, a read-write
| <input> element without also specifying what it would look like when
| it was read-only.
|
| Similar to :read-write, :read-only allows the author to specify
| precisely how a read-only user interface element should look.
|
| It should be noted that most elements will be neither read-write nor
| read-only. Elements must be capable of having markup-explicit read-only
| or read-write states. Elements that have no means of selecting the
| state will not be selected by either pseudo-class.

Received on Tuesday, 2 August 2005 17:49:14 UTC