MediaWiki talk:Common.css

• MediaWiki
• Meta
• Commons
• Wikibooks
• Wikiquote
• Wikisource
• Wiktionary
• de
• fr
• pl
• ja
• jbo
• it
• nl
• es

.navbox-list line-height

Could we throw out the custom .navbox-list line-height? Per above, it is no longer overridden by .plainlist and .hlist; all navbox lists are now double-spaced. Alakzi (talk) 17:41, 28 May 2015 (UTC)

I agree there are some redundant declarations and I will remove them. What do you mean 'double-spaced'? -- [[User:Edokter]] {{talk}} 21:40, 28 May 2015 (UTC)

It's just a term from the typewriter era which means double the height of the letters. Alakzi (talk) 22:48, 28 May 2015 (UTC)

That is the default spacing. In any case, I need to examine the chain of line-heights throughout, and can only do so once a patch to Vector (by me) has been deployed that fixes the line-height of list items in general. (edit: As I type this, it seems that patch is indeed live.) -- [[User:Edokter]] {{talk}} 09:04, 29 May 2015 (UTC)

Reset it to 1.5em, matching it with the headers. I could not remove it due to inconsistencies between skins. -- [[User:Edokter]] {{talk}} 09:18, 29 May 2015 (UTC)

"Consistent size for sub/sup"

Shouldn't this CSS snippet to be removed now that the associated bug is closed as resolved (Bugzilla:64653). Helder 21:20, 14 June 2015 (UTC)

That was never part of the typography refresh; I planned to include it, but felt it was better served as a general fix. -- [[User:Edokter]] {{talk}} 22:02, 14 June 2015 (UTC)

What is the inconsistency which it is fixing? Helder 00:06, 15 June 2015 (UTC)

Between browsers, which can vary between 9 and 12px (at 14px base fontsize), which hurt templates that use sub/sup. -- [[User:Edokter]] {{talk}} 17:59, 15 June 2015 (UTC)

Alignment of infobox labels

Per Special:Diff/668231133, please left-align all infobox |label=s. This would work:

.infobox th[scope="row"] {
    text-align: left;
}

Alakzi (talk) 15:16, 23 June 2015 (UTC)

On an aside since this is related to IE-specific behavior, I went looking for IE specific CSS and did the run around and finally concluded that it was deleted (at MediaWiki:Common.js/IEFixes.js) even though MediaWiki:Common.css still references IE specific CSS. Where is that CSS if it does exist, and if not, why does common.css still reference that MediaWiki page? --Izno (talk) 15:31, 23 June 2015 (UTC)

Doc error, fixed. Infobox never had IE-specific CSS. But I 'll move the tex-align to its proper place. -- [[User:Edokter]] {{talk}} 17:37, 23 June 2015 (UTC)

@Edokter and Alakzi: This has caused some issues on Template:MedalTableTop, which specifically states "text-align:center" for the medal templates, but this doesn't seem to override the left align (e.g. infobox medals on Usain Bolt). SFB 23:01, 23 June 2015 (UTC)

Well, {{MedalTableTop}} is an issue in and of itself. It'll go back to normal if we use my code. Alakzi (talk) 23:08, 23 June 2015 (UTC)

PS, it's far from the only affected one (e.g. Gulf Cooperation Council), it's just the one I'm seeing most frequently in my topic area. SFB 23:10, 23 June 2015 (UTC)

I can't fix it here, so I've fixed it there. Alakzi (talk) 23:35, 23 June 2015 (UTC)

The template sets the text-align on the table rows (<tr>); they need to be set at header/cell level. -- [[User:Edokter]] {{talk}} 18:43, 24 June 2015 (UTC)

There's no need to overwrite the text alignment of all cells; inhering from table or row is good practice. Alakzi (talk) 18:53, 24 June 2015 (UTC)

It certainly ought to be good practice, but given the way older browsers regularly failed to inherit various styles from the table element and above, it's something that has traditionally been treated with caution by developers. --RexxS (talk) 22:49, 24 June 2015 (UTC)

Table headers are centred by default. Infoboxes not built with {{Infobox}}, which applies an inline text-align: center; to column headers, have had all of their headers left-justified. Blanket-overwriting a browser default certainly isn't good practice. Alakzi (talk) 23:07, 24 June 2015 (UTC)

All collapsible infobox headers ({{Infobox rail line}}), all the S-line rows used inside {{Infobox station}} and {{Infobox China station}}, all the {{BSntext}} templates (Rokujizō Station § Layout), and so on and so forth, have been left-aligned. Please revert the change or fix it (would moving the declaration to .infobox tr work?). Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 08:28, 26 June 2015 (UTC)

A more specific selector is what would work best. I provided one such in my original request. Alakzi (talk) 09:47, 26 June 2015 (UTC)

