W3C home > Mailing lists > Public > public-html@w3.org > July 2007

(subscript, superscript: <sub> and <sup>) part of my review of 3.12 Phrase elements

From: Robert Burns <rob@robburns.com>
Date: Fri, 20 Jul 2007 04:39:00 -0500
Message-Id: <A4217A74-25FC-4A00-998F-5D5A23EF2E32@robburns.com>
To: HTML WG <public-html@w3.org>

Superscript and subscript:

I think we would be moving in the wrong direction if we try to  
redefine or refine presentational elements to be non-presentational  
elements. Mnemonics is important and authors will tend to use these  
for subscript and superscript presentation because of their names. It  
is also counter-productive to try to suggest they are semantic. Like  
bold and italics (or even more so) there is often a need to present  
content in either subscript or superscript  due to so many semantics  
the language just cannot justify all the uses. The example of TeX is  
a good one, since its hard to imagine what semantic element HTML  
could include that would accommodate such cases. So just use a  
presentational element if its presentation that's needed there.

The current draft says:
"These elements must only be used to mark up typographical  
conventions with specific meanings, not for typographical  
presentation for presentation's sake. For example, it would be  
inappropriate for the sup and sub elements to be used in the name of  
the LaTeX document preparation system. In general, authors should not  
use these elements if the absence of those elements would not change  
the meaning of the content."

Quite the contrary. These elements are meant to present their  
contents as either subscript or superscript. The goal of semantics is  
not to only use presentation to convey semantics. Rather its to  
differentiate semantics through markup differentiation (in part so  
that it can be differntiated in presentation). So instead the advice  
this paragraph should offer is to use other namespaces, class names  
from microformats and other authoring communities to achieve the  
desired presentation whenever possible. When such elements and class  
names are unavailable, instead use <sub> and <sup>. For example, a  
miccformat might exist for chemical molecular markup such as  
class='molecule-count'. The markup:

<p>mix liberally with H<span class='molecule-count'>2</span>O</p>

would be presented through an accompanying microformat recommended  
stylesheet as an "H" with a subscript "2" and an "O". If no such   
micfroformat semantic was available, it should be marked-up as:

<p>mix liberally with H<sub>2</sub>O</p>

We don't need to change these elements to be other than what they  
are. These are perhaps the presentational elements with the best use- 
case justification for remaining in HTML. It is true that the various  
semantic uses of <sub> and <sup> would best be covered by semantic  
elements. However, it only confuses he issue to treat  presentational  
elements as if they are semantic elements. Both the Tex example  
(along with the HTML4 French abbreviation example) strikes me as  
precisely the reason we need these elements in HTML. In both  
instances, there would be little likelihood of a microformat or XML  
namespace that covered those use-cases (so again, just use <sub> and  

This example should be reworded in a more informative language. It  
reads like a more normative pronouncement.
"When the sub element is used inside a var element, it represents the  
subscript that identifies the variable in a family of variables."

Something like:

For example:
"Authors may use the sub element inside a var element to represent  
the subscript that identifies the variable in a family of variables."

This is one possibility. Authors may find other uses for a sub  
element inside a var element and we should not prohibit those uses.  
Other uses might include molecular count if an author wanted to use  
the <var> to discuss a particular molecule.. There are likely other  
uses too. The point is that this should be rephrased to sound like an  
example rather than roughly like normative prose.
Received on Friday, 20 July 2007 09:39:18 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:24 UTC