[whatwg] :enabled and :disabled pseudo-classes should apply on fieldset elements

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'