W3C home > Mailing lists > Public > www-style@w3.org > November 2008

Re: Selectors Tests

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Sun, 09 Nov 2008 23:50:10 -0800
Message-ID: <4917E7B2.8010203@terrainformatica.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: www-style@w3.org

Boris Zbarsky wrote:
> Andrew Fedoniouk wrote:
>> And what about fieldset:disabled selector then?
> Shouldn't match, I would think.
>> And how would you specify say this:
>>   legend:disabled { color:gray; }
> What does it mean for a legend to be disabled?

Please see this screenshot: http://terrainformatica.com/w3/groups.png

>> Ideally :disabled flag shall be "on" for all elements that
>> have @disabled attribute by themselves or in one of their parents.
> That seems like a discussion for the HTML working group, not this one.

That is rather WebForms/XForms/etc. business than even HTML.

Seems like you also agree that :enabled/:disabled as other UI states are 
not a business of CSS. CSS shall define rule how these states
should be added in css by host domain.

For example there is a need in e.g. :current state flag that defines
current item in selects, menu, etc.

About "disabled" in general. In Windows for example there is a 
WS_DISABLED window state flag. If window is disabled then all its 
children are disabled too. And there is no such thing as WS_ENABLED.
You can only remove WS_DISABLED flag.

I do not think that windows behavior is directly applicable to the DOM
but this :disabled behavior is well known in other GUI systems too and
I think it makes sense to do not create not needed entities like :enabled.

If you need :input/:interactive then this is different story.

>>> In both cases :enabled basically means "can be submitted to the 
>>> server" at the moment.
>> But <option> and <optgroup> are not submittable.
> The former can have values sent to the server, though.

In any case they create exceptions from your rule.
So you will *always* use explicit selectors like:


Andrew Fedoniouk.

Received on Monday, 10 November 2008 07:50:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:41 UTC