[whatwg] Deprecating <small> , <b> ?

Asbj?rn Ulsberg writes:

> On Mon, 17 Nov 2008 15:26:22 +0100, Smylers <Smylers at stripey.com>
> wrote:
> 
> > In printed material users are typically given no out-of-band
> > information about the semantics of the typesetting.  However,
> > smaller things are less noticeable, and it's generally accepted that
> > the author of the document wishes the reader to pay less attention
> > to them than more prominent things.
> >
> > That works fine with <small> .
> 
> No, it doesn't, and you explain why yourself here:
> 
> > User-agents which can't literally render smaller fonts can choose
> > alternative mechanisms for denoting lower importance to users.

I don't see how that explains why <small> is an inappropriate tag to use
for things which an author wishes to be less noticeable.

> If the point isn't to literally render smaller fonts, you shouldn't
> indicate that you want the fonts rendered smaller either.

Indeed.  <font size="-1"> would be bad to use for this.

> What you want is to semantically indicate that the text wrapped inside
> the element is of less significance than the surrounding text, e.g. a
> negative 'strong' or 'em'.

Yes.  And I reckon than <small> works for that.  English has the idiom
of 'small print', roughly meaning text written by the legal department
rather than the marketing department.  But 'small print' doesn't
literally have to be typeset with a smaller font; it's a figure of
speech.

> 'small' isn't equal to what we're trying to express here.  What we
> need is a new element that can capture this semantic.

If we were starting from scratch then indeed <small> may not be the best
name to choose for this element.  But, unfortunately, we aren't.

<small> has existed for some time, and people are already using it.  If
one currently wants to denote lessor importance <small> is the best
element to pick.  Further, existing browsers know what to do with
<small>; if we introduce a new element then content that uses it will
have a sub-optimal rendering in current browsers, whereas <small>
already does something appropriate.

So I still think <small> works for denoting that something is of smaller
importance.

> > Indeed you can't.  And nor can you if you were reading printed text
> > with some words in bold.
> 
> Why does printed text set the standard for what we are able to express
> with a markup language?

It doesn't set the standard.  But it's useful in some comparisons.  And
most of the time humans cope perfectly well with inferring typographic
conventions without having them spelt out.

> > However, you would appreciate that the author had wished for some
> > particular words to stand out from the surrounding text.
> 
> That's a job for the style sheet, whether it's provided by the author
> or by the user agent.

The style-sheet can only pick out particular words if those words have
been marked-up as special in the document, so it doesn't solve the
problem of how to mark them up.

Further, this isn't using <b> because the house style is to have all
text in a bold weight (that can be done by style-sheets, and if the
style-sheet is missing all the content is still there); it's using <b>
to convey _some_ semantics: namely that those particular words are in
some way special.

So if the mark-up is <span class="brand_name"> or similar and the
distinguishing presentation added with CSS then users without
style-sheets are completely unaware that the author identified those
words as being special.  Whereas with <b>, everybody gets to know.

> > However, you can only notice this if the words have been
> > distinguished in some way.  With <b> , all user-agents can choose to
> > convey to users that those words are special.
> 
> They are only special for sighted users, browsing the page with a
> rather advanced user agent. They are not special to blind users or to
> users of text-based user agents like Lynx.

Not true.  Any user-agent can choose to convey that words marked in <b>
are somehow different from the surrounding words.  Lynx does this.

> If you want to express semantics, then use a semantic element.

That's begging the question.  If we define <b> to be semantic, then it
is!

> Expressing semantics through presentation only is done in print
> because of the limitations in the printing system.

Well, yes.

> If the print was for a blind person, printed with braille, one could
> imagine (had it been supported) that letters with a higher weight
> could be physically warmer than others, or with a more jagged edge so
> they could stand out.

Yup -- and an HTML-to-braille converter could choose to do that with
words marked in <b>, whereas it couldn't with <span class="BrandName">.

> Such effects would have been impossible if the document was only
> tagged with presentational markup.

To some extent, yes: not knowing whether a letter is where it is on the
page because it's a start of a paragraph or a heading, or just because
the previous line is full, hampers doing that.  And similarly for
typefaces.

> The same applies to other mediums than print -- you need to know the
> underlying reason of why something is presented the way it is to
> transfer that presentation to another environment. And for that you
> need the semantics.

Surely having the semantic of 'the author wished for this word to stand
out' is actually sufficient for that?

Smylers

Received on Monday, 24 November 2008 08:19:44 UTC