[whatwg] The blockquote element spec vs common quoting practices

There is another common pattern, seen in blogging a lot, of putting
the citation at the top eg
As <cite class="vcard"><a href="http://www.gyford.com/phil/"
class="url" rel="acquaintance met colleague"><abbr title="Phil Gyford"
class="fn">Phil</abbr></a></cite> wrote about the <a
href="http://www.gyford.com/phil/writing/2009/04/28/geocities.php">ugly
and neglected fragments</a> of Geocities:</p>

<blockquote>
  <p>GeoCities is an awful, ugly, decrepit mess. And this is why it
will be sorely missed. It?s not only a fine example of the amateur web
vernacular but much of it is an increasingly rare example of a
<em>period</em> web vernacular. GeoCities sites show what normal,
non-designer, people will create if given the tools available around
the turn of the millennium.</p>
</blockquote>

(from jeremy) or pretty much any post here:

http://www.theatlantic.com/ta-nehisi-coates/

Would a <header> pattern in the blockquote work for this?

If I was writing a detector for this pattern, <a> followed by a colon
and  <blockquote> would do it pretty reliably...

On Fri, Jul 8, 2011 at 4:20 AM, Jeremy Keith <jeremy at adactio.com> wrote:
>
> Oli wrote:
> > I?ve outlined the problem and some potential solutions (with their
> > pros and cons) in:
> > ?http://oli.jp/2011/blockquote/
>
> Excellent work, IMHO. I've added my own little +1 here: http://adactio.com/journal/4675/
>
> Oli continues:
> > I think the blockquote spec should be changed to allow the inclusion
> > of notes and attribution (quote metadata), perhaps by the addition of
> > a sentence like:
> > ??Block quotes may also contain annotations or attribution, inline or
> > in an optional footer element?
> > This would change blockquote from being purely source content, to
> > being source content with possible metadata inline or in a footer.
> > However I don?t think that?s a problem, as these things increase the
> > value of the quoted content. I think a spec change is necessary to
> > accommodate common quoting practices.
>
> This sounds good to me.
>
> 1) Oli has shown the real-world use cases for attribution *within* blockquotes. I know that the "Pave the cowpaths" principle gets trotted out a lot, but Oli's research here is a great example of highlighting existing cowpaths (albeit in printed rather than online material):
>
> http://www.w3.org/TR/html-design-principles/#pave-the-cowpaths
>
> "When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new."
>
>
> 2) This is something that authors want, both on the semantic and styling level (i.e. a way to avoid having to wrap every blockquote in a div just to associate attribution information with said blockquote). I believe that the problem statement that Oli has outlined fits with the HTML design principle "Solve real problems."
>
> http://www.w3.org/TR/html-design-principles/#solve-real-problems
>
> "Abstract architectures that don't address an existing need are less favored than pragmatic solutions to problems that web content faces today."
>
>
> 3) The solution that Oli has proposed (allowing footer within blockquote to include non-quoted information) is an elegant one, in my opinion. I can think of some solutions that would involve putting the attribution data outside the blockquote and then explicitly associating it using something like the @for attribute and an ID, but that feels messier and less intuitive to me. Simply allowing a footer within a blockquote to contain non-quoted material satisfies the design principle "Avoid needless complexity."
>
> http://www.w3.org/TR/html-design-principles/#avoid-needless-complexity
>
> "Simple solutions are preferred to complex ones, when possible. Simpler features are easier for user agents to implement, more likely to be interoperable, and easier for authors to understand."
>
>
> 4) Because the footer element is new to HTML5, I don't foresee any backward-compatibility issues. The web isn't filled with blockquotes containing footers that are part of the quoted material. Oli's solution would match up nicely with the design principle "Support existing content."
>
> http://www.w3.org/TR/html-design-principles/#support-existing-content
>
> "The benefit of the proposed change should be weighed against the likely cost of breaking content"
>
> Jeremy
>
> --
> Jeremy Keith
>
> a d a c t i o
>
> http://adactio.com/
>
>

Received on Thursday, 14 July 2011 11:59:02 UTC