Re: Cleaning House

Maciej Stachowiak wrote:

> On May 6, 2007, at 3:53 AM, Tina Holmboe wrote:
> 
>> On Sun, May 06, 2007 at 03:27:21AM -0700, Maciej Stachowiak wrote:
>>
>>>>> elements. But consider <i class="ship">.
>>>>
>>>>  Meaning nothing. Do you mean a ship name? Or is it an abbreviate
>>>>  name for a shipping label? Or perhaps even a status saying whether
>>>>  something is about to ship?
>>>
>>> What is the correct way, according to you, to mark up a ship name?
>>
>>   That wasn't the topic. Ideally we would use the <shipname> element,
>>   of course, but that doesn't exist in HTML - and no-one has ever
>>   said that HTML ought contain elements for all conceivable
>>   semantic constructs.
> 
> Agreed, but if there's no way to express the concept of a ship name in a 
> way that, according to you, is semantically meaningful, then I don't 
> think you can blame others for doing it in a way that isn't.
> 
>>   With that firmly out of the way, it depends on the style of
>>   publication - as others point out: it's by no means a certainty
>>   that a ship's name should be set in italics.
>>
>>   I would suggest the following if using HTML:
>>
>>      <span class="shipName">
>>       <abbr title="Her Majesty's Ship">HMS</abbr> Gannet</span>
>>
>>   Yes, the SPAN-element is semantically null. But no precise
>>   element exist. The 'house style' can now be attached to the
>>   class "shipName", but there is, in the above, /no semantic
>>   value communicated/.
>>
>>   Which is a shame, of course, but again: we can't make a
>>   markup language that fit all, and we most certainly cannot
>>   start guessing at what the content of an I-element might
>>   or might not be!
> 
> It seems, then, that in this case using the <i> element instead of 
> <span> would do no harm (both are according to you equally lacking in 
> semantics), and would have the benefit of defining a useful default 
> presentation for multiple media, even in non-CSS user agents such as Lynx.

Using the <i> element would result in (minor) harm in speaking UAs. As I 
pointed out earlier, <i> is typically emphasized by speaking UAs, but 
ship names should not usually be especially stressed. I have almost no 
experience of the braille produced by screen readers, but I suspect <i> 
would result in benefits in braille UAs that do not support CSS, since 
if a ship name is italicized in print it /should/ be italicized in 
English braille.

Pick your poison. To opt for <i> would be to formally recognize a 
difference between <em> and <i> such that voice UAs should stress the 
former and not the later. The alternative would be to imply that ship 
names should always be emphasized in voice, in which case one might as 
well use <em>.

If AT had better support for CSS, and CSS had style selectors, we'd be 
in a slightly happier place:

<span role="name:aircraft">Air Force One</span>
<span role="name:ship">Enterprise</span>

@media screen, print, tv, handheld, projection, braille, embossed {
span[role="name:ship"] {font-style:italic}
style("font-style:italic")
span[role="name:ship"]{font-style:normal;}
span[role="name:aircraft"]:contains("Air Force One") {font-style:normal}
style("font-style:italic")
span[role="name:aircraft"]:contains("Air Force One") {font-style:normal}
}

Neither <i> nor <span> can solve this problem. I suspect we're not going 
to get a typographically satisfying solution, even if role might give us 
a semantically satisfying one.

But perhaps documents would be improved if we had a <different> element. 
The semantic of <different> would be that the contained text differs in 
nature from the surrounding text; the proper behaviour would be for UAs 
to express that difference in a generic manner, e.g. GUI UAs could 
alternate italic and non-italic; text UAs could change color; voice UAs 
could change pitch; braille UAs might want to use italic. This would 
probably require a Hart's rules and braille standard for the 
representation of HTML, just as we now have Hart's rules for compositors 
and printers and a braille standard for the transcription of print.

Thankfully, the practical accessibility costs of the uselessness of <i> 
are /probably/ smaller than the aesthetic costs.

--
Benjamin Hawkes-Lewis

Received on Sunday, 6 May 2007 12:40:09 UTC