Re: Selectors Tests

fantasai wrote:
>  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

The following wording seems to do all of the above:

“The |:enabled| pseudo‐class represents user interface elements that are 
in an enabled state; such elements have a corresponding disabled state.

Analogously, the |:disabled| pseudo‐class represents user interface 
elements that are in a disabled state; such elements have a 
corresponding enabled state.

What constitutes an enabled state, a disabled state, and applicable user 
interface elements is language‐dependent.

Note that CSS properties that might affect a user’s ability to interact 
with a given user interface element do not affect whether it matches 
|:enabled| or |:disabled|; e.g., the |display| and |visibility| 
properties have no effect on the enabled/disabled state of an element.”

The first two paragraphs fulfill goal 4; paragraph three fulfills goals 
1 and 2; and paragraph four fulfills goal 3.

fantasai wrote:
>  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?

With the exception of the removal at the end that removes some 
restrictions, I don’t think that these adjustments really change 
anything with regard to the mentioned goals. Additionally, the “due to 
its semantics” part at the end of the second change doesn’t make much 
sense IMO.

Received on Thursday, 6 November 2008 09:05:37 UTC