Tue, 25 2005, Matthew Raymond wrote:

How does one style an element based on whether it has an association to
another element via an attribute? Specifically, how do I style a <label
with a |for| attribute?

Your two questions here seem separate. The second one is easy:

label[for]

The first is more interesting. A long time ago I suggested the //
combinator, a la:

label /for/ input { }

which would style an input element which had a label element pointing
at it with a "for" attribute. What you are asking seems to be the
opposite, which would be possible via:

label:matches(# /for/ input:focus) { }

for instance.

Both // and :matches() will probably never be added to Selectors, however,
since they both potentially can be very expensive to process.

We could probably get a simpler pseudo-class for this purpose:

label:friend(for, input:focus) { }

where :friend() is a pseudo-class that takes two arguments, one being
the name of an attribute to treat as an IDREF, and the second is a
selector to apply to the referenced element, with the pseudo-class
matching if the referenced element matches its selector.

This would take care of:

1) You want the label to have a dashed border when the associated
control is selected.

using the exact selector above, and:

2) You want non-associated labels do have a different style from
associated labels, even in cases where a <labelhas an incorrect |for|
attribute value.

using:

label:not(:friend(for, *)) { }

if we define :friend() as not matching if no element can be found that
matches the given attribute's ID.

3) You want all labels for a specific control or class of controls to be
styled in a specific way.

label:friend(for, [type=date]) { }

would select all labels pointing at elements with type="date".

This selector wouldn't be expensive to process, particularly (it wouldn't
be cheap, but it doesn't have the potential to run away scanning the
entire DM tree or anything, assuming IDs are cached).

Another (IM simpler) idea would be to just have label match the same
pseudo-classes that the control does, i.e., if a checkbox
is :checked, then the label can match :checked too. Same
for :disabled, :enabled, :indeterminate, and :focus. I don't see any
reason to introduce new selectors to solve this problem.

dave

25, 2005, at 12:54 PM, Ian Hickson wrote:

Tue, 25 2005, Matthew Raymond wrote:
>
>>
>How does one style an element based on whether it has an
>association to
>another element via an attribute? Specifically, how do I style a
><label>
>with a |for| attribute?
>>
>
Your two questions here seem separate. The second one is easy:

label[for]

The first is more interesting. A long time ago I suggested the //
combinator, a la:

label /for/ input { }

which would style an input element which had a label element
pointing
at it with a "for" attribute. What you are asking seems to be the
opposite, which would be possible via:

label:matches(# /for/ input:focus) { }

for instance.

Both // and :matches() will probably never be added to Selectors,
however,
since they both potentially can be very expensive to process.

We could probably get a simpler pseudo-class for this purpose:

label:friend(for, input:focus) { }

where :friend() is a pseudo-class that takes two arguments, one
being
the name of an attribute to treat as an IDREF, and the second is a
selector to apply to the referenced element, with the pseudo-class
matching if the referenced element matches its selector.

This would take care of:
>
>
>1) You want the label to have a dashed border when the associated
>control is selected.
>>
>
using the exact selector above, and:
>
>
>2) You want non-associated labels do have a different style from
>associated labels, even in cases where a <labelhas an incorrect |
>for|
>attribute value.
>>
>
using:

label:not(:friend(for, *)) { }

if we define :friend() as not matching if no element can be
found that
matches the given attribute's ID.
>
>
>
>3) You want all labels for a specific control or class of controls
>to be
>styled in a specific way.
>>
>
label:friend(for, [type=date]) { }

would select all labels pointing at elements with type="date".

This selector wouldn't be expensive to process, particularly (it
wouldn't
be cheap, but it doesn't have the potential to run away scanning the
entire DM tree or anything, assuming IDs are cached).

Tue, 25 2005, David Hyatt wrote:

Another (IM simpler) idea would be to just have label match the same
pseudo-classes that the control does, i.e., if a checkbox is :checked,
then the label can match :checked too. Same for :disabled, :enabled,
:indeterminate, and :focus. I don't see any reason to introduce new
selectors to solve this problem.

That doesn't address all of Matthew's requests, and would be specific to
<label>, not addressing similar problems with elements such as <map>, etc.
But I agree that it might make sense too.

10/25/05, ACJ <ego (AT) acjs (DOT) netwrote:
The CSS2 attribute selector [1] allows you to style labels with a for
attribute like this:

label[for] { border: thin dashed }

The first case you discribe (1) is not possible with current CSS, but
one could argue if it should. It sounds like behaviour to me (and should
therefor be handled by script).

Behavior is a ill-defined thing. What's your definition for it? is
it, "I know it when I see it."

>Behavior is a ill-defined thing. What's your definition for it? is
>it, "I know it when I see it."
>
A reaction to external or internal stimuli. (Like user input, or time
progression.)

