Re: HEADERS, FOR whom - any ID?

Hi Sander,

On Aug 7, 2007, at 6:57 PM, Sander Tekelenburg wrote:

>
> At 14:27 -0500 UTC, on 2007-08-07, Robert Burns wrote:
>
> [...]
>
>> As I said, I support the inclusion of @for for backwards
>> compatibility reasons. The thread, as I understood it, was about
>> forward looking approaches that were mostly designed to fix a
>> presentation and not a semantic issue. This to me point to a
>> deficiency in the presentation mechanism (such as CSS) and not in the
>> semantic language such as HTML (just applying our separation of
>> concerns design principle here). If the presentation was handled
>> suitably, I cannot think of any need to not simply enclose a control
>> inside a label or enclose the label inside the control.
>
> Having the label on either side of a control is not always  
> presentational. It
> may sometimes be, but at other times it may well be logical. Look at
> <http://webrepair.org/strategy/known%20systems#filter> for instance.

I can't tell which example you're referring to. Can you tell me what  
the LABEL elements contain? Are you referring to the Search form at  
the bottom of the page? If so, then I'm still not seeing the issue. I  
see a FIELDSET with three controls: an INPUT submit with no label; a  
SELECT with a LABEL displayed to the left; 3) and an INPUT text with  
no label.

In any event, I wasn't using "logical" in that way. It may well make  
sense to present a label above, below, besides or between controls.  
It is logical to do so, as in it makes sense to present it that way.  
I was using logical in the sense of a model as in a document model or  
an application model. In terms of HTML/XML it seems to me that  
implies that in terms of model we just should eventually try to move  
towards a control inside a label or a label inside a control (with no  
other semantic markup necessary)

The other source of confusion here is you seem to be reading me as  
saying "presentational" as in "merely presentational". I do not think  
of presentation as something unimportant or incapable of conveying  
subtleties in meaning. When I say it's a presentational issue, I'm  
merely saying that in the long run we should look to (and push) CSS  
and other styling mechanisms to solve the issue (giving authors more  
abilities).

If, on the other hand, you think this presentational distinction —  
this subtle semantic distinction — is something that we can express  
in HTML and therefore allow the presentational mechanisms to pick up  
on that, I'd be all for that. Would something like this convey the  
meaning (and presentation) of that FIELDSET?

<style type='text/css'>
	fieldset > label {label-side: left;}
  /* this could also be {label-side: right;}  or top or bottom etc   
Combined with other positional CSS, this seems like it would offer  
the styling control needed by authors while requiring the minimum  
semantics necessary to express the association of these elements */
	fieldset  > select {display: inline;}
	fieldset  > input {display: inline}
</style>

<fieldset>
	<input name="submit" type="submit" value="Show systems">
	 <label>whose name
		<select id="NameBool" name="NameIsContains">
			<option value="contains" selected>contains</option>
			<option value="is">is</option>
		</select>
		<input id="NameString" type="text" name="name" size="12" value="">
</label>

Again, this is only hypothetical. I'm not saying this should work in  
existing browsers. I'm trying to understand what the minimal  
expression necessary for authors that could be interpreted and  
displayed in a browser conforming to this enhanced recommendations.  
Also I'm trying to figure out where it makes sense to add semantics  
to HTML and where it makes sense to instead enhance CSS to solve  
these problems.

Take care,
Rob

Received on Wednesday, 8 August 2007 00:35:15 UTC