Re: Selectors Tests

Boris Zbarsky wrote:
>
> Andrew Fedoniouk wrote:
>>>>> This can't happen.
>>>>
>>>> This needs to be specified then.
>>>
>>> It is.
>>
>> Where it is?
>
> In the new text fantasai just put in, but even the old text said:
>
>   An element is enabled if the user can either activate it or transfer
>   the focus to it. An element is disabled if it could be enabled, but
>   the user cannot presently activate it or transfer focus to it.
>
> Which sounds pretty exclusive to me.
This phrase tells me that :enabled and :disabled "can be true at the 
same time.
Otherwise my parser is failed on "element is disabled if it could be 
enabled".
The light bulb is off if it could be on, eh?
>
>> Beg my pardon but this:
>>
>>   input:not(:enabled), textarea:not(:enabled), select:not(:enabled) {}
>>
>> is generally nonsense. Because of distinctly different display model of
>> these elements you will end up with:
>
> It's not nonsense if you're doing something other than just color 
> styling of the control itself or some such.
And what can you do else on input elements by CSS?
Are you speaking about jQuery kind of things? If "yes" then jQuery has 
exactly :input selector:
http://docs.jquery.com/Selectors/input
>
>> I suspect that your mental modal of :enabled/:disabled pair is better 
>> definable as:
>>
>>    :input/:disabled
>
> That's just a matter of naming; it has the same behavior.
Precise naming is a Good Thing as they say.

:enabled for developers out here means that it should also span on <a 
href> and other focusable
elements e.g. <div style="overflow:scroll">.

:input defines this entity significantly more precise, isn't it?

:input could be :disabled and :not(:disabled). That is simple and human 
comprehensible.

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Friday, 7 November 2008 21:03:08 UTC