just fixed another one. I guess we now have to do a search for all infoboxes with embedded tables and fix all of them :( 13:42, 26 June 2015 (UTC)

what's the fix for the previous and next links in Template:Infobox television episode? I imagine there are dozens of templates using these. Frietjes (talk) 13:44, 26 June 2015 (UTC)

You've just gotta duplicate the style rule in each cell and convert any "align" attributes to their CSS equivalents. Alakzi (talk) 14:14, 26 June 2015 (UTC)

that sucks, how are we going to find and fix all of these? Frietjes (talk) 14:23, 26 June 2015 (UTC)

I've been running insource: regexes with some degree of success; I've fixed twenty or so today and yesterday, including {{Infobox country}} and {{Infobox settlement}}. I've skipped lots of low-use infoboxes in the hope that this will be fixed here, eventually. Alakzi (talk) 14:31, 26 June 2015 (UTC)

The [scope="row"] selector also has problems in older browsers. Keep it simple and apply the alignment to the proper elements, Thank IE9 for not inheriting properly from the table row. -- [[User:Edokter]] {{talk}} 18:09, 26 June 2015 (UTC)

@Edokter, Jc86035, Izno, RexxS, Frietjes, Alakzi, and Sillyfolkboy: This coding modification was implemented over six weeks ago, and created a known set of text justification problems for a large number of templates that are transcluded in a large number of articles. What is the plan for correcting the template rendering errors created by this modification? And who among the proponents of this modification are now available to implement that necessary fixes? Dirtlawyer1 (talk) 22:09, 5 August 2015 (UTC)

If somebody can tell me what the text justification problem is in a given template, I can correct any rendering error. I've looked at Usain Bolt and Gulf Cooperation Council (the only examples given above) and I can't see any rendering error in any of the browsers that I have installed. Have those articles been fixed? Which articles are left with rendering errors? --RexxS (talk) 22:28, 5 August 2015 (UTC)

Navboxes top margin

It looks like we forgot to increase the spacing between the external links and navboxes after the latest visual refresh to headings. Could we bump the value of the margin-top on line 292 to 1.5 em to match the spacing between sections? Alakzi (talk) 12:07, 9 July 2015 (UTC)

Would that also apply to the case in which navboxes follow the references section? IMHO, 2em might look better. — Dsimic (talk | contribs) 12:15, 9 July 2015 (UTC)

No, it does not apply to references; we'd need to add a third selector, .reflist + .navbox. Alakzi (talk) 12:18, 9 July 2015 (UTC)

That would be awesome, as the navboxes would be no longer visually connected to the preceding section. — Dsimic (talk | contribs) 12:20, 9 July 2015 (UTC)

Not quite following. A navbox is not its own section; it is a regular template. Why should it have such a large top margin? -- [[User:Edokter]] {{talk}} 20:23, 9 July 2015 (UTC)

Right, but if it's too close to the preceding section, it might look like it's part of it. Alakzi (talk) 20:42, 10 July 2015 (UTC)

Exactly, navboxes currently look like a continuation of the section above, and that doesn't make much sense. — Dsimic (talk | contribs) 20:48, 10 July 2015 (UTC)

The navbox is part of the last section. -- [[User:Edokter]] {{talk}} 21:56, 10 July 2015 (UTC)

Technically, yes, but logically, no. — Dsimic (talk | contribs) 21:58, 10 July 2015 (UTC)

The content area is circumferenced (generally) by a 1em margin, regardless of section spacing. If there is no navbox, a category box would likely take its place; also with a 1em top margin. That is how the page is formatted. -- [[User:Edokter]] {{talk}} 22:04, 10 July 2015 (UTC)

Hm, then we either have the case of too large spacing between the sections, or too small spacing after the last section and categories, navboxes, authority control and whatnot. IMHO, that should be consistent. — Dsimic (talk | contribs) 22:07, 10 July 2015 (UTC)

Good points. Perhaps the spacing between sections should be reduced. Alakzi (talk) 22:12, 10 July 2015 (UTC)

I'd suggest that we both slightly reduce the spacing between sections and increase the spacing after the last section. IMHO, that would look much better. — Dsimic (talk | contribs) 22:16, 10 July 2015 (UTC)

You're welcome to try and get consensus for this on WP:VPR, but I don't see this happening. -- [[User:Edokter]] {{talk}} 07:54, 11 July 2015 (UTC)

Then it's better not to waste time trying to get sections closer to each other. :) — Dsimic (talk | contribs) 08:01, 11 July 2015 (UTC)

A 1em top-margin shouldn't be a problem. Once we had IE6 to think of, which didn't like the '+' selector for stacking. That is not an issue anymore. But 2em is way too much. -- [[User:Edokter]] {{talk}} 20:32, 9 July 2015 (UTC)

Then let's try with 1 em and see how it works. Though, if I'm not mistaken, CSS setting for 1 em is already in place, but I really don't see the effects? — Dsimic (talk | contribs) 20:48, 10 July 2015 (UTC)

Currently, the 1em only applies when preceded by a list (but not reflist template, which is a div). I'll make the change. -- [[User:Edokter]] {{talk}} 21:44, 10 July 2015 (UTC)

I saw your changes to the CSS code, but no spacing changes seem to be visible yet? Tried Ctrl+F5, of course. — Dsimic (talk | contribs) 22:16, 10 July 2015 (UTC)

Dsimic, link? -- [[User:Edokter]] {{talk}} 07:56, 11 July 2015 (UTC)

Just pick any page that has a navbox on it. I've seen no changes in spacing in over a dozen of such pages. — Dsimic (talk | contribs) 08:01, 11 July 2015 (UTC)

Here's a sample screenshot of the current state, as viewed in Firefox. — Dsimic (talk | contribs) 15:30, 11 July 2015 (UTC)

The margin wasn't changed, so what were you expecting to see? Alakzi (talk) 15:33, 11 July 2015 (UTC)

I'm pretty much a dumbass when it comes to CSS, :) but shouldn't that be the purpose of these changes Edokter made to Common.css yesterday? — Dsimic (talk | contribs) 15:43, 11 July 2015 (UTC)

The margin now applies everywhere (e.g after references), but it still is 1 em. Alakzi (talk) 15:47, 11 July 2015 (UTC)

Then we should definitely go with 2em. — Dsimic (talk | contribs) 15:49, 11 July 2015 (UTC)

Edokter thinks it should have the same margins as the category navigator, so it's not happening. Alakzi (talk) 15:55, 11 July 2015 (UTC)

Again, sauch a change requires a broad consensus at WP:VPR. -- [[User:Edokter]] {{talk}} 16:07, 11 July 2015 (UTC)

(edit conflict) @Dsimic: In essence, the change that Edokter made was that the first navbox would always have a 1em top margin. Previous to his edit, they had a 1em top margin only if they followed a numbered or bulleted list (such as a list of external links); when preceded by some other element (like a table), the gap was the bottom margin of the preceding element. One place to spot a difference is on a page where the first navbox is preceded by something that isn't a list, such as a succession box: see for example Angela Eagle#External links where the gap is twice as large as it was (1em instead of 0.5em). --Redrose64 (talk) 16:15, 11 July 2015 (UTC)

(edit conflict) Not really. Any such change to the page and heading margins should be made in core MediaWiki and discussed between people who understand UX, on Phabricator. Afterwards, we can adjust the navbox (and succession box) margins accordingly. Alakzi (talk) 16:18, 11 July 2015 (UTC)

I'm willing to start a Village pump discussion or create a Phabricator ticket – which one of those is the way to go? @Redrose64: Thank you for the explanation! — Dsimic (talk | contribs) 16:29, 11 July 2015 (UTC)

Goes to scope... If you want the change to be for the English Wikipedia only, we should discuss here. If you want to change the software used by thousands of projects, then Phabricator is the venue. -- [[User:Edokter]] {{talk}} 17:28, 11 July 2015 (UTC)

I'm looking only for the change in English Wikipedia. Any chances, please, for bumping it to 2em, which would flow perfectly with the current spacing between sections? — Dsimic (talk | contribs) 17:36, 11 July 2015 (UTC)

Just checking, Edokter, is this a WP:DEADHORSE case or we can discuss it further? — Dsimic (talk | contribs) 01:05, 20 July 2015 (UTC)

I would oppose that change, so even if it's not a dead horse, you have at least one detractor. The whitespace is fine as-is IMO. --Izno (talk) 01:42, 20 July 2015 (UTC)

Ok then, although I don't agree. I'll stop beating a dead horse and do something more productive. — Dsimic (talk | contribs) 06:11, 20 July 2015 (UTC)

FWIW, I concur with Edokter and Izno; 2em seems a bit excessive. It seems like you want the navboxen to be visually interpreted as forming a document section of their own, but I can't see a rationale for that. It's just more "page bottom crud" like succession boxes, stub tags, etc.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  10:27, 1 August 2015 (UTC)

I guess it's up to one's taste and perception, but navboxes are some kind of a logically separate document section. They surely don't belong either to "see also" links, references, or external links, but we currently have them visually connected to whichever section is the last one in an article. Moreover, according to WP:STUBSPACING stub tags are supposed to be double spaced, which just confirms that the navboxes should be treated in a similar way. — Dsimic (talk | contribs) 11:58, 1 August 2015 (UTC)

They are not separate from the article. This applies to all boxes at the bottom. The stub message is not a box though, and has no margin; that is why it is "usually desirable" to add an extra line to trigger a paragraph. -- [[User:Edokter]] {{talk}} 20:58, 1 August 2015 (UTC)

IMHO, navboxes are logically separate article sections. As I said, it's all about personal taste. — Dsimic (talk | contribs) 05:43, 2 August 2015 (UTC)

Harej's edit

Consensus has never been found for zebra-styled rows (though I am not sure I have an opinion). Please revert. @Harej: --Izno (talk) 19:56, 12 July 2015 (UTC)

@Izno: It is currently in use for Wikipedia:WikiProject Directory. Suggestions for alternatives are welcome. Harej (talk) 19:58, 12 July 2015 (UTC)

Not my problem. To get changes made on this page, especially inclusion of a new class, requires consensus here. Please show that consensus or revert your edit. Thanks. --Izno (talk) 19:59, 12 July 2015 (UTC)

(And there are plenty of discussions to look at; please review.) --Izno (talk) 19:59, 12 July 2015 (UTC)

I have found an alternative styling that does not require the use of CSS selectors. Harej (talk) 20:24, 12 July 2015 (UTC)

You also might want to check out http://snook.ca/technical/colour_contrast/colour.html#fg=002BB8,bg=E7EAFE which shows that your background doesn't quite cut it when a standard Wikipedia link is present in the text. --RexxS (talk) 22:37, 12 July 2015 (UTC)

Then I would've went with a different color, but the point is moot now. Harej (talk) 16:02, 13 July 2015 (UTC)

Well, the suggestion was to have a consensus discussion, not to "forbid" such a change. I'd be in favor of it, as it greatly enhances parseability of wide tables. We should at least have classes for this and an easy standardized way to turn it on for tables, even if it's unnecessary for compact tables and might not be something to have on by default.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:13, 30 July 2015 (UTC)

Compensate for italic lean

The fact that italic text leans to the right leads to a problem we can easily compensate for. In some fonts, an italicized character fuses with, even overlaps, a non-italicized character that follows it, leading to a readability/parseability problem. See Template:Var/testcases, which may or may not actually demonstrate the problem for you, depending on your fonts. This problem has been catalogued by others before, e.g. on CSS blogs, math formatting guides, etc. See, e.g., Jukka Korpela (2000), "Math in HTML (and CSS)" at "Italic may cause spacing problems", IT and Communication, Finland: Tampere University of Technology.

This can be compensated for by adding padding-right: 0.07em; or maybe padding-right: 1px; for everthing that is italic by default, including var { }, i { }, and em { }, though it is most important for var, since the issue mostly affects code and math presentation. We also would need to apply it to cite { } in theory, but it would actually be wiser to turn off italics on the element, as we did with dfn (which some browsers italicize by default); it's okay as a default style for sites that don't have their own style guidelines, but it doesn't make sense at Wikipedia. [Never mind that last; I see MW is catching up with HTML5, and we'll be using <cite> exclusively for titles henceforth.)

