Template talk:Blockquote/Archive 3

This is an archive of past discussions about Template:Blockquote. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Archive 2

Archive 3

Archive 4

More quoteness

Stale

– Discussion stalled in 2015; probably too many unrelated changes being proposed at once.

User:ais523 and myself have been hacking a bit on this template, fixing the margin bug when it's next to images, and adding a box parameter to make it boxed like {{quotation}} currently is. There is some scattered discussion (the scattering being largely my fault) at Template talk:Quotation and User talk:Martijn Hoekstra, and there is a proposed replacement template with test cases over at test wiki. It also requires a small common.css change. Does anyone see any issues or improvements? Can we go ahead with these changes? Martijn Hoekstra (talk) 10:39, 30 October 2014 (UTC)

There's been no objection. I think we can go ahead. --ais523 13:29, 5 November 2014 (U T C)

Hold on... I'd like to review some changes, do a little impact analysis and provide some optimizations. For instance, there are some margins and paddings that seem to counteract eachother, because of existing CSS in Common.css. My philoosophy is to initially let the browser decide the metrics, then add CSS where needed. I asume this is going to be the 'master' blockquote template? -- [[User:Edokter]] {{talk}} 11:07, 10 November 2014 (UTC)

As far as I'm concerned, this would be the "master", yes, but the TfD is still open, and while I don't forsee a different outcome, it would be a little presumptuous to already say it will be before there is an official close. The margin and padding issue is definitely a bit annoying. It's somewhat odd now, mainly due to trying to make the correct amount of spacing next to a floated element (which collapses margin), and still keeping it on a separate line from preceding inline content. If you can make that better, that'd be absolutely great (I've got some doodles that also integrate quote marks for pull quote on a jsbin, which I can't link to right now, but can in a couple of hours, that take a slightly different route, and might be able to solve everything too, but I'm not sure if it is a good idea to include pull quote capability as it might encourage its use, while MOS discourages it in article space. This might be some wasted effort since TfD showed consensus to keep a separate {{Imagequote2}}, {{Pullquote}}, and that signpost pullquote template. I still firmly believe it's best to have one semantically correct template that provides all functionality, but with consensus against that - which I still don't understand - I'm not completely sure yet what's best (and I'd love to hear other opinions on it too). Anyway, I'll share what I have at the moment when I get home tonight. Martijn Hoekstra (talk) 11:21, 10 November 2014 (UTC)

As of mid-2015, it's definitely the "master" block quotation template, and the variants have been merged into it. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 14:45, 12 September 2015 (UTC)

I was thinking about adding the 'big' quotes, either as option or default, as the typography refresh already did a similair thing, but was just implemented poorly. I'm all for semantics, the main objections were a different presentation. I too like to get rid of all table-based quoting templates. -- [[User:Edokter]] {{talk}} 11:28, 10 November 2014 (UTC)

I've got the 'big' quotes currently implemented as ::before and ::after selectors, with some padding, and relative/absolute positioning (where the quotes would be inside the padding region, so they shouldn't ever be able to overlap content), and the source in a semantic footer element with the work in a cite element (much like this template is right now). Let's compare notes later! (it really annoys me I can't get to my jsbin right now) Martijn Hoekstra (talk) 11:46, 10 November 2014 (UTC)

The sketch of semantic pullquote content: http://jsbin.com/vinoyizoyu/12/edit Martijn Hoekstra (talk) 18:51, 10 November 2014 (UTC)

The TfD outcome for the signpost template resulted in "merge". There's nothing to stop us re-nominating the other templates, if we can demonstrate that the functionality is now available here. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:58, 11 November 2014 (UTC)

The biggest one, Wikipedia:Templates for discussion#Template:Quotation is still open. Also, I don't want to re-nominate the signpost one, even if this template could take over it's exact function and appearance. Frankly, I'm a little done with that template. If they want to have obsolete HTML, they can have it, as long as they maintain it themselves, I don't see a problem. Also, I stirred enough drama with that one already.edit and I'm assuming that whatever change or improvement we would suggest, it will be perceived as an attack on their work, like I think the MfD was perceived. If anyone else thinks they can still effectively co-operate with the people who maintain that template, I have no objection, but I don't think any good will come of you or I attempting that end edit So, that means we should make sure this template supports all functionality and layout of at least Quotation and Imagequote2, and possibly some/all of the functionality of Pull quote? Martijn Hoekstra (talk) 14:17, 11 November 2014 (UTC)

Oh, and let's not forget {{bq}} if that closes as merge, and take all the good stuff from it if it closes as keep. Martijn Hoekstra (talk) 15:40, 11 November 2014 (UTC)

Some edits on the design: does http://jsbin.com/xuvimavoti/4/edit look good as a start? I imagine the pullquote and boxquote classes to be independently toggleble as parameters. If so, I'll try and work that out as a new sandbox on test. Martijn Hoekstra (talk) 16:10, 11 November 2014 (UTC)

Draft at https://test.wikipedia.org/w/index.php?title=Template:Quote/Sandbox2 with the basic testcases at the first section of https://test.wikipedia.org/wiki/User:Martijn_Hoekstra/quotetest . They need proper handling of the optional source paramters still, and maybe there is a bit too much padding now? Martijn Hoekstra (talk) 21:45, 11 November 2014 (UTC)

It's been three months, now. The template still hasn't been changed, and the TfD is still open. We're never going to get improvements done if the reaction to changes is always "hold up, maybe we can do better". --ais523 07:52, 6 February 2015 (U T C)

I can hardly close the TfD while I'm so involved. All we can do is wait until somebody else closes it. Martijn Hoekstra (talk) 14:09, 6 February 2015 (UTC)

I don't think we need the TfD to be closed to be able to improve the template, at least. Then we'd have good reason to relist the TfD (for visibility). --ais523 07:15, 18 February 2015 (U T C)

I have now closed the discussion (while heavily involved) and asked on WP:AN for review of the close. I'd like to request that we at least wait a couple of days to see what happens at AN before we enact my involved close. Martijn Hoekstra (talk) 10:51, 18 February 2015 (UTC)

Well, we're not allowed to merge, so that was a whole big exercise in time wasting. Martijn Hoekstra (talk) 06:12, 28 February 2015 (UTC)

Of course we're 'allowed' to merge, there's just no immediate consensus to do so, or on how to do so. So let's just get this template up to speed so it can handle all uses, then worry about wrapping/redirecting the others later. -- [[User:Edokter]] {{talk}} 10:55, 28 February 2015 (UTC)

