[whatwg] sic element

[Ian Hickson]

On Sat, 30 Jul 2011, Jukka K. Korpela wrote:
> 29.07.2011 23:56, Ian Hickson wrote:
> > > 
> > > Anyway, aren't you saying that <u> says "this text is annotated but 
> > > no annotation is given"? In that case, saying that <u> draws 
> > > attention to its content might be more appropriate.
> > 
> > The physical line is an annotation. It's just not articulated.
> 
> I think you are using the word "annotation" to mean something different 
> from "a note added by way of comment or explanation" 
> (http://www.merriam-webster.com/dictionary/annotation). What would an 
> annotation be without a note - without a comment or explanation?

I was using it in the sense used in Wikipedia:

   "An annotation is a note that is made while reading any form of text. 
   This can be as simple as underlined or highlighted passages."
    -- http://en.wikipedia.org/wiki/Annotation

If you have a word that better conveys this meaning, I'd be happy to 
use that instead.


> > > But the whole idea of transmogrifying the old <u> element, one of 
> > > the simplest elements of traditional HTML, to some purportedly 
> > > semantic element without saying what it _really_ means, is just 
> > > doomed.
> > 
> > Doomed in what sense?
> 
> People won't take it seriously or, perhaps worse still, some people 
> think they understand it and will start using <u> for something they 
> regard as annotations. This implies that the default rendering is 
> underlined, creating confusion with links.

I don't think what you describe here is a big deal. People fail to take 
specs seriously all the time, or use things in confusing ways all the 
time. I don't think this particular example is any more or less egregious 
than anything else in the spec.


> There's nothing to be gained from adopting this new semantics for <u>.

Sure there is. Device independence, for one.


> The suggested semantics has no solid ground on which browsers or search 
> engines or other software could build their actions on.

The ground seems as solid here as for the vast majority of other elements 
in the specification.


> > If you are concerned that people are going to use it for a different 
> > meaning that it has, then the whole language suffers from this problem
> 
> I'm not really concerned that way - rather, redefinition of <u> is an 
> unnecessary complication to the language.

I disagree with the premise of that concern.


> I'm more concerned that some people may actually try to use <u> by the 
> spec and cause confusion.

I would be overjoyed if people followed the spec!

In this particular case, the redefinition is nothing of the sort. The 
definition is explicitly intended to actually match common practice and to 
match the only non-presentational use cases people could come up with for 
having the element be valid at all.


> > If it's ok if it's entirely ignored, then it's presentational, and not 
> > conveying any useful information.
> 
> Presentational markup may convey useful information, for example that a 
> quotation from printed matter contains an underlined word.

HTML is the wrong language for this kind of thing.


> Underlining also has specialized usage e.g. in some transliteration 
> systems.

Could you elaborate on this?


> > A different voice, inflexion, auditory icons -- there are lots of ways 
> > of conveying this kind of thing in speech, just like there is in the 
> > visual medium.
> 
> I can't imagine how e.g. different voice would convey the meaning of an 
> "annotation" that does not attach any note to anything.

Inflexion changes, pauses, changes in timbre, pitch, speed, and other 
aspects of one's voice, are the ways all meaning is conveyed in aural 
conversations. I don't see why it would be different for this case than 
for any other case.


> > If you interpret the spec as saying that <u> is underline and it's 
> > fine to use it as before then you are misreading the spec.
> 
> I'm saying that people will keep treating it as underline, except for 
> some souls that will get confused and won't know what it is.

Well sure, just like some people will keep treating <blockquote> as 
meaning "indent" and just like how some people will persist in failing to 
understand how scripting APIs work.

Personally I have more faith in authors.


> It would be _so_ much simpler to keep <u>, <i>, <b> as physical markup, 
> like they have always been and will actually be used. If you wish to say 
> that authors must not use them, then say so (but it won't have much 
> effect). It seems that there's the issue of wanting to disallow them 
> (because they're physical markup) and wanting to allow them (because 
> programs generate them). That might be a tricky situation, but trying to 
> rescue them by artificial redefinitions can't possibly be the right way.

I think you are confused as to the goals here. The presentational markup 
that was <u>, <i>, <b>, <font>, <small>, etc, is gone. However, there are 
certain use cases that did not yet have elements yet were important enough 
to warrant us supporting them. By reusing existing elements, we are able 
to support them without having to wait for new elements to be implemented. 
By doing so in a way that closely matches how those elements were actually 
used in practice (at least to the same extent as other elements have been 
correctly used in practice) we can not only have older UAs support these 
new elements automatically, but we can do so in a way that does not 
introduce an undue volume of invalid pages.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'