:hover already borders on this, and I would personally like to see this
to be respected as the outer limit of how far behavioural conditions (by
the former definition) are specified in CSS.

Wouldn't :link also fall under this definition of behavior and for
that matter :unvisited?

The only thing here is the speed of the stimulus. :link triggers when
a link has been visited which is an external stimulus.

10/25/05, ACJ <ego (AT) acjs (DOT) netwrote:
Adrian wrote:

Behavior is a ill-defined thing. What's your definition for it? is
it, "I know it when I see it."


>>A reaction to external or internal stimuli. (Like user input, or time
>>progression.)
>>
>>:hover already borders on this, and I would personally like to see this
>>to be respected as the outer limit of how far behavioural conditions (by
>>the former definition) are specified in CSS.
>>
>>
>
>Wouldn't :link also fall under this definition of behavior and for
>that matter :unvisited?
>
>The only thing here is the speed of the stimulus. :link triggers when
>a link has been visited which is an external stimulus.
>
>
>
There are other selectors (of the pseudo-class and pseudo-element kind,
specifically) that border on this, too, yes.
:hover and ::selection are the most apparent ones to me.

To me, behavioral (and this is totally for the sake of existing CSS
implementations and specs) covers anything that can not be represented
by a static examination of the known properties the DM and/or system.

Tue, 25 2005, Boris Zbarsky wrote:

Ian Hickson wrote:
label:friend(for, [type=date]) { }

would select all labels pointing at elements with type="date".

This selector wouldn't be expensive to process, particularly (it wouldn't be
cheap, but it doesn't have the potential to run away scanning the entire DM
tree or anything, assuming IDs are cached).

This selector is not expensive to match on if you're already resolving
style for the element. It's expensive in the face of dynamic updates,
though. Whenever a node is removed from the DM or the ID of a node
changes, you have to walk the whole DM looking for labels that pointed
to the old id and changing their style.

Yeah, good point. (And the same the other way around, looking for labels
that now apply to it and didn't before.)

Tue, 25, 2005 at 05:28:17PM -0400, Matthew Raymond wrote:

Ian Hickson wrote:
Tue, 25 2005, David Hyatt wrote:

>>Another (IM simpler) idea would be to just have label match the same
>>pseudo-classes that the control does, i.e., if a checkbox is :checked,
>>then the label can match :checked too. Same for :disabled, :enabled,
>>:indeterminate, and :focus. I don't see any reason to introduce new
>>selectors to solve this problem.

That doesn't address all of Matthew's requests, and would be specific to
<label>, not addressing similar problems with elements such as <map>, etc.
But I agree that it might make sense too.

Another problem with David's idea is that it fails to address styling
based on attribute values rather than selectors. An example would be
specific labels for specific <inputtypes in HTML:

| label:friend(for, input[type=datetime])

Then there's the associations to elements with specific classes or IDs:

| label:friend(for, .myClass)
| label:friend(for, #myID)

Also, David's idea is misleading in some cases. As <labelhas been
redefined in Web Forms 2.0, a label may not be able to have focus, for
instance. (Then again, it may be that we don't what this kind of styling
anyways, considering UI conventions. Yet, there again, if
non-conventional UI behavior is implemented, you'd significantly
complicate the method of styling that way.)

Another idea: two new connectors.

E -F
Matches all elements F that are pointed to by an element E, by
means of an IDREF or URL. For example:

LABEL:hover -INPUT {background: yellow}

matches the INPUT element if the LABEL is hovered over:

<INPUT ID=a<LABEL FR=a>Label</LABEL>

E <- F
Matches all elements F that point to an element E, by means of
an IDREF or URL. For example:

INPUT:hover <- LABEL {background: yellow}

matches the LABEL element if the INPUT element is hovered over:

<INPUT ID=a<LABEL FR=a>Label</LABEL>

I haven't thought about it for more than 5 minutes, so I'm sure there
are lots of problems. But at least in 5 minutes I discovered fewer
problems with such connectors than with pseudo-elements or
pseudo-classes.

K, easy to use it isn't. Maybe 'E #linkto F' and 'E #linkfrom F'
are more readable?

Bert

Wed, 2005-10-26 at 01:00 +0200, Allan Sandfeld Jensen wrote:
Tuesday 25 2005 21:06, Matthew Raymond wrote:
How does one style an element based on whether it has an association
to another element via an attribute? Specifically, how do I style a
<labelwith a |for| attribute?

Situations where this would be useful:

1) You want the label to have a dashed border when the associated
control is selected.

Is there any particular reason you can not define associated labels to be
siblings or in another well known position to their control?

"input:focus + label"

Because they're not always siblings or in a well-known position.