W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2008

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 25 Nov 2008 10:49:34 -0600
Message-ID: <dd0fbad0811250849s3ea745b6xcddc33d93e8e8a18@mail.gmail.com>
On Tue, Nov 25, 2008 at 10:24 AM, Calogero Alex Baldacchino <
alex.baldacchino at email.it> wrote:

> Smylers wrote:
>
>> 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.
>> [...]
>>
>>
>
> Of course that's possible, but, as you noticed too, only by redefining the
> <small> semantics, and is not a best choice per se. That's both because the
> original semantics for the <small> tag was targeted to styling and nothing
> else (the html 4 document type definitions declared it as a member of the
> fontstyle entity, while, for instance, <strong> and <em> were parts of the
> phrase entity), and because the term 'small', at first glance, suggests the
> idea of a typographical function, regardless any other related concept which
> might be specific for the English (or whatever else) culture, but might not
> be as well immediate for non-English developers all around the world. As a
> consequence, since any average developer could just rely on the old
> semantics, being he intuitively confident with it, the semantics
> redefinition could find a first counter-indication: let's think on a word
> written with alternate <b> and <small> letters, or just to a paragraph first
> letter evidenced by a <b>, obviously the application of the new semantics
> here would be untrivial (i.e. an assistive software for blind users would be
> fouled by this and give unpredictable results). Despite the previous use
> case would be a misuse of the <b> and <small> markup, yet it would be
> possible, meaning not prohibited, and so creating a new element with a
> proper semantic could be a better choice.
>

No matter *what* we do, if there *is* a default style for an element, it
will be misused by people.  This is a fact of life.  Defining a new element
which is identical to <small> in every way except that it hasn't been
misused *yet* is thus a mug's game, because it *will* be misused in the same
way as <small>, and then we just have two identical elements for no reason.

Yes, bad markup will foul up semantic agents.  But people will *always*
write bad markup.  At least with the semantic redefinition we get to declare
lots of usages that *are* appropriate to be conforming without any effort on
the author's part.

And really, the type of people who would write a word with alternating
letters wrapped in <b> and <small> tags are hardly the kind to even *care*
about semantics.

But, you're right, we have to deal with backward compatibility, and
> redefining the <small> and <b> semantics can be a good compromise, since a
> new element would face some heavy concerns, mainly related to rendering and
> to the state of the art implementations in non-visual user agents (and the
> alike).
>
> However, I think that a solution, at least partial, can be found for the
> rendering concern (and I'd push for this being done anyway, since there are
> several new elements defined for HTML 5). Most user agents are capable to
> interpret a dtd to some extent, so it could be worth the effort to define an
> html 5 specific dtd in addition to the parsing roules - which aim to
> overcome all problems arising by previous dtd-only html specifications - so
> that a non html5-fully-compliant browser can somehow interpret any new
> elements. HTML 5 Doctype declaration could accept a dtd just for backward
> compatibility purpose, and any fully compliant user agent would just ignore
> such dtd. More specifically, such a dtd could define default values for some
> attributes, such as the style attribute (to have any new element properly
> rendered - some assistive technologies are capable to interpret style sheets
> too), and, anyway, there should be a way, in SMGL, to create an alias for an
> element (i.e., a new element - let's call it <incidental> - could be aliased
> to <small> for better compatibility).


Html5 is no longer an SGML language.


> Let's come to the non-typographical interpretation a today u.a. may be
> capable of, as in your example about lynx. This can be a very good reason to
> deem <small> a very good choice. But, are we sure that *every* existing user
> agent can do that? If the answer is yes, we can stop here: <small> is a
> perfect choise. Better: <small> is all we need, so let's stop bothering each
> other about this matter. But if the answer is no, we have to face a number
> of user agents needing an update to understand the new semantics for the
> <small> tag, and so, if the new semantics can be assumed as *surely*
> reliable only with new/updated u.a.'s (that is, with those ones fully
> compatible with html 5 specifications), that's somehow like to be starting
> from scratch, and consequently there is space for a new, more appropriate
> element.


I don't understand.  If some obscure UA can't extract an appropriate meaning
from <small> and come up with a device-appropriate rendering, why does that
mean we should have a new element?


>
>  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.
>>
>>
>>
>
> Apart from considering that <b> isn't a good choice in such a case
> (<strong> or <em> are far better, since they were born with the proper
> semantics), personally I hope in the near future every user agent (or at
> least any thought for human interaction) will be style-sheets compatible
> (meaning at least capable to draw importance and order from them), so that
> anything related to presentation, in any presentation media, would be
> separable from content.


No, Smyler's example was referencing things that specifically should *not*
be marked up with <strong> or <em>.  They're not being emphasized nor are
they of greater importance than the rest of the text - they are merely
purposely offset from the surrounding text for some reason (besides emphasis
or importance).


>
>  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">.
>>
>>
>
> Instead, it could if it were capable to understand CSS 2 and the
> 'BrandName' class were thought for this purpose too (i.e. if properties were
> declared accordingly for the aureal media type, since I think bringing less
> or more emphasys from aureal sheets to a brail presentation should be easy
> enough).


In the meantime, though, a hypothetical braille reader could run on existing
sites right now.  As well, the idea that authors will regularly keep up a
braille version of their style sheets is a pipe dream - it's rare enough to
find print stylesheets around, and those actually help sighted users.  <span
class="BrandName"> *only* conveys something to the user if they can perceive
the style you are assigning to it.  <b> conveys at least the semantic that
this text is slightly different, and it does so in a way that is harmonious
with the majority of existing uses in the wild.  You really shouldn't use
<b> to denote a heading, but if you *do*, at least it presents a better
semantic than <span class="heading"> does.

~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081125/559cbebf/attachment.htm>
Received on Tuesday, 25 November 2008 08:49:34 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:07 UTC