Re: Namespace

Robert Burns wrote:
> On Jul 17, 2007, at 6:27 PM, Lachlan Hunt wrote:
>> The definition in the current draft states (emphasis added):
>>
>>   The small element represents *small print* (part of a document
>>   often describing legal restrictions, such as copyrights or
>>   other disadvantages), or other side comments.
>>
>> http://www.whatwg.org/specs/web-apps/current-work/#the-small
>>
>> So it *still* represents small text.  Legal restrictions and copyrights
>> are just given as specific use cases for which small print can be used.
> 
> So are you staying that this is still a purely presentational element? 
> Then why not just deprecate it in favor of CSS (like <big>)?

I'm saying it still represents small text, and that there are legitimate 
use cases for it.  Whether or not those use cases are largely compatible 
with existing real world usage is certainly questionable and needs 
researching, but it's definition in HTML5 is compatible with it's 
definition in HTML4.

<big> does not have any known legitimate use cases.  The issue is not as 
black and white as simply being a presentational vs. a 
non-presentational element.

> For example, in the US (and maybe elsewhere) such legal wording is not 
> supposed to be presented in "small print" so it is a bit of a misnomer.

Do you have any evidence/references to support that claim?

Copyright statements and other legal notices that typically occur at the 
end of web pages (the use cases for which this is intended) are quite 
often presented in a smaller font.

> Small is just one example. We have several elements: <b>, <i>, <strong>, 
> and <hr>. Some of these are subtle differences (especially compared to 
> <small>), however, some are not so subtle at all.

I've addressed the issue of b and i before.

http://lachy.id.au/log/2007/05/b-and-i

The definition of strong and em has always been rather ambiguous in 
previous versions of HTML.  HTML5 refines their definitions in a useful 
and compatible way.

The definition of HR in HTML 2.0 was:

   The <HR> element is a divider between sections of text; typically a
   full width horizontal rule or equivalent graphic.

In HTML 3.2, that became:

   Horizontal rules may be used to indicate a change in topic. In a
   speech based user agent, the rule could be rendered as a pause.

In HTML 4.01, that became:

   The HR element causes a horizontal rule to be rendered by visual user
   agents.

The HTML4 definition is entirely presentational and not at all useful. 
HTML5 defines it in a way that is more compatible with its semantics in 
HTML 2.0 and 3.2.

   The hr element represents a paragraph-level thematic break, e.g. a
   scene change in a story, or a transition to another topic within a
   section of a reference book.

That also illustrates that changes in definition have occurred in the 
past and that such changes are not as serious as you claim.

>>> With that, "the likelihood that it will be interpreted and presented 
>>> as intended by an implementation" falls dramatically.
>>
>> The Rendering section of the spec will require it to be rendered with a
>> smaller font.
> 
> Yes, but the name collision means that non-visual UAs (UAs in the broad 
> sense as in any processing tool) will not know how to interpret <small> 
> because that one name refers to two different elements.

You're argument seems to be based on the fallacy that minor changes to 
semantics could seriously alter the processing, but that is not true 
because the processing requirements will also be defined in a way that 
is compatible with legacy content and UAs.

Ideally, the spec would give guidance for non-visual UAs, based on how 
such UAs handle it today.  HTML5 will not intentionally define 
processing requirements that are significantly incompatible with legacy 
content.

>> Replacing <small> with <span class="small"> or perhaps <span
>> style="font-size:smaller;"> (which is effectively all that can be done
>> automatically by such an editor) is really quite pointless.  Besides, if
>> that's not what the user wants their editor to do, they should be able
>> to disable that option.
> 
> This only displaces the problem to the user.

It doesn't displace the problem at all.  The user will know what they 
have used the elements for, and so the problem will have always been 
with them, not the editor.

> As a user I may want my UA to remove all presentational elements and 
> replace them with CSS.

If you only used <small> for presentational purposes in you're document, 
then there is little problem in replacing them with CSS.  If you know 
you only used them for semantic purposes, then don't let you're editor 
change them.  If you used it for both semantic and presentational 
purposes, that's your problem.  It is no different, for example, from 
using <em> for emphasis in some cases, and general purpose italics in 
others.

-- 
Lachlan Hunt
http://lachy.id.au/

Received on Wednesday, 18 July 2007 02:11:02 UTC