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

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

I'm thinking both.

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

There is no substantive difference.  At least a few setups I've seen use 
contenteditable for "wysiwyg" editing and allow full source editing as well 
(basically via innerHTML).  How is that different from a standalone editor?

> For instance, I don't expect to be able to set the
> value of an element's |style| attribute to "-moz-border-radius: 5px".

Why not?  The designMode in Mozilla certainly allows this to be done 
programmatically, so someone using it in their webpage could easily have a 
button to do it to the currently focused element (and some probably do).

>    Nutshell: Editing page content != editing HTML.

On the contrary, there is no difference between the two.

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

Good question.  ;)  At the moment, this is just what CSS3 UI says.

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

Correct.  At the same time, all modern graphical browsers with anything 
resembling nontrivial usage support them.

> 2) Some browser don't even support Javascript.

Indeed.  And some don't support contentEditable.  Or CSS.  So?

> 3) In some circumstances, bookmarklets and/or Javascript may be disabled
> 4) Bookmarklets are not available "out of the box", and the typical user
> doesn't even know what "Javascript" is.

No, but the typical user does understand bookmarks and bookmarklets are 
presented as such.

>    Stop trying to make a Javascript-accessible editing feature into a
> true editor mode.

Why?  In Gecko they are pretty completely identical to "true editor mode", as it 
happens.  There's really no difference between the two that I can see, past your 
desire that there be a difference...

> designed by the webmaster for them to do so.

Sure.  So?

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

Perhaps you'd care to define what "HTML editing mode" means?

>    I don't believe CSS defines "overflow" as affecting focus.

It doesn't.  Existing user agents do it because that's the only reasonable way 
to make overflow accessible.

> Therefore, this is a rather innocent inconsistency that evolved from UA
> implementation rather than the CSS and HTML specifications.

Feel free to suggest a different accessibility approach here. None of the 
existing UA makers saw one.

> One solution to fix the definition would be to simply drop the language regarding
> focus

This has been proposed to the CSS WG.

> and to require that any element matching the selector must be able
> to be toggled between semantic enabled and disabled states.

So for example hyperlinks won't match :enabled.  Is that desirable?  (I have no 
opinion here, btw.)

-Boris

Received on Tuesday, 2 August 2005 18:15:07 UTC