Tags: blockquote

9

sparkline

Sunday, April 9th, 2017

Eric’s Archived Thoughts: Grid-Powered Drop Quotes

I’ve been digging into CSS Grid a lot during the past week, so this post from Eric is very timely. On the surface it looks like a fairly simple use case but as you read through the explanation, it starts to become clear that the underlying thinking could be used in a lot of situations.

And, yes, like Eric, I too have been bitten by the Grid bug:

I’m working on my first redesign in a dozen years. If that doesn’t give you some sense of the power of Grid, well, I just don’t know what will.

Tuesday, November 5th, 2013

cite and blockquote – reloaded | HTML5 Doctor

The definition of the cite element (and the blockquote element) has been changed for the better in HTML5 …at least in the W3C version anyway.

Monday, August 19th, 2013

Bruce Lawson’s personal site  : On citing quotations. Again.

The semantics of the cite element are up for discussion again. Bruce, like myself, still thinks that we should be allowed to mark up names with the cite element (as per HTML 4), and also that cite elements should be allowed inside blockquotes to indicate the source of the quote.

Let’s pave that cowpath.

Wednesday, January 30th, 2013

Figuring out

A recent simplequiz over on HTML5 Doctor threw up some interesting semantic issues. Although the figure element wasn’t the main focus of the article, a lot of the comments were concerned with how it could and should be used.

This is a subject that has been covered before on HTML5 Doctor. It turns out that we may have been too restrictive in our use of the element, mistaking some descriptive text in the spec for proscriptive instruction:

The element can thus be used to annotate illustrations, diagrams, photos, code listings, etc, that are referred to from the main content of the document, but that could, without affecting the flow of the document, be moved away from that primary content, e.g. to the side of the page, to dedicated pages, or to an appendix.

Steve and Bruce have been campaigning on the HTML mailing list to get the wording updated and clarified.

Meanwhile, in an unrelated semantic question, there was another HTML5 Doctor article a while back about quoting and citing with blockquote and its ilk.

The two questions come together beautifully in a blog post on the newly-redesigned A List Apart documenting this pattern for associating quotations and authorship:

<figure>
 <blockquote>It is the unofficial force—the Baker Street irregulars.</blockquote>
 <figcaption>Sherlock Holmes, <cite>Sign of Four</cite></figcaption>
</figure>

Although, unsurprisingly, I still take issue with the decision in HTML5 not to allow the cite element to apply to people. As I’ve said before we don’t have to accept this restriction:

Join me in a campaign of civil disobedience against the unnecessarily restrictive, backwards-incompatible change to the cite element.

In which case, we get this nice little pattern combining figure, blockquote, cite, and the hCard microformat, like this:

<figure>
 <blockquote>It is the unofficial force—the Baker Street irregulars.</blockquote>
 <figcaption class="vcard"><cite class="fn">Sherlock Holmes</cite>, <cite>Sign of Four</cite></figcaption>
</figure>

Or like this:

<figure>
 <blockquote>Join me in a campaign of civil disobedience against the unnecessarily restrictive, backwards-incompatible change to the cite element.</blockquote>
 <figcaption class="vcard"><cite class="fn">Jeremy Keith</cite>, <a href="http://24ways.org/2009/incite-a-riot/"><cite>Incite A Riot</cite></a></figcaption>
</figure>

Friday, July 8th, 2011

[whatwg] The blockquote element spec vs common quoting practices

I’m getting behind Oli’s proposal to allow non-quoted footers within blockquotes in HTML. Here’s where I quote the design principles to support his case.

Wednesday, July 6th, 2011

Citation needed

Over on the HTML5 Doctor site, Oli has written a great article called Quoting and citing with <blockquote>, <q>, <cite>, and the cite attribute.

Now, I still stand by my criticism of the way the cite element has been restrictively redefined in HTML5 such that it’s not supposed to be used for marking up a resource if that resource is a person. But I think that Oli has done a great job in setting out the counter-argument:

By better defining <cite>, we increase the odds of getting usable data from it, though we now need different methods to cover these other uses.

Oli’s article also delves into the blockquote element, which is defined in HTML5 as a sectioning root.

Don’t be fooled by the name: sectioning roots are very different to sectioning content in a fundamental way. Whereas sectioning content elements—section, article, nav and aside—are all about creating an explicit outline for the document from the headings contained within the sectioning content (using the new outline algorithm), the headings within sectioning roots (blockquote, td, fieldset, figure, etc.) don’t contribute to the document outline at all! But what sectioning roots and sectioning content have in common is that they both define the scope of the header and footer elements contained within them.

The footer element is defined as containing information about its section such as who wrote it, links to related documents, copyright data, and the like.

This gives a rise to rather lovely markup pattern that’s used on HTML5 Doctor: why not use the footer element within a blockquote to explicitly declare its provenance:

<blockquote>
<p>The people that designed .mobi were smoking crack.</p>
<footer>&mdash;<cite class="vcard">
<a class="fn url" href="http://tantek.com/">Tantek Çelik</a>
</cite></footer>
</blockquote>

(and yes, I am using the cite element to mark up a person’s name there).

Well, apparently that blockquote pattern is not allowed according to the spec:

Content inside a blockquote must be quoted from another source.