Use of padding-right: 1px doesn't scale with increases in font size, so it doesn't work as well at large font sizes (generally always avoid doing anything in px that affects scaleable content; that's what's em exists for). But the difference is minor in the tests I've done so far (up to font-size: 500%;, which is what a legally-blind but still slightly sighted person I know uses), and 1px will work at very small font sizes, while 0.07em might round to 0 (I haven't been able to get it to do this at a font size that's legible; if it gets to where it's working in fractional pixels, it'll round first up to 0.1em before it ever rounds that to 0; it takes a really tiny font for 1/10 em to be smaller than 1 pixel.

I've tested both versions of the CSS in Mac OS X 10.10, several versions of Windows, CentOS Linux, Ubuntu Linux, FreeBSD, Android 4, iOS, and Chromium OS (freeware Chrome OS), usually with the default fonts provided by the OS and browsers; and in multiple browsers (all the common ones): Firefox, Chrome, Chromium, Explorer, Safari, Opera, Konqueror, even some oddballs like Samgsung Internet. This has no negative effects in any of them, using either version of the code above, which has been deployed in inline-style in {{Var}} as a proof of concept. Also tested with an unusually narrow monospaced font.

It cannot do anything to compensate for unrelated forms of undesirable weirdness. E.g., the default system fonts provided in a few of the test situations, including "vanilla" virtual machines of FreeBSD and CentOS, actually have a nearly opposite problem, with all italic text being shifted a hint leftward at the baseline, such that italic text apperars a bit closer to the preceding non-italic text than it should. The above solution to the identified problem that affects actual reability/parseability for real users, right now, has no effect on this other problem, pro or con (which just looks funny, and doesn't impact the ability to make out what the text says). An attempt to do something about that with margin-left or padding-left will have an exqual-but-opposite negative effect for everyone else, causing something like abc to look like a bc. Most Linux users install Web fonts packages and such, and don't stick with default system fonts, anyway, so it's basically a non-issue.

The proposed tweak has no effect at all in Konqueror in its native rendering mode (which has incomplete CSS support), nor of course in non-GUI user agents.

PS: The source mentioned above suggests also setting margin to 0 on these elements, in case any browsers are auto-applying some by default. I'm not aware of any that are, but the Template:Var/sandbox is doing this, to test it. I can't find a case where it makes a difference, and I have a lot of virtual machines and browsers.

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

This seems a well-thought out proposal that addresses an observable problem and I can't see any downside to deploying it. It has my support - with a clear preference, of course, for the padding-right: 0.07em; over anything that works in pixels. --RexxS (talk) 22:09, 19 July 2015 (UTC)

I also am agreeable to this change for var, em, i, and cite. Turning off cite is a separate bridge to cross; see MediaWiki talk:Common.css/Archive 15#Restore default style for HTML cite element (and also MediaWiki talk:Common.css/Archive 15#cite: included work titles). --Izno (talk) 01:51, 20 July 2015 (UTC)

I can only support the 1px option, for reasons I explained on the template talk page; 0.07em will round to zero on many clients that still ude a pixel grid for font rendering, negating the intended effect. Plus, at larger sizes, the space is not needed, so we don't need scaling space. -- [[User:Edokter]] {{talk}} 05:28, 20 July 2015 (UTC)

The earlier discussion is at Template talk:Var. I can't see that 0.07em will round to 0 with any font size above 7px. And I can't read any text in a 7px-sized font anyway, so who would it affect? As for the argument that at larger font sizes, it's not needed: a lot of things are not needed, but are still worthwhile, and so it would be in this case. I wouldn't oppose the improvement that the 1px option would bring, but would still prefer the 0.07 em option, as I maintain it would look better than 1px at larger font sizes. --RexxS (talk) 08:36, 20 July 2015 (UTC)

(ec) Edokter: So, you'd oppose an improvement for almost everyone (approx. 97% of users, and identical for them to the other version of the padding) on grounds that it doesn't improve enough in the direction you favor, the edge case who have superhuman vision already, and where neither version is worse for anyone than doing nothing? That doesn't seem right. At very least one would support either version and prefer one. The px version produces a probably useless effect, for a user class who may not exist, and basically no effect for a substantial group of users, while the em version provides no effect in the case where probably no one would use it anyway, but a more useful effect than the px version does for the fairly large class of vision-impaired users. Just from an accessibility and usability perspective, wouldn't we go with the em version?  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:07, 20 July 2015 (UTC)

I thought the whole point was to make the italics more legible at default and smaller font-sizes. Larger sizes do not suffer the problem, so why the need for more (scaling) space? It will look plain ugly. And what is the point of negating the effect below 7px; perhaps some people do read that comfotably (it depends on what font is used). The 1px makes it legible for all users, not most. -- [[User:Edokter]] {{talk}} 15:55, 21 July 2015 (UTC)

Larger sizes do suffer the problem, for visually impaired users (i.e., those using the large fonts). What "plain ugly" effect are you seeing? I blew this stuff up to 500% size, in multiple browsers on multiple OSes with different fonts, and encountered no such problem. But, maybe I'm making an accessibility argument that isn't significant enough to care about; I asked WT:ACCESS and WT:WCAG, since users who are actually in that class of partially-sighted people are regulars there and can give more direct feedback. As I said earlier, I'd be in favor of the 1px version over doing nothing. My concern is that there is no "maybe" about the fact that some users read at 500% font size, and actually need to. It seems to me that this trumps the hypothetical, that some users (who don't literally need to) could maybe actually read below 7px size.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:38, 29 July 2015 (UTC)

