Re: HEADERS, FOR whom - any ID?

HI Sander,

On Aug 8, 2007, at 5:59 PM, Sander Tekelenburg wrote:

>
> At 21:21 -0500 UTC, on 2007-08-07, Robert Burns wrote:
>
>> On Aug 7, 2007, at 8:32 PM, Sander Tekelenburg wrote:
>
> [...]
>
>>> We're talking about author CSS in this case (because only the
>>> author can know
>>> whether the text of the label makes sense at one or the other side
>>> of a control).
>>
>> In this example, yes. However, that's an indication that there are
>> semantics missing from the markup. For example, an enumerated
>> attribute  on a label could indicate whether the label default
>> position was meaningful or not.
>
> Ah, now I see where you're heading :) Yes, such an attribute could  
> safeguard
> from inappropriate CSS rules. Agreed.
>
> However, I don't think it would be wise to rely on authors to set  
> this. The
> other way around seems safer: allow authors to define that the  
> order of the
> label and its control is irrelevant, and only allow CSS to switch  
> label and
> control around when this attribute is set. Authors might still set  
> such an
> attribute when it is inapproriate, but at least they'll need to  
> make the
> mistake on purpose then.

I could see that. If it's something like @order= { relevant |  
irrelevant } with relevant as the default that would accomplish that.  
Perhaps the attribute belongs on the FIELDSET element too. I'm still  
trying to think through the structure.

> [...]
>
>> having such an attribute would allow
>> users to arrange controls and labels in the way they preferred
>> (without messing up the cases where label order mattered).
>
> Agreed.
>
> [... <label>blah<control1><control2></label>]
>
>>> I wonder what such markup would imply. How should a UA treat that
>>> in a manner that is useful for the user?
>>
>> To me this implies that two controls are related to the extent that
>> they act together and share the same label.
>
> Agreed. I'm just wondering how the UA might convey that. Which of  
> the two
> controls should be activated when the label is 'clicked'? Or should  
> it not
> activate but do something else?

I'm not that familiar with how UAs currently handle activation. I  
guess in the case of two or more buttons (including <input radio>,  
<input button> and button, that might not be advised. In that case I  
think the controls need separate labels (and therefore it doesn't fit  
the semantics Im proposing). For other controls, I don't think  
clicking activates so much as focuses. In that case it could just  
focus on the first of the controls. Clicking directly  on the another  
control (a smaller area) or tabbing would move to the next control.

Doe that make sense? I think mixing LABEL with FIELDSET authors could  
create intricate compound controls.

Take care,
Rob

Received on Wednesday, 8 August 2007 23:58:07 UTC