Re: Cleaning House

Tina Holmboe:
> On Sat, May 05, 2007 at 09:10:19AM -0400, Murray Maloney wrote:
>
>> The semantics* of <i> is emphasise with italic typeface.
>> The semantics* of <em> is emphasise, probably with italics

"Emphasis" can be semantics, but "emphasise" cannot, because it is an  
instruction.

>   The I-element was introduced in HTML 2.0, (...)
>
>      "The <I> element indicates italic text."
>
>   This was reconfirmed in HTML 3.2, (...). In HTML 4.0 and 4.01 (...)
>   the definition of <i> remain the same.

How much does it matter really how something was defined in an  
earlier version of a standard if the new definition is basically  
compatible?

HTML 2-4 said |i| denoted italic text, yet through the use of a  
styling language like CSS authors (or users or browser vendors) may  
change that appearance. So what should one think of a definition that  
cannot stand something considered in the same specification, though  
rather hypothetically up to HTML 3.2?

>   There is, for all the arguments tossed at it, no semantic
>   interpretation defined /anywhere/.

Yet! This is what WA1 currently says:

   The |i| element represents a span of text

Instances of |i| from before CSS that spanned an entire block-level  
element instance are not covered nicely by this. Where |i| spans only  
one or few words inside more text the redefinition usually is sound  
and backwards compatible.

Acceptable (perhaps):
: <h2>Foo bar <i>baz</i> quuz!</h2>

Inacceptable:
: <h2><i>Foo bar baz quuz!</i></h2>

Wrong:
: <i><h2>Foo bar baz quuz!</h2></i>

   in an alternate voice or mood, or otherwise offset from the normal  
prose,
   such as a taxonomic designation, a technical term, an idiomatic  
phrase
   from another language, a thought, a ship name,

I really loathe this ship name issue, because it seems a very  
English, very specific, very rare thing that should not appear there  
explicitly.

   or some other prose whose typical typographic presentation is  
italicized.

   Terms in languages different from the main text should be  
annotated with
   |lang| attributes (|xml:lang| in XML).

In linguistics, words and phrases that you are talking about, no  
matter the language, are commonly presented in italics, without  
quotation marks.

   The |i| element should be used as a last resort when no other  
element is
   more appropriate. In particular, citations should use the |cite|  
element,
   defining instances of terms should use the |dfn| element, stress  
emphasis
   should use the |em| element, importance should be denoted with the  
|strong|
   element, quotes should be marked up with the |q| element, and  
small print
   should use the |small| element.

>   IF a claim is made that authors don't care about
>   semantic HTML - and evidence overwhelmingly suggest that
>   they did in the past not give a damn - then it is both
>   illogical and silly to claim that they have somehow
>   magically used <i> in a semantic fashion.

People do stuff for a reason, most of the time. They are not  
necessarily aware of that reason, consciously, but if you make them  
think about it they should be able to phrase it. (Some poor  
individuals may lack the ability for such self-reflection. That is  
why others have publicised typographic rules for this which they  
observed.)

The current WHAT WG text covers a lot of such reasons, but certainly  
not all of them. This does not apply at all for block usage, like  
already described.

>   If, on the other hand, you claim authors HAVE cared about
>   semantics, then removing the I-element is the only
>   logical way to go, as it is /by definition/ a
>   font-style element and /nothing else/.

That was only true if there was a better fitting element type for  
each and every reason people have used |i| semantically in the past.  
The pragmatic approach is to make |i| bear real semantics.

>> Additional semantics may be layered upon these elements by  
>> employing CLASS
>> attribute values.
>>

This is debatable for |class|, but up to a certain degree I agree.

>> Such semantics may be interpreted by CSS or XSL
>>

CSS and XSL do not interpret semantics.

Received on Saturday, 5 May 2007 21:27:07 UTC