Last modified: 2014-04-29 23:26:12 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 63985 - [Regression] Vector: font-size and line-height should not be applied to #bodyContent (too specific, not applied to VisualEditor etc.)
[Regression] Vector: font-size and line-height should not be applied to #body...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
unspecified
All All
: High normal (vote)
: 1.23.0 release
Assigned To: Krinkle
: code-update-regression
: 64124 (view as bug list)
Depends on:
Blocks: typography-refresh 64599
  Show dependency treegraph
 
Reported: 2014-04-16 01:01 UTC by Steven Walling
Modified: 2014-04-29 23:26 UTC (History)
12 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---
jforrester: Backport_to_Stable+


Attachments

Description Steven Walling 2014-04-16 01:01:01 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. :)
Comment 1 James Forrester 2014-04-18 18:19:26 UTC
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.
Comment 2 Erwin Dokter 2014-04-19 10:24:37 UTC
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?
Comment 3 Erwin Dokter 2014-04-19 10:38:26 UTC
*** Bug 64124 has been marked as a duplicate of this bug. ***
Comment 4 James Forrester 2014-04-21 21:15:48 UTC
(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.
Comment 5 Erwin Dokter 2014-04-23 17:50:44 UTC
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.
Comment 6 James Forrester 2014-04-24 18:12:13 UTC
(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.
Comment 7 Gerrit Notification Bot 2014-04-24 20:31:40 UTC
Change 129567 had a related patch set uploaded by Trevor Parscal:
Use .mw-content for content styling

https://gerrit.wikimedia.org/r/129567
Comment 8 Erwin Dokter 2014-04-24 21:03:12 UTC
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.
Comment 9 Gerrit Notification Bot 2014-04-29 12:03:13 UTC
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
Comment 10 Gerrit Notification Bot 2014-04-29 20:46:06 UTC
Change 129563 merged by jenkins-bot:
vector: Apply content text style via .mw-body-content instead of #bodyContent

https://gerrit.wikimedia.org/r/129563
Comment 11 Gerrit Notification Bot 2014-04-29 20:46:26 UTC
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
Comment 12 James Forrester 2014-04-29 20:48:35 UTC
Will back-port to wmf2 at least.
Comment 13 Gerrit Notification Bot 2014-04-29 23:26:12 UTC
Change 130481 merged by jenkins-bot:
vector: Apply content text style via .mw-body-content instead of #bodyContent

https://gerrit.wikimedia.org/r/130481

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links