Re: HEADERS, FOR whom - any ID?

On Aug 7, 2007, at 8:32 PM, Sander Tekelenburg wrote:

>
> At 19:27 -0500 UTC, on 2007-08-07, Robert Burns wrote:
>
>> On Aug 7, 2007, at 6:57 PM, Sander Tekelenburg wrote:
>
> [...]
>
>>> 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.
>>
>>
>> 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 depends on the text of the label and the control. Except for  
> some simple
> cases, it seems unlikely to me that it is easy to author that text  
> such that
> it makes sense either way around.

I see we're using "logical" in the same way. I would disagree about  
the frequency of the issue you raise. In your example, you took extra  
steps to make the controls and labels arranged as a sentence. I would  
say that's an important use-case that is handled just fine without  
CSS. However, it's pretty rare that controls and labels are used in  
that way.

> Once that is the case, CSS should *not*
> mess that up. (Which it could, by not being supported or available,  
> or maybe
> even when naively defined by the user.) That's what "present" means  
> to me.
> "Presentation" is a means to convey meaning, whereas "logic" is a the
> definition of that meaning. In the example I gave I don't see how  
> the meaning
> could be defined in any other way than through the text, which you  
> cannot
> move parts of around with CSS without messing up the conveyance of  
> that
> meaning.

There are all sorts of things designers and users could do with  
stylesheets that could obscure the meaning of a semantic document. My  
recommendation would be that they don't do those things. However,  
that would leave a lot of room for an author to position labels in  
all sorts of ways in relation to a control. The default without CSS  
would be to present it just as a sentence as it does in this example.  
I don't really see the problem yet.

>> It is logical to do so, as in it makes sense to present it that way.
>
> I'm using "logical" and "presentational" in the HTML/CSS context.  
> Logic
> applies to content/structure/meaning. Presentation applies to  
> conveying those.

I would only add to that the presentation plays two roles. One is to  
convey meaning (like making emphasized text bold). The other is  
purely stylistic (like selecting Times New Roman instead of Helvetica  
or Times). There's always a danger in applying the purely  
presentational styling to obscure some meaning. For example making an  
entire paragraph italics for purely styling reasons will obscure the  
meaning presented through the italicized emphasis text.

> [...]
>
>> 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.
>
> 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. This is similar to the proposed  
@layout attribute in XHTML2 where setting it to relevant indicates  
that the whitespace is relevant to the meaning. Similarly a LABEL  
could indicate whether its position is relevant. Again by rounding  
out the semantics of HTML, authors, users and designers all become  
aware of semantics and also become more aware of how styling should  
relate to those semantics. This may be getting to the edge of what we  
want to define in HTML5, but 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).

> Author CSS is incapable of conveying any meaning when it is not
> available. Not all UAs support CSS and not all UAs that do will  
> always have
> it switched on. There might even simply be a (network; server
> misconfiguration) problem fetching the Style Sheet (when it is a  
> separate
> file).
>
> Thus the HTML itself must be usable without CSS. It wouldn't be if  
> you'd rely
> on CSS to switch a label from one end of a control to the other.  
> CSS can help
> to convey (or obscure) meaning; not define it.
>
> [...]
>
>> Would something like this convey the
>> meaning (and presentation) of that FIELDSET?
>>
>> <style type='text/css'>
>> 	fieldset > label {label-side: left;}
>
> That wouldn't work. See above.
>

However with an attribute selector it would work (limiting it to  
labels where order was insignificant). Sometimes adding a little  
piece of semantics like this (one that I believe would work with CSS  
in all 'current' browsers) can empower users in many more ways.

> The HTML below might solve the issue of one label for multiple  
> controls, but
> 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. The order of those  
controls is significant (though the styling could present them  
vertically or horizontally). I would imagine that a UA would present  
that in the same way as your page currently does. In Safari 3 (beta)  
on the live DOM view[1], it looks much the same as it look on your  
page (without any CSS messing it up anyway). I don't know how other  
current browsers present that (or if they parse it correctly, but  
they should).

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


Take care,
Rob



[1]: <http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C% 
21DOCTYPE%20html%3E%0A%3Ctitle%3ETests%20around%20the%20dates%3C/title 
%3E%0A%3Cscript%3Evar%20d%20%3D%20new%20Date%28%29%3B%3C/script%3E%0A% 
3Cfieldset%3E%0A%09%3Cinput%20name%3D%22submit%22%20type%3D%22submit% 
22%20value%3D%22Show%20systems%22%3E%0A%09%20%3Clabel%3Ewhose%20name% 
0A%09%09%3Cselect%20id%3D%22NameBool%22%20name%3D%22NameIsContains%22% 
3E%0A%09%09%09%3Coption%20value%3D%22contains%22%20selected%3Econtains 
%3C/option%3E%0A%09%09%09%3Coption%20value%3D%22is%22%3Eis%3C/option% 
3E%0A%09%09%3C/select%3E%0A%09%09%3Cinput%20id%3D%22NameString%22% 
20type%3D%22text%22%20name%3D%22name%22%20size%3D%2212%22%20value%3D% 
22%22%3E%0A%3C/label%3E>

Received on Wednesday, 8 August 2007 02:22:10 UTC