Page MenuHomePhabricator

Unify blockquote treatment in DSG, MinervaNeue and Vector
Open, Needs TriagePublic


blockquote currently have a mix of styles that are not aligned to Design Style Guide, or their lack of makes them hard to identify:

Current Vector


  • No border indicating a quote
  • Top/bottom spacing dependent on the element inside blockquote

Current MinervaNeue


Vs SD's Flow reply in MinervaNeue



Blockquote styles were put into place in the Style Guide with orienting on MinveraNeue's.
Update DSG's by

  • using 4px border left in Base80 #eaecf0
    • It would result in 8px border for hrs, 4px for blockquotes and 3px for h2 underlines
    • Changing color from Base70 to slightly lighter Base80, equal to hr and h2 underlines. The border is not the only information carrying element, therefore contrast question is moot.
    • Adding 8 sp padding on top and bottom to give the bigger font (not applied in upcoming patches for reasons of diverse content application) a bit more whitespace
    • Leaving 32 sp padding start and end as is
    • Removing top and bottom margin from only-child and top margin from first child in order to get whitespace right.

QA steps

Event Timeline

Restricted Application added subscribers: Masumrezarock100, Aklapper. · View Herald Transcript

Change 635092 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/skins/MinervaNeue@master] Amend blockquote spacing to Design Style Guide

Change 635097 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/skins/Vector@master] Unify blockquote spacing and style

I'd like to use this occasion to complain about the blockquote styling in Minerva (and the guide) :)

I've always found the larger and distinct font very distracting. This kind of styling would be perfect for pull quotes in a magazine article (or maybe Wikinews). It looks out of place in Wikipedia articles that actually quote some source (e.g. If anything, the quote should be de-emphasized, instead of being emphasized over the article text. (And of course, this styling is also unhelpful on any discussion page.)

@matmarex Noted. I think this comes down to personal preference and see the different font style as possibly advantageous. But in this first step it's about the indentation and border anyways.

I had a look at this @Volker_E. It’s hard to imagine how the styles look and feel like without seeing them in context. How about applying the proposed styles to a few examples and post screenshots here to see “in action”? My intuition would tell me that 20sp is a tad too big in context, but that’s just a vague guess. Gladly having a look at this again again!

Change 635092 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Amend blockquote spacing to Design Style Guide

Change 635097 merged by jenkins-bot:
[mediawiki/skins/Vector@master] Unify blockquote spacing and border style with Design Style Guide

Where styling like borders is used, it is only rarely that it is intended to mark off a blockquote but instead (and indeed noted earlier), a pull quote. These are not equivalent and providing formatting to generic blockquotes that makes them appear as pull quotes provides additional undesirable emphasis. No, it is not personal preference to compare a generic blockquote with a pull quote. The increased size is similarly frowned upon (thanks Matma!).

You will not find a professional English style guide meant for the kind of writing employed on Wikipedia (at the least) recommending the use of such a bar in providing for a blockquote, and I would guess most such guides in other languages have a similar lack. (And indeed I anticipate they similarly lack discussion on increased size.)

Where is the discussion that produced Minerva's behavior? Does the style guide accord for the fact that the bar was likely chosen in Minerva because there is no space to indent? That is clearly not a problem on desktop. The rationale for 'syncing' Vector to what Minerva does is accordingly lacking. ("It's in the style guide" doesn't mean a lot given above context.) That Minerva's behavior is different is seen as a pain by editors in the know. The bar might be reasonable on a small screen where there is little room to indent, but that is not a requirement on desktop resolutions (even width-limited ones).

Vector's display is proper. We've had years of discussions at en.wikipedia about this stuff, and consensus has resolved repeatedly to do what major, mainstream publishers do, which is standard block quotations: same typeface, same size, indented a bit on both sides. No italics, no big font, no little font, no different font, no colored backgrounds or bars, no giant quotation marks. The last RfC on this forced all the "decorative" quotation templates (the thing that look like magazine-style pull quotes) stop doing that in articles, and only emit basic block quotation markup when used in mainspace. If the mobile version is doing something different, then that needs to be fixed. If it is, the only reason that's been allowed to continue is that not enough editors have noticed and objected, being more focused on the default Vector output. Using font, color, and icon gimmicks to drag the reader's eyes to selectively presented quoted material is a serious WP:UNDUE problem. Most of the other Wikipedias follow the style lead of the English one on most matters (and get most of their formatting template code from there as well). Any WMF projects (or other wikis using MediaWiki) are welcome to do whatever they want with quotations, using local CSS. The "MediaWiki:"-namespace interface pages exist for a reason. Decorative hooey of any kind should not be imposed by default by this software. That includes pointless vertical bars (a style adopted from a particular blog platform that has nothing to do with MediaWiki or WMF or its projects).

