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

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.

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

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

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

>    Well, that's a discussion for WHATWG, really. It does point out,
> though, that languages should specify semantics such as enabled/disabled
> and read-only/read-write.

Yes, I think we all agree on that.  Which is why my original mail on the issue 
was to whatwg.

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

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

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

>> Not quite; being focusable does not imply having enabled and disabled states...
> 
>    No, not entirely, but a |disabled| attribute does.

The point is, per the current CSS definition either of the two is enough.

>    Oh, I see what you mean. One might think ":link:visited" is valid.

It's valid.  It just doesn't match anything.

-Boris

Received on Tuesday, 2 August 2005 15:45:59 UTC