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

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

   It's not impossible to implement an HTML editor via DHTML and
|contenteditable|. In fact, it wouldn't be impossible if you just used
DHTML and changed the underlying HTML using events. That doesn't mean
that all elements should be :read-write by virtue of the fact that they
can be modified via the DOM.

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

   Mozilla allows you to build entire applications, and I'm not talking
web apps either. They also have vendor-specific CSS that are intended to
be used more for Mozilla-based apps than web apps.

>>   Nutshell: Editing page content != editing HTML.
> 
> On the contrary, there is no difference between the two.

   There is if you don't have the underlying Javascript and UI to _MAKE_
them the same. I could port Mesa to DHTML, but that doesn't mean we
should have special CSS properties for OpenGL.

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

   Which is why we need to change it.

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

   So, because some browsers support execution of Javascript via a
bookmark, and some of those browsers support a proprietary primitive
editing mode, all elements should be considered either read-only or
read-write depending on how a single proprietary DOM property is set?

>>2) Some browser don't even support Javascript.
> 
> Indeed.  And some don't support contentEditable.  Or CSS.  So?

   So people WITH CSS but WITHOUT Javascript or contentEditable must
suffer at the hands of the overbroad definition of :read-only and
:read-write. And yes, the USERS suffer. Just as they can use
bookmarklets, they can also edit their user stylesheet. In fact, they
suffer more than web developers, because they no longer have an easy way
to style read-write and read-only controls.

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

   Bull-yotz! The typical user does NOT know how to save a link as a
bookmark without actually clicking on it first. It may be easy to do in
many browser, but it is not discoverable. They actually have to know
what bookmarklets are in order to use them.

   That said, you could make the argument that theses same users
wouldn't know CSS either. However, that doesn't mean you design your
website stylesheets around the minority who know about both
designMode/contentEditable and bookmarklets.

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

   Then what's the use case for N|vu?!?

>>designed by the webmaster for them to do so.
> 
> Sure.  So?

   So if they can design in HTML editing, they can design in a simple
|class| attribute and use that for styling. In fact, Web Apps 1.0
includes new DOM support that makes it easier to add classes to an element.

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

   It is desirable. I can think of neither a means of disabling
hyperlinks in HTML nor a reason for doing so. Therefore, how is
something enabled if it can never be disabled in the first place?
Allowing :enabled on anything that's activatible would just force us to
develop something like :form-control that much sooner, and it wouldn't
solve the problem for other entities that may have explicit
enabled/disabled states but are not controls.

Received on Thursday, 4 August 2005 14:01:23 UTC