Because the content within the blockquote’s footer isn’t part of the quoted content, it shouldn’t be contained within the blockquote.

I think that’s a shame. So does Oli. He filed a bug. The bug was rejected with this comment:

If you want the spec to be changed, please provide rationale and reopen.

That’s exactly what Oli is doing. He has created a comprehensive document of block quote metadata from other resources: books, plays, style guides and so on.

Excellent work! That’s how you go about working towards a change in the spec—not with rhetoric, but with data.

That’s why my article complaining about the restrictions on the cite element is fairly pointless, but the wiki page that Tantek set up to document existing use cases is far more useful.

Sunday, July 3rd, 2011

Examples of blockquote metadata ❧ Oli.jp (@boblet)

Now this is how you make progress on getting changes made to a spec: by documenting real-world use cases.

Tuesday, June 28th, 2011

Quoting and citing with blockquote, q, cite, and the cite attribute | HTML5 Doctor

An excellent article from Oli on markup patterns for quotations …though I still think that the cite element can be used for people’s names.

Monday, December 5th, 2005

DOM Scripting Your Way to Better Blockquotes

This article first appeared in 24 Ways, the online advent calendar for geeks.

Block quotes are great. I don’t mean they’re great for indenting content – that would be an abuse of the browser’s default styling. I mean they’re great for semantically marking up a chunk of text that is being quoted verbatim. They’re especially useful in blog posts.

<blockquote>
<p>Progressive Enhancement, as a label for a strategy for Web design, 
was coined by Steven Champeon in a series of articles and presentations 
for Webmonkey and the SxSW Interactive conference.</p>
</blockquote>

Notice that you can’t just put the quoted text directly between the <blockquote> tags. In order for your markup to be valid, block quotes may only contain block-level elements such as paragraphs.

There is an optional cite attribute that you can place in the opening <blockquote> tag. This should contain a URL containing the original text you are quoting:

<blockquote cite="http://en.wikipedia.org/wiki/Progressive_Enhancement">
<p>Progressive Enhancement, as a label for a strategy for Web design, 
was coined by Steven Champeon in a series of articles and presentations 
for Webmonkey and the SxSW Interactive conference.</p>
</blockquote>

Great! Except… the default behavior in most browsers is to completely ignore the cite attribute. Even though it contains important and useful information, the URL in the cite attribute is hidden.

You could simply duplicate the information with a hyperlink at the end of the quoted text:

<blockquote cite="http://en.wikipedia.org/wiki/Progressive_Enhancement">
<p>Progressive Enhancement, as a label for a strategy for Web design, 
was coined by Steven Champeon in a series of articles and presentations 
for Webmonkey and the SxSW Interactive conference.</p>
<p class="attribution">
<a href="http://en.wikipedia.org/wiki/Progressive_Enhancement">source</a>
</p>
</blockquote>

But somehow it feels wrong to have to write out the same URL twice every time you want to quote something. It could also get very tedious if you have a lot of quotes.

Well, “tedious” is no problem to a programming language, so why not use a sprinkling of DOM Scripting? Here’s a plan for generating an attribution link for every block quote with a cite attribute:

  1. Write a function called prepareBlockquotes.
  2. Begin by making sure the browser understands the methods you will be using.
  3. Get all the blockquote elements in the document.
  4. Start looping through each one.
  5. Get the value of the cite attribute.
  6. If the value is empty, continue on to the next iteration of the loop.
  7. Create a paragraph.
  8. Create a link.
  9. Give the paragraph a class of “attribution”.
  10. Give the link an href attribute with the value from the cite attribute.
  11. Place the text “source” inside the link.
  12. Place the link inside the paragraph.
  13. Place the paragraph inside the block quote.
  14. Close the for loop.
  15. Close the function.

Here’s how that translates to JavaScript:

function prepareBlockquotes() {
  if (!document.getElementsByTagName || !document.createElement || !document.appendChild) return;
  var quotes = document.getElementsByTagName("blockquote");
  for (var i=0; i<quotes.length; i++) {
    var source = quotes[i].getAttribute("cite");
    if (!source) continue;
    var para = document.createElement("p");
    var link = document.createElement("a");
    para.className = "attribution";
    link.setAttribute("href",source);
    link.appendChild(document.createTextNode("source"));
    para.appendChild(link);
    quotes[i].appendChild(para);
  }
 }

Now all you need to do is trigger that function when the document has loaded:

window.onload = prepareBlockquotes;

Better yet, use Simon Willison’s handy addLoadEvent function to queue this function up with any others you might want to execute when the page loads.

That’s it. All you need to do is save this function in a JavaScript file and reference that file from the head of your document using <script> tags.

You can style the attribution link using CSS. It might look good aligned to the right with a smaller font size.

If you’re looking for something to do to keep you busy this Christmas, I’m sure that this function could be greatly improved. Here are a few ideas to get you started:

  • Should the text inside the generated link be the URL itself?
  • If the block quote has a title attribute, how would you take its value and use it as the text inside the generated link?
  • Should the attribution paragraph be placed outside the block quote? If so, how would you that (remember, there is an insertBefore method but no insertAfter)?
  • Can you think of other instances of useful information that’s locked away inside attributes? Access keys? Abbreviations?