Smylers wrote:
Asbjørn Ulsberg writes:
On Mon, 17 Nov 2008 15:26:22 +0100, Smylers <[EMAIL PROTECTED]>
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.
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).
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.
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.
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 <small> 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 <b> element, if
redefined in its semantics, whould become a redundant alternative to the
<strong> and <em> 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
