- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Sun, 09 Nov 2008 23:50:10 -0800
- 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:
input:disabled,
textarea:disabled
{
}
--
Andrew Fedoniouk.
http://terrainformatica.com
Received on Monday, 10 November 2008 07:50:45 UTC