W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2009

[whatwg] Bibliography Markup in HTML5

From: tjeddo <tjeddo@gmail.com>
Date: Mon, 28 Sep 2009 20:37:57 -0700
Message-ID: <fc6666d10909282037r7f8352ebg4b70a10ffe8152a0@mail.gmail.com>
Erik, Thanks for your response.

>> I mean, there is new language support
>> for an 'aside' section element but no 'bibliography' section element!?
> A full-on bibliography (if it's not a separate page) would function
> well as a <section> or <footer>, unless I misunderstand the way those
> elements are supposed to work.

Footnotes certainly make sense within a footer. Although, like you state,
a full-on bibliography might be its own page but doesn't intuitively belong
within a footer--at least in the conventional sense of the word. I guess
that is what disturbs me about what is written in Section 4.4.9 on the
Footer element.

"When the footer element contains entire sections, they represent
appendices, indexes, long colophons, verbose license agreements, and
other such content.

The footer element is not sectioning content; it doesn't introduce a
new section."

Bibliographies and appendices are often one or more traditional page lengths,
which is why I don't think the footer element makes sense here.  Although, I
would be very curious to hear the author's intentions for putting
appendices, indexes, etc. in a footer.  In any case it does seem like
the term 'footer' is being overloaded here.

I think a formal bibliography fits more appropriately within a
<section> as opposed
to a <footer>.  Although, I think the value of the scheme I brought up
in my original
email would be lost.  That is, a user agent could expect bibliography
entries within
the context of <bibliography> tags, but not so if simply in the
context of <section>

>> <bibliography> ...
>> <dt id="refsRFC5322">[RFC5322]</dt>
>> <dd><cite><a href="http://www.ietf.org/rfc/rfc5322.txt">Internet Message
>> Format</a></cite>, P. Resnick. IETF, October 2008.</dd>
>> ...
>> </bibliography>

> 1. There'd need to be some clear-cut understanding about what would go
> in the <dt> and <dd> elements. Would the <dt> before the "citation
> entry" and the <dd> optional for "annotation" or something? Would
> multiple <dd>s be allowed per <dt>? Would authors understand the
> difference? In your example, it feels like <dt> is for "shorthand
> bibliographic entry" and <dd> is for "longer bibliographic entry,"
> which feels a bit cumbersome and offers pretty good odds for repeated
> content.

I agree. Explicit interpretations for the <dt> and <dd> tags would need
to be provided if present between <bibliography> tags--but this is no
different than their contextual definitions given for the new figure and
details elements.

In the bibliography context some attempted definitions might be ...
The 'dt' element's content is a displayed sequence of characters
that a reader uses to associate a citation in the main document content to the
bibliography entry identified by the sequence.

Content examples for <dt> from various citation styles could be:
"[SVG], [13], 13.,..." or the 'dt' element may be empty (in the case
of MLA style)
and simply provide an 'id' attribute that can be linked to in citations.

The 'dt' and 'dd' would occur in pairs.  The 'dt' is the shorthand reference key
that corresponds to the bibliography entry details of the following
'dd' element.

> which feels a bit cumbersome and offers pretty good odds for repeated
> content.
I think the redundency is necessary as a citation within the text will
not always
be exactly the same as the key provided in the 'dt' element of the intended
bibliography entry.  An example citation might look like:

"...it is proven that foo has only three bars <a href="#ref-ABC">[ABC,
pp. 23--24]</a>."

where the corresponding bibliography 'dt' element would look like this:

<dt id="ref-ABC">[ABC]</dt>
<dd>...entry details for ABC...</dd>

That is, specific pages are provided after the key--yet it is still
clear the author
is referring the the [ABC] bibliography entry.

> 2. I'm not sure the <dt><dd> pattern allows for any useful mnemonic
> device related to a dedicated <bibliography> element.

You are right. Although, this is exactly what is being done in the new
'figure' and 'details' elements.  From Section 4.8.1

"The first dt element child of the element, if any, represents the
caption of the figure element's contents. If there is no child dt
element, then there is no caption."

Certainly a new 'caption' element would have been ideal to represent
the caption of a figure.
But unfortunately, HTML5 is trying to reuse existing tags where
appropriate to support
legacy HTML.

While 'dt' and 'dd' are generic, you can arguably convince yourself that the
content of 'dt' is the term or item being defined by or mapped to the 'dd'
definition description.

In summary, it is the W3C's use of <dt> and <dd> for marking up their
entries in their specifications that I thought made the most sense in
the absence of
a more comprehensive bibliography vocabulary.  And placing these
elements in a new
context such as <bibliography> allows you to provide specific
contextual definitions.
Additionally, user agents can unambiguously interpret the contents of
the 'dt' and 'dd'
elements if they encounter them within <bibliography> tags as opposed to <dl> or
<section> tags.

Tim Eddo
Received on Monday, 28 September 2009 20:37:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:52 UTC