- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 28 Apr 2011 19:09:43 +0000 (UTC)
On Tue, 7 Dec 2010, Jonas Sicking wrote: > On Tue, Dec 7, 2010 at 5:08 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Sun, 12 Sep 2010, Mounir Lamouri wrote: > >> > >> The current state of the specifications do not mention fieldset elements > >> for the :enabled and :disabled pseudo-classes but fieldset can be > >> disabled so I guess it might be convenient to have these pseudo-classes > >> applied to them. > >> > >> Opera applies :disabled and :enabled to fieldset elements and Mozilla > >> might do the same. > > > > It's not really the <fieldset> that is enabled/disabled, it's the > > controls within it. Put it this way: if we dropped support for disabled="" > > from the spec, I think one would still argue that <input> is :enabled > > Really? Why then isn't a <div> ever :enabled? Because it doesn't do anything, same as <fieldset>. (I guess it could be argued that contenteditable might make it enabled; we could have elements with contenteditable match :enabled if you like. They'd similarly match :disabled if we ever added something to disabled a contenteditable editing host.) > :enabled IMHO only makes sense on elements which can be disabled, which > is why div:enabled never matches anything. So if we removed disabled="" > from <input> I don't think input:enabled would match anything. The CSS spec says: The :enabled pseudo-class represents user interface elements that are in an enabled state; such elements have a corresponding disabled state. (It leaves those terms up to the host language.) I don't think a <div> is a "user interface element" (modulo when it has a contenteditable attribute). I do think an <input> is a user interface element. On the other hand, I suppose you could argue that the selectors spec implies that anything that is :enabled can be disabled, such that if <input> didn't have a disabled="" attribute we would never have it match :enabled either. That seems rather odd to me though. > > I don't think one would argue that <fieldset> is :enabled. Case in > > point, nobody argued that <fieldset> should match :enabled before we > > added the disabled="" attribute to it. > > IMHO because it couldn't be disabled before then. Another question is, > on what basis are you saying that just the controls inside the fieldset > are disabled, and not also the fieldset itself? The fieldset isn't a "user interface element". It's just part of the structure, like a <div>. > I think a more important question is if it would be useful to have > fieldset:disabled match. I.e. would anyone want to use that selector in > CSS or querySelector? I have many times seen user interfaces like: > > [X] Some preference > [ ] Sub-preference 1 > [ ] Sub-preference 2 > > Where the sub-preferences are grayed out if the top-level preference is. > And it's generally not just the sub-pref checkboxes that are grayed out, > but also the labels next to them. This could be accomplished using a > selector like: > > fieldset:disabled .controlLabel { > color: gray; > } Yeah, that's a fair point. Done. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 28 April 2011 12:09:43 UTC