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
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