I don't really understand, how is making this template suitable for all usecases for both templates something different than merging? Martijn Hoekstra (talk) 15:08, 28 February 2015 (UTC)

It isn't. It's the way how that differs. Putting up a TfD first, which incures a deadline, is never the right way to acomplish anything. Had this template been prepared beforehand (and therefor act as meta template), a merge would be much easier to accept. -- [[User:Edokter]] {{talk}} 15:45, 28 February 2015 (UTC)

But then TfD would have been presented with a done deal, and there would be nothing to decide about anymore. I concider that a backhanded way to push changes without proper consultation of the community. Here, the discussion closed with no consensus to merge the templates. Merging them regardless goes directly against the close of the discussion, which has been open for long enough for people to weigh in. Martijn Hoekstra (talk) 16:22, 28 February 2015 (UTC)

The keyword is convenience. The only reason the merge was opposed is because the templates looked different and do not allow other presentation then its own. Had this TfD been presented with this one being able to do the work of the others, there would be no opposition, as all the other would essentially be redundant. There was no consensus to merge because no one wanted to do the work. That doesn't mean the work is 'forbidden'. -- [[User:Edokter]] {{talk}} 17:21, 28 February 2015 (UTC)

The work was done at the TfD. Also, I see a pretty clear consensus to merge. But I've had enough of arguing TfD closes for the day. Alakzi (talk) 19:31, 28 February 2015 (UTC)

The work was already done for 90% by ais, with a little bumbling around the edges by me. But that's not what the opposes were about. One wanted a MOS change first, and one didn't want an extra parameter in a template invocation. There was nothing about the work that needed to be done, or if the merge would be technically feasible. Don't get me wrong, I think it's stupid not to merge the two templates but we should be happy enough the TfD finally closed, and if that's not in the way I think was logical just means that I have to change the way I try to work with templates (i.e. don't start work on a template before TfD closes, because my intuition about something being obvious is off base). It shouldn't mean I should ignore the close, and do the merge regardless. I'm still struggling to try to understand what the argument against really is, because I understand neither (the MOS one is irrelevant if the boxed variety is not used in mainspace, and the paramter objection could easily be dealt with with a thin wrapper), but it seems there is significant opposition to even the most straightforward of technical fixes. I don't really understand it, so I don't know how to deal with it yet. I concede you are better at that than I am (I note for example that The ed17 thanked you for performing a merge he fought tooth and nail to prevent), but going directly againt the outcome of a TfD discussion by performing the merge, and justify it by calling it "improving the template" rather than merging is not a step I'm willing to take. If you still want to do so, feel free to use any of the work I put in earlier, but I'm not willing to do so myself. Martijn Hoekstra (talk) 19:56, 28 February 2015 (UTC)

I'm being more annoyed than reasonable at the moment. I think my points here are valid, but I'm too annoyed to be sure; please take them with a large grain of salt. My appologies for ranting and possibly disrupting. Martijn Hoekstra (talk) 22:58, 28 February 2015 (UTC)

There might be macro problems with TfD and people's general unwillingness to adapt, but I see this as being little more than a lazy close. I know that's not a shining example of AGF, but I thought I might as well be honest. Participants to the discussion were cooperative and productive. Except for the sole !vote against a switch, which could've been accommodated, as you say, nobody was opposed to a merge. Alakzi (talk) 23:09, 28 February 2015 (UTC)

@Swarm: I'm sorry if this sounds harsh—and, if I'm off the mark, you've got my okay to "lambaste" me! Your help with the backlog is definitely appreciated. Alakzi (talk) 23:21, 28 February 2015 (UTC)

To be fair, I have been riding this issue on the back seat because I didn't want derail any active discussion (which hasn't ben active for a long time). I should have stepped in sooner and continue the work you started in the sandbox. Anyway, no rush. -- [[User:Edokter]] {{talk}} 23:44, 28 February 2015 (UTC)

This seems overly complicated and trying to address too many things mingled together at once. The fix for the margin-bug-next-to-images is much simpler, as I've detailed at #Fixing the display problem with images, below. I do agree that the templates should be merged, but that's a different discussion and issue than how to fix the CSS problems. PS: Typography Refresh abandoned the "giant quotation marks" thing after users rebelled about it. On en.wiki, MOS would've had MediaWiki:common.css override it anyway; we don't want block quotations formatted like pull quotes in news style. Anyway, for future merges, may I suggest taking them one at a time? As each one merges in the special pleading to keep this one or that one separate becomes weaker and weaker. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 05:11, 30 July 2015 (UTC)

Changes to cite and blockquote in HTML specs

Resolved

– Fixed.

The changes discussed at http://html5doctor.com/cite-and-blockquote-reloaded/ are interesting. Maybe we should revise this template accordingly? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:27, 5 November 2013 (UTC)

Please note that the article refers to HTML 5.1.[1] When we adopt HTML 5.1, then we can update this. -- Gadget850^talk 18:23, 5 November 2013 (UTC)

Update: The current version of HTML5 (28 October 2014) now also reflects those changes.[2]. The minimal change would be to wrap the |author= value in <cite>...</cite> if |author= has a value and |title= does not. The maximal change would be to wrap both in this element. For coding purposes it would be easier to do the latter. ~~Since~~ While both would semantically correct according to the current spec, ~~I'm not sure "purists" have any argument one way or the other.~~ there's a good reason to do the latter (see below). More specific spec links: "The cite element", "The blockquote element". Code example 3 at the first of these shows use to mark up only the title of the cited work, not the author also, while other examples show markup of the author, of URLs, etc. Note that not all of the examples illustrate things WP itself would do, or the styles we would use. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 03:45, 30 July 2015 (UTC)

Further note: It's clearly preferable to have it surround both parameters, and to have MediaWiki:common.css stop auto-italicizing it, since <cite> may often contain only the author's name, and not be limited to the italicized title of a major published work. I.e., this:

It could probably be shown by facts and figures that there is no distinctly native American criminal class except Congress.
– Mark Twain, "Pudd'nhead Wilson's New Calendar", Following the Equator (1897)

is was clearly wrong style [it was italicizing everything including author name], despite being marked up correctly (both as to HTML5 and as to MOS). I've raised this issue at MediaWiki talk:Common.css#The cite element needs to not auto-italicize any longer. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 21:25, 30 July 2015 (UTC) Updated: 14:50, 12 September 2015 (UTC)

