W3C home > Mailing lists > Public > public-html@w3.org > August 2013

Re: Proposal for the deprecation of <blockquote>

From: Heydon Pickering <heydon@heydonworks.com>
Date: Thu, 15 Aug 2013 17:17:09 +0100
Message-ID: <CAJFUXE-inHy3ZTjKyPqkKkZCg9XiL=Cv6ikKb7_G4NSPvWeU1Q@mail.gmail.com>
To: public-html@w3.org
Hi Karl,

It appears that Wikipedia's emphasis on the W3C's non-semantic
definition of <blockquote> is over-egged. Perhaps one of us should
edit it? :-)

That aside, I'm not at all convinced about the use of <cite> as a
means of attribution for quotations. The <cite> element is already
notoriously misunderstood
and it would take a specification change just to make it an applicable
element. This is even before we begin to cludge together the
relationship between
<blockquote> and <cite>.

In addition, your "in context" example (reproduced below) appears to
be erroneous, since the unsemantic <div> element used to encapsulate
the <blockquote> and the
<p> (<cite> AND <a rel="author">) cannot be considered a thematic
container. That is, there's no (meaningful) shared context for
<blockquote> and the following <p>.

<div class="quote">
<blockquote cite="uri-quote"><p></p></blockquote>
<p><cite><a href="uri-book">book title</a></cite>, <a
href="uri-author" rel="author">Author-Name</a></p>
</div>

The material you asked me to read offers using a [cite] and [id]
relationship (http://wiki.whatwg.org/wiki/Cite_element). Have you
forgotten to provide the ID that is suggested
for the [cite]/[id] relationship? I know I'd forget if it was me, as
well as many other feckless authors :-)

Compare this with <figure> and <figcaption>, where the relationship is
clear and author advice gives guidance on how to deploy the
<figcaption> so that the relationship
is not broken (as either a first child or last child WITHIN the
context of the <figure>
http://www.w3.org/TR/html5/grouping-content.html#the-figcaption-element).

Here's an example:

<figure>
<p>Please discuss on the list not on twitter. Or drop me from the
twitter discussion.</p>
<figcaption>said by Karl Dubost</figcaption>
</figure>

Note that suggested user agent styles make <figcaption> a block level
element. There's no need for extra paragraphs, but they are permitted
if needed (the spec permits "flow content").

A more complex example, based on yours:

<figure>
<p>The quotation</p>
<figcaption><cite><a href="uri-book">book title</a></cite>, <a
href="uri-author" rel="author">Author-Name</a></figcaption>
</figure>

In this example, not only are the figure's contents and its caption
actually in thematic context (figure actually means something, unlike
<div>), but the "book title" and "author" citations are also
semantically associated as each being components of a common
<figcaption>.  I think it's fair to say that a "caption" means
"explanation"
(https://www.google.co.uk/search?q=caption+definition&ie=utf-8&oe=utf-8&rls=org.mozilla:en-GB:official&client=firefox-a&gws_rd=cr)
and that author and source attributions are both
sound components of an explanation .In your example, they are only
members of a basic paragraph; a paragraph that does not belong to a
<blockquote> or anything else meaningful.

Even if the paragraph _was_ inside the blockquote, it doesn't mean
"caption". In other words, the following common pattern is less
semantically clear and incisive than the preceding example:

<blockquote>
<p>The quotation, this time in a paragraph</p>
<p><cite><a href="uri-book">book title</a></cite>, <a
href="uri-author" rel="author">Author-Name</a></p>
</blockquote>

To make your method work, we'd have to redefine <cite>, then possibly
incorporate [cite] and [id] attributes to cludge a relationship
between "quotations" and "citations". That's a lot of work
for spec writers, vendors and authors who are supposed to use the
resulting patterns. I think it's a lost cause.

Alternatively, the <figure>/<figcaption> construct already exists, is
semantically appropriate (it is _not_ reserved for graphics alone) and
much easier to write and remember.
Received on Thursday, 15 August 2013 16:17:41 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:34 UTC