Re: Underline element.

Ben Boyle wrote:
>  I prefer to use an element with *some* meaning as an alternative to
>  span, if possible. I like the detail of additional vocabs that RDFa
>  can offer, and I see strength in combining these practices. In the
>  example above, I would choose:
>
>  <i property="shipping:shipName">Titanic</i> (possibly cite may be
>  better in this case).
>
>  Italics does not and will never convey the rich semantics of RDFa.
>  But it provides a meaning... a correct meaning in this case as
>  italics is appropriate (in English, a valid point re translations but
>  equally valid point that markup, not only content, requires
>  translation). I try to use markup that provides the best (semantic)
>  match.

Italicization adds no additional information here, so I don’t see how 
this is any more meaningful than use of a span would be. If you output 
an unitalicized “Titanic” into a document, its meaning is unchanged. In 
this case, at least, it’s also unambiguous, particularly if you use the 
full name: RMS Titanic.

If you use the noted RDFa, you’ve narrowed the meaning to “ship name”. 
Admittedly, I see no machine use for this information, but, assuming 
that it /is/ useful, there’s certainly more meaning that can be derived 
from it than by use of italicization.

On the other hand, if you use the i element, all you’ve done is tell a 
user agent that the text is italicized, which tells little to nothing 
about what the information is since italicization is used in so many 
contexts and the meaning of the element is not narrowly defined. If that 
isn’t clear enough, consider that semantic information is meant for 
computers; how is a computer to tell what italicization means here?

Ben Boyle wrote:
>  Think of it as a fallback for UAs that do not support RDFa. Or think
>  of RDFa as progressive enhancement for markup that is loose and
>  ambiguous in meaning.

You can still get italicization if the user agent does not support RDFa 
via attribute selectors:

[property="shipping:shipName"] { font-style: italic; }

If you consider the element itself—not its presentation—the fallback, 
then I must ask what benefit will a user agent will derive from this 
information and/or how additional meaning will be conveyed to users.

>  * by "typically italicised" I mean as defined by a style manual. If I
>  just wanted italics for decorative reasons I would not introduce an
>  i element - css will do the job.

Style manuals are manuals to presentation. They don’t provide semantic 
information. Consider that styles vary: there are disagreeing style 
manuals for the same types of information; some groups use house styles 
rather than more widely known styles; and, if a style was really that 
universally understood, then you wouldn’t need a manual for it.

I suppose that a particular presentation might be useful if the profile 
of that manual were able to be explicitly associated with a document, 
assuming that ship names were the /only/ italicized construct but, then, 
you could just use something like property="shipping:shipName" and have 
that automatically styled by the associated profile too.

Received on Monday, 14 January 2008 17:30:39 UTC