Re: [CSS3] UI element states pseudo-classes

Thanks, Laurens,

| 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.

This is a good and symptomatic example.
See, even in CSS spec. itself there are no one place where you can define 
all selectors.
http://www.w3.org/TR/2001/CR-css3-selectors-20011113/ defines one set with 
:checked (sic!)
and UI module defines one more set (specific for XForms).

I don't really understand the intention to put "state switchers" into 
specific pseudo-classes
It is exactly the same if we would define all possible HTML/XML attributes 
with their own pseudoclasses
like TD:rowspan(2) versus TD[rowspan="2"]

These state pseudos are ruining the whole modularization idea. 
Modularization of the spec and modularization of the implementations.

To be short: we have a strange syntax mix of entities which describe 
structural pseudoclasses and pseudoelements like :first-child
and ui-state-pseudo-classes which I believe are not classes in common sense. 
ui-states logicaly are more close to attributes then to
anything else.

CSS declartion input[@disabled] more clerly underlines the fact the state 
value should be requested from
the element.

Again ui-state-pseudo-classes and structural pseudoclasses belongs to 
different namespaces and it is better to express this
more clearly for the sake of modularization.

Andrew Fedoniouk.
http://terrainformatica.com














|
| 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 20:20:17 UTC