Test, if your browser settings will even allow a font to go that small: Using 0.07em padding @ 7px: Cc vs. Oc — and using 1px padding: Cc vs. Oc — and using no padding: Cc vs. Oc. That's even smaller than nesting <sup><sup>...</sup></sup>: ^Cc (which we wouldn't do without jacking up the font size in either HTML or switching to <math>. We just don't use fonts that small, and who would make them that small manually? Lots of users make text bigger though. I 2.25x reading glasses, and still get eyestrain and jack up font size toward the end of the day. The scaling difference between the em- and px-padded versions isn't a huge deal, but doing font-related stuff in px has been denigrated since the mid-'90s for good reason. Anyway, I actually tested this, blowing up a screencap of that 7px font 500%, and can confirm that the 0.07em version does lose its padding-kerning at that size, but does it matter? Who here can legibly see the difference in the three-way test above, without cheating (no ctrl-+ / cmd-+, no glasses changes, etc.)?  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:07, 20 July 2015 (UTC)

I'm not entirely against this, but I do think it's sort of pointless in it's fragility. Truly, if you care about this level of detail of text rendering, it's time to start filing complaints with Operating System vendors, it might take longer, but at least it will benefit everyone. The web is the web and that comes with a certain amount of uncertainty about how your page will be rendered on a client. —TheDJ (talk • contribs) 18:18, 21 July 2015 (UTC)

