Re: Namespace

On Jul 17, 2007, at 6:27 PM, Lachlan Hunt wrote:
> Robert Burns wrote:
>> Earlier I gave the example of changing the semantics  of <small>  
>> from meaning "presentationally small text" to meaning "legal  
>> descriptions and other disadvantages"
>
> 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>)?

> IMHO, it is perfectly OK to refine semantics in a way that is a
> compatible subset of its existing meaning, which is exactly what  
> has happened with <small>.

However, the draft does not "refine semantics in a way that is a
compatible subset of its existing meaning". 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. At least as  
the current draft is written. Also (and this is reflected in the  
HTML4/ HTML5 differences document) , the element is supposed to have  
different semantics than the HTML4 <small> element. In other words  
according to the differences document this is not just a  
clarification in the prose or a recommendation it is a semantic  
change. To use semantics in the broad sense of the term the semantics  
of the HTML4 element is meant to imply a purely presentational text  
difference that is smaller than the surrounding text. The HTML5 draft  
implies the semantics of the element is reaches beyond presentation.

HTML 5 therefore introduces a new semantic element <small> that has a  
namespace name collision with the HTML4 <small> element. If it is as  
you say — that these are merely examples of text that may be  
presented smaller than the surrounding text — then why isn't this  
element deprecated in favor of CSS like <big> is.

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.

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

> http://www.whatwg.org/specs/web-apps/current-work/#rendering
>
>> From my earlier example, a UA that strips out <small> elements and  
>> converts them to CSS will be stripping meaning out of a document.
>
> 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. As a user I may want my  
UA to remove all presentational elements and replace them with CSS.  
However, now, because of a name collision, we have elements that have  
the same name as presentational elements. However though they share  
the exact same name with the presentational elements they are not  
presentational elements. This is a name collision and its something  
that a namespace basically promises won't happen. If we're going to  
play fast and loose with names then we shouldn't use the term  
namespace at all. That way we make it clear that these are just a  
bunch of names we use that we do not claim are a part of a namespace.  
We can and will change them on a whim so expect name collisions.


>> You may say, well no tool should be stripping out <small> because  
>> it has a special meaning in HTML5.
>
> I'd say it shouldn't do so automatically without the user's consent,
> regardless of its meaning.

Again, that just displaces the problem and does nothing to address  
it. A user may want all HTML4 <small> elements to be replaced by CSS.  
You as a user may never do something like this, but other users may  
want to (and there are a lot of reasons to do so. However, now it  
requires careful examination and the ability to divine the author's  
original intent to determine whether each <small> element is either  
an HTML4 <small> element or an HTML5 <small> element. Again, there  
are two elements here. No way to determine which one is which by name  
alone.

Take care,
Rob

Received on Tuesday, 17 July 2007 23:50:11 UTC