<br><br><div class="gmail_quote">On Tue, Nov 25, 2008 at 10:24 AM, Calogero Alex Baldacchino <span dir="ltr"><<a href="mailto:alex.baldacchino@email.it" target="_blank">alex.baldacchino@email.it</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Smylers wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>
Asbjørn Ulsberg writes:<br>
<br>
  <br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Mon, 17 Nov 2008 15:26:22 +0100, Smylers <<a href="mailto:Smylers@stripey.com" target="_blank">Smylers@stripey.com</a>><br>
wrote:<br>
<br>
    <br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In printed material users are typically given no out-of-band<br>
information about the semantics of the typesetting.  However,<br>
smaller things are less noticeable, and it's generally accepted that<br>
the author of the document wishes the reader to pay less attention<br>
to them than more prominent things.<br>
<br>
That works fine with <small> .<br>
      <br>
</blockquote>
No, it doesn't, and you explain why yourself here:<br>
<br>
    <br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
User-agents which can't literally render smaller fonts can choose<br>
alternative mechanisms for denoting lower importance to users.<br>
      <br>
</blockquote></blockquote>
<br>
I don't see how that explains why <small> is an inappropriate tag to use<br>
for things which an author wishes to be less noticeable.<br></div>
[...]<br>
  <br>
</blockquote>
<br>
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. <br>

</blockquote><div><br>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.<br>

<br>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.<br>
<br>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.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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).<br>


<br>
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).</blockquote>
<div><br>Html5 is no longer an SGML language.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.</blockquote>
<div><br>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?<br> <br></div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
However, you would appreciate that the author had wished for some<br>
particular words to stand out from the surrounding text.<br>
      <br>
</blockquote>
That's a job for the style sheet, whether it's provided by the author<br>
or by the user agent.<br>
    <br>
</blockquote>
<br>
The style-sheet can only pick out particular words if those words have<br>
been marked-up as special in the document, so it doesn't solve the<br>
problem of how to mark them up.<br>
<br>
Further, this isn't using <b> because the house style is to have all<br>
text in a bold weight (that can be done by style-sheets, and if the<br>
style-sheet is missing all the content is still there); it's using <b><br>
to convey _some_ semantics: namely that those particular words are in<br>
some way special.<br>
<br>
So if the mark-up is <span class="brand_name"> or similar and the<br>
distinguishing presentation added with CSS then users without<br>
style-sheets are completely unaware that the author identified those<br>
words as being special.  Whereas with <b>, everybody gets to know.<br>
<br>
  <br>
</blockquote>
<br></div>
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.</blockquote>
<div><br>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).  <br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


If the print was for a blind person, printed with braille, one could<br>
imagine (had it been supported) that letters with a higher weight<br>
could be physically warmer than others, or with a more jagged edge so<br>
they could stand out.<br>
    <br>
</blockquote>
<br>
Yup -- and an HTML-to-braille converter could choose to do that with<br>
words marked in <b>, whereas it couldn't with <span class="BrandName">.<br>
  <br>
</blockquote>
<br></div>
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).</blockquote>
<div><br>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.<br>
<br></div>~TJ<br></div><br>