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:12:52 +0000
Message-ID: <1167855172.7682.130.camel@galahad>
Henri Sivonen wrote:

> Assuming that putting an ISBN URI in attribute somewhere solves  
> anything on its own is an illusion. If the source is hidden metadata,  
> it is mostly useless, because the reader doesn't read it. If the UA  
> is expected to render the information about the source somehow, the  
> problem of presenting sources is just moved to a different place.

In other words, if UAs are forced to display citation information, then
authors no longer have to worry about it. Sounds good to me.

> I'll be more convinced about "tools will save us" once I first see  
> that working on a smaller scale than the Web. Let's say TeXlipse with  
> the described UI generating BibTeX entries and inserting the proper  
> \cite{} on the LaTeX side.

I'm baffled by this. I don't know enough about Tex or TeXlipse to
understand why you think this would be a helpful test of the interface.
I'm not even sure how it would apply to the Tex world. As far as I can
see, it's like asking for an implementation of anchor links in TeXlipse.
Might you elaborate on why this would be a better proof of concept than
a Firefox extension?

> How much data is provided depends on the type of writing. If someone  
> quotes someone else's blog, quotation marks and a plain <a href link  
> back are enough. 

Well, perhaps. But an interface like I am describing would be less
complicated than the current process of copying text, putting it in
quotation marks, copying a link, putting it in an <a> element, writing
some link text, and then correcting the link so that ampersands are
correctly encoded.

> If you want to designate the source, you need to know it and express  
> it in a human-readable way. I am not suggesting any particular  
> formatting. 

But authors /do/ have to use particular formattings: those typographic
conventions you mentioned earlier.

> Not having to bear the cost of producing semantic quotation markup.
> Metadata and semantic markup are *not* without a cost.

You need to factor the real costs of linking to web content and of
concocting print-style citations with markup and CSS into your equation.
The "metadata" is the same in either case.

> Out of the feature range that UA implementors might want to implement

Why mightn't UAs want to implement it?

> ?Quotation? (<a href='...'>Source</a>)
> 
> Punctuation and plain links go a long way for human readers.

There is no way for machines to conclusively differentiate quotation
punctuation from non-quotation punctuation. If a human listener (e.g. a
screen reader user) wishes to sure that she is not missing quotations,
she must listen to all the punctuation. Even then, it may be somewhat
unclear. But listeners do not want to listen to all the punctuation,
because the majority of it is superfluous.

Using punctuation instead of markup also makes it harder to go back and
find the quotation text in the source, or to verify that quotations are
accurate.

With plain links, all the metadata has to be structured and formatted a
s link text.

In any case, there is nothing preventing UAs rendering q and cite in
that fashion.

>  And I am unconvinced that authors would be willing to spoon feed data mining  
> tools, considering that the beneficiaries of such spoon feeding are  
> not the authors themselves nor even their direct human audience.

So you want to quote a book. Do you choose to:

a) Spend a minute gathering the relevant information and arranging it
into a marked up and styled citation?

b) Spend three seconds typing an ISBN into a box and get the same
result?

I choose b).

(As an aside, people seem quite happy to spoon feed data mining tools.
They'll even pay for the privilege. Look at LibraryThing and Delicious
Library!)

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

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