As Edokter says, it's a font, not OS, or browser issue. (I guess its an OS issue in one minor sense in a couple of cases, i.e. the default fonts included, but users of those OSes rarely stick with them, so it doesn't matter.) The tweak doesn't seem "fragile" to me; it doesn't break anything, for any one, it just has to be optimized for one extreme of the spectrum of font sizes or the other. Web accessibility best practices already tell us which one of those to use. :-) In either case it is better for a minimum of 97% of users, yet worse for 0. Here we get to reduce a tiny bit of the GUI browser rendering uncertainty as zero cost (other than the time spent arguing about it).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  19:23, 22 July 2015 (UTC)

I should acknowledge a mistake I made in an earlier comment. Alakzi has pointed out to me that a least one browser (Chrome) uses a floor() function, not a round() function, to convert calculated ems to pixels. The effect of that in such browsers would be that 0.07em would round down to 0px below font sizes of 14px, which would negate the value of the fix at just the range where it would be most useful. In light of that, my preference would tip towards padding-right: 1px;, but as before, either fix would be an improvement over the present styling. --RexxS (talk) 21:31, 22 July 2015 (UTC)

@RexxS: Hmm. But it's not actually having the effect being predicted by you and Alakzi; Chrome is my everyday browser on the OS I use most, and I tested that browser specifically in multiple OSes, along with others.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:24, 29 July 2015 (UTC)

