Re: Namespace

On Jul 17, 2007, at 9:10 PM, Lachlan Hunt wrote:

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

In HTML 4.01 <big> is simply the opposite of <small>. The meaning of  
both of those elements is to change the size of the text relative to  
the surrounding text. In HTML5, the proposal is to introduce a new  
element <small> that does not mean the text should be smaller than  
the surrounding text: it instead means some (relatively nebulous)  
legal concept of fine-print. (something generally not accepted in the  
law). Its a very specialized meaning and it wouldn't be in there  
except for some misguided impulse to rescue a presentational element  
and reuse it for a non-presentational use. So in the case of <big>  
and <small> I think it is as black and white as presentational versus  
non-presentational.

Earlier you gave the example of changing something like <small>or  
perhaps</small> to  <span class="small"> or perhaps <span>. However,  
that's not the kind of change that would represent best practice.  
Best practice would be to replace the presentational element with  
something more meaningful. I think <span> and <div> both encourage  
those practices. So instead, one would expect a change from using  
<small> to something like <span class="copyright"> Copyright  
2007<span> or to <span class="disclaimer">… <span>. These are the  
types of  meaningful class names that often accompany <span> and  
<div>  Of course those class names could accompany <small>, but why  
use them on an element that comes with presentational baggage. Also,  
I think it supports authoring system that simply neglect to add  
meaningful class names to elements such as <small>

Of course with XML, the class mechanism for extending semantics is  
supplemented by compound documents and  other embedded xml  
namespaces. So the same thing could be accomplished with a LegalML or  
LawML or ContractML or whatever.. Whether authors and authoring  
communities extend HTML with semantic class names or other XML  
namespaces, both mechanisms mean we do not need to introduce  
extremely nebulous semantics like <small> into HTML5: specially at  
the risk of a name collision.

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

I'd have to hit the law library for that, but if there are any 1st  
year law students on the WG, they could probably cite something from  
memory.

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

That's fine. And emphasis is often presented in an italics font. That  
doesn't mean we should toss out the semantic facilities of the  
language and just return to presentational attributes. Again, why  
keep <small> when we're getting rid of <big>. They're simply opposite  
sides of the same semantic. Why not an <AllCaps> element for other  
legal jargon. Often contracts include some all upper case text too.

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

I think everything you say in that article about <b> and <i> could  
just as well be said about <big> and <small> and <font> and <blink>.  
Though with <b> and <i> I don't think there's any substantive change  
in the semantics so I don't think those are related to the namespace  
issue we're discussing.

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

I don't see how its compatible. strong emphasis is a lot like  
emphasis.(in that they both have the word emphasis in them). Strong  
in terms of importance does not seem at all compatible to me. I'm not  
even sure what it means to make a fragment of text as important as  
opposed to emphasized. Why are authors writing text that is  
unimportant. Sound like a waste of time and bytes to me.

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

I would say these are very minor changes and you've convinced me that  
the HTML5 meaning returns to earlier traditions. However, I think the  
changes with <hr> are about the subtlest I could imagine. I think  
that's why there are no problems with these changes to <hr>.

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

No, you've introduced the fallacy. My concern is that substantial  
changes in semantics will cause name collisions. That's simply a  
fact, even if you want to call it a fallacy. Again, you're trying to  
change semantics by finding semantics that will still render in a  
compatible way in a small subset of the UAs in the wild. Again, this  
is just like the author who finds an element that looks right in a  
few browsers  and uses it to convey the intended meaning. Once it  
ends up in another browser that doesn't use the same rendering  
convention, the author's assumptions are revealed to be false.

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

But why bother creating name collisions in the first place. Has there  
really been a strong cry from authors who need who need to markup  
their document text as important (<strong>) or with legal mumbo jumbo  
(<small)>). I don't think so. So why undermine the integrity off the  
namespace by introducing new elements with the same name at all. Just  
leave <strong> alone and deprecate <small> (like we're deprecating  
<big>).

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

The user an author do not have to be the same person. Again, your  
displacing the problem. The user who edits a document created by  
another user (the original author) does not necessarily know what the  
original author meant. Perhaps they would like to remove all  
presentational elements (like HTML 4.01 <small>) and they do not want  
to remove any semantic elements (like the HTML5 <small> element). If  
this editor (a person, not a app)  is not the original author, how  
would they determine which elements to remove and replace with CSS.

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

Again, the issue is what do I do with a document that I didn't  
create. And one that I have no way to tell if its an HTML4 or an  
HTML5 document. What does <small> mean there.

I'm not trying to blow this out of proportion. My point is that if we  
want to inherit a namespace created by others, we shoul adhere to the  
semantics of the namespace. What that means exactly depends on the 5  
types (or others) I outlined. However, you're getting this namespace  
issue mixed up with compatibility issues (they're related, but not  
the same thing). The compatibility issues in XHTML2 are often created  
to avoid namespace issues (like creating a <handler> element that is  
semantically different enough from the <script> element to justify  
changing the name. Or introducing an <h> element instead of reusing  
the <h1> -– <h6> elements. These have definitely created  
compatibility problems. However they specifically avoid namespace  
problems. XHTML2 changes the content models of some elements (as does  
HTML5), however that's much less of a problem than changing the  
meaning of elements. I would say especially since those newly  
introduced elements with the same names are not really very useful  
for authors or users.

Take care,
Rob

Received on Wednesday, 18 July 2007 04:14:06 UTC