27

A blockquote nearly always comes with a source, however the way to format the quote often differs:

Either way, this got me thinking that in UBB the formatting is done for you like this normally:

[quote=http://www.example.com]The quote[/quote]

Which tends to format the source URL in a consistent way in the blockquote. For example something like number 5 above, however right aligned like below.

An example of how this could theoretically look, however do note that 1) I am not a designer, 2) I used &nbsp;'s to format it this way in this preview and 3) the spacing is a bit off as I used <sub> to get the font size different.
                                                                                                       source: http://www.example.com

Which in turn got me thinking whether it wouldn't be a good idea if a similar option would be included in SE markdown.

Concrete proposal

It's far harder in markdown to think up a good syntax than it is in UBB, but I would personally suggest an empty line (just >) and then on the last line of the blockquote the literal string > Source: followed by the source (which can be either an URI, a full markdown link or just text), thus giving:

> blockquote
>
> Source: http://www.example.com

Following the markdown design goals this is fully readable in plain text, it picks up already some of the currently used syntax, but is explicit enough that it should never catch anything it shouldn't have caught. The alternative is dropping the line outside the blockquote like

> blockquote

Source: http://www.example.com

Though I am personally inclined to prefer the first option as the relationship is slightly more explicit.

As far as interaction with the editor goes and the -button, I would suggest that the > Source: line is included by default if clicked without an selection and triggers an error if left empty (the user should either remove the line or enter a source). If the user already has selected a text it could trigger a simple prompt dialog to ask for the source/attribution.

Now, in regards to (further) diverging from the standard: It's important to realize that blockquotes are a first class citizen in the way SE is used. Where one will not find a lot of blockquotes in typical markdown usage (being code), on SE you will find hundreds of thousands of them. And the good thing about this proposed syntax is that it follows markdown philosophy so well that it won't even actively look bad if parsed in an actual standard-abiding markdown parser (it would just look better on SE). (And yes, I am aware commonmark exists, but I am not sure where that project is realistically heading~)

PS. Whilst writing this proposal I found out that 5 years ago somebody brought up this issue in the context of quoting other users and mostly without a concrete proposal. Considering it's 5 years later and this is a far more specific proposal I decided to post it separately like this.

3
  • 5
    This would be a great addition in my opinion.
    – GregRos
    Aug 9, 2015 at 15:58
  • 3
    Since this hasn't been implemented yet, what's the current recommended way of attributing blockquotes?
    – Stevoisiak
    May 22, 2017 at 17:51
  • Is there any recommendation? What is most popular? A lot of semantic info being lost.
    – vaughan
    Sep 1 at 9:19

2 Answers 2

10
+50

I recently brought up this topic on Meta ELU, Citation/attribution for quote in blockquote on ELU. In the course of investigating before posting about the issue, I discovered that the W3C HTML5 recommendation of October 2014 addresses citations/attributions within blockquotes.

The cite attribute of blockquote suggests one approach; however, the cite element is more versatile than the cite attribute, being extensible by class to author, title, url, etc. For coding examples covering a variety of attribution types and contexts, see the discussion in "4.4.4 The blockquote element" of the W3C recommendation.

The responses to my post on Meta ELU confirmed the point that Markdown as implemented on SE doesn't currently support either the cite element or the cite attribute, and suggested that support for those should be requested on SE. Further, use of something like

> quote
> 
>? attribution

in Markdown was suggested in the responses, along with the implementation of an appropriate style rule or rules. The Markdown as suggested and shown above could be transformed to this HTML,

<blockquote>
quote
<cite>attribution</cite>
</blockquote>

then rendered appropriately by style rules, perhaps resulting in something like this:

quote

— attribution

Elaborations of the foregoing are more to my taste (although quite possibly to the taste of few others), for example

> quote
> 
>?a author of source
>?d date of source
>?t title of source
>?u url of source

where any or all of a, d, t, and u are optional. This Markdown might be transformed to HTML such as

<blockquote>
quote
<cite class="author">author of source</cite>
<cite class="date">date of source</cite>
<cite class="title">title of source</cite>
<cite class="url">url of source</cite>
</blockquote>

SE style rules could then govern how the quote and its attribution would be rendered.