I'm going to agree with TheDJ here: you're screwing around with the kerning to make it look better for some users at the expense of others (including those with browsers/OSes/fonts that do it correctly)? No thanks. Anomie⚔ 18:24, 23 July 2015 (UTC)

@Anomie: Please re-read. It isn't done at the expense of anyone. It makes it look either better or visually indistinguishable (depending on fonts) for ~97% of users (all those using GUI browsers and who do not have vision problems); for the remaining ~3%, it will either also help those with vision problems (in my version), or not help them (in Edokter's version). For 0% of users does it have any negative effect of any kind. And TheDJ didn't say anything about this question, but suggested that it's an OS vendor problem (which it clearly isn't).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:24, 29 July 2015 (UTC)

In my browser and font stack it inserts unnecessary extra kerning, not terribly different from [9]. I haven't customized my browser or my font stack beyond installing DejaVu Sans. It's up to the fonts and font rendering engine (often part of the OS, otherwise part of the browser) to supply correct kerning. Anomie⚔ 11:56, 30 July 2015 (UTC)

In theory. In reality this essentially never happens for italicized text on websites unless they actually supply the fonts or do it with images. If the extra kerning for you doesn't render the material unreadable, then it wouldn't seem to be a big issue. In Edokter's version it's only 1px difference, and in mine, only more than that (by design) if you are using a large font. A 1px gap is unlikely to make any text unreadable, but when it separates run-together glyphs, it makes any affected text more readable.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:11, 30 July 2015 (UTC)

• So, are we going to get on with this or what?  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  08:56, 5 August 2015 (UTC)
  • Probably not. Regular italics is normally spaced, so the issue seems to be limited to the {{var}} template. -- [[User:Edokter]] {{talk}} 16:19, 5 August 2015 (UTC)

Fix for very long-standing problem of blockquote not working with images

There's a long-known problem of blockquote being "invisible" next to floated images. It's because (somewhere, I have not identified where yet) the left and right indentation of the blockquote is being done with margin instead of padding. This was never desirable anyway, I would think, because it moves the content box to "hug" the content, instead of keeping it the same size as a regular div, and keeping the extra left and right whitespace as part of the element's internal content instead of extraneous to it.

It's fixed with this:

blockquote {
    margin-left: 0; margin-right: 0; padding-left: 2.8em; padding-right: 2.8em;
}

The "2.8" was measured, not a guess.

I've sandboxed this, in multiple browsers on multiple OSes, at Template:Quote/testcases-images (you may need to give yourself a smaller font temporarily, to keep the tests' textual content beside/between the images).

While this could be just added to Template:Quote it should really be done site-wide, so it silently fixes all block quotation to work properly with all our floated images.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  03:01, 30 July 2015 (UTC)

I support this change. This is an old bug that needs to be fixed. – Jonesey95 (talk) 11:36, 30 July 2015 (UTC)

Such is the nature of floating block elements; they overlap with other block elements. As block elements are not supposed to be side-by-side, this is expected behaviour. That is not to say this is worth a try... barring any ill effects inside a blockquote. For example, this will affect styling such as background color, which will continue to overlap floating content. Also, what you "measured" is just 40px; which is the default margin for blockquotes (margin: 1em 40px; in all user agents). It just happens to be around 2.8em with 14px font size. So if we do this, we should use 40px. -- [[User:Edokter]] {{talk}} 16:18, 30 July 2015 (UTC)

Ah, good catch on the 40px. I was fooled by it growing proportionally as I changed the font-size on the fly with ctrl-plus, but would have caught it if I'd manually changed the font size in the code. We probably should have been overriding the 40px with a relative amount, anyway, and using my em-based version works fine. Expected behavior from the point of view of box-model theoretics doesn't really mean much to us; this being a practical publication not an HTML demo site, we need the work-around, since this is a real, long-standing problem that people vent about, and which they do bad things to get around, like italicize quotations, misuse pull-quotation templates as block-quotation templates, etc. The background-appearance issue should really only affect {{quote box}} and any very similar templates (where there'd be an undesirable gap between the border and the quotation's background), and this can be resolved with a class or by tweaking the CSS of the individual templates.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:04, 30 July 2015 (UTC)

There are several issues like this when it comes to the "default settings". Simply having left and right margins of child elements (Paragraphs in this case) within the parent blockquote tag inherit the aforementioned 40px throughout produces the same results fwiw. -- George Orwell III (talk) 00:28, 1 August 2015 (UTC)

I like the idea, but unfortunately, that produces a double indentation when there is no floating content. -- [[User:Edokter]] {{talk}} 08:29, 1 August 2015 (UTC)

Yeah, I already tested that sort of thing before I saved the first copy of the test page. Here's a demo of that failure.  — SMcCandlish ☺ ☏ ¢≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:47, 1 August 2015 (UTC)

Ok, point taken. Still, I'm uncomfortable in changing the default specs for the blockquote tag to achieve non-block like inline rendering when images are part of the mix. That scenario, to me, seems to be the exception rather than the norm when it comes to the application of the "plain" blockquote tag. Being the exception, I'd much rather see a class definition assigned to accommodate the proposed change for those image situations or the equivalent inline stylings within a specific template geared just for those same exceptional image scenarios.

