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

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.

>    It stands to reason that a pseudo-class has some kind of higher
> meaning that applies to all languages, or else it's just a bunch
> namespace-specific CSS properties that happen to have the same name.

Of course.  Did I ever imply otherwise?

>    Also keep in mind your Amaya example. If XForms support was added to
> Amaya, and Amaya implements the CSS3-UI versions of :read-only and
> :read-write, then the CSS3-UI definitions actually contradict XForms 1.0
> Appendix F _DIRECTLY_.

Indeed, one could view it that way.

>    Then shouldn't we have pseudo-classes specifically for editors

Possibly.  As things stand in CSS3-UI, those are :read-only and :read-write.

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

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

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

>    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

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

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

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

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

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

-Boris

Received on Monday, 1 August 2005 03:21:47 UTC