Over a million developers have joined DZone.

Pull Quotes and a Little HTML Philosophy

DZone's Guide to

Pull Quotes and a Little HTML Philosophy

· Web Dev Zone ·
Free Resource

Jumpstart your Angular applications with Indigo.Design, a unified platform for visual design, UX prototyping, code generation, and app development.

Many front-end articles out there talk about solutions. About bugs, workarounds and fixes, methodologies, best practices and major development fails. Most articles out there tend to be quite definitive, comfortable with what they are preaching even though our field of work is a maze of gray areas and uncharted territories. So let's not do that today, instead let's write an article that poses more questions than it answers. Today let's talk pull quotes.

The Nature of Pull Quotes

A pull quote is a small blurb of text from an article that is replicated and given extra visual attention. It differs from a real quote in the sense that it doesn't reference an external source, instead it highlights a snippet of text from the page it is on. One article can feature one or more pull quotes, usually depending on the size of the article. If you still don't know what I'm talking about, you can check this article from theverge.com, the pull quotes are the big orange blurbs of text in between the paragraphs.

There are two good reasons for using pull quotes. First of all they brighten up the design considerably. Instead of plain text/image articles you can insert some color and visual trickery into the reader's flow. But they also serve a more functional purpose. A pull quote teases people into reading the article. It uses these little blurbs of text to draw the attention, gently urging the reader to look for the context of the quote. Some variations exist, magazines for example usually don't make a spacial link between the appearance of the source text and the pull quote, forcing you to scan the entire article for the context of the quote. A website like The Verge places its pull quotes closer to their source text, giving them more of an orientation function while scrolling through the article.

Now that we know what they are, how do we translate these elements to html?

The Dilemma

If you're pressed for time and you're set on taking the easy way, pull quotes pose little to no real problems. They are small snippets of text, wrapped in a container that contains a class for specific styling demands. The structural source position of a pull quote is there where it appears on screen. To be honest, that's how I've been implementing them. It's clear and simple, but something didn't feel right.

When reading an article on The Verge the pull quotes often start offscreen, unable to draw the reader's attention. Once you start reading the actual article they scroll into view, but if the article is interesting enough by itself their function becomes purely visual. Then when you finally encounter them in the flow of the article you're still bound to read them. When they appear close to their source snippet though, this makes for a pretty weird effect (you're actually reading the same thing twice).

Since a pull quote is a mere duplication of existing content, the question is whether is it feasible to include them into the source of your html and should you opt do so, where to put them structurally. I've been trying to think it through and I've come up with two separate approaches (none of which are actually easy or worth the trouble, but still).

Pull Quote Goes into the HTML Source

      <section class="pullquotes"> 
          <div class="pq" data-quoteref="(pqid)"><a href="(pqid)...</a></div> 
	<div class="main"> 
		<div id="(pqid)></div> 

Starting from the concept of a magazine pull quote (the point of such a quote is to be seen right away), structurally speaking the quotes belong in the header of the article. They aren't truly part of the body content, instead they function as a kind of teaser (a list of quotes) that hopes to convince the reader to go through the entire article. If you take The Verge variant into account you can also link the quotes and use them as anchors to jump to its related context (just as long as they don't conflict with potential other in-article navigations, in that case I would forgo the links and depend on the anchor navigation instead).

It really all depends on what you as an author prefer. Either have people read through the entire thing, or have them skip easily to a selection of interesting sections while ignoring other parts of the article. As for the order of the pull quotes themselves, they should probably best follow the natural order of their appearance in the article.

Pull Quote is Generated

	<div class="main"> 
		<div clas="pq" id="(pqid)></div> 
		<span data-quoteref="(pqid)">...</span> 

The second option starts from the idea that a pull quote is merely replication of existing data and should therefor not be present in the source. It presents no additional value to the content itself and should only be shown to people using a visual browser. So we let javascript do the dirty work of duplicating them. The only thing we do here is span the portion of text to be quoted and define a destination for the duplication of the quote.


Like I said, I probably wouldn't implement neither of both solution I presented above, simply because the gain is not proportionate to the effort to implement it. But if I leave all practical considerations behind, I'm still not really sure which method I'd prefer. The first one is nifty alright, but it puts more distance between the start of the document and the point where the actual content of the page starts, on the other hand the teaser quotes might truly pull in an extra volume of readers. The second solution is cleaner but doesn't give you the extra teasing content, hence losing out on potentially useful functionality.

As for fallback mechanisms, both methods do require javascript but since a pull quote is just duplicated content the fact that they won't appear isn't much of an issue. The first method does retain its extra functionality even with javascript disabled though, so that's a definite plus.

Did I miss anything or there are any other great solutions out there? Other perspectives and ideas are definitely welcomed. This is just my two cents, but I feel it's something worth pondering about when you have a spare minute.

Take a look at an Indigo.Design sample application to learn more about how apps are created with design to code software.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}