[whatwg] Web Forms 2.0 Feedback

Matthew Thomas mpt at myrealbox.com
Thu Jan 6 05:59:23 PST 2005

On 6 Jan, 2005, at 3:04 AM, Matthew Raymond wrote:
> ...
>      I've actually adopted most of your new <select> markup in another
> post, so we no longer have any fundamental disagreement over this
> markup. (Although I still have a few issues with <shead> and whether or
> not it should be inside <select>.)

Sure. (I don't really care either way -- though if you're  
showing/hiding/moving a tree control with scripts and/or CSS, it may be  
annoying to have to deal with two elements each time rather than one.)

>>>> Even if goodwill was irrelevant, if you made HTML semantically  
>>>> complete enough to drop <div>, I guarantee you would have added too  
>>>> many block elements for authors to choose the correct one anything  
>>>> like most of the time. <div>, <b>, <i>, <sup>, <sub>, and <span>  
>>>> might be presentational tofu, but they keep HTML from being too  
>>>> complex, and that's important.
>>> ...
>>>   The elements <sup> and <sub> are not entire presentational. For  
>>> example, how do you represent a chemical formula in HTML? If a title  
>>> has a power at the end, how do you indicate that? Granted, they have  
>>> a presentational component to them, but that presentation itself has  
>>> a semantic meaning.
>      (Note that the above reply construction glosses over the fact  
> that I completely don't understand getting rid of <div> and <span>,

I wasn't suggesting <div> and <span> should be abolished; I was  
explaining why they shouldn't be. Any version of HTML which was  
semantically complete enough not to need <div> or <span> would be too  
complex to be understood by any noticable proportion of Web authors,  
and therefore too complex to be used semantically correctly by any  
noticable proportion of Web authors, which would defeat the point of  
having the semantics in the first place.

> unless of course you're suggesting that they be replaced with a  
> display-free element: <styleme class="myStyle">The text I want to  
> style.</styleme>

Such an element would still have a default display: value, which would  
be "inline" unless overridden, so it would be functionally identical to  

> ...
>> Exactly the same applies to <b> and <i> as to <sup> and <sub>.  
>> They're usually used to mean *something*, but a computer can't tell  
>> what it is.
>> <http://mpt.net.nz/archive/2004/05/02/b-and-i>
>> <http://mpt.net.nz/archive/2004/05/09/semantic>
>      Your argument, as presented in these links, is a little soft. If  
> one wants something to be presented using bold or italic, you can use  
> a <span> and CSS.

 From the second link: "the only difference in using <span> is that it  
works for fewer readers".

> And since you state yourself that <b> and <i> can have their  
> presentations neutralized by CSS, while at the same time having no  
> real semantic meaning, you really can't argue that they're better  
> solutions than <span>.

They are, because they work for more readers. (Just like, for example,  
Web Forms 2.0 works for more readers than XForms does.)

> Better to depreciate <b> and <i> and let people resurrect them with  
> XBL later.

So (to paraphrase  
blog=3006739&post=108387135135169014#c1083975062>), your suggestion is  
for people to (a) use CSS so they can (b) apply XBL so they can (c) use  
a method that only works in a tiny minority of browsers for (d) making  
characters bold or italic. As opposed to using <b> or <i>, which takes  
about 1/100 of the time and works for about 20 times as many browser  
users. Hmmm, decisions, decisions.

>      Furthermore, I don't buy your argument that <sup> and <sub> are
> just as presentational as <b>/<i>. For instance, I once had to  
> implement a fake tooltip system in VB using a rich text control  
> because the standard tooltips couldn't display the chemical formulas  
> that my
> employer wanted displayed. Some text information requires <sup> and
> <sub> for you to be able effectively communicate certain information.

Again, I know that <sup> and <sub> are (almost always) used to mean  
something, just like <b> and <i> are. But again, just as with <b> and  
<i>, *a computer can't tell what you mean*. When you use <sup> do you  
mean exponent, or footnote, or moment, or transpose of a matrix, or  
something else? Purely from the markup, a computer can't tell, because  
<sup> is presentational. When you use <sub> do you mean number of atoms  
in (that part of the structure of) the molecule, or variable instance,  
or logarithm base, or matrix index, or something else? Purely from the  
markup, a computer can't tell, because <sub> is presentational.

> ...
>     There is an argument for <b> and <i>, though: For user agents that  
> don't support CSS, taking these elements away leaves you without some  
> very fundamental presentational tools. I think this is a very valid  
> argument, but it's easy to get carried away with it by using it to  
> justify elements like <font>.

Not really. <font> does not fill semantic holes in HTML nearly as  
often, or as essentially, as <b> and <i> do. I would even be happy with  
the deprecation of <tt> in HTML 5, because the world's uses for  
monospace text are covered by HTML's semantic elements to a degree that  
the uses of bold or italics are not.

Matthew Thomas

More information about the whatwg mailing list