Matthew Raymond wrote:
"WF2" stands for "Web Forms 2". Why would it even define :read-only
for non-forms elements?
It shouldn't. That was the point of my original mail, which you seem to have
missed. The current text is ambiguous -- either it's not talking about non-form
elements at all, or it's defining :read-only to NOT ever apply to them. I would
like the text clarified to the first interpretation, at which point for non-form
elements implementors can do whatever CSS3 UI or other relevant spec says
without worrying about it conflicting with WF2.
Outside of form controls, the only time an element isn't read-only is
when it's within an element that has |contentEditable| set
Or when the whole document is in an editor, as opposed to a browser.
So :read-only is never useful in the context of HTML 4.01 + Web Forms 2.0.
Again, my concern is with WF2 specifying things that affect behavior outside of
its context.
I agree that how :read-only behaves with respect to elements in a
|contenteditable| container needs to be defines. However, it doesn't
need to be defined in WF2.
Precisely my point. The current WF2 phrasing defines it to not match, if read
literally.
Your argument doesn't make any sense. XForms defines pseudo-classes
for use with XForms elements, which are by definition all form elements.
Why expand pseudo-classes obviously intended for form elements to
non-form elements?
Because they make sense and are useful for more than just form elements? The
same reason that :hover and :active, originally destined for just links, were
greatly expanded.
Then it really doesn't matter what CSS3-UI says?
It matters when it explicitly says something. It also matters to suggest a
course of action in cases when the document language doesn't explicitly address
styling.
In that case, we can
just leave the spec unchanged, as it clearly defines what :read-only
applies to, and doesn't prevent us from expanding how we can use it later.
Actually, it does prevent us from expanding. That would be the problem.
The width of the checkbox is 100 pixels. You should have used the
:disabled pseudo-class from CSS3-UI:
I realize :disabled would match there. The question is why :read-only should
not match -- the checkbox is readonly in this case; the user can't change its value.
No, the checkbox is disabled. Read-only controls are typically
inaccessible for the life of the application.
That's not the case in a lot of applications I've seen where controls are
actually switched from read-only to read-write...
None of which addresses my question. We agree that the checkbox should match
:disabled. Why should it not also match :read-only? It's not like the two are
ever claimed to be mutually exclusive.
Clearly, if you're looking at markup and want to know what :read-only
selects, and you see an element of the form <[element] readonly>, you'd
expect that to be selected. By contrast, you don't think of a simple
paragraph in terms of read-write access
A lot of people sure do. Ever tried using Amaya? Or any other browser that
supports editing (most of them at this point, though not to the extent that
Amaya does)? If you meant to say that _you_ don't think in those terms, then
I'll accept that on faith. ;)
so you may not think of that being selected by :read-only
So the problem where people were using *:hover and assuming only links would
match?
I think this can be prevented if the very first time :read-only is shipped in
browsers it already has the final behavior. Given that we're attempting to
implement :read-only right now, I would like to pin this behavior down for
precisely that reason -- so that we don't ship something in Gecko 1.8 and then
change it majorly a year later in 1.9.
I don't see ANY usefulness to having :read-only apply to non-control
elements.
One example: you can select editable parts of a document for special styling so
the user can see which parts he can edit.
It would mean that you can't use :read-only for
language-independent styling of read-only form controls.
That's true. Perhaps we need a :form-control pseudo-class to address this
issue? Not something XForms would have introduced, since it's all form
controls, but in the context of HTML5 and CSS3 UI it might be useful.
But "8.2. Relation to the CSS3 User Interface module" specifically
defines that, and you even state to the effect that it /should/ be
defined there, so what's your point? Besides, I was also reacting to the
fact that your example didn't use "readonly".
Precisely. I see no reason to tie :read-only to the "readonly" attribute, which
you seem to want to do very badly.
-Boris
