Re: [CSS3] UI element states pseudo-classes

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.

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?

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.
How XUL handles this, btw?

Something like element[@statename]  where @statename is a name of the state 
specific to the element. I guess this would be enough.
We should declare list of well know states and left other values to 
implementation details.

| This is also (near-irrelevant) potentially the same amount
| of mess as your repeatedly mentioned, and repeatedly
| proposed '%%' value argument (which in _theory_ I,
| personally,  support; though in description I do not)

Agreed, mea culpa with %%. I did attempt actually to define them "formally"
http://www.terrainformatica.com/htmlayout/fspu.whtm but it is just a 
modified copy from
MultiLength units description from HTML spec. In fact this is far from 
ideal. I
am not so strong in writing formal definitions in English. :( Care to help 
anyone?
%% units rocks! :)

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

In fact it make sence *for all* input elements to have an "undefined" state 
or "no-value-given" state (or "changed").
It does really makes sense to highlight e.g. address field if it is empty on 
the form.
But this is another story as far I understand.

[CSS3] says only about checkboxes and radios:
"The :indeterminate pseudo-class
Radio and checkbox elements can be toggled by the user, but are sometimes in 
an indeterminate state, neither checked nor unchecked. This can be due to an 
element attribute, or DOM manipulation. The :indeterminate pseudo-class 
applies to such elements. While the :indeterminate pseudo-class is dynamic 
in nature, and is altered by user action, since it can also be based on the 
presence of an element attribute, it applies to all media"
[1]
"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?

Andrew Fedoniouk.
http://terrainformatica.com

[1] http://www.w3.org/TR/2001/CR-css3-selectors-20011113/#UIstates

Original Message from: "Justin Wood" <116057@bacon.qcc.mass.edu>
|
| On Sat, 8 Jan 2005 18:42:19 -0800
|  "Andrew Fedoniouk" <news@terrainformatica.com> wrote:
| >
| >There are too many "interesting" states of input elements
| >which make sense
| >to expose into CSS. For example :changed or :input-error
| >would be pretty
| >useful, right?
|
| 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...
|
| >But I think if we will go this way (declare each state
| >bit as a separate
| >class) we will end up with the mess.
| >And in general: we should avoid declaration of
| >pseudo-classes which can be
| >applied to only some particular type of
| >elements as CSS is more or less universal language/tool.
|
| We may end up with a "mess" if it is not defined properly
| by CSS in general, and the languages themselves will in
| the future define which CSS Pseudo's apply to them, for
| example an XML element <myCustomInputField> wouldnt have a
| clue what CSS Pseudo's apply to it, unless the language
| explicitly says which ones, so that when it comes to be
| the case, they say what it is and viola it will apply
| there... (CSS3 Selectors, from my understanding defined
| how they may apply to HTML for example, since that is a
| language pre-dating this specification).
|
| This is also (near-irrelevant) potentially the same amount
| of mess as your repeatedly mentioned, and repeatedly
| proposed '%%' value argument (which in _theory_ I,
| personally,  support; though in description I do not)
|
|
| >....
| >
| >Group of radio boxes can live without ":indeterminate"
| >state. E.g. <select>
| >lives happily without it and it also has multiple items
| >to select from.
| >Tristate checkboxes are also something which is hard to
| >imagine visually. It
| >is better to use <select> from three options to present
| >your intention
| >clearly.
| >
|
| 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 ;-)
|
| ~Justin Wood (Callek on moznet IRC)
|

Received on Sunday, 9 January 2005 07:49:10 UTC