Re: Proposal for the deprecation of <blockquote>

I'm all for using Microdata / RDFa (although microdata now appears to be
off the agenda, since the API has now been dropped from webkit and blink
http://manu.sporny.org/2013/microdata-downward-spiral/).

However, I disagree that a generic caption-like element represents an
"advanced" use case. There are many circumstances where we want to use an
element that simply "describes its parent" in this way and I think the
already numerous (legitimate) uses suggested in the spec' for <figure>
supports this argument.

If I stretch the definition of <figure> just slightly, I am already
entitled to describe a quotation with a <figcaption> (including <cite>s and
whatever else). This leaves <blockquote> as a bit of an anomaly, hence the
original proposal for deprecation.

I appreciate that <caption> is probably the wrong way to go for the reasons
you describe, but I still think <cite> is not enough. <cite> and <caption>
do two quite different tasks: The first is to define the source of the
information, while the other is to "explain" it. I may wish to explain the
information with a source, or I may not. I may not wish to include an
explanation at all. This is legitimate with <figure> but inefficable
(currently) with <blockquote>: If the quotation _must_ be from a separate
source, I should really include a link or reference to this source. In this
case I have two shoddy options, one verbose one and one that's currently
not supported for authors:

   - the cite attribute (boo!)
   - a paragraph or link or something
   - various RDFa attributions
   - child <cite> element

I'm completely in support of your proposal to change the definition of
<cite> to include author (and organisation?) names, as well as the guidance
change to have <cite> as a child of blockquote.

This just leaves the problem of quotation descriptions that aren't _just_
the name of the person.

It seems to me that the following is inadvisable...

<cite>said Heydon</cite>

...but surely, the following is no good either:

<blockquote>

   <p>I want to deprecate the blockquote</p>

   <p>said <cite>Heydon</cite> on his blog, <cite>HeydonWorks</cite> at
<time>6 o'clock</time></p>

</blockquote>

"Said" and "on his blog" are essentially orphans and it would take more
parser complexity to establish that the second paragraph is not part of the
quotation than it would with

<blockquote>

   <p>I want to deprecate the blockquote</p>

   <blockcaption>said <cite>Heydon</cite> on his blog.
<cite>HeydonWorks</cite> at <time>6 o'clock</time></blockcaption>

</blockquote>

If <blockcaption> is advised to be a direct child of <blockquote>,
disentangling it would be easy for user agents / AT etc.

What do you think the chances are of introducing <blockcaption> as
essentially a duplication of <figcaption> with the same relationship to
<blockquote> as <figcaption> is to <figure>? I'm all for it, but I thought
giving <blockquote>'s responsibility to <figure> would be easier.






On Fri, Aug 16, 2013 at 8:08 AM, Bruce Lawson <brucel@opera.com> wrote:

> On 15 August 2013 21:19, Heydon Pickering <heydon@heydonworks.com> wrote:
> >
> > The reason I suggest <figure> over <blockquote> is by the simple
> expedient
> > that <blockquote> doesn't have an equivalent of
> > <figcaption>; it doesn't have an element for saying "a bunch of
> information
> > - author, source, description, whatever - about the
> > thing".
>
> There's no reason why a <div> and some spans can't be hooked up with
> RDFa/ microdata for a bunch of information, inside a <figure> and
> <figcaption> now for "advanced" use-cases like that.
>
> My proposal to allow <blockquote> Blah <cite>Your
> mum</cite></blockquote> is for simple, common uses such as those
> documented by Oli Studholme http://oli.jp/example/blockquote-metadata/
>
>  >
> > Ultimately, <figcaption> is clumsily named. We should be using
> <caption>, as
> > we do with tables, for both <blockquote>s and
> > <figure>s. In fact...
>
> If we were starting with a clean slate, yes.This was suggested, but
> <caption> is weird - there are legacy pages, legacy CMSs and legacy
> browsers to be supported. See this 2006 discussion, for example
>
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-November/007971.html
>