Re: [CSS3] UI element states pseudo-classes

Andrew Fedoniouk wrote:
> Justin Wood:
> | CSS cant dictate "when" that is behavioral for scripting,
> | scratch :changed, and with :input-error how would you
> | determine what that applies to exactly, or where it would
> | be used, what properties apply to it, etc...
> 
> Agreed, but I cannot see any difference in principle between :changed
> and let's say :visited. The same change of state as a result of user 
> interaction.

CSS3 does define the :valid and :invalid attributes:

http://www.w3.org/TR/2004/CR-css3-ui-20040511/#pseudo-validity

When to match such pseudo-classes is of course up to the user agent. But 
that is basically valid for all CSS selectors.


> Anyway my message was about different thing,
> :changed (all), :current-item (select),  :selected-item (select), 
> popup-shown (menu), etc. -
> there a lot of state flags in fact which need special indication.
> So why particular input elements are honored by having special 
> pseudo-classes and others do not?

As you can see in the CSS3 UI module (a Candidate Recommendation) I 
linked to above, there are many more UI pseudo-selectors than just the 
:hover, :active, :focus, :enabled, :disabled, :checked and 
:indeterminate which are defined in CSS3 Selectors. So no particular 
input elements are honored by special treatment. I think that answers 
your question?


> My point is simple: instead of multiple pseudo-classes (whose name legion 
> potentially) we should create one "state" pseudoclass which
> will use just different values. Potentially different CSS applications (not 
> only HTML) will use their own sets of values.
> 
> Something like element[@statename]  where @statename is a name of the state 
> specific to the element. I guess this would be enough.

I'd say :enabled, :disabled, :checked, :indeterminate are pretty 
generic, and can apply to more than just HTML radiobuttons and 
checkboxes. You're talking about introducing another token '@' to 
designate the concept of 'state', but er, isn't that what : is for?? 
(well, it actually denotes automatic classes, but you can even think of 
selectors like :first-child as being part of 'state', if you for example 
consider sortable tables).

When a certain application needs other selectors aside from these, it 
can always define its own extensions using :-app-something...


> | What if there is an admin form for example which shows a
> | sample User Preferences page, and the admin is to set
> | defaults...  a default of "disabled" for a tri-state
> | checkbox would be much more elequantly shown via a
> | checkbox than a select, I am not saying your situation
> | shows no merit, but in a case to remove a CR Pseudo, you
> | have to consider all cases ;-)
> 
> See, checkbox by definition has no third state. Checked/unchecked. Trigger.
> In Windows checkbox is in 'undefined' state only between mouse-down and and 
> mouse-up
> (space-down / space-up). The reason why is that is unknown to me.
> So I don't understand why this short moment of time got its own pseudo.

That's not true. In Windows at least, checkboxes can have three states, 
unchecked, checked, and indeterminate (visibly, filled with a green 
square in XP theme). Indeterminate usually refers to the current 
situation or the default. Example where this is used: if you select 
multiple files, some of which hidden, the box for the 'hidden' attribute 
is in indeterminate state. Checking it will add the hidden attribute to 
all, unchecking it will remove it, and having it in indeterminate state 
will leave them as they are. I can think of numerous other applications 
where this would be very useful.

Note that HTML doesn't have indeterminate checkboxes (as far as I know, 
maybe it can be done through the DOM), nor does Web Forms 2.0, currently 
(afaik).


> "Components of a radio-group initialized with no pre-selected choice are an 
> example of :indeterminate state. "
> The group of radios has already visual indication of no-value case. Clear 
> and understandable. And what else special should be drawn here?

By the same reasoning, why would you need :checked, as the UI already 
clearly renders a visible state for checked. Thing is, currently the UI 
renders :indeterminate on radio buttons as unchecked, however what if I 
wanted them to render with a bright red background, yelling 'YOU HAVE 
FORGOTTEN TO MAKE A CHOICE HERE' at me? :) Even if the browser doesn't 
do that, I could do that for my own site, or more generically in a 
custom stylesheet which applies to all websites I visit.


> | It doesn't, actually. Apart from the issue Laurens pointed out, :checked
> | applies to <option> elements in HTML, say....
> 
> Why not option[selected]?
> why selected state needs to be named as ":checked"?

Again, the source does not change when you select different options. By 
using option[selected] you will only target the option which has been 
selected by default per the source (you could do something like 
option[selected]:after{content:' (default)';color:red;}, though of 
course there's :default as well which works even if the source doesn't 
indicate a specific default).

Why it is called 'checked' instead of 'selected', checked indicates a 
broader concept than just checkboxes alone, and there is no need to 
invent a new pseudo-class for every tag it can be applied to. The naming 
isn't the most generic possible, I agree, but this is what we have now. 
Besides, the term 'selected' otoh (which looks like best candidate at 
first sight) is perhaps a bit too generic and could apply to multiple 
things (think ::selection).

p.s. I'm actually not sure if :checked matches selected elements in a 
select box, but I guess it does :).


~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san!!

Received on Sunday, 9 January 2005 17:22:09 UTC