W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2007

[whatwg] <blockquote cite> and <q cite>

From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Date: Wed, 03 Jan 2007 20:35:01 +0000
Message-ID: <1167856502.7682.151.camel@galahad>
Anne van Kesteren wrote:
> Well, the reason I started this thread was to provide a replacement /  
> alternative to the cite="" attribute as defined for the <blockquote> and  
> <q> elements using some terminology the HTML5 proposal already provided.  
> Mostly to make the metadata more "visual".

An unambiguous association between q/blockquote and a cite URI is the
key thing. The spec as it stands currently lacks this for q without the
cite attribute.

I'm not constitutionally opposed to making the metadata "more visual" in
itself, although I think it would be more user-friendly, efficient, and
flexible to require UAs to expose the metadata than to require authors
to produce a rendering themselves. It would also be a bit of a break
with tradition, but one I think would ultimately be for the best.

So long as we have an unambiguous association, we could at least write
tools to regenerate citation text in a different citation style
automatically. Of course, then one might begin to wonder why authors
were being required to write out, mark up, and style citation text in
the first place ...

I do think authors still need to be able to specify their own citation
metadata when required, largely because of failings in HTML's document
structure which mean that with many documents you can get a fragment
identifier but can't work out what that fragment actually represents:
it's just another div. (Although an id like "comment-345" does give one
a clue.) Fortunately, HTML5 will make that situation a bit better thanks
to the <article> element.

Of course one could bring custom metadata of this sort within the URI
model easily enough, by using a TinyURL-type lookup service that
included the metadata in the URI.

--
Benjamin Hawkes-Lewis
Received on Wednesday, 3 January 2007 12:35:01 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:51 UTC