[whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5

Thu Mar 22 14:25:38 PDT 2007

On Oct 30, 2006, at 22:33, Ian Hickson wrote:

> On Sun, 29 Oct 2006, Henri Sivonen wrote:
>> FWIW, I think <samp> and <kbd> don't deserve to be in HTML and I  
>> am not
>> convinced that the use cases for <var> could not be satisfied by <i>.
>
> I'm lukewarm on all three, but the cost to keeping these is probably
> slightly less than the cost to removing them, so I'm tending towards
> keeping them...

I tend to agree. But then they should not be used as a basis for  
arguing anything about the design of HTML5 or as bases for analogies  
for including new "semantic" elements of similar kind.

>> I can't remember seeing any use case-based rationale for the <t>
>> element. I'm not convinced that having it is a good idea.
>
> <t> (or an equivalent) has been widely requested, especially in the
> microformats and CSS communities. Several microformats have need for
> encoding specific times and/or dates, and are currently (ab?)using  
> <abbr>
> for this purpose.

OK.

> The CSS community has requested a <date> or <time>
> element because they want to restyle dates and times according to  
> locale.

I tend to think that this has huge potential for people getting  
confused and missing appointments. Time zones are impractical and  
confusing enough without DWIM changing them.

> Also, the aforementioned research indicated that there are substantial
> amounts of content on the Web that uses invented elements, IDs, and  
> class
> attributes to mark up dates and times. For example, I found about  
> the same
> number of pages with the obscure ID "updatedtime" as I did pages  
> with a
> <button> element; "date" was the 14th most frequently seen class name.

However, merely marking up something as *a* date without knowing  
*what* date is not particularly interesting. (Compare with the  
fluffiness of Dublin Core.)

>> I'm inclined to think that the <cite> element is useless. <i>  
>> could be
>> used for marking up titles of works and <b> could be used for  
>> magazine
>> and newspaper-style marking up of first instance of personal names. I
>> have yet to see a markup consumption use case that would work on the
>> public Web and would use <cite>.
>
> <cite> is used more than <button>. It's used almost as often as <h6>.
>
> One of the reasons for keeping <var>, <cite>, <em>, etc, separate,  
> instead
> of saying that authors should just use <i> for all of them, is that it
> makes styling them differently much easier.

Assuming, of course, that you want to style them differently instead  
of just italicizing all of them.

I am still on the fence about using <cite> in my thesis. Currently I  
am using it to mark up titles of works.

> (Why is <i class="var"> better than <var>?)

It isn't. But <i> is better than <var> for editor UIs if all you want  
to do is to italicize (the common case).

>>>     * note and reference for footnotes, endnotes, and sidenotes (not
>>> aside in “HTML5”)
>>
>> Yes, this is an area where document and converter authors  
>> currently need
>> to come up with their own class-based hacks. Ideally a continuous  
>> media
>> user agent could show footnotes in context so that they don't  
>> become de
>> facto endnotes.
>
> If anyone has any ideas on this, please post them to the list. (The  
> CSS
> group is also looking at footnotes closely.) One thing to consider  
> when
> looking at footnotes is "would the title="" attribute handle this  
> use case
> as well as what I'm proposing?". If the answer is "yes", or  
> "almost", then
> it's probably not a good idea to introduce the new feature.

I am not happy with title='' for footnotes.

First, there are all the usual objection against putting natural- 
language text in attributes.

Second, tooltips (the typical screen media presentation of title='')  
have significantly different properties compared to print footnotes  
when it comes to reader attention. Tooltips aren't very discoverable  
and are inconvenient to read. Footnotes, on the other hand, are  
rather easy to read. Moreover, footnotes containing prose (as opposed  
to just URIs or other identifier data) actually work as a device for  
emphasizing stuff that the author pretends to de-emphasize while  
knowing that (s)he is really emphasizing. Tooltips don't work like  
this. I remember reading somewhere (I forget where) that many people  
read the footnotes first when they turn a new page in a book.

This is why I'd be interested in being able to turn <aside>s into  
footnotes in print.

>>> * bibliographies, tables of contents, and indices (some in “HTML5”)
>>
>> One of the issues here is the tension of HTML as an authoring  
>> format and
>> HTML as a delivery format. That is, do we really want the browser  
>> to do
>> the stuff BibTeX does? OTOH, if the browser just displays output  
>> from a
>> bibliography generator, what level of semantic encoding is actually
>> useful for the consumers of the document? PDF doesn't attempt to go
>> further than identifying what blocks are bibliography entries. Is  
>> that
>> useful enough to bother? If the markup is very detailed so that  
>> Google
>> Scholar (or whatever) could analyze cross-references in scientific
>> papers, wouldn't that veer back into focusing on computer science
>> papers?
>>
>> I, for one, am writing about HTML5 in LaTeX. One of the reasons was
>> BibTeX even though I have to hack a .bst of my own.
>
> I have to be honest that personally I've not really found a need for a
> bibliography tool. In fact, the preprocessor I use to generate the  
> WHATWG
> specs (the one that does all the cross-references) supports automatic
> bibliography generation, but I go out of my way to not use it and  
> to do
> the bibliography manually. (And the WF2 spec doesn't have a small
> references section!)
>
> But if you could eloborate on exactly what it is you need in terms of
> bibliography in HTML5, it's certainly an area open for discussion.

Actually, I don't think HTML5 should leave bibliography formatting to  
the browser. There are just too many ways to want to micromanage the  
bibliography presentation. I guess that leaves HTML as both an  
editing format and a delivery format but the editing and delivery  
instances cannot always be the same. Instead, intermediate processing  
on the authoring side is needed.

BTW, after writing what is quoted above, I moved from .tex, .bib,  
TeXlipse and LaTeX to .xhtml, .bib, oXygen, TeXlipse and Prince. So I  
got rid of LaTeX but kept .bib. To make it work, with the help of the  
TeXlipse lead developer, I wrote a special-purpose bibliography  
generator for XHTML that uses the .bib parser from TeXlipse.

It appears that the microformat folks are working on hCite. I can't  
figure out what hCite is exactly (see the thread starting at http:// 
microformats.org/discuss/mail/microformats-discuss/2007-March/ 
008996.html ), but it seems to me that isn't workable as a hand- 
authoring format. Instead, you'd have to generate it from something  
like .bib.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/