10
  • 1
    Markdown should be easily readable without a parser, it's one of the core concepts of Markdown, so the ?a/d/t/usyntax definitely doesn't pass that rule, but beyond that: You're totally right about the generated HTML. Oct 6, 2016 at 7:30
  • @DavidMulder, Well, yes...the email model doesn't have any particular signifier for source attribution, so needs extension. What do you think of the >? suggested by Andrew Leach? Failing that, and sticking to the email model behind Markdown quotes, I'm afraid the best we can hope for is > From: rather than > Source: .
    – JEL
    Oct 6, 2016 at 7:51
  • The ? doesn't mean anything, nor is it a syntax users are familiar with. Personally I think a generic Source: any markdown might be best, because it covers all options. If you want to quote a website: Put a link with the title there, if you want to quote an image: Put just the link there, if you want to quote something you found in a book: Just put a string there, etc. When you need 4 different qualifiers for that you will have to create a pretty complex UI to support that or require the user to remember that from the top of their head. Oct 6, 2016 at 10:15
  • Adding dates could be worth considering, but isn't that already mostly covered by the SE revisions functionality for those rare cases where someone needs it? Oct 6, 2016 at 10:16
  • @DavidMulder, Your comment about dates gives me pause. Dates are a standard part of (some) attributions. For example, a blockquote from a poem by Carl Sandburg might be attributed with, on a separate line at bottom, "-- Carl Sandburg, 'Salvage', 1914". Were you just thinking of attributions referring to other questions/answers on SE sites when you proposed sourcing? If so, I've seriously misunderstood your proposal.
    – JEL
    Oct 9, 2016 at 8:44
  • Nope, attribution in general, I just assumed that you were discussing access dates, which are normally considered important for sources. The date of publication seems like quite an odd candidate to pick out of all possible citation fields. Oct 10, 2016 at 5:52
  • @DavidMulder, as noted, a, d, t and u are just examples of the "elaborations" I favor, with the optimal being extensible to a standard set of bibliographic fields. However, I suspect that we're worlds apart anyhow: date of publication or composition is information I need to evaluate a source, while date of access has little (but not no) bearing. Either way, I'm agreeing with your suggestion, but also suggesting > From: is more in line with Markdown 'philosophy' than > Source:. I'd be happy with either form, though, so long as attribution for block quotes was standardized.
    – JEL
    Oct 11, 2016 at 6:22
  • Realistically I think the most important thing is to motivate people to include it and improve consistency of the UI. Date of publication is something that can always be found by accessing the source, date of access is normally considered important as sources have become fluid (we don't live in the age where a work was published just once). Luckily we can assume that access dates are the same as post publication dates, but just trying to explain where my assumption came from. Oct 11, 2016 at 11:28
  • Either way, I wanted to run a SEDE query to compare how many people write Source: and how many people use From: currently. Personally I don't think I ever saw From: being used naturally by people, but if it's more common then I would totally agree with your proposal. Oct 11, 2016 at 11:29
  • 1
    @DavidMulder Actually, in my ELU answer where a lot of this was taken, I specifically explain >? as meaning "Where does that come from?" Mar 31, 2017 at 13:23
6

Nice idea! I would like it to "trigger" when the whole blockquote is a link, e.g.

[>The quick brown fox jumps over the lazy dog](https://en.wikipedia.org/wiki/The_quick_brown_fox_jumps_over_the_lazy_dog)

Which right now renders as:

>The quick brown fox jumps over the lazy dog

And instead would be cool to have it as:

The quick brown fox jumps over the lazy dog
                                                                                                                                              (source)

3
  • Thx! :) So, are you suggesting that as the main syntax for attribution in blockquotes? Because I considered that as well, but the big disadvantage is that in other markdown parsers it would look terrible. I would be all in favour though of a warning instructing the user how to properly attribute quotes. Aug 9, 2015 at 18:12
  • Yeah, just looks easier to implement. Other parsers aren't relevant, SE use its own branch of markdown as far as I know. Aug 9, 2015 at 18:14
  • Never replied to your comment, but just because SE uses it's own parser doesn't mean that the Markdown original text isn't CC-licensed and that various other sites use it. I personally have for example build an import tool which could selectively import questions from a certain SE network site, and although there were differences in certain minor cases, nearly everything was good to go in one go using a spec compliant parser (only thing I needed to change was automatically adding an enter after lists). Not something major to support or anything, but good to think of :) . Oct 6, 2016 at 10:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .