[whatwg] Web Forms 2.0 Feedback

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 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 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 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 
<http://tecknik.net/blogback/data/bb.php? 
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 or , 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 and are (almost always) used to mean 
something, just like and are. But again, just as with and 
, *a computer can't tell what you mean*. When you use 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 
 is presentational. When you use 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 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. does not fill semantic holes in HTML nearly as 
often, or as essentially, as and 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
http://mpt.net.nz/