- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Wed, 18 Jul 2007 09:27:36 +1000
- To: Robert Burns <rob@robburns.com>
- CC: HTML WG <public-html@w3.org>
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. 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>. > 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. 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. > 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. -- Lachlan Hunt http://lachy.id.au/
Received on Tuesday, 17 July 2007 23:28:47 UTC