Resolution: W3C's own documentation has been updated to consistently reflect that the <cite>...</cite> element applies to all citation data, not just the title. Mediawiki:Common.css has been corrected to stop force-italicizing the title. {{Quote}} has been updated to apply the element correctly per the current HTML5 specs. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 14:50, 12 September 2015 (UTC)

Square box instead of space showing after mdash

Unresolved

Any place I see the {{quote}} template used if the attribution pipe is used a little square box appears instead of the space after the mdash and before the first letter of the attribution. I even see it here at [[Template:Quote]] in the rendered example.

I have submitted a case to https://phabricator.wikimedia.org/T115689 and updated the case today.

I don't see the square on my Blackberry Bold 9900 using the Blackberry browser.

Cheers! {{u|Checkingfax}} {Talk} 23:34, 21 October 2015 (UTC)

There was a thin non-breaking space that is not displayed by some systems. I replaced it with a regular nbsp. -- [[User:Edokter]] {{talk}} 10:56, 22 October 2015 (UTC)

Thank you, Edokter. Cheers! {{u|Checkingfax}} {Talk} 11:26, 22 October 2015 (UTC)

That's typographically wrong; see WP:DASH: full-width spaces are not used with em dashes. I switched it to the thin space ( ), across all the quotation templates (which I kind of have on "speed dial"). That named character entity is not "exotic" in any way, and has been around since the mid-1990s or so. An alternative would be use an en dash with a full-width space, but the thin-spaced em dash should work everywhere. PS: Anyone who does not have fonts installed to handle spacing and punctuation characters represented by numeric character references, like the hair space, are going to have a lot of problems on WP, which makes heavy use of Unicode. We probably should not be tweaking templates to try to compensate for "I haven't undated my PC in ten years" PEBKAC. We cannot predictively account for every possible problem such users run into here, and basically much of the Web is going to be malfunctional for them, since their ancient browsers are going to choke on all sorts of things everywhere. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 05:06, 25 October 2015 (UTC)

SMcCandlish. Hah! There's such a little box in your raw signature! I have the very latest Google Chrome browser, thank you: Version 46.0.2490.80 m ("Google Chrome is up to date"). Your tweak got rid of the box, but now there is no space between the em dash and the first attribution letter. Edokter had it going on even if imperfect. Thank you. Cheers! {{u|Checkingfax}} {Talk} 05:36, 25 October 2015 (UTC)

Checkingfax, fonts don't come from browsers, they come from the font files installed in your OS. It doesn't matter how new your browser is if you won't install modern fonts with broad Unicode support (or have them installed but are using your browser's font preferences/settings, or user CSS, to apply a font that doesn't have good Unicode support). We're not in a position to perpetually try to compensate for every possible user-side failure by dumbing down markup on our end, or we might as well use HTML 4 and CSS 2. There's no problem with using an em dash followed by a thin space; all users can render that. Using a full-width space after an em dash is a style error. Using a hair space after an em dash is apparently problematic for some users, but the em dash + thin-space solution is the correct one (or, alternatively, an en dash followed by a full space, but the quotation templates have long used em dashes, and it's the most common style even off WP, so I would expect such a change to be controversial). Anyway, yes there is a space between the dash and the text that follows it, a thin space. There used to be no space at all. Some time ago I rectified this readability issue with a hair space; you couldn't render that character, and complained; Edokter changed it to a full space, which is against WT:DASH (and Chicago Manual of Style, et al.); I put it as a thin space (which is a tiny bit wider than a hairspace); this result is still more kerning space than the template had originally, which was zero. I'm skeptical this can be explained any more clearly. PS: There is no such little box in my signature. My sig is properly character coded [though some might object to the Unicode equivalent of ASCII art aesthetically]. You are seeing a box in my signature because of your own font settings. This should help. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 07:43, 25 October 2015 (UTC)

(ec) Thin space is not a problem, but not all Unicode is OK, and saying users with old OSes will have problems because 'WP uses Unicode' is way too simplistic. Unicode is a living standerd which is continually updated. We are now at 9.0 I believe... Point is, just because some character is defined in Unicode doesn't mean it automagically starts to work for everyone. It ussally takes years before 1) the mainstream fonts are updated to support them, and 2) the major OSes have included those fonts. So keep in mind before you use any 'exotic' character again; anything above Unicode 5.0 is probably supported by less then 5% of our readers, and there's nothing they can do about that. Requiring downloading special fonts is also not an option. -- [[User:Edokter]] {{talk}} 07:56, 25 October 2015 (UTC)

I guess you'll have to take {{IPA notice}} and every template like it to WP:TFD then, since instructing the downloading of such fonts is precisely what they do. LOL. "Not an option"? It's the only option in most cases. In this unusual, individual case we're fortunate that there's virtually no difference between the hair space and thin space, and the latter has been around for long enough that everyone can use it. I'm not making an argument that the hair space needs to be put back in. But WP came to a consensus a long time ago to continue to use Unicode appropriately, and let people catch up. The "I just get boxes" complaint and "I'll replace something you can't render with something different" sort of "solution" is usually not going to be a valid approach. You cannot go to Kannada and replace that language's characters with other characters from some other language that appeared in Unicode earlier, after all. This hair-space case is a highly unusual exception. WP being in the top 5 most used websites and making such heavy use of Unicode is surely among the main vectors of everyday people's systems being incrementally upgraded, font-wise, to support newer versions of Unicode. While this is not WP's mission, it's a positive side effect. If people are frequently having Unicode problems here (even I do rarely, for obscure languages), we probably need to assemble a freeware font collection and make it available as a "new user package", available from some Help-namespace page here, and linked to from templates like the one I mentioned (the "rendering support" link in that doesn't actually even go to anything any longer; the section it was linking to no longer exists, at least not under that name. I'll dig in history and see if I figure out what the intent was; I'm guessing it was #Fonts at the same article, but that short section it's actually particularly helpful). [Update: Fixed.] — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 09:53, 25 October 2015 (UTC)

