- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Wed, 10 Aug 2005 23:34:50 -0400
- To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- CC: www-style@w3.org
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" content can. 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.
Received on Thursday, 11 August 2005 03:35:02 UTC