Template talk:Blockquote/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

HTML <p> tags not added correctly

Resolved

 – Problem isn't happening any more.

As mentioned a couple of times above, this template is not correctly placing things into paragraphs. Judging by the comments, and the template's help text, it once did, so I think that should be restored. For instance, this is the HTML result of {{quote|Line 1<br/> Line 2<br/> Line 3<br/> Line 4.}}, the example from #line breaks above:

<blockquote class="templatequote">
<div>Line 1<br />
<p>Line 2<br />
Line 3<br />
Line 4.</p>
</div>
</blockquote>

To see why this is a problem, look at this longer example (subst'ed):

The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog.

The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog.

The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog. The quick brown fox jumps over the lazy dog.

The line spacing is different in the first paragraph compared to the following two, as is the first inter-paragraph space compared to others. Quietbritishjim (talk) 20:25, 25 February 2011 (UTC)

Cannot reproduce this any longer. It was probably not a problem with this template, but something in the site-wide stylesheet long since fixed. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 15:50, 2 February 2012 (UTC)

Remove line break to stop template from breaking discussion closes

Resolved

 – Fixed.

Currently the {{quote}} template breaks discussion closes, see Wikipedia:Articles for deletion/1929 Ottawa sewer explosion. Once the quote template is used, the box stops, and does not extend to the end of the discussion. I ran into this problem once before, and fixed it by nowiking the quote, but as it is a reoccuring problem, I think we need to fix it. I have sandboxed a fix for the template at {{Quote/sandbox}}. The only change is the removal of a line break, see the change. It will fix the problem, as demonstrated in my sandbox: problem with original template, change to sandboxed version problem gone. Monty₈₄₅ 03:40, 10 October 2011 (UTC)

 Fixed, that's a strange one ... — Martin (MSGJ · talk) 16:33, 10 October 2011 (UTC)

Template with more features, compatibility; please test

Moot

 – Quote and Bq templates have merged.

{{Bq}} appears to offer the main features of this template, and many others. Can anyone break it? I am aware from this talk page that sometimes people find ways to make {{Quote}} produced unexpected output. I'd like to get its basic code fixed before trying to replicate the more nit-picky functions of this template. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 17:12, 2 February 2012 (UTC)

Line breaks

Resolved

 – Workaround provided for intractable known MediaWiki bug, and added to template documentation.

The following: {{quote|Line 1<br/> Line 2<br/> Line 3<br/> Line 4.}} produces:

Line 1

Line 2
Line 3

Line 4.

Why is there a <p> only after the first line? Is there an alternative way of quoting (verses, etc.) with line breaks? Shreevatsa (talk) 06:34, 12 November 2009 (UTC)

There is definitely something wrong still. The HTML output of the above example, when it hits the browser, is:

<blockquote class="templatequote"> <div>Line 1<br /> <p>Line 2<br /> Line 3<br /></p> Line 4.</div> </blockquote>

That's weird. We shouldn't see <p>...</p> markup at all in the absence of an actual blank line in the wiki source (which we couldn't use anyway, due to T8200; see #Lists, below for an explanation), or manual markup forcing it, e.g.:

:{{quote|Line 1<br /> :<p>Line 2<br/><br /> :Line 3<br/></p><br /> :Line 4.}}

The really weird thing is the closure of the <p>...</p> after Line 3. Anyway, this almost has to be a MediaWiki bug not a template error, but may take extensive testing to figure out and report at MediaWiki Bugzilla, if it's not been reported already. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 16:38, 2 February 2012 (UTC)

Various test cases to confirm my suspicions

Testing indented version: Line 1 Line 2 Line 3 Line 4. Testing minor markup differences: Remove your stray space character after Line 2</br />: Line 1 Line 2 Line 3 Line 4. All on one line: Line 1 Line 2 Line 3 Line 4. Move the <br>'s: Line 1 Line 2 Line 3 Line 4. All of the above unindented: Line 1 Line 2 Line 3 Line 4. All on one line: Line 1 Line 2 Line 3 Line 4. Move the <br>'s: Line 1 Line 2 Line 3 Line 4.

Yep, this is definitely T8200; the only solution for this is to use unbroken markup:

Line 1
Line 2
Line 3
Line 4.

However, as I reported below at #Lists, there is an HTML comment workaround for readability that let's you do whatever you want, and is even indentable:

{{quote|1=<!--
-->Line 1<br/><!--
-->Line 2<br/><!--
-->Line 3<br/><!--
-->Line 4.}}

Or even:

{{quote|1=<!--

-->Line 1<br/><!--

-->Line 2<br/><!--

-->Line 3<br/><!--

-->Line 4.}}

Result of either:

Line 1
Line 2
Line 3
Line 4.

This should make poetry editing much easier.

 Done: The template documentation needs to be has been updated with an example like this.

— SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 01:20, 3 February 2012 (UTC) Updated 08:58, 3 February 2012 (UTC)

Lists

Resolved

 – Workaround provided for intractable known MediaWiki bug, and added to template documentation.

• The following two paragraphs are in a single {{quote}}.

  This text is followed by two newlines.

This text should be indented.

The last paragraph is not even in a <blockquote> element, never mind the <ul>. I think this is a consequence of Bugzilla 6200. The workaround mentioned in the template documentation (which makes newlines turn into <p>s) doesn't help here. {{Cquote}} behaves correctly but at the expense of unsightly oversized quotation marks. Hairy Dude (talk) 17:02, 2 February 2012 (UTC)

Yes, that is precisely the case. You have to use consecutive markup:

• The following two paragraphs are in a single {{quote}}.

  This text is followed by two newlines.

  This text should be indented.

There is no way around this because of T8200.

There is, however an HTML comment cheat you can use to at least make it more readable/editable:

• The following two paragraphs are in a single {{quote}}.

  This text is followed by two newlines.

  This text should be indented.

We can just hope that this "perennial bug" get fixed some day. They say they're working on a badass new parser, but they've been saying that for years. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 00:46, 3 February 2012 (UTC)

Thanks for the workaround and especially docs. Bug 6200 is really annoying! Hairy Dude (talk) 13:28, 6 February 2012 (UTC)

Some parameter aliases for compatibility with (replacement of?) Template:Epigraph

Moot

 – Quote and Epigraph templates have merged.

{{Editprotected}} Make |quote= an alias of |text=, and |cite= an alias of |sign=. (i.e. {{#if:{{{text|{{{quote|{{{1|}}}}}}}}|...}} markup). We can then simply redirect the ancient, obsolete {{epigraph}}, which is otherwise essentially identical to {{quote}} (or eventually to {{Bq}}, which is being developed with even more features. Regardless, {{epigraph}} has no reason to exist any longer. It was originally intended for pull quotes, but has long since been superseded by {{cquote}}. Even if someone finds some new use for it, there is no reason for the parameters to not be compatible so that templates can be converted between, at will with trivial ease in articles. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 00:37, 3 February 2012 (UTC) PS: If we really, really, really want to preserve the kinda pointless difference between the templates of spacing between the quote and the citation, we can add another if-test for it, but that's a serious WP:DGAF matter. PS: The template is only used on a few hundred articles at all. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 00:49, 3 February 2012 (UTC)

Can we just replace uses of epigraph with quote instead of bloating this template? — Bility (talk) 16:40, 7 February 2012 (UTC)

Sure, if you want to manually or AWB-wise edit the name of and parameters on that template on the 267 pages that use it, be my guest. :-) — SMcCandlish   Talk⇒〈°⌊°〉 Contribs. 17:56, 13 February 2012 (UTC)

Okay, I'll get on AWB when I get home. — Bility (talk) 19:12, 13 February 2012 (UTC)

Pretty much done, the only thing left are user pages and archives. — Bility (talk) 09:45, 14 February 2012 (UTC)

Perhaps someone should put a not on the epigraph doc page telling people not to use it anymore? D O N D E groovily Talk to me 13:35, 14 February 2012 (UTC)

Done. Can this request be closed? — Bility (talk) 16:52, 14 February 2012 (UTC)

Everything seems to be fine here, so deactivating the request. Tra (Talk) 20:47, 17 February 2012 (UTC)

Bare div tag

Resolved

Why is there a pointless <div>...</div> around the {{{text|{{{1}}}}}} content, with no styling, no class, no id, no reason or use for a div being there? Did I miss some geeky reason this was added? Is it just a bit of leftover dead code from when all the styling was moved into the site-wide CSS file? — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 15:53, 31 January 2012 (UTC)

Oh, I found out why: It's because of T8200. Please change <div>...</div> to <div class="Bug6200">...</div>, as at {{Bq}}, so we know why it's there and know it can be removed when that MediaWiki bug is fixed. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 17:11, 2 February 2012 (UTC)

 Done Tra (Talk) 05:28, 18 February 2012 (UTC)

Proposed change to make consistent with HTML5 and improve accessibility

Resolved

 – Technical problem was resolved in the merger with {{Bq}}.

In HTML5, the <cite> tag is reserved for titles only. [1] Therefore, its current use in the template is invalid HTML5 and may cause problems down the road, and in particular may cause accessibility problems for screen readers. Therefore, I want to make two technical changes. First, common.css should be changed to:

/* Styling for Template:Quote */
blockquote.templatequote { 
     margin-top: 0; 
}
blockquote.templatequote .attribution { 
    line-height: 1em;
    text-align: left;
    padding-left: 2em;
    margin-top: 0;
}
blockquote.templatequote .attribution .source {
    font-size: 85%;
}

Second, the template should be changed to:

<blockquote class="templatequote"><div>{{{text|{{{1|<noinclude>{{lorem ipsum}}</noinclude><includeonly>{{error|Error: No text given for quotation (or equals sign used in the actual argument to an unnamed parameter)}}</includeonly>}}}}}}
</div>{{#if:{{{sign|{{{2|<noinclude>TRUE</noinclude>}}}}}}|<div class="attribution">—{{{sign|{{{2|<noinclude>[[Someone's full name|Someone]]</noinclude>}}}}}}{{#if:{{{source|{{{3|<noinclude>TRUE</noinclude>}}}}}}|, <span class="source">{{{source|{{{3|<noinclude>''Source''</noinclude>}}}}}}</span>}}</div >}}</blockquote><noinclude>
{{documentation}}
<!-- Add cats and interwikis to the /doc subpage, not here! -->
</noinclude>

COGDEN 08:48, 6 May 2011 (UTC)

Yeah, this actually is a real issue. Correct use of <cite>...</cite> would be:

{{quote|text={{Lorem}}|sign=Anne O. Nymus|source=''<cite>The Unlightable Being of Bareness</cite>'', 1992, p. 37}}

It's a manual, human judgement thing. So this still needs to be fixed. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 15:46, 31 January 2012 (UTC)

Just FYI, this problem has been fixed in {{Bq}}; just get the code to do so from there. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 15:48, 2 February 2012 (UTC)

Please could you clarify what needs changing - perhaps put the required change in the sandbox subpage? Tra (Talk) 05:34, 18 February 2012 (UTC)

Whenever you're ready, just add back {{editprotected}}. Tra (Talk) 23:13, 18 February 2012 (UTC)

Problem with Cquote redirecting to Quote

Resolved

{{cquote}} currently redirects here, even though it doesn't take the same parameters. This is from an old revision of Polish resistance movement in World War II:

{{cquote|Within the framework of the entire enemy intelligence operations directed against Germany, the intelligence service of the Polish resistance movement assumed major significance. The scope and importance of the operations of the Polish resistance movement, which was ramfied down to the smallest splinter group and brilliantly organized, have been in (various sources) disclosed in connection with carrying out of major police security operations.||| [[Heinrich Himmler]], 31 December 1942<ref name="occupation"/>}}

I assume that was correct when it was written. With the new definition of {{cquote}}, the final parameter was ignored, and the article had an error message about the "occupation" reference being defined but not used. I've fixed this one, but how many other quotations are no longer displaying their reference? -- John of Reading (talk) 17:57, 4 January 2013 (UTC)

...and the redirect has been undone, so don't waste any time on this. -- John of Reading (talk) 19:27, 4 January 2013 (UTC)

Quotemarks in example

Resolved

An example in the documentation says: "Cry “Havoc” and let slip".
This looks like a violation of MOS:QUOTEMARKS, since it uses "tilted" quotemarks (“...”) rather than "typewriter" quotemarks ("...").
—BarrelProof (talk) 15:31, 10 May 2013 (UTC)

Yes,  fixed --Redrose64 (talk) 17:59, 10 May 2013 (UTC)

Possible bug w/ section headers?

I don't know where else to post this, hope this is the right place. In the article Comcast Corp. v. FCC I came across an issue where a section heading following a quote was not displaying. The heading (The FCC’s new net neutrality rules) showed up in the TOC but not in the text. I corrected this by adding a '.' after the template at this edit [2], but that's obviously a cheap hack. Could someone look into this? Maybe it's just my browser but I'm using FF fully updated under KUbuntu most current stable release (13.04). Anyways, I know jack about templates, so if this isn't the right place, please bring this to the proper place. Eaglizard (talk) 08:37, 22 June 2013 (UTC)

I've seen this before, possibly with {{quote box}}, but I don't recall how we fixed it at the time. In this case, the headings were present but displaced off the right-hand edge of the screen. You can verify that they're present by going to this version, marking text from "Decision on Comcast v. FCC ^[6]" to "The FCC released", copying to clipboard and pasting somewhere else - what gets pasted is "Decision on Comcast v. FCC [6] The FCC's reaction The FCC released".

I've moved these headings back into the visible area by adding {{clear}} immediately after each {{quote box}}. --Redrose64 (talk) 09:56, 22 June 2013 (UTC)

Problem

Resolved

I enabled the "beta" Typography refresh setting. Since then, I have noticed that the black quotation marks generated by this template display on top of images, infoboxes, etc. In other words, they do not adjust to their surroundings. I did not notice this before enabling the new typography setting. --Another Believer _(Talk) 15:20, 27 March 2014 (UTC)

This template does not add fat quotes, it is done by the new CSS. Please give us an example of alignment issues. --  Gadget850 ^talk 15:24, 27 March 2014 (UTC)

I've seen several occurrences, but here is one example. On my screen, the left quotation mark is on top of the picture of Liza Minelli. --Another Believer _(Talk) 15:45, 29 March 2014 (UTC)

The blockquote changes are not part of the Typography Refresh, but were included in the Typography Refresh as part of the beta. If that doesn't make sense, then see Wikipedia:Village_pump_(technical)#Blockquotes. As best I understand this, the blockquote changes will be reverted on April 3. --  Gadget850 ^talk 16:32, 29 March 2014 (UTC)

With the typography update applied yesterday, the Typography Refresh beta was removed and only the font CSS updates were applied. This is no longer an issue. --  Gadget850 ^talk 14:09, 4 April 2014 (UTC)

Protected edit request on 10 April 2014

Resolved

At present, the combined effect of the class="templatequotecite" and <cite>...</cite> tag on the source parameter is to reduce its rendered size to 78% of normal. This causes accessibility problems for visually impaired visitors and violates our recent guidance at Wikipedia:Manual of Style/Accessibility #Text: "Avoid using smaller font sizes in elements that already use a smaller font size .... In no case should the resulting font size drop below 85% of the page fontsize (or 11px)."

One simple solution which preserves the semantic markup would be to use a span with "font-size:larger" around the source parameter. I've made an example modification to the sandbox.

Current

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

— Someone, Source

Sandbox

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Someone, Source

If further differentiation between |sign and |source is desired then a reduction of around 92% at each step would leave the source at 85% of page font size, but would entail further tweaking via spans to partially offset the effect of class="templatequotecite". RexxS (talk) 20:44, 10 April 2014 (UTC)

@RexxS: at the moment, the "Source" text appears bigger than the "Someone" text in my browser (Firefox, Ubuntu). This seems a bit unnatural - is it possible to make it the same size or slightly smaller? Best — Mr. Stradivarius ^{♪ talk ♪} 03:52, 11 April 2014 (UTC)

@Mr. Stradivarius: There's a bigger problem here, that I've just realised by looking at this in FF, where I wasn't logged in. Monobook is rendering the entire quote smaller than the page font size, but Vector renders them the same font size. Are you using Vector?

Anyway, I've now reduced the compensation in the sandbox from "font-size:larger" to "font-size:1.17em" which might also give more consistent results across browsers. See how the sandbox version looks now. We should probably hold off on making any changes at the moment to this template as the problem of "small within small" text only seems to occur in Monobook and the fix may lie there. --RexxS (talk) 07:58, 11 April 2014 (UTC)

Ok, I've marked the request as answered for now. When you're aware of a good fix, please feel free to make a new request. (Although I suppose you don't actually have to now that I've lowered the protection level to template editor.) — Mr. Stradivarius ^{♪ talk ♪} 09:29, 11 April 2014 (UTC)

I think you made the fix overly complex. Simply remove class="templatequotecite", as its only purpose is to make the <cite> smaller. --  Gadget850 ^talk 09:44, 11 April 2014 (UTC)

I've put that fix in the sandbox. The font size looks better on Firefox/Vector to me, but the sign and source parameters are no longer indented. Maybe we should fix the class in MediaWiki:Common.css instead? — Mr. Stradivarius ^{♪ talk ♪} 10:01, 11 April 2014 (UTC)

Also, yes, I'm on Vector. — Mr. Stradivarius ^{♪ talk ♪} 09:52, 11 April 2014 (UTC)

I've removed the offending font-size from Common.css, so there should be no more trouble in Monobook. I don't know why the source cite should be so small anyway. — Edokter (talk) — 12:17, 11 April 2014 (UTC)

Merge with Template:Bq

Moot

 – The templates have merged.

A merge of {{Bq}} with this template is being considered at Wikipedia:Templates for discussion/Log/2014 November 29#Template:Bq. Comments are welcome, thanks! —PC-XT+ 01:24, 9 December 2014 (UTC)

Extra carriage return?

Resolved

Hi, I posted a comment today using the quote template and I notice one space precedes the quotation, and two spaces follow it. Is this on purpose?

Tarantino stated that he had tremendous fondness for the works of Alan Smithee, remarking:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.^[1]

However, filmmaker Martin Scorcese described Smithee's works as "doo doo".^[2]

It seems to do this whether I put the "However" line on a different line or right after the quote. It looks weird to me, although if that's a MOS standard, I'll gladly yield. Thanks in advance for any edification. Cyphoidbomb (talk) 19:27, 6 January 2015 (UTC)

The template uses a blockquote, which has a generous default bottom margin. So yes, it is normal. -- [[User:Edokter]] {{talk}} 19:32, 6 January 2015 (UTC)

Protected edit request: most recent edit has broken it

 Fixed

The most recent edit, by Gadget850, has broken the template, which displays {{{author author name}}}. Can someone please revert it? — OwenBlacker (Talk) 13:26, 10 January 2015 (UTC)

Fixed by adding the missing "|" character rather than reverting. SiBr₄ (talk) 13:33, 10 January 2015 (UTC)

Facepalm --  Gadget850 ^talk 14:07, 10 January 2015 (UTC)

What error?

Resolved

Can anyone explain this line from § Restrictions?

“If you do not provide quoted text, the template generates a parser error message, which will appear in red text in the rendered page.”

The only way it makes sense to me is if it means quotation marks, which don’t belong around a blockquote and don’t cause an error. —174.141.182.82 (talk) 15:09, 12 April 2015 (UTC)

If there is no content, then an error is displayed. -- Gadget850 ^talk 16:08, 12 April 2015 (UTC)

{{quote}} →

Ohh, it’s referring to the text itself. Thanks, and sorry for my confusion. —174.141.182.82 (talk) 16:39, 12 April 2015 (UTC)

Huge quotation marks

 Invalid

 – Wrong kind of template; issue doesn't apply to this one.

Hello. I have an experience editing on Wikia. I'm just curious why doesn't have this the quotation mark thingy like those of the cquote template. The cquote template is used in some articles and it messes up with the infobox. NejiLoverr26~TheCurseWriter 12:58, 4 June 2012 (UTC)

I saw the same problem and used cquote as a workaround: [3]. Since that works, maybe someone can figure out what is wrong with quote (compare quote and cquote, I don't understand template language) and fix that (and "revert" my change, only relevant part). comp.arch (talk) 19:24, 10 March 2014 (UTC)

Because {{Centered pull quote}} (aka {{cquote}}) "is a template meant for pull quotes, the visually distinctive repetition of text that is already present in the same article. In most cases, this is not appropriate for use in encyclopedia articles." "NOTE: This template should not be used for quotations if they are not repeated elsewhere in the main text." --  Gadget850 ^talk 19:51, 10 March 2014 (UTC)

I saw that it was not appropriate. Decided to do it anyway as it is a workaround. What are the implications? It seems to "work" (better than before, take a look). Anyone can revert but please inform if there is a better way or even possible to fix this template in the meantime. comp.arch (talk) 10:22, 11 March 2014 (UTC)

If you saw that it was inappropriate, why did you do it anyway? There's no workaround for "it's inappropriate". The quotation at that page is not a pull quote, it's a block quote. I've put it back to using the correct template, like the rest of Wikipedia does. Please see MOS:QUOTES. We don't want giant quotation marks in articles around block quotations. The use of actual pull quotes (which that was not) is very rare in WP articles.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:58, 29 July 2015 (UTC)

Not visible when wrapped around a left-aligned image

Moved to #Fixing the display problem with images

I have tested this in both Safari 5.0 and Firefox 3.6.3 on OS X. As far as I can tell, there are (at least by default) no visible style attributes associated with the blockquote element except a left indent. If the text is not up against the left edge of the frame, then the quoted text is not visually distinctive in any way at all. Example:

This paragraph is not in a quote template. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi consectetur semper turpis, vitae gravida odio pulvinar in. In tincidunt purus a risus bibendum et dictum lorem laoreet. Proin vel nulla erat, vel commodo felis. Etiam dapibus dictum odio, nec eleifend neque volutpat in. Sed vel erat nibh, sed aliquam felis. Nullam neque nulla, vehicula nec ornare in, ultrices in magna. Fusce tempor ultrices tortor, vel tempus dolor mattis adipiscing. Donec vestibulum interdum fermentum. Integer vel tellus dolor. Nunc ligula sem, gravida quis eleifend vitae, auctor id purus.

This paragraph is in a quote template, but the only way you're going to know that is by looking at the source. In dictum posuere elementum. Pellentesque gravida tristique sodales. Nulla vel purus ut arcu iaculis facilisis rhoncus in sapien. Etiam cursus lobortis eros, sit amet gravida sem commodo eget. Sed auctor mollis ligula, quis pretium ipsum malesuada et. Nam eget risus a risus tristique bibendum vitae in elit. Etiam dui justo, mollis vel elementum eget, fringilla sit amet ligula. Maecenas sit amet diam a tortor bibendum varius. Phasellus a ligula non felis molestie pretium. Fusce congue magna eget odio tristique consequat. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Maecenas dolor nulla, eleifend vitae tristique ut, pellentesque ac mi. Aenean gravida justo vel justo gravida ornare. Mauris lacinia est sit amet massa tristique hendrerit. Vestibulum faucibus urna quis mauris posuere sed mollis sapien accumsan. Donec dui diam, malesuada eget aliquam in, feugiat aliquam sem. In vel turpis magna, quis mattis ipsum. In hac habitasse platea dictumst. Curabitur ut elementum libero. Sed lorem ante, bibendum ut hendrerit ut, porttitor vitae tortor.

This paragraph is not in a quote template. Ut consequat lorem sit amet elit posuere eget feugiat enim aliquam. Maecenas pellentesque ullamcorper orci vitae consequat. Phasellus sit amet nisl quis enim sagittis pellentesque. Sed fringilla hendrerit aliquet. Suspendisse nec lacus eget nunc venenatis condimentum. Mauris euismod, quam quis commodo tincidunt, sem dolor fringilla enim, et mattis tortor magna non mi. Duis sed facilisis nisl. Fusce luctus orci non orci ultrices sed tristique magna dapibus. Nullam facilisis porttitor neque. Pellentesque id felis vel leo volutpat suscipit. Praesent pellentesque odio diam. Nullam gravida fermentum velit, quis interdum ligula fermentum at. Quisque eget diam leo, pulvinar congue arcu. Proin id pellentesque nunc. Nunc non erat nunc. In hac habitasse platea dictumst. Nulla pulvinar, sem sit amet mollis pretium, lectus ligula accumsan urna, volutpat eleifend libero purus eget augue. Donec non sodales risus. Suspendisse ligula dolor, rutrum quis molestie a, tristique eget justo. Sed suscipit, eros a hendrerit accumsan, purus nulla euismod dui, eget sodales nisi est sit amet eros.

The same issue exists with the {{bquote}} template.

Capedia (talk) 20:31, 12 June 2010 (UTC)

This is (I think) an issue with HTML standards - unless wikipedia defines its own unique blockquote element. normal text is not 'aware' of floating elements: blockquotes are defined by indenting the text a couple of ems from the left containing margin and when a float pushes the text more than a couple of ems to the right, the parser decides that the indenting rule is satisfied. I don't think there's anything that can be done about that. --Ludwigs2 21:56, 12 June 2010 (UTC)

OK. What brought me here was the Battle of Iwo Jima article, where this problem is manifest in the paragraph beginning "In light of the above situation." I guess the best solution is to use {{quotation}} (or {{cquote}}?) instead of the {{bquote}} template that the article currently uses. I think I'll go make that change now. Capedia (talk) 00:35, 13 June 2010 (UTC)

I'd be surprised if there isn't a way around this (not with this particular template but with a deeper change, like another div added to the output of all pages. Bears looking into. I may try to some test casing if someone bugs me to do so (i.e. if people care enough about this to leave me a talk page message asking me to spend time on it). I'm reasonably good at figuring out CSS annoyances. See below. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 15:57, 2 February 2012 (UTC)

Actually someone already proposed something we can use to work around this: Template talk:Quote/Archive 1#Adding indenting parameter?. I think it is a good idea. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 16:46, 2 February 2012 (UTC)

Why was this proposal not implemented? Not being able to left-align images with a blockquote is a pain when designing an article. It needs fixing. Darkwarriorblake (talk) 21:07, 12 January 2013 (UTC)

This problem is still occurring in the middle of 2014... Some guy (talk) 05:00, 28 May 2014 (UTC)

I'm shocked this wasn't fixed already. Only took minutes to work out what the issue was. See #Fixing the display problem with images.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:48, 30 July 2015 (UTC)

Doesn't produce source in tagline if there's no sign, and other odd output

Resolved

I've been having a bit of trouble in the article George Orwell trying to quote some text from the man himself.

The cause of the trouble is that Quote won't put out the tag line if there's no sign parameter, neither specified positionally nor as a named parameter.

I don't want to have to put "George Orwell" as the sign parameter, because it's obvious from the context that we are quoting from Orwell, i.e. the subject of the article itself. While harmless, it's redundant and ugly (in my opinion).

I've added some test cases to demonstrate this. I've done the same for the other parameters, for balance. I note also that if sign is specified but not source, the sandbox version (but not the live version) currently puts out an extraneous end comma after the signature.

I also notice that if you don't supply any text it just puts out the tag line.

Any or all of these may or may not be intentional. At least, I think they should be documented better rather than the dreaded "why is this template not working?" syndrome. I'm happy to add stuff to the documentation once we agree what should happen; this is not one of those "somebody should do something about this" calls. I think not having any text should be an error, but perhaps it is deliberately optional so you can just use {{quote}} to provide a tag line.

I haven't looked whether this affects other variants of this template ({{rquote}} and so on); I guess their implementations could be shared, providing a tag line in some template {{tagline}} or something, which encapsulates these "rules" in one place.

I come here first to get opinions on what should happen. Not putting out a provided source just because there is not a provided sign (i.e. silent failure) does not seem a good option; if sign is intended to be required to get source to be put out, an error should be generated if it's not supplied. I can see exactly where it's going "wrong" (from my perspective) in the template source, i.e. that parameter 3 (or source) is only put out if parameter 2 (or sign) is present (it's inside the if-condition). The fix, then, is fairly trivial (and I'll probably go do that in the sandbox), but of course we need consensus.

Si Trew (talk) 09:57, 15 July 2010 (UTC)

Yeah, this should be fixed; it's kind of stupid. It also makes it impossible to quote anonymous works like the Bible. I would suggest an optional |anon=y parameter, which suppresses the sign code, and to modify the sign code to display an error if it is empty and the anon parameter is empty or absent. That would appear to take care of all cases. Anyway, the bug reported here is still certainly happening:

{{quote|1={{Lorem}}|source=Foo|sign=}}

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

— Foo

Trickery doesn't work:

{{quote|1={{Lorem}}|source=Foo|sign= }}

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

—  , Foo

since, as reported over a year ago by Si Trew, it outputs a bogus comma-space. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 16:53, 2 February 2012 (UTC)

I've fixed this properly, no trickery required, and no bogus comma-space:

{{quote|1={{Lorem}}|source=Foo}}

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

— Foo

Let me know if this somehow manages to break something (though I'd be surprised, since I tested all possible combinations of source and sign and everything worked fine in my tests). 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 13:05, 18 June 2015 (UTC)

Good show!  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:31, 30 July 2015 (UTC)

Paragraphs

Resolved

There is something wrong with the template in splitting text into paragraphs. Previously when using the template, if one left a space between two paragraphs, the template would, naturally, recognise this and have the quoted text split into paragraphs as required. For some reason, it is not doing this one and the template is combining the text into a single solid block; I only noticed this issue yesterday. Does anyone know how to fix this, without having to resort to using multiple forced line breaks (<br/>) when quoting? Cheers, Abraham, B.S. (talk) 01:02, 14 November 2009 (UTC)

Nevermind: it seems User:Rjanag has fixed it. :) Cheers, Abraham, B.S. (talk) 01:07, 14 November 2009 (UTC)

It doesn't work if the quote is indented with a colon. --Apoc2400 (talk) 20:36, 20 November 2009 (UTC)

It doesn't work if there is a colon prior to the opening braces, whether intended as an indent or otherwise. I've just experienced the problem and fixed it with this edit, after a conflab with a couple of people with rather more experience than myself. This is rather an awkward bug, given that it sometimes means we have to abandon decent grammar. I might need to find an alternate template for this situation, but preferably not the blockquote HTML markup. - Sitush (talk) 03:17, 14 November 2011 (UTC)

Whatever the issue was, it is no longer happening as of July 2015: [4]. Unless it's a browser-specific problem. If it's still happening for you, we'll need more information.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  05:03, 30 July 2015 (UTC)

Vanishing quotes

Wrong venue. Please move to MediaWiki talk:common.css

 – This is problem with a CSS rules for blockquote{} in common.css, not this template's fault.

There seems to be a problem with quotes nested between userboxen - see the invisible quote on User:Notafly. Shyamal (talk) 08:39, 15 September 2014 (UTC)

What is the problem? --Redrose64 (talk) 11:17, 15 September 2014 (UTC)

I see the Nietzsche and Goethe quotes. What browser are you using? --  Gadget850 ^talk 11:26, 15 September 2014 (UTC)

The quotes essentially do not show (I changed my user page due to the same problem). And you are right about browser specificity. Works ok on Firefox 25 but I was checking in Chrome (desktop) Version 25.0.1364.97 but I thought I saw something similar in the inbuilt Android (a "recent" version, will check it up if needed) web browser as well. Shyamal (talk) 12:08, 15 September 2014 (UTC)

By "the quotes essentially do not show", do you mean that the quote marks - "..." - are not appearing, or that the text enclosed by the {{quote}} template is not appearing? --Redrose64 (talk) 16:20, 15 September 2014 (UTC)

Sorry for the bad description. The quoted text, quotes - everything gone, but the first quote shows up not the next. A white block appears where the text should be. Screenshot and here is the HTML :

<div class="wikipediauserbox" style="float:left;border:1px solid #6EF7A7;margin:1px;width:238px;">
<table style="border-collapse:collapse;width:238px;margin-bottom:0;background:#C5FCDC;">
<tr>
<th style="border:0;width:45px;height:45px;background:#6EF7A7;text-align:center;font-size:14pt;color:black;padding:0 1px 0 0;line-height:1.25em;vertical-align:middle;white-space:nowrap;;"><a href="/wiki/English_language" title="English language">en</a></th>
<td style="border:0;text-align:left;font-size:8pt;padding:0 4px 0 4px;height:45px;line-height:1.25;color:black;vertical-align:middle;">This user is a <b><a href="/wiki/Category:User_en-N" title="Category:User en-N">native</a></b> speaker of <b><a href="/wiki/Category:User_en" title="Category:User en">English</a></b>.</td>
</tr>
</table>
</div>
<blockquote class="templatequote">
<p>“In der Beschränkung zeigt sich erst der Meister” Natur und Kunst</p>
<div class="templatequotecite">—<a href="/wiki/Goethe" title="Goethe" class="mw-redirect">Goethe</a></div>
</blockquote>
<div class="wikipediauserbox" style="float:left;border:1px solid Black;margin:1px;width:238px;">
<table style="border-collapse:collapse;width:238px;margin-bottom:0;background:#A0A0A0;">
<tr>
<th style="border:0;width:45px;height:45px;background:white;text-align:center;font-size:8pt;color:black;padding:0 1px 0 0;line-height:1.25em;vertical-align:middle;">ACADEMIC JOURNAL</th>
<td style="border:0;text-align:left;font-size:8pt;padding:0 4px 0 4px;height:45px;line-height:1.25em;color:black;vertical-align:middle;">This user has had his/her work published in an <b><a href="/wiki/Academic_journal" title="Academic journal">academic journal</a></b>.</td>
</tr>
</table>
</div>

Shyamal (talk) 02:34, 16 September 2014 (UTC)

Nothing to do with this template. It's a general MediaWiki bug with the <blockquote> element, and should be reported as one, if it hasn't been already (though I'm not sure what the procedure is these days, since they abandoned Bugzilla; there's a page of instructions at mw:How to report a bug). I've demonstrated this isn't a bug in the template, at Template:Quote/testcases-disappearing. Walk through the history of that page to see the tests proving it (I left the page blanked, because we don't want the page being categorized in user categories by the userboxes used in the test data). In the interim, the problem can be worked around by using <div> instead of <blockquote>. The bug is weird, because the content literally does disappear. It's not invisible. If you copy-paste the entire page into a text editor, the text of the missing quotation(s) is not there; but if you view the page source the code to display it is present, and there's no obvious indication why it would not be rendered. For me (Chrome browser, Mac OS X) the Nietzsche quote is there and rendered properly, while the Goethe one, and its <cite> have been replaced by an empty whitespace block. Swapping in some other element makes the content appear.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  04:29, 30 July 2015 (UTC)

The problem appears to be at least related to the overflow: hidden; applied to blockquote in MediaWiki:Common.css; disabling this rule in Chrome's developer tools causes the quote(s) to display normally. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 05:41, 30 July 2015 (UTC)

Ooh, good catch. I guess that'll need to be tested further there. That rule was added for a reason, too, so it probably shouldn't just be deleted. Might just be a matter of reordering where it appears. I've confirmed on that tescases page that using overflow:inherit works. This is rare enough I'll just document it in the /doc page and mention the workaround at Mediawiki talk:common.css.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:23, 30 July 2015 (UTC)

Template-protected edit request on 18 August 2015

Please remove or <noinclude> the TfM notice in the template body; this template has over 50,000 transclusions and is unlikely to be significantly affected by a merger. Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 11:39, 18 August 2015 (UTC)

@Jc86035:  Already done by Jonesey95. --Ahecht (TALK
PAGE) 15:50, 18 August 2015 (UTC)

Barquote

I've created a new quotation template, {{barquote}}, which might be worth considering integrating into the rest of the set of quotation templates. At the moment, it's only used in one article, but that might change. -- The Anome (talk) 10:34, 18 August 2015 (UTC)

Quotation temple TfD

FYI

 – Pointer to relevant discussion elsewhere.

There's potentially important TfD at Wikipedia:Templates for discussion/Log/2015 August 18#Template:Barquote, some possible results of which are (given what has been proposed so far):

• A change to site-wide block quotation style, by merging the new {{Barquote}} template into {{Quote}} as its new default style.
• A change to the site-wide block quotation template, by merging the new {{Barquote}} template into {{Quote}} as an optional style that has not been subject to any consensus discussion; this would permit and effectively encourage the addition of random, editor-preferred styles that vary from article to article.
• A change to WP:MOS to more explicitly state that we have a single, consistent block quotation style. This is presently true, as we have one block quotation template at {{Quote}} – aside from this new "competing" one at TfD – and it applies style consistently via CSS code in Mediawiki:Common.css. Such a clarification might need to happen anyway, since there's some evidence that people are using inline CSS to elaborately mark up block quotations in unusual ways).
• No change other than deleting the variant template.

Which ever of these you think is the best result, or if you think TfD is not the right venue for that discussion, you should probably comment in some way at the TfD in question, since at least two of these results would have a WP:FAITACCOMPLI effect of changing site-wide approach to block quotation style without their being any WT:MOS (or Template talk:Quote) discussion about it.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:20, 1 September 2015 (UTC)

Fixing the display problem with images

Unresolved

 – Discussion of a solution is open at Mediawiki talk:Common.css#Fix for very long-standing problem of blockquote not working with images

I've identified what the problem (first reported in 2010) is, and what the fix is. Add the following CSS to the <blockquote>: margin-left: 0; margin-right: 0; padding-left: 2.8em; padding-right: 2.8em;

I've sandboxed this at Template:Quote/testcases-images, in multiple browsers, on multiple OSes.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:50, 30 July 2015 (UTC)

Update: I've brought it up at MediaWiki talk:common.css, since it's something that should be fixed for <blockquote> generally. But we might have to settle for fixing it in this template only, given the amount of resistance there usually is to implementing anything at that page, especially if only one person brings it up.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  05:14, 30 July 2015 (UTC)

Teeny little bug

 Dupe

 – Same issue that is resolved in thread just above this.

On Otto Hahn ([the latest intact version] or others before it), there are many block quotes, but one that has some images to its left does not get indented. (Just search for "A NEW ELEMENT".) Two browsers (Firefox, ie11) refuse to indent there. It was the same when it used <blockquote>text</blockquote> (the previous intact version); it stayed the same using {{quote|text}}. If you narrow the window until the quote is pushed down below the images, the quote gets indented. If you widen the window, no matter how wide, the quote is not indented. (So it's not a matter of having sufficient room in the middle to indent both sides.) It's scary when a formatter has no effect whatsoever. ((The whole darn Web is busted!!!)) This behavior might be a mistake in "all" web browsers, or not; I can't say; but even if some browsers render it as expected (I haven't tried Safari, good (old) Opera, Chrome), it would probably never get corrected.

Maybe a different CSS for {{quote|text}} would fix the indenting of text on the right side of images (or between left-side and right-side images). (The text has to indent both sides from effective margins, not the whole page or column's margins.) Or maybe changes to the images' HTML or CSS would make it work as intended. Or maybe there is just no way to make the images define a text box that has irregular sides, instead of residing inside a text box that has straight sides. As a last resort, a rearrangement of the page would be needed. (I didn't set out to redesign the page layout, so I'm not ready to start fiddling and fighting with it right now. Maybe later.) -A876 (talk) 04:10, 30 July 2015 (UTC)

This is a duplicate of the bug resolved in the thread immediately above this.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  04:37, 30 July 2015 (UTC)

(It might be a duplicate of the above, but I see no similarity in the descriptions. The images display fine; the quoted paragraphs display incorrectly in the presence of images.) (You brought the above in from elsewhere, which links here, but the above doesn't link back.)

Thanks. Great work. Very interesting.

The actual template is not yet corrected. (When do "they" get around to that? (When "they" left a template unprotected and someone dared to put in a tested edit, "they" hurriedly reverted it, saying (effectively) "I'm scared".))

Without a corrected template, up to four paragraphs in Otto Hahn (before edit) still display with the problem (quotes with no indentation on either side when between an image on the left and on image on the right). So I tried changing the worst affected paragraphs using your "proposed fix". (I had to look around because you present several formulations, including some that only indent one side correctly.) (Also, I think it is preferable to override the template, not the HTML tag, as you recommend above.) (Also you do not show the complete HTML code above. The complete HTML code is embedded in your demo page: <blockquote style="margin-left: 0; margin-right: 0; padding-left: 2.8em; padding-right: 2.8em;">Text...</blockquote>.)

When I replaced {{quote|Text...}} with your example code {{quote|style=margin-left: 0; margin-right: 0; padding-left: 2.8em; padding-right: 2.8em;|Text...}}, the paragraphs indented correctly on both sides: Otto Hahn (after edit).

The same fix would probably help several more quotes on that page which have images only on the right, because the default template does not handle them properly either, indenting them on the left, but failing to indent them on the right. -A876 (talk) 07:15, 18 August 2015 (UTC)

@A876: 'When do "they" get around to that?' – It's still under discussion, but there seems to be consensus to fix it, at the Mediawiki talk:Common.css thread.

'When "they" left a template unprotected and someone dared to put in a tested edit, "they" hurriedly reverted it, saying (effectively) "I'm scared".' I know. It's a long-standing problem, and I'm not sure what the solution is. I run into this "you can's do anything with CSS without my 'permission' first"-style problem pretty frequently. It's difficult to get any action to take place at MW:Common.css, and the same parties who slow things down there have a tendency to go around reverting attempts to fix the issue with inline CSS at the template level, leading to protracted disputes.

The test page was intended to show that some potential "solutions" only indent one side correctly, and/or do not scale; the solution actually under discussion at MW:Common.css is the correct one (the one you quote above), though someone wants to use a fixed, non-scaling 40px version instead of 2.8em. If you'd like to encourage speedier action (regardless what version of the fix you prefer), that discussion is at Mediawiki talk:Common.css#Fix for very long-standing problem of blockquote not working with images.

 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:12, 12 September 2015 (UTC)

cite attribute

I'd like to add a parameter to specify the cite attribute for the <blockquote> tag. I would do so myself, except I feel URLs added in this way should be made available in/as the byline as well, but I'm not sure how best to go about that. I'm also not sure what parameter name might be preferred; my obvious choice is url, but others might disagree. =) 「ディノ 奴千？！」^{? · ☎ Dinoguy1000} 13:00, 18 June 2015 (UTC)

@Dinoguy1000: That's already there. It's the |source= parameter, a.k.a. |3=. As of this writing, it only surrounds the source work (book, website, whatever), and the cited author is outside the <cite>...</cite> element. There's a thread above, at #Changes to cite and blockquote in HTML specs, about possibly having that element surround both the author and the source, which is permissible but not required in HTML5. If you think it would be desirable to have it do it that way, that would probably be the thread in which to say so, or your view might not be noticed on that point.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  04:46, 30 July 2015 (UTC)

I was talking about the cite attribute, not the element, i.e. <blockquote cite="http://example.com">... This must be implemented via a new parameter because according to the spec, the value must be a URL, and no current parameter is guaranteed to be a URL. Regardless, though, I went ahead and added this parameter, using my original choice of url, but I doubt it's been used anywhere yet so it could still be renamed if necessary. 「ディノ 奴千？！」^{? · ☎ Dinoguy1000} 05:47, 30 July 2015 (UTC)

@Dinoguy1000: Ah! Yes. You even linked to it. Sorry for the temporary blindness. I can't see that this would be useful here, because of WP:EL, and the way the feature works (or, rather, mostly doesn't). We almost never want to link to a URL directly in article content except inside a reference citation, but a URL is the only permissible content of the the cite= attribute. Given that it does nothing visible in many browsers, what would be the encyclopedic point, anyway? It would be easily abusable to hide linkspam. See this example:

Hold tight and pretend it's a plan!
– The Doctor

In several browsers I've tried, this does nothing at all visible in the user agent, not even if you hover. If we enabled this feature at all, it would have be disabled in mainspace, and it's pretty much non-functional anyway. WP doesn't use every conceivable feature of HTML, just the useful ones for the project. What's the use case here? Aside: This test demonstrates that we do in fact need to fix our handling of <cite>, however; it should not be applied to just the title of the work and should not be auto-italicizing. We're still treating it like the pre-2013 HTML5 Draft version of the element.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:13, 30 July 2015 (UTC)

It's a bit of metadata meant to aid in attribution. As far as visibility is concerned, it could be a requirement that the URL be replicated in a tag in the byline of the quote (or something similar); if this template were to be converted to a module, this could even be enforced automatically. I don't think the spam angle is a real concern, either; the various spam report bots shouldn't be fooled by its lack of visible effects in browsers, and the URL blacklist and edit filters will work correctly with it (and if there's a requirement that the URL be duplicated in a manner visible in browsers, that lowers this concern even further). All that being said, though, now that you raise the point, I'm rather out of touch with the WP editing community by now (having been retired and mostly inactive for years), and thus am not in a position to answer whether the community would want this feature, or if so, how or where it would be applied, so as far as that goes, if it's really not wanted here, feel free to revert my addition. =) 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 02:28, 31 July 2015 (UTC)

That just brings me back to "what's the point?" If the URL is duplicated in in a <ref>, or otherwise is included in the visible <cite>...</cite> element (not attribute), then it serves no purpose as an attribute, and just adds to page loading time [albeit not noticeably] for no reason. I hadn't reverted because maybe someone has a reason to use it, like "Oh, this provides useful metadata for [some application here]", but no one's been forthcoming with any yet.

I see from https://html.spec.whatwg.org/multipage/semantics.html#the-blockquote-element that this content attribute can have a correponding IDL (i.e., Javascript) element, so in theory we could do something with this URL via a script, e.g. a WP:Gadget, but I cannot think of anything that we would do with it, at least not in mainspace, per WP:EL, etc. The same document also says: "User agents may allow users to follow such citation links," though I can find zero that do so, and continues: "but they are primarily intended for private use (e.g. by server-side scripts collecting statistics about a site's use of quotations), not for readers." And we're not doing anything with them, nor do we have plans to. It does say that "To obtain the corresponding citation link, the value of the attribute must be resolved relative to the element."

In theory we could use this sort of thing internally for quotations of one WP:POLICY page in another. For example, have a bot check that something at WP:FAUNA#Redirects marked {{quote|class=policyquote|cite=/wiki/Wikipedia:Article_titles#quoted-at-WP:NCFAUNA.Redirects}} is still a word-for-word match with text at WT:AT that was wrapped with <span class="quotedpolicy" id="quoted-at-WP:NCFAUNA.Redirects">...</span>, but I think the likelihood of anything like this ever being implemented is very close to zero. A content-facing potential use could be bot-checking an external cite URL for non-404 periodically in case it breaks, on the theory that quotations should have higher verifiability requirements than other content, but there's no consensus at present that this is true, and no such bot planned. If we did have some uses like these in mind, this feature could be put back in.

 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:39, 12 September 2015 (UTC)