[whatwg] Deprecating , ?

Tue Nov 25 08:49:34 PST 2008

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 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 , 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 and 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 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 or . 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. *only* conveys something to the user if they can perceive
the style you are assigning to it. 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
 to denote a heading, but if you *do*, at least it presents a better
semantic than does.

~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081125/559cbebf/attachment-0001.htm>

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