Wikipedia talk:Manual of Style

Wikipedia's "Manual of Style/Text formatting" should allow boldfacing of "row headings"

Proposal: Include the following in the short list of things that it is permissible to boldface:

• As an inline heading (also known as a row heading) in a list, between the * at the beginning of the list entry and the rest of the entry's content, and having the concise characteristics of a higher-level, own-line heading, rather than of discursive text.

[Proposal was WP:REFACTORed to top of section, because the nom's draft version and later-accepted version are both buried in a lot of oddly-formatted material. I helped draft the final version, so consider me co-nominator, but I disclaim any connection to the off-topic material below by the original nominator.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:29, 26 July 2015 (UTC)]

Wikipedia’s “Manual of Style/Text formatting” currently does not explicitly permit the boldfacing of inline, or row, headings. Under Boldface, at https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Text_formatting#boldface, under == Boldface ==, then under === Other uses ===, the advice reads (all below is quoted material until the line):

Use boldface in the remainder of the article only in a few special cases:

• To identify terms in the first couple of paragraphs of an article, or at the beginning of a section of an article, which are the targets of redirects to the article or section (e.g. sub-topics of the article's topic, rather than the synonyms as already boldfaced per the above). (See Wikipedia:Redirect § What needs to be done on pages that are targets of redirects? for examples and further details.)
• Mathematical objects traditionally written in boldface such as vectors and the rational number symbols Q and Z.
• In some citation formats, for the volume number of a journal or other multi-volume works.

---

As a result, a STiki Barnstar of Bronze Merit-winner who has been keeping tabs on my edits in a particular article (“Patterson-Gimlin film”) has deleted the boldfacing of over a dozen inline headings, including some that pre-existed my editing. When I protested, he cited the aforesaid Manual via “MOS:BOLD”.

However, lower down on the same page in that very Manual, the boldfacing of inline headings is employed (all below is quoted material until the line):

Italic type (text like this) should be used for the following types of names and titles, or abbreviations thereof:

• Major works of art and artifice, such as albums, books, video games, films, musicals, operas, symphonies, paintings, sculptures, newspapers, journals, magazines, epic poems, plays, television programs, radio shows. Medium of publication or presentation is not a factor; a video feature only released on video tape, disc or the Internet is considered a "film" for these purposes, and so on. (See WP:Manual of Style/Titles § Italics for details.)
• Court case names: FCC v. Pacifica. (Case citation or law report information is presented in normal font)

---

In addition to the fact of exiting common use, documented above, boldfacing of row headings is fairly common and unobjectionable in publishing. It's user-friendly for the same reason that the boldfacing of standalone headings is helpful. It helps the reader grasp the outline of the material, and helps the re-reader navigate it more easily; it provides readers with visual "handholds" in a blank wall of normal text. (These advantages can be seen in a second instance of the Style Manual's use of a boldfaced inline heading style, at the end of its References section.)

The deleter of my boldfacings is acting in good faith, and he has a good case as the Manual is currently worded. And furthermore, even if he were to agree to undo his deletions, which I think he may have hinted at in his latest comment, another person could come along and justifiably delete them again, based on the Manual’s wording. So that wording should be expanded. Here’s what I suggest as a new second item in the Manual’s list above. Improvements welcome:

“* As an inline heading, also known as a row heading, in a list format (preceded by an *), which should come at the beginning of the text and have the concise characteristics of higher-level, own-line headings, rather than of discursive text.” RogerKni (talk) 18:33, 24 July 2015 (UTC)

---

@SMcCandlish: :@Melonkelon: :@Herostratus: SMcCandlish has commented on my write-up above in a different location, Village Pump: Policy, where I posted it before posting here. (I should have waited another 12 hours before posting here, in which case I'd have reorganized my comment above as he suggested, and put the proposed new text first, and the rationale second.) He provided these additional justifications for this change to the Style Manual:

"The real rationale #1 for this is that a heading is a heading, and doesn't serve a suddenly-different purpose when it is put inline to better suit the format of a list or other layout need. "The #2 rationale is that it's already deployed in similar situations, so not permitting it for lists is inconsistent and confusing. Examples: a) row and column headers in tables (a world-wide default in GUI browsers, not just on WP); b) glossary entries and any other things that resolve to dt markup in HTML (the boldfacing is hardcoded into MediaWiki as the default font-weight for the element); c) inline headers for infoboxes, navboxes, and similar templates; d) list entries on disambiguation pages and set index articles; d) ... [there are probably other examples]."

He's also suggested some tweaks to the wording I proposed for the Manual in the last paragraph of my submission just above, which I've accepted, so it now reads:

'* As an inline heading (also known as a row heading) in a list, between the * at the beginning of the list entry and the rest of the entry's content, and having the concise characteristics of a higher-level, own-line heading, rather than of discursive text.' RogerKni (talk) 20:32, 25 July 2015 (UTC)

---

Comments

• Support the version at the top of the thread, which the proponent agreed to, as seen later in the proposal. My rationale in detail is discernible here, from previous discussion, but boils down to: 1) A heading doesn't magically become a not-heading when it is formatting inline, to fit the needs of the presentation. 2) This is consistent with a myriad of other inline headings in Wikipedia, all boldfaced, including list entries already in disambiguation pages, set index articles, and many others; data table column and row headers; infobox and navbox headers; glossary entries; etc. It is also used frequently through WP:POLICY pages include MOS itself. In short, it's simply a glaring omission. Nothing about it requires boldfacing, or conversion to a format that would suggest boldfacing, or that any particular punctuation or other formatting mandates boldfacing; it's simply permitting what most of us are already doing. PS: I suggested removing all the inter-editor venting and the weird formatting before posting, but didn't do so promptly enough, I gather. That stuff shouldn't prejudice the actual wording proposed, which I massaged; I'm essentially the co-nominator of the text at the very top. Amenable to tightening, BTW.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:29, 26 July 2015 (UTC)

Discussion

Well, you have a reasonable point. I think that you went way down the primrose path at Patterson–Gimlin film, sprinkling boldfacing throughout the article text far too liberally, and this is why the the other editor went on a general rampage of cutting out bolding in the article, including the instances you cite as being OK. This has perhaps poisoned the well a little bit? Any, just on the merits of your point:

You have a reasonable point, and your example (showing the use of bolding in WP:BOLD in a way not actually prescribed in that article) is quite amusing. However, I'm not convinced. First of all, I don't know as it'd an improvement to always require this. For instance, I'm not certain that

• Major works of art and artifice, such as albums, books, video games...

is really that much better than

• Major works of art and artifice, such as albums, books, video games...

It might be. Matter of taste, maybe. However, I'm all in favor of allowing but not requiring it because I'm a let-a-thousand-flowers-bloom kind of guy. Others aren't, they are more lets-look-like-a-publication-with-an-actual-stylebook-rather-than-your-sisters-scrapbook people, and that's reasonable too. Herostratus (talk) 22:46, 25 July 2015 (UTC)

This example does not actually qualify at all, though, if this were article text:

• Major works of art and artifice, such as albums, books, video game...

That's is discoursive text running directly with the prose that follows it. MOS, as a policy page, is not written in encyclopedic style but is a work of technical writing, and its own use of "* Boldfacing, follow-on material in same sentence" in many cases, also found on lots of WP:POLICY pages, isn't what's at issue here, or illustrative of the "rule". The proposed addition also would not be "requiring" much less "always requiring" it. The recommendation for the whole section in which the new item would appear is "should", and that's fine. Something serving as a heading should have this formatting, whether block or inline (cf. table headers, etc.). It doesn't mean everything with a colon is a heading, or mean anything else other than it says. The thousand flowers can bloom as they will:

This is dialogue. (I think there is a convention for that, maybe it's italics or bold, I don't remember, and I don't know if it's a convention MOS supports; not germane to this discussion.)

• MacGyver: "I don't use guns."

This isn't really a heading per se but a simple identifier; the years would be in sequential numeric order, and nearly identical, so boldfacing them serves no purpose, except maybe when each list entry is substantial block of text; up to editorial discretion to treat it as an inline heading or not:

• 2015: Won the [insert a bunch of award stuff here]

In the case of these two:

• Psychology – Introduced by [whoever], the concept initially described [blah blah], and today encompasses [yadda yadda] ...
• Anthropology – In physical anthropology, the term denotes [foo] and is distinguished from the meaning [bar] in cultural anthropology and linguistics ...

those are obviously inline headings, despite the en-dash format instead of colon usage. And so on. I'm skeptical that we really need to spell all this out, but some examples like this could be used to illustrate the point. It should not be done here (MOS is long already!), but at a new little subsection at MOS:LIST. If we add one, include an instruction not to mix and match styles in the same list, and that's probably about all we'd need to say.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:51, 26 July 2015 (UTC)

Revision

@SMcCandlish: :@Melonkelon: :@Herostratus:

In light of the feedback above, I've modified my proposal to read:

Under the 'Boldface' section of the Manual of Style (MOS), then immediately under the 'Other uses' subheading, insert the following:

"Boldface may be used, but need not be:

"* For an inline heading (also known as a row heading) in a list, between the * at the beginning of the list entry and the rest of the entry's content, and having the concise characteristics of a higher-level, own-line heading, rather than of discursive text."

How is this for wording in 'a new little subsection at MOS:LIST'? (I'll add an appropriate heading when I get there. Suggestions welcomed now.)

• "* Inline headings need not be followed by any particular punctuation mark, or by any punctuation mark at all, provided the boldfaced text could stand alone as a heading; in other words, provided it has 'the concise characteristics of a higher-level, own-line heading.'

• "* Boldfaced inline headings should be avoided in a list of one-line entries whose inline headings have a similar and predictable nature, such as a list of consecutive years, and in borderline cases, impossible to define by rule, where boldfacing would look too 'busy.' "

RogerKni (talk) 22:01, 27 July 2015 (UTC)

Comments

"Need not be" is fine, and would help prevent over-bolding (a potential concern raised above).

Both bullet points for MOS:LIST seem fine in meaning, though could use some wordsmithing (e.g. in the second one, "... avoided in a list of one-line entries whose inline headings have a similar and predictable nature, such as a numeric sequence; or other cases where boldfacing may be more distracting than helpful."). The first bullet would be better saying something about the characteristics than quoting the statement about them, but nothing comes instantly to mind. I'm unable to think of a case that would have no punctuation at all; inline use would seem to require some demarcation between inline heading and follow-on text (indeed, it would be necessary for WP:ACCESSIBILITY purposes, since text-to-speech and some text-only browsers have no boldfacing, so it would just produce a run-on). We should specify that some divider is needed, and suggest that the colon (:) and the en dash (–) are common choices, but that whatever is used, it should be consistent throughout the list, and that a change of style from one to another in the same article should be avoided for lists of a similar character [It's often desirable to use a different style for completely different kinds of lists, though]. This reminds me, we should probably eventually have a template for this, that has a CSS class; I can handle that myself if the proposal is accepted. I don't see any outright objections so far, but the messy formatting of this, with all these horizontal lines, makes it hard to parse (and I'm not trying to 'count votes", just observing that there don't seem to be many objections to address in re-drafting, or any objections to the whole idea. Specific wording suggestions for MOS:LIST can be made over at WT:MOSLIST later, after hammering out here.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:34, 27 July 2015 (UTC)

SMcCandlish wrote, just above: "I'm unable to think of a case that would have no punctuation at all; inline use would seem to require some demarcation between inline heading and follow-on text (indeed, it would be necessary for WP:ACCESSIBILITY purposes, since text-to-speech and some text-only browsers have no boldfacing, so it would just produce a run-on)."

I think it would not be unusual for list items to lack a punctuation mark after their boldfaced inline heading, and yet not produce an accessibility problem. Here’s an example, consisting of lead-in text followed by three list-entries, in which only the "Author-(letter)" portion is boldfaced:

Authors have expressed themselves as follows on the XYZ Affair:

• Author-A says it’s an outrage, citing . . .
• Author-B insists it’s no worse than a dozen other scandals . . .
• Author-C couldn’t be reached for comment; his answering machine . . .

Text-to-speech software would not produce a funny-sounding run-on in those cases. Therefore, I suggest appending the last sentence below to the first paragraph of advisory’s text, so the proposal's text reads:

• "* Inline headings need not be followed by any particular punctuation mark, or by any punctuation mark at all, provided the boldfaced text could stand alone as a heading; in other words, provided it has 'the concise characteristics of a higher-level, own-line heading.' If no punctuation is employed, the boldfaced text should be the subject of the sentence or clause that follows.

• "* Boldfaced inline headings should be avoided in a list of one-line entries whose inline headings have a similar and predictable nature, such as a list of consecutive years, and in borderline cases, impossible to define by rule, where boldfacing would look too 'busy.' "

Modifications welcome. RogerKni (talk) 06:31, 28 July 2015 (UTC)

@RogerKni: But "Author-A says it's an outrage, citing ..." has no inline heading; it's entirely discursive text. The "If no punctuation is employed, the boldfaced text should be the subject of the sentence or clause that follows" bit is directly contradicting "the concise characteristics of a higher-level, own-line heading". Doing something like "Author-A says it's an outrage, citing ..." is precisely what we don't want, and what people would kill this proposal to prevent!

As an aside, if someone did "Author-A: "It's an outrage." (citing ...), that's dialogue reporting, in which the speaker identification should probably be treated as an inline heading. I checked around; usage in external sources is wildly inconsistent, but leans toward boldface, italics, ALLCAPS, and SMALLCAPS, the latter two of which are more or less banned on Wikipedia, and the second of which will conflict with other uses of italics, which just leaves bold, in exactly the style we're recommending: "Author-A: 'It's an outrage.' (citing ...)" I.e., give dialogue as an example of when to use this, if we end up giving exmples. This last iteration of the proposal text doesn't see to address anything I raised above, BTW.

It's not helpful to keep repeating what everyone is saying and repeating the barely-modified blocks of text. This has already gotten so long that other editors won't read it. Better to hash out some wording tweaks for a while, then produce a redraft after some more iterations, or we'll just lose everyone. It would also be helpful if you learned our conventional ways of formatting talk page posts, indenting replies with ":" at the beginning of a line and replies to replies below them with "::", and so on. The discussion will be much easier to follow for other editors (which is who we're trying to attract to the discussion). [I'm trying to command you to do this or that, I'm saying as a practical matter there's basically only one way to do it or people will mostly just ignore it and move on.]  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:21, 28 July 2015 (UTC)

@SMcCandlish: :@Melonkelon: :@Herostratus:

SMcCandlish wrote just above, quoting an example I’d used:

'But "Author-A says it's an outrage, citing ..." has no inline heading; it's entirely discursive text.'

That assumes that a punctuation mark is needed to delimit an inline heading. But I think the end of boldfacing adequately signifies the end of the heading; furthermore that "Author-A" does have "the concise characteristics of a higher-level, own-line heading".

No reader would be led astray by the lack of a punctuation mark in the four-line example I supplied above (about "the XYZ affair"). The boldfaced authors' names at the start of each list-entry are clearly topic-headings for that entry. It would not be reader-friendlier to write the topic word twice instead, thus: "Author-A. Author-A says it's an outrage, citing ..."

Nor would it be writer-friendlier, or copy-editor-friendlier. Wordy existing paragraphs are often easier to follow if copy-edited into a list format, with each sentence being a list-entry. Once that has been done, it is additionally helpful to the reader to boldface the subject of each line, if it happens to begin the sentence. It is also less work for the editor than rewriting the sentences and inserting extra words and punctuation.

In order to address an SMcCandlish suggestion of 22:34, 27 July 2015, I propose that the following text (largely copied from his) follow the first sentence in the first paragraph of my two-paragraph proposal above:

"Suggested punctuation marks after an inline heading are the colon (:) and the en dash (–), although others are acceptable. Whatever mark is chosen, it should be consistent throughout the list. For lists of a similar character, a change of mark from one to another in the same article should be avoided."

SMcCandlish wrote, "It's not helpful to keep repeating what everyone is saying and repeating the barely-modified blocks of text." I will avoid doing so in the future. My intent was to be helpful by avoiding the need for readers to look back to prior comments for context, but to bundle and repeat it locally.

I feel I am out of my depth in packaging and promoting my proposal here. I'd appreciate it if you, SMcCandlish, or some other Wikipedia adept who is reading this, would volunteer to "carry the ball" henceforth. — Preceding unsigned comment added by RogerKni (talk • contribs)

@RogerKni: I understand it can be frustrating. I'll be happy to carry the ball on this one, because I care about it, too. BTW, whatever external editor you are using (Microsoft Word?) you need to turn off the "smart quotes" (curly quotes) feature in it, or use a different, plain-text-only one; it is changing ' and " into the curly versions, on the fly, and breaking wiki-formatting. I've had to fix several of your posts, including the above one, in this regard. It would do that in articles, too.

Early in this discussion people were already objecting, in other wording, to the idea that "the end of boldfacing adequately signifies the end of the heading". I.e., we'll get nowhere without there being a punctuator of some kind. It's not that any reader would be led astray, it's that boldfacing the beginnings of list items when they don't have the character of *Item: Discursive material here is seen as excessive. That's basically why we don't already have a "rule" permitting inline headings in lists: No one has been able to articulate a rule that doesn't permit willy-nilly boldfacing simply to introduce list items, and this is widely objected to. It's the main objection to the proposal as originally drafted, here, too. So, if we want any support at all for sometimes using bold for inline headings, ever, it'll have to be narrow and specific, because consensus already "assumes that a punctuation mark is needed to delimit an inline heading".

There would be no need to use the redundant construction '''Author-A'''. Author-A says "whatever they said..."; if it's desirable to treat the speaker as a inline heading, then dialogue format '''Author-A''': "Whatever they said ..." will do.

There's a general consensus against copyediting paragraphs into lists, but rather the other way around is favored. See, e.g., MOS:TRIVIA which strongly advises to rewrite lists of details into prose paragraphs. MOS:LIST has similar advice more generally

It's already implicit that other characters than : and – could possibly be used; MOS is just a guideline. It's hard to think of ones that would be appropriate very often, so the WP:CREEP principle applies here. MOS should not try to pre-figure every conceivable scenario, or it will be 10x longer than it already is.  :-)

At this point, I think the proposal has bogged down so much it's best to just close it and launch another one later. I'll be happy to do that.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  01:37, 30 July 2015 (UTC)

@ SMcCandlish. Re your willingness to relaunch my proposal: Good, I’m happy to hand over the baton.

Re curly quotes: I created my previous post in Word, but I replaced its curly punctuation marks with straight/plain quotes and apostrophes taken from your comment before it, which I had copied into Word. I don’t know what went wrong. This time I’ll check how it looks and correct it on-site.

(Say, maybe Wikipedia could/should add a filter that automatically converts curly items as they are pasted into it.)

If Wikipedia's 'consensus already "assumes that a punctuation mark is needed to delimit an inline heading"' then there is no practical hope for me to fight it in my proposal.

But I don’t accept its contention that: 'if it's desirable to treat the speaker as a inline heading, then dialogue format Author-A: "Whatever they said ..." will do.' That’s because the boldfaced name at the start will often not be a 'speaker,' but merely the subject of the sentence. So dialog format would not suffice, because his remarks are paraphrased, as in the three list-example-items I provided above. To handle paraphrased remarks when a punctuation mark is required after the boldfaced portion, an undesirable repetition of the name would be needed.

As for, 'No one has been able to articulate a rule that doesn't permit willy-nilly boldfacing simply to introduce list items': I think I did so when I wrote, 'If no punctuation is employed, the boldfaced text should be the subject of the sentence or clause that follows.' That’s adequately restrictive. I urge the consensus to ponder this.

Re: 'There's a general consensus against copyediting paragraphs into lists . . . . ' Oops!

PS: A period should be explicitly mentioned as a permissible punctuation mark, along with the colon and N-dash.RogerKni (talk) 13:33, 30 July 2015 (UTC)

RogerKni (talk) 13:27, 30 July 2015 (UTC)

Usage of & versus a break

Hi all, although I believe that breaks are better usage, still wanted to confirm, what is the MOS for separating two names in a list order? Which one should it be from the following:

• Ryan Murphy & Brad Falchuk
• Ryan Murphy <br> Brad Falchuk

There is an existing problem with all the American Horror Story articles using the former as opposed to the latter. —Indian:BIO ^{[ ChitChat ]} 04:32, 25 July 2015 (UTC)

Using it where? I just looked at American Horror Story and did not see it. Agreed, use linebreaks (unless the two people are a team and credited as such), but it's <br /> not <br> (the shorter, sloppy version makes the server do extra parser work for no reason). Depending on the nature of the infobox field, it may be ,<br />, when giving a short inline list and you want it to break at a specific point. PS: There are also templates for doing inline lists {{plainlist}} and {{comma separated entries}}, and MOS should probably start recommending them where appropriate (probably not in MOS proper, but at MOS:LIST and WP:INFOBOX, because the coding and semantic markup results will be superior, and it will be easier for wiki editors who are not "HTML people" to maintain.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:01, 26 July 2015 (UTC)

Hi SMcCandlish the usage is at American Horror Story: Freak Show and American Horror Story: Hotel in the episode lists, sorry should have guided you to the edit area. Thanks for clarifying, I think {{plainlist}} should be better for using it. Shall I change in the article? —Indian:BIO ^{[ ChitChat ]} 05:31, 26 July 2015 (UTC)

@IndianBio: Oh, under the "Written by" column. I'd thought this was about infoboxes. Okay. I wouldn't, after all, use the inline list templates (two isn't a "list", really), nor <br />, since there's no need to line-break it for people with wide montitors (it all fits on one line for me, and would look weird and vertical-space-wasting to line-break forcefully between those two names. It's just regular text, and should use "and", or "," not "&" (which implies they're a unit of some kind); "and" is clearer, but if space is at a premium, comma will do. If the intent is to just ensure that, at narrower window widths, the individual's names don't line-break, but the cell's content can break at the conjunction, just {{nobr}} around each name::

• {{nobr|[[Ryan Murphy]]}}, {{nobr|[[Brad Falchuk]]}}

 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  06:53, 26 July 2015 (UTC)

Thanks for confirming, will implement as you suggested. —Indian:BIO ^{[ ChitChat ]} 07:09, 26 July 2015 (UTC)

is this a policy on wikipedia

is this a policy on wikipedia — Preceding unsigned comment added by A8v (talk • contribs)

These are guidelines that are widely accepted by the community. See this page to read about what policies and guidelines are. EvergreenFir (talk) Please {{re}} 21:08, 27 July 2015 (UTC)

Short answer... No... it isn't "Policy"... but it is excellent guidance, and is widely accepted as such. The MOS itself states that we can make an exception to this guidance if necessary ... but it takes a fairly solid consensus to do so. Be prepared to make a compelling case that an exception is necessary. Blueboar (talk) 01:11, 28 July 2015 (UTC)

Blueboar is right to advise caution. In my experience, people treat the MoS as if it were a set of non-negotiable rules, even though they're technically not supposed to. Darkfrog24 (talk) 16:02, 28 July 2015 (UTC)

In my opinion, a lot of that stems from Wikipedia's over use of short-cuts... when a policy or guideline has too many short-cuts pointing to its various sub-devisions, people tend to only pay attention to the sub-devision that is linked by the short-cut... and ignore the rest of the policy or guideline... such as the part where it says it's OK to make exceptions to it. MOS is not the only guideline or policy where that is an issue. Blueboar (talk) 20:09, 28 July 2015 (UTC)

Proposal: Disable giant quotation marks in mainspace; deprecate pull quotes in articles

There are virtually no legitimate uses of pull quotes in WP articles, because WP is not written in news style. Worse, editors are rampantly ignoring the instructions in both MOS:QUOTES and the documentation of the pull quote templates like {{cquote}}, and using them as pure decoration for block quotations. I've used {{cquote}} around the proposal details below, to illustrate it. The majority of the uses of these templates are to incorrectly format block quotations in articles. This can be resolved by putting a namespace test in the templates that suppresses display of the giant, decorative quote marks if the templates are used in articles. The small number of existing, actual pull quotes in articles can be reformatted with another template, such as {{quote box}}, that no one tries to abuse for inline block quotations (it shunts the quotation into a right-hand sidebar box, which is a more common style for pull quotes that using weird, giant quotation marks, anyway). I've illustrated the {{quote box}} template with the "Note" to the side of the proposal details below. Actually, mostly pull quotes in mainspace could just be removed, but that should arguably be up to article-by-article consensus determinations.

Several of us have been trying to clean up this mess for years, and it never gets any better, so it's demonstrably time to just do away with the "attractive nuisance" of {{cquote}} adding giant quotation marks in mainspace.

Note

These proposals are all severable (e.g., one might favor 1, 3, 4, without actually deprecating pull quotes; or support #1, 2, 4, without recommending any template for pull quotes at all; etc.)

“

Details:

1. Disable the display, in mainspace, of giant quotation marks in templates that use them.
2. Recommend generally against the use of pull quotes because they are rarely appropriate in encyclopedic text.
3. Recommend {{quote box}} for pull quotes, in the rare case that consensus at a page is certain that one should be included. [Or recommend some other replacement template(s) without giant quotation marks.]
4. Use AWB or some other process to convert most uses of {{cquote}} in mainspace to {{quote}}, or when it is clearly a pull quote (because the same quote is repeated elsewhere in the article), to {{quote box}} [or some other alternative].

”

 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:21, 30 July 2015 (UTC)

• support - these are rampantly abused in almost every situation that I have seen them in articles. i cannot imagine where they would be appropriate. -- TRPoD aka The Red Pen of Doom 00:32, 30 July 2015 (UTC)
  • The only arguably legitimate cases – rare – that I've seen are in very large articles, where a pull quote is used to repeat and highlight a quote or partial quote that has already been given in a dense block of paragraphs. Even if these cases are great ideas (dubious), there are very few of them. I think it's dubious because it's extremely difficult to do this without triggering WP:UNDUE concerns. If you then need two pull quotes, to illustrate both sides of an issue, that's a visual mess, and better handled with a section summarizing the opposing views.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:46, 30 July 2015 (UTC)
• Conditionally Support: The MoS recommends blockquotes for longer quotes, and also has guidelines for their format: no quotation marks, no pull quotes, and no italics. However, the standard {{quote}} template has no way (that I know of) to force [extra] indentation of a quote inserted next to a left-justified image. I have seen many articles where either italics or cquotes are used to set such quotes off from the surrounding text. (The correct formatting can be achieved using a blockquote HTML instruction followed by a CRLF and a colon-forced indent, but I don't think this is accepted as standard practice.) If the quote template could be modified to do these indentations properly (preferably automatically, but with a separate parameter directive if necessary), I would wholeheartedly support the proposal. 2600:1006:B11A:ED71:14E8:C473:9B00:7111 (talk) 01:13, 30 July 2015 (UTC)
  • The fix for this problem has just now been submitted at MediaWiki talk:Common.css#Fix for very long-standing problem of blockquote not working with images.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:04, 30 July 2015 (UTC)
    • Wow, that was quick. Thanks. If it was that easy, it makes me wish I'd taken an HTML class.

With that under control, I support the proposal. Normally I oppose hard-coded, unbypassable restrictions, but as you point out this guideline is pretty clearly decided but pretty widely ignored, so one change to the template would save an awful lot of wasted time changing articles. 2600:1006:B11A:ED71:14E8:C473:9B00:7111 (talk) 04:09, 30 July 2015 (UTC)

• Oppose. I don't see that the case has been made that this has to be decided centrally. While I personally do not often find occasion to use this feature, I also don't see it causing widespread harm; whether an individual use is appropriate can be discussed on a case-by-case basis. --Trovatore (talk) 01:20, 30 July 2015 (UTC)
  • Things don't have to be "harmful" to be poor style rejected by consensus. It's already has been decided centrally, for years, and is being evaded (out of carelessness mostly, though sometimes obstinacy) because of a shiny template acting as a beacon, "use me, u-u-use m-e-e", despite MOS and the template's own documentation saying not to. The case-by-case approach has been tried, for years, and dismally failed. It will continue to fail because 99+% of the time it's added to an article without discussion, and content editors at articles are not going to argue about it. Article talk pages are not for arguing over style quibbles; settling such matters is why MOS exists in the first place.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  01:45, 30 July 2015 (UTC)
    • Far too much is decided centrally. This is a bad thing. I know you feel differently. --Trovatore (talk) 02:01, 30 July 2015 (UTC)
      • Um, ok. But this was already decided centrally years ago. Maybe you want to make a counter proposal that block quotations should use giant quotation marks, and MOS changed to say that? Or whatever it is that you want?  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:04, 30 July 2015 (UTC)
        • So what it seems to me you're saying is, stuff was decided centrally previously, but it isn't being followed, so now we should decide more stuff centrally, to make it easier to enforce the old stuff. Is that a fair summary? That's a genuine question; it's certainly possible that I've missed your point, and if so, then please do point out where. --Trovatore (talk) 03:47, 30 July 2015 (UTC)

It's clarifying the existing consensus. This process, which you object to for being "centralized" (like everything else with {{guideline}} or {{policy}} on it), has already proven fruitful, in identifying precisely why MOS is being ignore by some editors: They're doing it to work around a CSS bug, that is even now being slated for correction at Mediawiki talk:common.css; the problem has been known to exist since 2010 I think, but only just now nailed down. But <gasp>, this, too must be Evil and Bad, since that's another sinister centralized discussion. But don't tell anyone, the cabal might overhear, and send in a black ops team to silence you.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:09, 1 August 2015 (UTC)

• Support 1, but I'm not sure this is a MOS issue. The guide and the template already say not to use this style in article space, but it is used, probably because it's easy and visually interesting. I support changing the template to display as a regular block quote in article space. Pburka (talk) 03:22, 30 July 2015 (UTC)
• Heck no, absolutely not. {{cquote}} is great, it's one my go-to tools. This whole thing is kind of a clusterfuck, but not really as bad as you might think, as long as few things are understood.

1. First, right, there's essentially no need or use for pull quotes in this encyclopedia, of course not; every reasonable person understands that, I would think.
2. Second, {{cquote}} (which, absurdly, devolves to the misnamed {{Pull quote}}) has nothing to do with pull quotes and never has, notwithstanding the silly and universally ignored admonitions in the instructions. (If you don't believe me, do a random search of uses of the template; I did 20, and all 20 were regular quotes rather than pull quotes, and I assume (and certainly hope!) that that scales up indefinitely at ~100%.)
3. Third, the use of the large quotation marks is pleasing to the eye, communicates quickly and efficiently to the reader that she is shifting from reading body text to reading a quotation, and is in line with reasonably professional, reasonably modern layout.

You can call big quotes a cliche or you can them a timeless classic, but either way I grant they're not cutting edge; but at least don't scream "Hi, we're from the 20th century! Isn't HTML cool?" to the reader, as {{Quote box}} does. So ugly.

I'm old enough to remember using the ASCII line characters (╔ and ═ and so forth) to draw boxes. {{Quote box}} is maybe a slight improvement on that and brings the look up into a kind of 1990s vibe. Whee. As to {{Quote}}, it's terrible -- using only indentation (which is often lost on mobile devices, on image-heavy layouts, or if your text size is set larger than standard) keeps the reader guessing about what she's reading -- is it a quote? Is it body text? You have to read ahead to figure this out. Completely breaks one's concentration, to no gain. Just awful.

Anyway, here's the solution: just do as I and everybody else who uses {{cquote}} does: simply ignore the stuff about pull quotes. Problem solved! (Obviously, we could improve things by removing the admonition about pull quotes and otherwise bring the instructions in line with actual practice. That'd be ideal. I tried doing that but an editor objected. Fine. It's not worth fighting about, as long as everyone understands -- as they appear to do -- that those instructions are just something some individual wrote a long time ago and is not worth paying any mind to.) Herostratus (talk) 04:20, 30 July 2015 (UTC)

Um, except there is no consensus at all for giant quotation marks as block quotation style on Wikipedia. The fact that a pull quote template (even if you want to call it not-a-pull-quote-template) is being misused to format a tiny fraction of block quotations doesn't magically change that. The fact that most uses of this template are for block quotations does not translate magically into "most block quotations use that template"; just ain't the case, never has been, never will be. The fact that a CSS problem was causing block quotation to be undifferentiated from other prose when mashed up against a floated image is the primary reason some editors were citing WP:IAR to use {{cquote}} for block quotations, or to italicize quotations (or do some other thing to differentiate the text). When the CSS issue is fixed, shortly, this IAR rationale no longer exists, leaving nothing but an "I like giant quotation marks" feeling. If you think everyone loves giant quotation marks, we can just have an RfC, as I suggested to Trovatore, to see if consensus agrees with you. I think we all already know how that will go. If you think {{quote box}} is ugly propose some CSS changes to it. There are lots of ways to do more subtle things stylistically than what that template does. If you can demonstrate genuine usability problems with {{quote}}, same story: CSS exists for a reason, and it can probably be handled with a minor style change, e.g. a subtle background color shift, just enough to pass accessibility tests for contrast. Your 'at least don't scream "Hi, we're from the 20th century! Isn't HTML cool?" to the reader ... Completely breaks one's concentration, to no gain. Just awful.' is precisely why the giant quotation marks are deprecated. They look like some 13-year-old's "My First Webpage" idea of "design". We have an entire additional guideline against festooning articles with cutesy little graphics like this. For a reason.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:32, 1 August 2015 (UTC)

PS: {{Cquote}}'s very first explanatory documentation stated clearly it "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.", etc. This, along with the related MOS material, dates to 2006, and consensus has not changed in favor of plastering giant quotation marks all over Wikipedia in the intervening 9 years, sorry.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:41, 1 August 2015 (UTC)

• Oppose, they aren't that 'giant' and are usually interesting to run across. They accent that 'this is a quote', and usually are used for important quotes. If there are too many on a page I can see a reduction, but an occasional use seems to enhance, rather than injure, a page. Randy Kryn 12:00, 1 August 2015 (UTC)

  • They accent that 'this is a quote', and usually are used for important quotes.

This points out a significant problem with the way they are currently (mis)used. Why are Wikipedia editors deciding which quotes are "important"? Or, why would unimportant quotes be viewed as acceptable in the first place? 2600:1006:B11A:ED71:14E8:C473:9B00:7111 (talk) 22:40, 1 August 2015 (UTC)

• Comment. I am not aware that cquotes are "rampantly abused", or that pull quotes lack "legitimate uses" in WP articles; these points are not yet established. And I have a vague memory, on once encountering such "gigantic quotes", of finding that instance not just interesting, but even amusing, And I don't know why WP articles should not occasionally be amusing. So I would be reluctant to universally and arbitrarily prohibit them. (I agree with Trovatore: "far too much is decided centrally".)

As to rampant use: how often? And is there any measure of how much of that is misuse, abuse, or just lack of care in selecting a quote template? Are there more nuanced ways of dealing with such cases? ~ J. Johnson (JJ) (talk) 20:33, 1 August 2015 (UTC)

• Query - MOS:QUOTE states: "Do not enclose block quotations in quotation marks (and especially avoid decorative quotation marks in normal use, such as those provided by the {{centered pull quote}} template, which are reserved for pull quotes)." Thus MOS:QUOTE seems to implicitly recognize that pull quotes may be used, and that large so-called "large decorative quotation marks" may be used for pull quotes. Am I missing something here? Dirtlawyer1 (talk) 21:09, 1 August 2015 (UTC)

Advice about using columns in articles

Do we actually have any MOS advice about when to use columns in articles? By "columns", I mean {{multicol}} and related formatting, not the "rows and columns" in proper tables. MOS:COLUMNS is a red link, and my search turned up nothing obvious. WhatamIdoing (talk) 19:07, 30 July 2015 (UTC)

Is there an article that actually uses multiple columns (other than in a proper table?)... if so, could you give us an example? Blueboar (talk) 23:54, 30 July 2015 (UTC)

There are a number of WP:Embedded lists which do so. Special:Whatlinkshere/Template:Multicol or any of the family of templates should provide an example, such as Arthur Laurents#Directing. --Izno (talk) 03:05, 31 July 2015 (UTC)

And presumably other than in Notes and References sections – right? ~ J. Johnson (JJ) (talk) 20:56, 31 July 2015 (UTC)

See also Australian hip hop § Notable artists, which uses {{divcol}}. —sroc 💬 06:50, 1 August 2015 (UTC)

Note this from Wikipedia:Manual of Style/Layout § Standard appendices and footers §§ See also section (MOS:SEEALSO):

Contents: A bulleted list, preferably alphabetized, of internal links to related Wikipedia articles. Consider using {{Columns-list}} or {{Div col}} if the list is lengthy. The links in the "See also" section might be only indirectly related to the topic of the article because one purpose of "See also" links is to enable readers to explore tangentially related topics.

—sroc 💬 06:57, 1 August 2015 (UTC)

Also refer to Wikipedia:Manual of Style/Accessibility § Block elements §§ Tables §§§ Layout tables, which discourages the use of tables for layout purposes. —sroc 💬 07:01, 1 August 2015 (UTC)

Is there some recurrent problem that MOS needs to address?  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:04, 1 August 2015 (UTC)