Downloading fonts is not the only option; webfonts are still being researched. IPA is also a totally different subject (and with decent support), as are other non-latin scripts; but we're talking about splashing unspported characters in places where it is not even needed... such as this quote template. Should it be supported? In a perfect world, absolutely. But unfortunately, we're not living in a perfect world and your vision is not compatible with reality. So your rant above simply does not apply to this situation. Rule of thumb in Unicode is: Ask youself if such characters are actually needed, then use what ever is most widely supported. -- [[User:Edokter]] {{talk}} 10:38, 25 October 2015 (UTC)

template logic

Dinoguy1000, we really need to use the same logic for in the 'if clause' of the conditional as the 'then clause', otherwise you can get strange output for situations like

{{quote|A|sign=|cite=C|source=|ts=D}}

before, since the same logic was used in both cases, the |cite= and |ts= were silently ignored. now, they trip the 'if clause', but then show nothing since they are overridden by the blank |sign= and |source=, and so you get the floating dash. a far more robust version can be found in this version of the sandbox. by using template:if empty in the 'then clause' the blank parameters are ignored, and don't override the non-blank parameters. of course, an even better solution would be to not allow so many variations of the same parameter names, but that would require cleaning up the articles. Frietjes (talk) 20:34, 30 November 2015 (UTC)

You're right, and I should have considered that in my edit. The main thing that stopped me was that I wasn't aware of {{if empty}} off-hand, and so if I'd gone ahead with it I would have used nested #if statements - something we can probably agree wouldn't have been very manageable considering the number of alternate names for the same input. As you said, though, cutting down those alternates would be a very good way of controlling the code bloat in this case, and for that matter I don't think the recent addition of a number of variants should have happened. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 06:08, 2 December 2015 (UTC)

Frietjes, the new version is transcluding false-positive {{error}}s in main namespace

Can you fix it so that {{error}} is only transcluded when the big red error message is actually displayed in the article? Thanks, Wbm1058 (talk) 23:37, 3 December 2015 (UTC)

Wbm1058, fixed for now. there is probably a more elegant solution, but, will have to think about it ... Frietjes (talk) 13:15, 4 December 2015 (UTC)

Thanks. Hopefully there's a way to do it without removing the {{error}} template entirely. There were several templates I modified for "false-transclusions", when I was working on cleaning up false transclusions. It's tricky though, and when you don't work on templates constantly you can get rusty pretty fast. I'd have to go back and look at what I did to fix other templates with similar issues when I was working on that. Wbm1058 (talk) 16:04, 4 December 2015 (UTC)

Incomplete conversion of pull quotes

In fixing the errors flagged in Category:Pages incorrectly using the quote template, I found one where improper usage {{pull quote}} was converted to {{quote}} (diff). Care needs to be taken to check the parameters used, because the syntax of these two quote templates is not identical; my fix: diff. – Wbm1058 (talk) 18:49, 4 December 2015 (UTC)

yes, thanks for the reminder, that's the reason we are tracking |4=, |5=, ... basically, catching post template merger issues. Frietjes (talk) 00:33, 5 December 2015 (UTC)

Curious fix

Frietjes, why would this edit fix anything? I thought that text= and 1= should be equivalent? That one had me stumped; I was going to come back to it later. Wbm1058 (talk) 00:24, 5 December 2015 (UTC)

Wbm1058, I believe it was just a server cache issue. sometimes you have to purge the page after you edit it, or wait for the job queue to catch up or something ... Frietjes (talk) 00:27, 5 December 2015 (UTC)

Frietjes, right, the system has been misbehaving more often in strange ways like that recently. Sometimes even null edits don't seem to fix it. I'll leave this one for you User:Kamina/vector.css as I don't follow why a comment in a script would trigger the categorization, or I guess this is it?

.quote {
  margin: 0.4em 0px 0.5em 2.2em !important;
  padding: 2px 5px 2px 5px;
 
  background-image: url('http://upload.wikimedia.org/wikipedia/commons/thumb/d/d3/Quote_background_transparent.png/38px-Quote_background_transparent.png');
  background-size: auto 32px;
  background-position: right bottom;
  background-repeat: no-repeat;
}

Wbm1058 (talk) 00:41, 5 December 2015 (UTC)

It's because template transclusions and links in comments in CSS and JS files add entries to the link table (so it is the /* {{Quote}} */ comment causing this, not the CSS you copied above). Useful for tracking script usage, if the script in question has a standard installation method of copying code that includes a comment with a link to the source script, though it can also be problematic as you see there. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 02:38, 5 December 2015 (UTC)

Thanks

... to whomever fixed the interaction between quotes and right-aligned images/boxes, thus eliminating the need for {imagequote}. A minor but highly annoying headache eliminated! EEng (talk) 18:18, 10 December 2015 (UTC)

Wait a second!

I thought Template:Quote/to right of image and its kind were now unnecessary because the underlying bug was fixed. Am I mixed up? EEng (talk) 22:44, 16 December 2015 (UTC)

That template should be obsolete now. -- [[User:Edokter]] {{talk}} 11:45, 17 December 2015 (UTC)

So why not redirect it? Its very existence made me wonder whether there were reasons it was still needed sometimes. EEng (talk) 16:52, 17 December 2015 (UTC)

