Last modified: 2014-04-29 23:26:12 UTC
VE's edit surface has a body font size of 0.8em (equals 13px) which mismatches with the new default body font size (0.875em, which translates to 14px on Chrome and Firefox on most systems). The same is true for line-height, which is now 1.6em for body content. We should make sure the two are consistent. The body font stack and heading settings do get translated to VE edit mode correctly, so we're close. :)
As discussed, we should apply the styling to bodyContent to affect other parts of the page like siteSub, contentSub, printfooter, catlinks, and also VE edit surface etc.
Both @body-line-height and @body-font-size are already applied to #bodyContent (see bug 63731). Don't you mean they should be moved to div#content instead, where everything else is defined?
*** Bug 64124 has been marked as a duplicate of this bug. ***
(In reply to Erwin Dokter from comment #2) > Both @body-line-height and @body-font-size are already applied to > #bodyContent (see bug 63731). Don't you mean they should be moved to > div#content instead, where everything else is defined? Sorry, yes. Corrected title.
Just discovered that setting the 0.875em fontsize to #content instead of #bodyContent messes with the layout of the entire page; the navigation bar relies on the fontsize of #content to be 1em, otherwise it collapses. To compensate, the left margin of #content would have to be modified from 10/11em to 11.43/12.57em. That seems quite an unsightly hack with a potential for alignment issues due to rounding errors. Just so you know.
(In reply to Erwin Dokter from comment #5) > Just discovered that setting the 0.875em fontsize to #content instead of > #bodyContent messes with the layout of the entire page; the navigation bar > relies on the fontsize of #content to be 1em, otherwise it collapses. > > To compensate, the left margin of #content would have to be modified from > 10/11em to 11.43/12.57em. That seems quite an unsightly hack with a > potential for alignment issues due to rounding errors. > > Just so you know. Suggests that we should probably revisit the margins a little, but yes. :-( Can we get this fixed urgently? It's a quite disruptive regression for VisualEditor users.
Change 129567 had a related patch set uploaded by Trevor Parscal: Use .mw-content for content styling https://gerrit.wikimedia.org/r/129567
I'm not quite sure about the pre-typograpy-refresh situation, but it shouldn't be to different from the curent. Here's the situation now . We have #mw-head-base (tabs and personal links) and #content (#firstHeading, #bodyContent, #catlinks and everything in between). Both have a base fontsize of 1em and left-margin of 10/11em. They need to match, no matter what, to align the tabs with the content part of the page. Fontsize isn't actually set until deep inside the various parts: #p-personal li {font-size: 0.75em;}, div.portal div.body ul li {font-size: 0.75em;}, div.vectorTabs li a {font-size: 0.8em;}, and in #bodyContent {font-size: 0.875em;} The rest of the Vector layout relies on the base fontsize of 1em. If you must have 0.875em for #content, then the entire structure needs to be revised. So I don't know is VE can match the current situation, that would be the easiest way.
Change 129563 had a related patch set uploaded by Krinkle: Make new styles target .mw-content instead of #bodyContent https://gerrit.wikimedia.org/r/129563
Change 129563 merged by jenkins-bot: vector: Apply content text style via .mw-body-content instead of #bodyContent https://gerrit.wikimedia.org/r/129563
Change 130481 had a related patch set uploaded by Jforrester: vector: Apply content text style via .mw-body-content instead of #bodyContent https://gerrit.wikimedia.org/r/130481
Will back-port to wmf2 at least.
Change 130481 merged by jenkins-bot: vector: Apply content text style via .mw-body-content instead of #bodyContent https://gerrit.wikimedia.org/r/130481
