- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Mon, 29 Aug 2005 18:04:48 -0400
Ian Hickson wrote: > On Sun, 28 Aug 2005, Matthew Raymond wrote: >>>Ok, I'm glad you agree that it reinforces CSS3 UI and doesn't conflict >>>with it. That is what was intended. We can't really do anything else, >>>since CSS3 UI isn't one of the specs WHATWG is doing. >> >>Sure you can. You can change the language is a way that doesn't make WF2 >>depend so completely on a portion of the specification that is clearly >>in dispute. > > Should the CSS3 UI spec change, WF2 would change with it. However, I don't > see how we can make a clarification of intent for another specification > not depend on that specification. Yeah, after looking at the section in question, it's of limited use if it can't define how HTML interacts with CSS3-UI specifically... >>>>| Matches form control elements that have the readonly attribute set, >>>>| and to which the readonly attribute applies (thus radio buttons will >>>>| never match this, regardless of the value of the attribute), as well >>>>| as other elements defined by this specification that are defined as >>>>| read-only under the CSS3 Basic User Interface Module. >> >>Actually, looking at the first part (which is pretty much identical to >>what you have), it's in conflict with CSS3-UI, because <input >>type="radio" disabled> technically matches the CSS3-UI definition >>:read-only selector. > > I discussed this with some CSSWG members, and our conclusion was that > :read-only and :disabled being orthogonal was the most useful, which is > why I wrote the WF2 spec the way I did. I'll bring that up in www-style as a reason to change the spec, then. ;) >>>The whole point of the section is to say which elements defined by WF2 >>>match the definition of CSS3 UI. >> >>CSS3-UI is quite clear about that. Anything, and I mean ANYTHING, that >>is not "user-alterable" is :read-only under CSS3-UI. Even disabled >><input> controls are user-alterable. That's why any implication that a >>disabled radio button is not :read-only would be a contradiction of the >>CSS3-UI specification. > > Since that was apparently not the intent of the specification, it isn't as > clear as we might have hoped! :-) Hence the much more specific definitions > here. (What does "user alterable" mean? With the Mozilla DOM Inspector I > can "alter" anything in any DOM.) Well, what's worse is that "user alterable" is a subset of the definition of "read-only" as it is defined in HTML 4.01. A read-only element in HTML is submittable and focusable unless it is also disabled. The :read-only pseudo-class as defined in CSS3-UI, which is defined in terms of user alterability, would include content that is not submittable, and therefore apply to elements not considered read-only in HTML 4.01. >>>One possibility would be viewing a database view where the user has >>>rights to edit a field on some records but not others (e.g. allowed to >>>edit the customer's start date but only if the customer hasn't started >>>yet). As you flip through records, the field becomes read-only or not. >>>It's not disabled, because the data is still relevant, even though it >>>can't be edited. (Indeed in XForms "enabled" is spelt "relevant", >>>IIRC.) >> >>Are you suggesting we expand <fieldset> to include |disabled| and >>|readonly| properties that are inherited by child controls? > > Disabled is already done. "readonly" I'm less sure about, but I have added > it to the list of things to consider for WF3. It's possible that a group of fields could be read-only, especially if you don't have security access to change them, so this does need to be considered. Very true. >>That may not be such a bad idea. (BTW, I've already reconsidered my >>position on whether |disabled| and |readonly| are mutually exclusive. >>They are not.) > > I think they are. :-) If they were not, why would they be independent > attributes? Even in XForms the two concepts are separated. I think you're confusing "mutually exclusive" with "orthogonal".
Received on Monday, 29 August 2005 15:04:48 UTC