Re: Namespace

To reiterate my views on this I would rather see HTML5 adopt the   
XHTML1 namespace and work to prevent name collisions in our changes  
to the namespace. If we feel — in the interest of backwards  
compatibility — the introduction of new elements (with new semantics)  
with the same names as HTML4 / XHTML1 elements, then I think we  
should go with our own namespace URI. That would not be my first  
choice, but I can understand if others felt the newly introduced  
elements (with name collisions) were important enough to keep. The  
drawback to that is it only differentiates elements sharing the same  
name in XHTML. There is not really a viable mechanism to  
differentiate names in different namespaces in the text/html  
serialization.

Take care,
Rob

On Jul 17, 2007, at 6:49 PM, Robert Burns wrote:

>
> 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 Wednesday, 18 July 2007 00:06:32 UTC