[whatwg] Deprecating , ?

Tue Nov 25 08:24:27 PST 2008

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 semantics, and is not a best choice per se. That's both 
because the original semantics for the 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, 
and 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 
 and letters, or just to a paragraph first letter evidenced 
by a , 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 and markup, yet it would be 
possible, meaning not prohibited, and so creating a new element with a 
proper semantic could be a better choice.

But, you're right, we have to deal with backward compatibility, and 
redefining the and 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 
for better compatibility).

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 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: 
 is a perfect choise. Better: 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 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.

>>> 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 isn't a good choice in such a case 
( or 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.

>> 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).

Anyway, I'm not against a redefinition of semantics, since that 
could be a good choice, or at least something to take properly into 
account; I just think there is also space to consider a 'brand new' 
element for such a semantics, in order to take the 'lesser importance' 
semantics apart from any typographical issue. But the element, if 
redefined in its semantics, whould become a redundant alternative to the 
 and elements carrying on the 'old' typographical issues: 
we should consider this; yet, such redundancy could be desireable for 
backward compatibility sake.

Lastly, I think that the 'deprecation' of any element should be 
different from 'obsoleting' it, and should be done in a different 
manner. The W3C html 4 specifications uses different DTDs for this; 
current draft on HTML 5 aims to avoid DTDs, but the same could be 
achieved with a specific PUBLIC section on the document type declaration 
(actually, if I'm not wrong, such a section is only intended for xslt 
compliance), so that deprecated elements (eventually with a redefined 
semantics) could survive along with new (equivalent) elements, at the 
author will.
> Smylers
>   
Regards,
Alex

 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f

 Sponsor:
 Un cellulare VIP? Scarica i wallpare con le star di Hollywood!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8276&d=25-11

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