Matthew Raymond wrote:
I believe that viewpoint is
correct. From that viewpoint, :read-write and :read-only actually
become "subclasses" of :enabled.
Daniel Glazman wrote:
I thought I demonstrated quite clearly on my blog that the markup is
not sufficient to infer anything global about the read-only or
read-write state because the context of the markup instance also
matters, but apparently I was wrong to think that demo was enough.
I think the problem here is that there's a fundamental disconnect
between what read-only and read-write mean in CSS and what they mean in
HTML/XForms. For HTML (and I believe also for XForms, but it's hard to
tell without reading the spec cover-to-cover), the term "readonly"
refers to content that can be submitted but can't be changed by the
user. Control content can only be prevented from being submitted by
disabling the control.
If you look at XForms, it has "readonly" and "readwrite" events that
occur when the "readonly" property of a control changes. The original
XForms versions of the :read-only and :read-write pseudo-classes have
their names clearly mapped to these events.
From these two languages, we get that "read-only" and "read-write"
apply only in the following cases:
1) You have an element containing data that can be submitted to a server
using a submission process defined by the markup language.
2) The element can go in and out of a language-defined "read-only" state.
3) "Read-only" content cannot be changes by the user, while "read-write"
The CSS3-UI definitions of "read-only" and "read-write" ignore all
but the last case. It allows text to be "read-only", in spite of the
fact that it would take significant amount of outright scripting to
submit the content of non-control elements to a server. It allows
elements with no defined "read-only" properties or attributes to match
:read-only or :read-write. In short, it completely ignores the context
in which "readonly" is used in existing W3C languages.
You have failed to give me ONE example that shows why this
fundamental conceptual disconnect between HTML/XForms and CSS is
necessary, nor have you convinced me that it is critical that styling
involving editing MUST be tied to the concept of read-only and
read-write. It seems to me that such styling is entirely practical using
completely separate pseudo-classes/media types/et cetera.
What do I know, I'm only working on my 4th wysiwyg stylesheet-based
markup editor after all...
I do not find your use of sarcasm and a logical fallacy involving
your level of experience very persuasive.
http://www.mozilla.org/products/firefox/ - Get Firefox!
http://www.mozilla.org/products/thunderbird/ - Reclaim Your Inbox!
Please avoid sending me Word or PowerPoint attachments.