The web, the noob, and the soup

[herenvardo]

I can hardly believe that the <i> and the <b> tags are still there;
and I'm afraid there are some issues that must be cared about:
First of all, the redefinition of these tags (as well as a few others,
such as <small>) clashes against one of the basic goals of HTML5:
backwards compatibility. If we expect the browsers to process all
legacy documents as if they where HTML5, when these tags are found
they will be granted a meaning they didn't have. If you find something
like <i>this is italized</i> (which is legitimate and fully compliant
HTML3.2 and 4.x Transitional), then the <i> tag means simply
"italics". Even if the spec or the browser want to know why is that
text italized, they only can make educated guesses which, in the best
of cases, are still random: italics were used for italics' sake, and
retro-actively giving the tag a new meaning will cause the original
intention of the author to be distorted: if legacy documents don't
preserve their meaning (or lack of it for that matter) when processed
as HTML5, then backwards compatibility is broken. And, for most cases,
authors just meant "I like how this looks in italics" when they used
the <i> tag.
The same reasoning applies, in principle, to any other
formerly-presentational retroactivelly-redefined element.

Another side issue is that resurrecting these deprecated elements may
resurrect the "presentational temptation" on many of the authors who
were there in the times of 3.2. In the worst case, some authors might
take the wrong conclusion that "HTML is presentational again", and
turn back to the practices of indenting with blockquotes, seting font
sizes with headers, and so on; or even more blasphemic, those who come
from 4.x transitional which are used to mix presentational tagsoup
with CSS might end up taking the <i>, <b>, or <q> elements (for the
convenience of being a sinle character) as shorthand "hangers" for
class and style attributes. Although the spec is quite clear on this
sense, we cannot assume that the average web developer will read the
specification (actually, some of my friends and former class-mates
from the Computing Faculty of Barcelona take me as crazy just because
I _do_ normally read the specifications of the technologies I use
(although I'm indeed crazy, I think this is coincidental rather than
consecuential :P ) ). Most authors will learn the new version of the
language from many kinds of sources, such as references, tutorials,
textbooks, etc.; and any of these sources might leave out important
details of the spec to go "straight to the main stuff". In my most
honest and humble opinion, I think it is not enough to define what's
right and what's wrong; but we also should make an effort to avoid
encouragin (even unintentionally) bad practices.

The sector I'm most afraid of (actually, I have been unable to sleep
tonight, thinking about this) are noobs. I think it is essential for
the newcomers to HTML to learn the language on terms of structure and
not of rendering/presentation. Once they find the <i> or <b> tags,
they will get confused and miss the point. Don't forget that the noobs
of today may be the gurus of tomorrow; and maybe someday they will be
creating HTML7 or 8 the same way we are now creating HTML5: we'd
better make sure they get the essence of the language.

DISCLAIMER: This is just my point of view; and I thought I should
share it. I could of course be wrong, and be worrying needlessly. But
I will think that I'm right until somebody convinces me that I'm not
(that's how my brain works).

Regards,
Eduard Pascual,
Software and Web developer.

[Frank Ellermann]

Eduard Pascual wrote:
 
> I can hardly believe that the <i> and the <b> tags are
> still there

These tags are fine, what is not fine is the missing <tt>.

> the redefinition of these tags (as well as a few others,
> such as <small>) clashes against one of the basic goals
> of HTML5: backwards compatibility.

IMO the "redefinitions" are a dubious figleaf.  It would
be more straight forward to say that they are semantically
duplicates of <em> and <strong>, handled differently only
as far as optional tag-based CSS-decorations mandate it,
i.e. when looking for tags by name in the DOM.

For <tt> pick the least popular similar tag in this zoo
and deprecate it in favour of <tt>, instead of the other
way around.  Candidates could be <kbd> or <samp>.  

> <i>this is italized</i> (which is legitimate and fully
> compliant HTML3.2 and 4.x Transitional), then the <i>
> tag means simply "italics".

NAK.  And <tt>this is not teletype</tt> also does not mean
what is says.  TT means "The real Thing", as seen in code,
keyboard input, a reference manual, samples, boilerplates,
or similar.

<i> is a kind of historical shorthand for <span class="i">
with a strong tendency towards <span class="i em">.

> if legacy documents don't preserve their meaning (or lack
> of it for that matter) when processed as HTML5, then
> backwards compatibility is broken.

That makes no sense, a legacy document is a legacy document,
and if <i> in the legacy DTD means "inverse video blinking"
or what else, then HTML5 cannot change that.

Above all it does not "break" anything.  Of course browsers
should be very careful *what* they pick when their abilities
to display differences are limited.  Eight colour pairs are
an idea, and clearly <i> would get its own colour pair, as
it happens the same as <em>.  Ditto <b> and <strong>.  And
of course <a> and the deprecated <u>.  Add "normal display",
a fifth colour pair for <tt> and <code>, something for <big>
and <h1>, maybe <small> and <h4>, and the last colour pair
can handle <s>, <del>, and <strike> on this minimal device.

 Frank