Please provide instructions for disabling this unwanted formatting.

Communities that have specifically opted for traditional indented text formatting, as provided by the MLA or the APA, do not want distracting gray bars that contradict style guides and local manual of style consensus. Thanks.

This comment was removed by Esanders.

German Wikipedia has disabled this feature as well.

  • Our quotes are already enclosed in quotation marks. Nearly always.
  • Mostly they are provided via template, which is adding language dependant quotation marks and supporting semantics by <blockquote>, and indenting.
  • A certain amount is (mis)using : for indentation and enclosing in quotation marks. Those would get different appearance.
  • We abandoned direct usage of <blockquote> which comes from newbies via VE and will be replaced by template. Quite often that one is just misused for indentation, got a stupid grey bar now but no quotation at all.

The grey bar is superfluous and confusing in our context, and not very common in German typography, only some journals and websites use that. Our John Doe would not understand the meaning of grey bars.

For this issue DSG has a cultural bias. It is inspired by US american view of the world and may be used for and WMF internal affairs. It is not applicable literally to almost 1000 wikis in many languages and typographic cultures and scriptings, even more without consultation with communities before.

I would also add that this lame "bar-quote" stuff is a blog style that is no longer even popular on blogs. I recently went through a bunch of tutorials on customizing block- and pull-quote formatting, in various blogging platforms (WordPress, etc.), and virtually none of them recommend this style any longer, and many of them did not even illustrate it at all. So, you've clumsily forced a dead style from about 2005 on everyone, for no reason, on top of not having any concern for local wikis' own style guides. Outside of special circumstances like trying to make a fully functional mobile skin for small-screen, no-mouse devices, there is absolutely no reason for WMF's MW devs to be "pre-styling" any element in invasive ways that diverge sharply from WHATWG- and W3C-recommended defaults. Combine the KISS Principle and the Principle of Least Astonishment when it comes to such things. We may not care much when it comes to MW's own navigational/operational interface elements, but when you start imposing strange effects in the content you're very likely making a mistake.

PS: While the mobile skin probably isn't ideal for traditional block quotation (indented on both sides, no quotation marks), because space is already horizontally constrained in the average mobile viewport (and may flex and change in unpredictable ways in some mobile browsers, including elimination of such spacing), I'm even seeing skepticism that this "bar-quote" stuff is a good approach at all in that skin, because its meaning is not at all obvious (plus it still wastes horizontal space). It would make much more sense to present, in that skin, blockquote as a simple div that is a plain ol' quotation, with quotation marks (no, not giant, stupid, decorative quotation marks, just plain ones). Let the the glyphs to use be determined by the specific project in some easy way, e.g. guillemets at French projects, and so on. And give sufficient lead-time warning to actually implement something instead of just springing nasty surprises on the entire community, I beg you.

Some additional bits:

  1. Undoing of this bar-quote stuff on en.wikipedia is no longer a discussion. It was effectively reverted, with prejudice, by changes to MediaWiki:Common.css, and pretty quickly after some initial testing.
  1. Use of this bar style might be sensible on talk pages, since they are semi-threaded and the bars would help visually indicate thread relationships. And en.WIkipedia's own Template:Talk quote block already uses a bar-quote style, without heads asploding. However, replies on talk pages are presently being wrongfully encoded as mangled d-lists (dl, dd, etc.). They are a total trainwreck, and until that is fixed, any twiddling around with quotation style on talk pages is a total waste of time. The short vresion: a d-list is valid only when it opens with <dl>, closes with </dl>, consists of definition/description/association list content (something that can't be auto-detected of course), and includes at least one dt element and at least one dd element, in that order (though you can have dl dt dt dd /dl, or dl dt dd dd /dl, or dl dt dt dd dd /dl, to account for terms with more than one variant or terms with more than one explanation). So, in any case in which ; and : markup isn't forming such a valid d-list, MW should reinterpret it as divs (; as a boldfaced one and : as an indented one) without generating any list markup. On talk pages, this could be extended with IDs and such, the produce better threading, while that should of course not apply to article content. This will take further work to clean up; e.g. a line starting with * should not close with /li on that line if the line below it starts with :, including that indented content within the li. And so on. We've been over this at other tickets, some dating back to the original bugzilla.
  1. The general problem addressed in 2, above, needs to be fixed more than any other HTML compliance problem MW has, because all these bogus (and invalid) d-lists make talk pages a living Hell for uses of screen readers.

@Volker_E btw. this element also would really benefit from setting overflow:hidden to reset the block context to avoid issues with floating elements (much like we do for H#). en.wp has had this in it's Common.css for years.

Especially with an added padding border bar, as that simply gets hidden when positioned to the right of left floating content.. See also discussion on Dutch wiki where they also recently added overflow:hidden for the same reason.