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

> > >    Then shouldn't we have pseudo-classes specifically for editors
> > 
> > Possibly.  As things stand in CSS3-UI, those are :read-only and
> :read-write. 
> 
>  This seems like an obvious distinction that must be made. When I think of
> using :read-only and :read-write, it's for a typical HTML page where the
> only editable things are form controls, etc. This is largely where existing
> CSS applies and extending to encompass contentEditable seems unwieldy.
>  
>  This discussion has proven that both of these pseudo-classes lose meaning
> when applied to editors, so I think it makes sense to create a separate
> specification (along with its own pseudo-classes) for CSS in editors.

This is a fun discussion and all but doesn't it just reek a little bit
of pointlessness. And I'm not talking about read-write, but the desire
to apply non-layout properties to form elements. The application isn't
saying where to put the element anymore, it's now saying what to color
it, what keyboard access to give it and so on. This breaks about an
ungodly number of accessibility guidelines and a lot of design
guidelines that say, don't do things differently than the rest of the
operating system, but here we are, giving web designers the capability
to again abuse the content viewers, the users as it where, of these
web pages.

I also find it all a bit silly when we're talking about this since
XForms abstracts just a bit the exact widgets used when it encounters
the various XForm model elements.

What I guess I'm getting at is that CSS-UI is a really bad idea that
shouldn't have even been suggested much less spec'd up. Don't mess
with the OS's ability to interact with the user. Each OS is already
tailored to it's user base and it doesn't need CSS to give the power
to authors and not the users.

-- 

Orion Adrian

Received on Tuesday, 2 August 2005 13:35:34 UTC