Its things like that which ultimately make it harder to for semantic layout conversions to other formats more troublesome than they should be. Plus both approaches should also be viewed in mobile mode - their rendering includes quote marks. -- George Orwell III (talk) 20:18, 1 August 2015 (UTC)

"Those image situations" cannot actually be predicted at all, because the content flows and adjusts to fit the viewport and other constraints. Every single page with an image fits "the exception", so it is our "norm". I don't know what you mean by "non-block like inline rendering". Nothing at all about the display: block; is being changed. We're just compensating transparently for a problem with the element's spacing being handled with margin by default instead of padding. Purism concerns have to take a back seat to "can people read the encyclopedia?" Right now they often cannot except when editors do MOS-violating things to work around this blockquote-and-images problem, like italicizing quotations, or abusing pull quote templates with giant quotation marks (which will turn into redundantly doubled quotation marks in some mobile browsers). If we really wanted to be purist about this and to stonewall against any changes to "default" behavior, why not ask why we're using float for almost every image and wrapping it in in a box with a caption thing, in a style that bears little resemblance to what HTML+CSS do by default, when this is obviously unnecessary and causes problems like this one? If we're going to stick with that brittle over-styling, we have to be willing to compensate for the problems it causes to the central content (text) of the encyclopedia.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:08, 5 August 2015 (UTC)

Fixing this sooner than later would be good. Resolution of this is holding up other things.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  10:17, 1 August 2015 (UTC)

The cite element needs to not auto-italicize any longer

See also: Template talk:Quote § Changes to cite and blockquote in HTML specs

After something of an HTML developer community revolt, the early HTML5 change of the <cite> element to only pertain to the title of the work has been abandoned, as of late 2013. The published, non-draft version of HTML5 (28 October 2014) has expanded the scope and usage of the <cite> element, which may now be nested inside the <blockquote> element. [10]. (This was initially expected not to take effect until HTML5.1, but oh well.) All of a quotation citation's details are now wrapped in this element, not just the title of a work. Ergo, it should not be auto-italicized on WP, since this interferes with our own MOS and WP's citation styling. More specific spec links: "The cite element", "The blockquote element". Several code examples show <cite> markup of the author, of URLs, etc. not just work titles (and WP does not italicize all work titles, anyway, only major works as defined at MOS:TITLE). Note that not all of the examples illustrate things WP itself would do, or the styles we would use. As an example, 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 clearly wrongly styled on WP – the <cite>'s wording should appear as: Mark Twain, "Pudd'nhead Wilson's New Calendar", Following the Equator (1897) – despite being marked up correctly (both as to HTML5 and as to MOS). This post is concurrent with a related thread at Template talk:Quote#Changes to cite and blockquote in HTML specs.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:36, 30 July 2015 (UTC)

And... back to where it is in HTML 4. Html 5 (apparently prior to 28 October 2014) only applied to the title. *laugh*.

There should probably be a post over at Help talk:CS1. --Izno (talk) 02:46, 31 July 2015 (UTC)

There is an interesting example of the form:

<p><cite>Universal Declaration of Human Rights</cite>, United Nations,
December 1948. Adopted by General Assembly resolution 217 A (III).</p>

which rather apparently is only applying to the title rather than the full work. I suppose the caveat of "must have either title, author, or URL" makes our current use of cite correct, if not the most correct? --Izno (talk) 02:50, 31 July 2015 (UTC)

Although the etymology of 'cite' lies in summoning a person to court, in the sense where it's used on Wikipedia (and in html) it always refers to a work, which can be referred to by its title. From that viewpoint, the semantics of <cite>...</cite> imply that it should apply to the work itself (via its title), whereas the author, date, etc. are related, but not the object of what is being cited. --RexxS (talk) 13:19, 31 July 2015 (UTC)

Except HTML 5 (the October 2014 W3C Recommendation) allows for use of cite containing author or URL as an acceptable substitute to title; and the way I read it is the same as SMC--that is that the whole citation can or should be wrapped in cite. See e.g. the second example:

  <blockquote class="twitter-tweet">
  <p>♥ Bukowski in <a href="https://twitter.com/search?q=%23HTML5&src=hash">#HTML5</a> spec examples
  <a href="http://t.co/0FIEiYN1pC">http://t.co/0FIEiYN1pC</a></p><cite>— karl dubost (@karlpro) 
  <a href="https://twitter.com/karlpro/statuses/370905307293442048">August 23, 2013</a></cite>
  </blockquote>

--Izno (talk) 13:41, 31 July 2015 (UTC)

