RE: Selectors Tests

One could argue that it is up to the document language styled by CSS to define the UI and markup semantics of these states. The only thing CSS might then state is that an element matching :enabled should not match :disabled and vice-versa.

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Andrew Fedoniouk
Sent: Wednesday, November 05, 2008 5:25 PM
To: fantasai
Cc: Boris Zbarsky; Lachlan Hunt; www-style
Subject: Re: Selectors Tests


fantasai wrote:
>
> Boris Zbarsky wrote:
>>
>> fantasai wrote:
>>> Well, the Selectors spec is fixable. Daniel and I are actively
>>> editing it now. However I don't think I agree that :enabled/:disabled
>>> should not apply to type="hidden". The distinction does exist for
>>> hidden controls as well, does it not?
>>
>> Indeed.  Disabled hidden inputs do not submit.
>>
>> If that's the sort of distinction we want for :enabled/:disabled,
>> that's also fine by me; the spec text just needs to be adjusted to
>> handle that, then.
>
> Goals for rewording:
>   - Allow HTML5 to easily define what elements are :enabled or :disabled
>   - Make sure definition of :enabled/:disabled depends not on CSS but on
>     the semantics of the markup and object model.
>   - Make sure <input style="display: none"> matches :enabled
>   - Make sure <a href=""> does not match :enabled
>
> Here's a proposal:
> http://dev.w3.org/csswg/selectors3/#UIstates

>
> Change
>  # The :enabled pseudo-class allows authors to customize the look of
>  # user interface elements that are enabled — which the user can
>  # select or activate in some fashion (e.g. clicking on a button
>  # with a mouse)
> to
>  | The :enabled pseudo-class represents user interface elements that
>  | are in an enabled state — e.g. elements that the user can alter or
>  | activate in some fashion, but that could be disabled in a different
>  | context.
>
> Change
>  # Similar to :enabled, :disabled allows the author to specify
>  # precisely how a disabled or inactive user interface element should
>  # look.
> to
>  | The :disabled pseudo-class represents user interface elements
>  | that are in a disabled state — e.g. elements that could be enabled
>  | but cannot currently be altered or activated by the user due to
>  | its semantics.
>
> Remove
>  | 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.
>
> Comments? Suggestions for improvement?
>
>
It is not clear what :enabled means exactly.

:disabled is a state of focusable element - the DOM element that has
some active behavior (controller) assigned to it.
That element could be :disabled, otherwise it will accept focus.
For example <input type=text> is focusable element as its behavior knows
about and will handle setFocus() request.
Passive elements like <p> and <div> are normally non-focusable. To make
such elements focusable we  someone should
define  <p tabindex=1 > for example.

So are my questions:
1)  is :enabled is a sort of :focusable element?
2) Is any passive DOM element like <p> has :disabled state flag by
default? Or it has neither :disabled nor :enabled?
3) Usually <p tabindex=1 > is a focusable element so presumably it
should get :enabled (or better :focusable) state flag
    and <p tabindex="-1" > should have :disabled flag. Is this how it
supposed to work?

I believe (and propose) that CSS should have just :focusable
pseudo-class. Thus all passive elements will have not this flag set
and active input elements (including those that have @tabindex >= 0
defined) will get the :focusable state. Active input elements
that are disabled by e.g. using @disabled (and so will not accept focus)
are not :focusable.

Otherwise we need to specify clearly of what :disabled, :enabled,
:not(:disabled) and :not(:enabled) mean.

--
Andrew Fedoniouk.

http://terrainformatica.com

Received on Thursday, 6 November 2008 03:50:38 UTC