Yeah, we should eliminate traces of FUD on this matter. If the problem is fixed and the workaround templates are not needed, they should redir to the real thing (or if they weren't used much, hunted down and replaced, and the workaround templates deleted). — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 00:54, 29 January 2016 (UTC)

A bug

Resolved

Adding a signature makes the template ignore line breaks in the text. For example:

[T]he various typefaces used before the introduction (The) Times New Roman didn't really have a formal name. They were a suite of types originally made by Miller and Co. (later Miller & Richards) in Edinburgh around 1813, generally referred to as "modern". When The Times began using Monotype (and other hot-metal machines) in 1908, this design was remade by Monotype for its equipment. As near as I can tell, it looks like Monotype Series no. 1 — Modern (which was based on a Miller & Richards typeface) — was what was used up until 1932.

But:

[T]he various typefaces used before the introduction (The) Times New Roman didn't really have a formal name. They were a suite of types originally made by Miller and Co. (later Miller & Richards) in Edinburgh around 1813, generally referred to as "modern". When The Times began using Monotype (and other hot-metal machines) in 1908, this design was remade by Monotype for its equipment. As near as I can tell, it looks like Monotype Series no. 1 — Modern (which was based on a Miller & Richards typeface) — was what was used up until 1932.
— Dan Rhatigan, type director

Can someone please fix this? Esszet (talk) 23:31, 1 January 2016 (UTC)

Esszet, this probably could be fixed by adding a newline before the signature div tag, for example, compare

[T]he various typefaces used before the introduction (The) Times New Roman didn't really have a formal name. They were a suite of types originally made by Miller and Co. (later Miller & Richards) in Edinburgh around 1813, generally referred to as "modern". When The Times began using Monotype (and other hot-metal machines) in 1908, this design was remade by Monotype for its equipment. As near as I can tell, it looks like Monotype Series no. 1 — Modern (which was based on a Miller & Richards typeface) — was what was used up until 1932.

with

[T]he various typefaces used before the introduction (The) Times New Roman didn't really have a formal name.
They were a suite of types originally made by Miller and Co. (later Miller & Richards) in Edinburgh around 1813, generally referred to as "modern". When The Times began using Monotype (and other hot-metal machines) in 1908, this design was remade by Monotype for its equipment. As near as I can tell, it looks like Monotype Series no. 1 — Modern (which was based on a Miller & Richards typeface) — was what was used up until 1932.

will see if anyone sees any problem with adding the newline ... Frietjes (talk) 15:21, 5 January 2016 (UTC)

here is a sandbox version with the fix. Frietjes (talk) 15:24, 5 January 2016 (UTC)

Frietjes It doesn't look as though anyone has any problem with it. Esszet (talk) 16:10, 22 January 2016 (UTC)

Esszet, thanks for the reminder ... now implemented. Frietjes (talk) 16:13, 22 January 2016 (UTC)

To editors Frietjes and Esszet: The most recent edit messed up the quote sig on my user page. I confirmed this by changing this sandbox back to the previous version and previewing it on my user page. This edit sets the sig back to the left margin for some reason, instead of where it was under the quote. I've illustrated it below.

How it was:

(type quotation here)

Paine

After the most recent edit:

(type quotation here)
— Paine

Can what you want done be accomplished differently? Paine 23:52, 22 January 2016 (UTC)

(type quotation here)
— Paine

Pinging Frietjes because I didn't get a notification for that… Esszet (talk) 20:15, 24 January 2016 (UTC)

@Paine Ellsworth and Esszet:, the difference with the example presented by Paine Ellsworth is the ':::' preceding the quote template, so when the signature div is put on a second line, something, probably HTML tidy, kicks it out of the association list (dt/dl) created by the ':::' (see this test case). however, if we keep it on the same line, it looks like something, probably HTML tidy, removes the line breaks (see this test case). I could argue that using ':::' just for indentation is bad for accessibility (and instead you should use '|style=margin-left:7em', see above), but that's probably not going to convince anyone to stop doing it. how about a compromise where we add a parameter (I have no idea what to call it) which would turn on the feature which preserves the newlines? or, do we just use the style= to do the indentation? or do we go back to the old version and tell people to use <poem>...</poem> inside? or do we add a feature which adds <poem>...</poem> inside? Frietjes (talk) 15:18, 25 January 2016 (UTC)

It looks as though everything after the first line break created by putting the text on a separate line (though not by <br>) is dissociated from indentation created by colons even if there's no signature included (see below). Does that make a difference? Esszet (talk) 15:47, 25 January 2016 (UTC)

::::{{Quote|'''''{{Color|#9724c4|(type quotation here)}}'''''<br>'''''{{Color|#9724c4|(type quotation here)}}'''''
'''''{{Color|#9724c4|(type quotation here)}}'''''

'''''{{Color|#9724c4|(type quotation here)}}'''''}}

yes, you are correct, you can't include line breaks if you indent the quote template with colons, which is another reason why using colons to indent the template is fragile. Frietjes (talk) 16:55, 25 January 2016 (UTC)

It didn't even work before the latest edit. Could it be fixed somehow? Esszet (talk) 17:14, 25 January 2016 (UTC)

To editors Frietjes and Esszet: <div style="margin-left:7em"> as a wrapper around the entire quote + sig works well and is fine with me:

(type quotation here)
— Paine

Might want to make a mention of this application of the style param (to indent a quote) in the documentation somehow. Thank you very much for the tip, Frietjes! Be prosperous! Paine 17:24, 25 January 2016 (UTC)

Frietjes Is there any way that indenting the quote template could be made more practical? I think you're right in doubting that people are going to stop using colons if you just tell them to use |style=, and I'd have to say that also applies to <div>...</div> tags. Esszet (talk) 18:42, 26 January 2016 (UTC)

Esszet, we could add a parameter, say |indent=, but I still don't think that would prevent people from trying to use colons. I can't really think of a case where you would want to use colons for indenting the quote (outside of talk pages). as I said before, we could make the new additional linebreak (between the quote and the citation) optional. perhaps it would be good to have a bot scan all uses to see how many are uses are being indented by colons? Frietjes (talk) 18:48, 26 January 2016 (UTC)

The best thing to do would be to just try to make the colons work, but I don't think we can do that here. Do you want me to take the issue to MediaWiki's support desk and see if they can do anything about it? Esszet (talk) 19:25, 26 January 2016 (UTC)

How much of an issue is this, really? If editors use colons to further indent a quote, such as I did on my user page, and then they see that the quote's sig is not indented, won't they come to this page to find out what's wrong? I think all that's needed is a ditty on the /doc page to let editors know specifically how to use either the style param or the div tags to get the indentation they seek. Paine 21:55, 26 January 2016 (UTC)

It's not that much of an issue, but I can't imagine it would be all that difficult to fix. I'll take the issue to MediaWiki's support desk and see what they say. If they do say it would be difficult to fix, I'll leave it at that, and we can try here to come up with a more practical means of doing it. Esszet (talk) 15:33, 28 January 2016 (UTC)

I would call the indent-with-colons "problem" an accidental feature; it prevents people from misusing the standard quote template to try to do indented pull quotes (see MOS on this; we mostly do not use pull quotes; only about 1 in 200 uses of a pull quote template is actually for a pull quote, and most of those should be removed, too, because they're usually NPOV violations). Supporting fancy formatting in userspace isn't part of this template's job; anyone can do whatever they want with CSS there. Same goes for unusual layout requirements in mainspace; just use a div or something to indent the quote. This comes up so infrequently, I wouldn't devote any time to it. As for the other issue, I've added to /doc that if you need to preserve fixed whitespace, use <poem>; that's what it's for, after all, and MediaWiki eating whitespace is something that affects other block elements, not just the <blockquote>...</blockquote> used by this template. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 01:11, 29 January 2016 (UTC)
- Thank you, and I agree (don't look so astonished :>) Be prosperous! Paine 18:17, 30 January 2016 (UTC)
  - Use of deflist markup (i.e. colons) for indentation is an abuse, but this bug also shows up with bullet lists:
    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, somewhere
  - As this paragraph shows, it ends the list, which is quite wrong. I'm working around it by manually adding <p> tags. Hairy Dude (talk) 15:07, 1 February 2016 (UTC)

Yeah, it's just a MediaWiki issue we have to live with. The use of ; and : to indent things is shite when it comes to semantic HTML (because it formats the material as description lists (a.k.a. definition lists or association lists) in HTML, and this is an abuse of separation of content and presentation just to get a trivial stylistic effect, like abusing HTML tables for layout). No one much cares if we do it in talk pages, but I eliminate this on-sight in articles. If you need to indent a line, use {{in5}} or another indenting template. If you need to indent a block of content that is not a quotation, use {{block indent}}, which supports internal <p>...</p> paragraph breaks and such, and can be configured to indent on one or both sides. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 21:40, 2 February 2016 (UTC)

Thanks everyone for screwing up the presentation of archived discussion pages like this one, apparently just to make the trivial point that Wikipedia conventions on talk page layout don't comply with the programmer's handbook of coding. SpinningSpark 11:24, 6 February 2016 (UTC)

To editors Frietjes and Esszet: it appears that the edit to this Quote template should be reverted until a way can be found to keep the indented quotation formats on existing pages intact. There's no telling how many discussion pages have been adversely affected by the change. Be prosperous! Paine 17:05, 9 February 2016 (UTC)

Paine Ellsworth, I wrapped the additional line break inside an #if: statement. to turn it on, use |multiline=y. Frietjes (talk) 17:12, 9 February 2016 (UTC)

Works very well on Spinningspark's noted talk page above, and on my user page as well, thank you! Paine 17:28, 9 February 2016 (UTC)

Frietjes, thanks for fixing that. SpinningSpark 23:38, 9 February 2016 (UTC)

A vexing issue fixed here, but how?

Anyone who has had more coffee than me know why the problem illustrated at Template:Block indent#Technical issues with block templates is no longer affecting this template? (If you transclude the same Template:Block bug documentation doc snippet into Template:Quote/doc, the output in both table rows is identical). It would be good to propagate this improvement to all templates using divs and other block elements, and document what the cleanest version of it is in Help-namespace pages about coding (and maybe even update some MediaWiki bug reports about what the workaround is). The "traditional" way to work around this has been to insert <nowiki /> as the first thing in the block content parameter, before any list or other markup dependent on a character like * or # being at the beginning of a line. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 19:24, 15 February 2016 (UTC)

SMcCandlish it's because the text is wrapped inside the {{if empty}}. because Template:Block indent uses nested parameters rather than {{if empty}}, it has lower processing overhead, but doesn't process the list markup the same way. here is the most simple example that I know which illustrates the core difference

Input	Output
<div>{{#if:1\|* one * two * three}}</div>	one two three
<div>* one * two * three</div>	* one two three

Frietjes (talk) 19:48, 15 February 2016 (UTC)

A bug, part 2

The bug described above seems to have reared its ugly head again. At Aeon (Gnosticism)#Horos I'm unable to get the paragraph break in the second quotation to render correctly using a blank line, as currently demonstrated on my sandbox. Hairy Dude (talk) 11:21, 4 June 2016 (UTC)

Bug was never solved. In this case, using |text= fixed it. The the template still has issues, like using a block-level <div> inside an inlnine <cite> tag. That is what causes HTML Tidy to mess with the output. -- [[User:Edokter]] {{talk}} 11:57, 4 June 2016 (UTC)

Why are the char & character parameters separated from rest of the list ?

{{edit protected}} This template is using {{comma separated entries}} to handle the attribution, i.e. {{{author}}}, {{{title}}}, {{{source}}}, ... so that they are displayed nicely one after another and separated from each other with exactly one comma. However {{{char|{{{character}}}}}} is excluded from and followed immediately by {{comma separated entries}}. Though it is still showing up properly, I just do not understand the reason behind it. Would it not be intuitively easier to understand the code if it is included? I just made a {{Quote/sandbox}} to try it out, and you can take a look at Template:Quote/testcases#With character. Even though theis is not a big deal, I think it would help a lot if later there is any change or upgrade. Thanks!--Quest for Truth (talk) 02:04, 22 July 2016 (UTC)

Silly me! There is a subtle "in" after comma if {{{char|{{{character}}}}}} has value and is displayed. --Quest for Truth (talk) 02:28, 22 July 2016 (UTC)

But read again my testcase with closer look. It doesn't sound natural to put an "in" between Sherlock Holmes the fictional character and Sir Arthur Conan Doyle the author. After the word "in", a reader should be looking for the title of the work rather than the author. Keep in mind that this template is very flexible and allow user to choose which parameters they would like to use. There are a few approach to this problem:

Think of another word to accommodate all the possibilities. Sometimes |author= has value, but other times it is skipped.
Make it choose which word to use depending on which parameters are used. If |author= has value, words like "by" should be used instead of "in". If only |title= has value, the word "in" is suitable.
Rearrange the order. The {{{character}}} should be followed by "in {{{title}}}", which in turn should be followed by "by {{{author}}}". But does it require to use the order "{{{author}}}, {{{title}}}" when character is absent?

Any thoughts? --Quest for Truth (talk) 03:00, 22 July 2016 (UTC)

Note

Because I am tired of referring back to Wikipedia:Templates for discussion/Log/2014 October 20, everytime I want to do a multilingual quotation, the deleted Template:Multilingual quotation can be simulated with: {{columns|width=auto | col1 = {{quote|{{langx|en|Quotation not in English.}}|Author}} | col2 = {{quote|{{langx|es|Quotación no en inglés}}}} }}
— Preceding unsigned comment added by Furius (talk • contribs) 21:40, 18 February 2016‎ (UTC)

Demo:

English: Quotation not in English.
— Author

Spanish: Quotación no en inglés

So people can see what it does. @Furius: You can put that code in User:Furius/Multilangquote or something, and just do {{subst:User:Furius/Multilangquote}}, anywhere you need it, save the page, then re-edit it to insert the content. I have to note that the original TfD rationale was that we generally don't need to do this kind of display. It's usually more useful to just give the English translation, and provide the original with |quote= in the citation template for the source of the quote. There's not much utility on en.wikipedia in providing blocks of non-English content, unless it's being analyzed as such for a specific purpose, e.g. in a linguistics article. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 07:48, 20 February 2016 (UTC)

FYI: For better or worse, I just independently created the somewhat similar {{Verse translation}}. In my defense (if such is needed) my chief impetus was articles on verse forms, in which the non-English content is, I think, germane. I've subsequently noticed {{Text and translation}} (though I like mine a little better!). Cheers. Phil wink (talk) 23:59, 7 August 2016 (UTC)

August 2016 Notice -- RfC involving this template

It is here: Wikipedia talk:Manual of Style#RfC: What (if anything) to do about quotations, and the quotation templates? Herostratus (talk) 21:01, 20 August 2016 (UTC)

Styling

It's become pretty common in many stylesheets out there to highlight blockquotes with a line on the left, like this:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed ultricies nisi eu lectus egestas scelerisque. Etiam vitae ante vel lorem efficitur fermentum at quis nisi. Nulla et augue eget arcu scelerisque malesuada. Maecenas porta vestibulum libero eget varius. Donec lacus magna, fermentum vel ante vitae, malesuada posuere magna. Aenean scelerisque in neque ut semper. Donec eleifend tortor justo, ut ullamcorper tortor dictum at.

For contrast, here's how it currently looks:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed ultricies nisi eu lectus egestas scelerisque. Etiam vitae ante vel lorem efficitur fermentum at quis nisi. Nulla et augue eget arcu scelerisque malesuada. Maecenas porta vestibulum libero eget varius. Donec lacus magna, fermentum vel ante vitae, malesuada posuere magna. Aenean scelerisque in neque ut semper. Donec eleifend tortor justo, ut ullamcorper tortor dictum at.

I would like to propose that this template adopts this style, as it makes blockquotes more identifiable, and in line with the pattern that readers may have encountered elsewhere. Thoughts? --Waldir ^talk 19:41, 17 August 2016 (UTC)

I like it. I copied it over to an RfC on this subject which I just started at Wikipedia talk:Manual of Style. Hopefully there it will get many eyes and we'll see who else likes it. Herostratus (talk) 21:11, 20 August 2016 (UTC)

Thanks! I'll make sure to follow the discussion on that RfC. --Waldir ^talk 21:38, 20 August 2016 (UTC)

Already rejected: This was proposed a year or two ago in a Village Pump RfC and shot down. It looks far too much like our cleanup/dispute templates, and there was a clear sense that it's some "gee-whiz" blog style (an already dated one at that), and not appropriate here. Others also felt it was heavy-handed and visually disruptive in general, serving to draw WP:UNDUE emphasis to quoted material and steer the reader's interpretation, when what WP wants to do is minimize the amount and impact of quotations (see WP:OVERQUOTE and WP:NPOV). Another problem with it is that it will not improve, only worsen, the problem of block quotations being "squeezed" between left and right images, by further reducing the horizontal space. available. In such a layout, it will look like a broken partial border for the right side of the lefthand image. Oh, and a template that did this style was TfDed. Its style was merged as an option into one of the other templates. No one uses it. (It may have already been removed as cruft by now). — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 06:53, 21 August 2016 (UTC)

Proposed change

Declined

– Not applicable to this language.

I suggest that the formatting for this template be changed to match what is in my opinion the aesthetically superior ro:Format:Citat from the Romanian Wikipedia:

<div style="padding-left:3%; padding-right:3%; color:#606060; text-align: left; font-size:95%"> <span style="font-style:italic">„{{{1}}}”</span>{{#if:{{{2|}}}|<div class="templatequotecite">—{{{2}}}{{#if:{{{3|}}}|, ''{{{3}}}}}''</div>}}</div><noinclude>{{pp-semi-template|small=yes}}</code>

I hope that others agree.--Sıgehelmus (Talk) |д=) 21:13, 20 November 2016 (UTC)

English wikipedia would not use the „Romanian quotation style”, which is never used in English. — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ< 07:42, 23 October 2017 (UTC)

Date support

Is there a reason why this template doesn't support the use of the date of the quotation? If a quote is taken from a debate or event that took place on a specific day, it is common to see the date quoted in sources in such instances, e.g. "John Smith - 12 April 1956". The template documentation says: "Technically, all citation information can be given in a single parameter" and then goes on to say that the information should be identified by parameter to help with the generation of metadata (when did Wikipedia turn from an encyclopedia into a project to generate metadata?). But if you have extra information that you want to include that doesn't fit the existing parameters, you are stuck. Shoehorning it in somewhere else will just pollute the metadata. Carcharoth (talk) 05:41, 5 September 2016 (UTC)

I agree with this. Often it makes sense to date when something was said/written. A data paramater would be very benefitial here. -- Ebelular (talk) 13:18, 27 September 2016 (UTC)

I have added a "date" paramater to the sandbox. Can people check this and see if it's OK, and then maybe we can apply that to the main quote? -- Ebelular (talk) 13:34, 27 September 2016 (UTC)

Um, the |source= parameter is a catchall for all citation information. If we want to do more specific meta-data we can do that, but we'd probably do it by recycling long-extant code from the WP:CS1 system, not re-engineering it here. If you want to ask why WP is concerning itself with citation metadata, the place to ask (or object or support) is at WT:CS1, since that's where this decision was made and where the code to implement it is crafted and re-crafted. — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ< 07:44, 23 October 2017 (UTC)

Uncommon comma?

Hi, y'all. Why is there a comma and space at the end of the attribution in this quote?

— Christina Shane-Simpson; Kristen Gillespie-Lynch, [23]

Cheers! {{u|Checkingfax}} {Talk} 20:09, 22 August 2017 (UTC)

@Checkingfax:haha, this is exactly what brought me here. seems the <ref> was placed in the "source" parameter, and the comma was auto-inserted before it.

Fixed, i think, by removing the source parameter. k kisses 18:29, 21 October 2017 (UTC)

@Checkingfax and K kisses: The author/source parameters of the quote template are for visual effect, not for WP:V citations; they're for visual attribution of a usually famous quote (e.g. to do something like |author=Martin Luther King Jr.|source="I Have a Dream" speech. When using this template for the average block quotations, the full <ref>...</ref> citation goes after the colon introducing the blockquote. If you do what K kisses did, you're "polluting" the author field's metadata with non-author information that belongs in |source=. If it were important in that article's context to display the author and source info and to also have an inline citation, the way to do it would be something like:

The study concluded that:<ref>{{cite journal |last1=Shane-Simpson |first1=Christina |last2=Gillespie-Lynch |first2=Kristen |title=Examining potential mechanisms underlying the Wikipedia gender gap through a collaborative editing task |journal=[[Computers in Human Behavior]] |date=January 2017 |volume=66 |pages=312–328 |doi=10.1016/j.chb.2016.09.043}}</ref> {{quote |text= ...visible female editors on Wikipedia and broader encouragement of the use of constructive feedback may begin to alleviate the Wikipedia gender gap. Furthermore, the relatively high proportion of anonymous editors may exacerbate the Wikipedia gender gap, as anonymity may often be perceived as male and more critical.|author=Kristen Gillespie-Lynch |source="Examining potential mechanisms underlying the Wikipedia gender gap through a collaborative editing task", ''Computers in Human Behavior'', (2017)}}

That's assuming that the attribution to Gillespie-Lynch alone is actually correct (seems unlikely), and that one wanted to have that much source info appear in the visual output of the template. From the context there, this does not appear to be desirable, given the nature of the rest of the quotes in that material. I thus fixed it differently [3]. However, given the short length of the quote, this template probably shouldn't have been used in the first place; it is not used there for others, which are just given inline in the prose. — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ< 07:39, 23 October 2017 (UTC)

@SMcCandlish: but the documentation clearly states that "A reference citation can be placed: [...] After the quoted person's name, in |author=, when a |source= is not being added: [...] {{quote |text=Quoted material. |author=Pat Doe<ref>...</ref>}}". peace, k kisses 12:08, 23 October 2017 (UTC)

Docs need work. — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ< 12:10, 23 October 2017 (UTC)
Done. — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ< 12:50, 23 October 2017 (UTC)

Single line quotes broken by undesired newline in threaded talks

Using single line quotes in the middle of a threaded (indented) talk where it can appear in the middle of the sentence is currently broken.

Proof: The following wikicode

:::: ''In a long thread discussion... {{Lorem ipsum}}... I'm speaking about this: {{Quote|This is an ''inline'' quotation: {{Lorem ipsum}}...}} which '''I'd like''' to comment. {{Lorem ipsum}}...''
:::: ''Do you see that ? {{Lorem ipsum}}...''

This is caused by the fact that the last </blockquote> is preceded by a newline, which breaks the wiki input line and forces a new paragraph to be generated after it. This unwanted newline should be removed (or hidden by HTML comments) to really support inline quotes without breaking indented talk threads. (this newline was added in this old diff but this was wrong).
As well, the code {{#if:{{{multiline|}}}|<nowiki />}} is followed in all cases by a newline, which must be placed inside the "#if" by placing it between "nowiki" tags (so the newline will not be trimmed by "#if").

Thanks. verdy_p (talk) 04:38, 26 January 2018 (UTC)

Suggestion: "nested" parameter

It's a bit of a pain to copy/paste the style for nested quotations that suppresses the size change and decorative quotation marks. Could we get a nested=yes parameter that adds it automatically? Hairy Dude (talk) 03:17, 31 March 2018 (UTC)

Edit causes conflict with <small> tags

I believe the recent edit of 08:37, 10 August 2018 of Template:Quote by TheDJ resulted in Multiple unclosed formatting tags lint errors when the template is wrapped by <small>...</small> tags. There are more than 20 items affected in the main (article) namespace. (It is possible that I'm mistaken and these articles had the error even before this edit, but I don't think so.) Was this change necessary, or, is there a way to accomplish the same goal without generating this lint error? —Anomalocaris (talk) 10:32, 15 August 2018 (UTC)

@Anomalocaris: You shouldn't wrap entire templates with <small> nor with <center> or any of that kind of stuff. Styling should be done from or via (parameters) the template, and not from article content. However, this might seem like an unintended side effect of the introduction of TemplateStyles. It seems that style elements are neither phrasing nor Flow content. I wonder what User:SSastry_(WMF) thinks about this... —TheDJ (talk • contribs) 11:46, 15 August 2018 (UTC)

Since Linter errors are detected by Parsoid, this could be because of https://phabricator.wikimedia.org/T186965. We lost track of that bug, but now that TemplateStyles has been deployed everywhere, we should fix that soon. But, that apart, yes, ideally, formatting tags wouldn't be wrapping (what used to be known as block tags in html4) tags like div, blockquote, etc. But, in any case, in this instance, these are false positives and we'll fix that soon. Thanks for the heads up! SSastry (WMF) (talk) 14:55, 15 August 2018 (UTC)

Small should not wrap this template. That's a fault of the local wikitext, regardless of implementation of TemplateStyles. --Izno (talk) 15:08, 15 August 2018 (UTC)

@TheDJ, SSastry (WMF), and Izno: I am working on replacing

<small>{{quotation|...}}</small> → {{quotation|style=font-size:smaller|...}}

in the affected articles. —Anomalocaris (talk) 22:47, 15 August 2018 (UTC)

Usually smaller text isn't really appropriate, but I'm not the one making the fix... --Izno (talk) 03:31, 16 August 2018 (UTC)

multiline parameter not working?

At least in Firefox on Linux, I see no difference between cases with and without multiline=y:

Line 1
Line 2 Line 3

Paragraph 1
Paragraph 2
Paragraph 3

I'm at least temporarily removing that parameter from the documentation, so folks will use one of the more reliable methods in the "Line breaks" section. In the long term, though, should this parameter be repaired or just removed since there are alternatives? -- Beland (talk) 20:10, 2 March 2019 (UTC)

This was broken in other ways, including causing italic quoted material (if the quote ended in an italicized string) carrying over the italics to the entire content of |source=, when the |multiline= parameter was not specified. The code was not doing anything at all other than conditionally inserting/removing <nowiki />, when that bit of code actually needed to be present in all cases. I'm not going to dig way back in the history to try to figure out what was originally intended, but have simply removed this broken and undocumented parameter. The content wrapped by this template can be formatted by any means any other content block can be, including preservation of line breaks, and use of <poem> for unusual and precise layout demands. — SMcCandlish ☏ ¢ 😼 17:55, 30 January 2020 (UTC)