Not just me; all the usual suspects like HTML5Doctor, W3Schools, etc. say the same thing. As for "can" vs. "should", from the MW:Common.css perspective, assume "should", since some uses (including in templates) will interpret it the broad way. In particular, Template:Quote will probably go back to that way, because the template has separate parameters for author and work, and neither are required, so the element has to surround both of them to be consistently applied. PS: I have notified Help talk:Citation Style 1 about this discussion and its import for that template (the citations we generate with it should be entirely surrounded by <cite>...</cite> again, after we stop italicizing it here. Sooner would be better for that fix, BTW.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  10:17, 1 August 2015 (UTC)

The current HTML5 spec (that's the one that says "W3C Recommendation 28 October 2014" near the top) indicates in section 10.3.4 that the cite element should be italicised by default. --Redrose64 (talk) 12:01, 1 August 2015 (UTC)

I think this is being looked at from the wrong perspective. The italic recommendation for <cite>...</cite> is merely a presentational issue: it has no effect on the semantics of the markup. On Wikipedia we have always presented the content of our cite tags as italic. This has meant that it is the title of the cited work that has been italicised, even when only as a proxy for the cite tag. Because HTML5 allows more than the title to be valid content of a cite tag doesn't mean that we have to do the same. I can see no reason why our house presentational style should not remain just as it is - it simply implies that we choose to restrict the meaning of any cite tag to the title of a work and correct it when that guidance isn't followed. --RexxS (talk) 13:22, 1 August 2015 (UTC)

Rexxs: It's never actually worked, though. WP (like most formal publications that pay attention to and have a particular citation style) only italicizes the titles of major works, not minor works (see MOS:TITLE). So this auto-italicization is a big FAIL when it comes to the title of a song, poem, chapter, article, etc., all of which are marked up in quotation marks, not italics. We need to do nothing by default with this style, and let the citation, quotation, and other templates do what they need to with it on the fly. There is no actual use case for a bare HTML Title_here in Wikipedia. As I already explained about the quotation template, if this isn't fixed, then the templates cannot use this tag (unless they forcibly de-italicize it with local CSS on the fly) consistently. This is bad for metadata; e.g., one could build a maintenance tool to trawl WP for block quotations without citations, but this would fail for all of those that use {{quote}}, because tag <cite>...</cite> only wraps the |source= parameter, which is optional and only used for titles of major works (books, journals, etc.)  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  08:51, 5 August 2015 (UTC)

(edit conflict) Redrose64: Yes, I know it says it should be italicized by default. WP is not the default use case, and all HTML+CSS defaults are expected to be overridden when particular use cases don't work with the default options. The defaults exist to just do something. There are plenty of times when that something doesn't suit a particular publisher's exact needs. This is obviously such a case.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  08:51, 5 August 2015 (UTC)

OTOH, the WHATWG living standard defines <cite> thusly: "The cite element represents the title of a work ... A person's name is not the title of a work ... and the element must therefore not be used to mark up people's names." Perhaps someone in the know could tell us what the status of WHATWG contra W3C is, presently. Alakzi (talk) 13:46, 1 August 2015 (UTC)

That one also says to italicise the cite element, in Section 14.3.4. --Redrose64 (talk) 14:08, 1 August 2015 (UTC)

OTOH to your OTOH, the WHATWG spec suggests that

<p>My favorite book is <cite>The Reality Dysfunction</cite> by
Peter F. Hamilton. My favorite comic is <cite>Pearls Before
Swine</cite> by Stephan Pastis. My favorite track is <cite>Jive
Samba</cite> by the Cannonball Adderley Sextet.</p>

is a correct use of the cite tag. Which, I honestly can't see where that has ever been "typical".

It does seem that the W3C spec is inconsistent, since italicizing as a default anything but a title is also questionable (I suppose we happen to italicize the work in CS1, but I see that as only a "higher level" title).

Alakzi This article is interesting on that point, from later last year. --Izno (talk) 15:48, 1 August 2015 (UTC)

Though, the W3C (latest HTML 5.1 nightly of March 2015; didn't check the stable) does that also at

<p>Who is your favorite doctor (in <cite>Doctor Who</cite>)?</p>

. Blagh. --Izno (talk) 16:03, 1 August 2015 (UTC)

Never use HTML 5.1 nightly as a source. It can change - well, nightly. --Redrose64 (talk) 22:35, 1 August 2015 (UTC)

Agreed on that.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  08:51, 5 August 2015 (UTC)

So long as I cite my sources, and no-one deigns to provide a counterexample to suggest that the nightlys are particularly different (or even slightly different) in the case of painful inconsistency, it's actually useful to provide what the actual current thought on the use of a particular HTML element is, rather than what it was nearly a year ago. --Izno (talk) 13:54, 5 August 2015 (UTC)

(edit conflict) Izno: Yes, it is inconsistent. W3C's use cases for <cite> encompass any conceivable bibliographic/citation/speaker/sourcing material of any kind, and not just for blockquote (having it mean only title of major work was an early HTML5 experiment that was rejected). We, at common.css, cannot possibly predict every WP uses case for this, so the only rational thing to do is not force a style on it, but let the particular uses (mostly templates) determine this. In some cases it may well only be used for title of major work (in theory; in reality many minor works would also get misstyled that way), while in others it would be all non-author work-related metadata, including volume, etc., while in others (perhaps the majority) it'll end up being the entire citation, including the author, and that's the semantically cleanest way to do it, especially with regard to quotation attributions and source citations.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  08:51, 5 August 2015 (UTC)