- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Sun, 28 Aug 2005 13:50:29 -0400
Ian Hickson wrote: > On Sun, 31 Jul 2005, Matthew Raymond wrote: >>>>>Note that the text above was reviewed by the editor of the CSS3 UI >>>>>spec and given the all-clear. >>>> >>>>Of course he gave it the all clear. He's the one who wrote the >>>>disputed portion of the spec in the first place. >>> >>>Which disupted section of which spec? >> >>For CSS: >> http://www.w3.org/TR/2004/CR-css3-ui-20040511/#pseudo-ro-rw >> >>For WF2: >> http://whatwg.org/specs/web-forms/current-work/#relation Clarification: I meant that the author of CSS3-UI would obviously approve of language in WF2 that reinforces CSS3-UI, since he wrote the section that the material reinforces. > CSS isn't being disputed here (or if it is, it's the wrong mailing list). No, at this point it's being disputed in www-style. I've made extensive and detailed arguments there. > And the editor of the CSS3 UI spec didn't write the disputed part of the > WF2 spec; I wrote the latter. Which is why I want you to change it. >>>If the disputed section is the one I wrote (i.e. the one quoted above) >>>then no, he didn't; I wrote it. >> >>I never said he wrote it. > > You said "Of course he gave it the all clear. He's the one who wrote the > disputed portion of the spec in the first place." -- if you didn't mean > that then I've no idea what you meant, sorry. See the above clarification. >>You altered WF2 to make it repeat aspects of what he wrote (CSS3-UI). >>Obviously the person who wrote the sections of the CSS3-UI spec you're >>drawing from is going to agree with corrections that reinforce his own >>content. > > 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 it clearly in dispute. >>What was wrong with the revision I suggested?... >> >>| 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. > > Well, the second part doesn't say anything (it's redundant with CSS3 UI). 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. So, even if we specificly endorse :read-only and :read-write as they are defined in CSS3-UI, the text should read as follows: | :read-only | | Matches form control elements that have the readonly or disabled | attributes set, and to which the readonly attribute applies (thus | enabled radio buttons will never match this, regardless of the | value of the attribute), as well as elements defined by this | specification that are not form controls (namely form, label, | datalist, option, optgroup, and fieldset elements). | | :read-write | | Matches form control elements that do not have the readonly or | disabled attributes set (including password fields, although | technically they should be called "writeonly"). The section that currently says the following... | A disabled field can still match this pseudo-class; the states are | orthogonal. ...is wrong. Anything that is not "user-alterable" under CSS3-UI is read-only. With regard to the entire section, note that :enabled, :disabled, :checked and :indeterminate are defined by CSS3 Selectors, not CSS3-UI. The latter spec only defines some details of the :active pseudo-class. (Then again, you should know that, because your name is on the CSS3 Selectors spec.) As to a certain level of redundancy, I don't see how that can be avoided. CSS3-UI is clear in its meaning, in both its existing for and with my proposed changes on www-style. If my proposed changes to CSS3-UI are accepted, though, I suggest the following changes to the WF2 spec: | :read-only | | Matches elements that have the readonly attribute set. | | :read-write | | Matches elements that do not have the readonly attribute set, but | support the readonly attribute. > 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. >>>>In a scenario with script, when would you disable the <input readonly> >>>>element specifically and in markup rather than disabling a parent >>>><fieldset>? >>> >>>There might not be a parent <fieldset>. In any case, what's the >>>difference? >> >>So, when am I going to need to disable a single read-only control >>independently of other controls? Not seeing a use case here. > > 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? 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.)
Received on Sunday, 28 August 2005 10:50:29 UTC