[go: up one dir, main page]

Page MenuHomePhabricator

Improve printing of all sup and sub elements.
Closed, ResolvedPublic

Description

I see that recently someone fixed the line height issues caused by references in the <sup> elements.

This was done by setting

sup.reference {
    line-height: 0;
}

I propose changing this to

sub, sup {
   line-height: 1;
}

This is the same that the Desktop version uses as well and was reached after long investigations over multiple years as the best solution and was then moved from en.wp into our MediaWiki styles. If we use it on desktop, might as well use it in print as well.

There should be no difference between 0 or 1 (as font size multiplied by 0 is invalid and falls back to multiply by 1 [or user-agent default]).

Event Timeline

TheDJ renamed this task from Improve printing of sup and sub elements. to Improve printing of all sup and sub elements..Aug 4 2017, 9:35 AM

@TheDJ Where (in which file) is the line-height: 0 on sup.reference set?
There's a content.parsoid.less rule with line-height: 1 for sub, sup.

If we gonna touch this, we should probably go for complete normalize approach, which uses 0 to overcome browser quirks:

sub,
sup {
  font-size: 75%;
  line-height: 0;
  position: relative;
  vertical-align: baseline;
}

sub {
  bottom: -0.25em;
}

sup {
  top: -0.5em;
}

@VolkerE It seems that it is only on the staging for reading team:
http://reading-web-staging.wmflabs.org/w/index.php?title=MediaWiki%3APrint.css&type=revision&diff=26&oldid=9

BTW, that suggestion has a significant problem. It was what we tried initially in English Wikipedia and it completely messes up multiple nested sups or subs (quite common in math articles).

Screen Shot 2017-08-10 at 13.26.37.png (346×706 px, 79 KB)

This problem is why we switched to line-height:1, which is pictured below it. That way the first level still fits into the normal line height, but at the same time when you stack multiple levels deep, the HTML will still make way for the exception to the rule.

line height is also defined as 0 in https://en.wikipedia.org/wiki/MediaWiki:Print.css so when we know what we want to do we'll fix it there.

Looks like this has been discussed before somewhere as DJ says

I would suggest, let's set it to 1 on https://en.wikipedia.org/wiki/MediaWiki:Print.css

any further normalization can be done as a followup with different card

Change 373299 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/Vector@master] Set line height to 1 for sup and sub elements

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

Fixed on wiki. Patch takes care of it in the code if I can get a quick merge ^

Note that we have done this for screen styles years ago – T51965. As I understand, this task is just about print styles? Possibly, the rule should be in core print styles, not only in Vector?

Change 373299 abandoned by Jdlrobson:
Set line height to 1 for sup and sub elements

Reason:
let's do in this in core print styles

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

Change 373315 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/core@master] Set line height to 1 for sup and sub elements

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

@TheDJ Thanks for the clarification, I've never heard/thought of nested <sup>/<sub> elements before, those are clearly evil 😈
As a side-note: After looking at the normalize.css code again, I remembered why the position: relative/top/bottom way was taken.
Due to inherited line-height values and in order not to let layout be dependent on goodwill of rendering engines and their ua stylesheets above solution was taken.
So either always and full layout control with negative positioning and extra CSS

sup sup {
    top: 0;
}

or so-so layout control with rendering insecurities by line-height: 1 in some browsers/DOM combinations.

Change 373315 merged by jenkins-bot:
[mediawiki/core@master] Set line height to 1 for sup and sub elements in print

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

Looks like the code achieves what the description is asking for.
resolving this. unlikely that this did not solve a problem.

cc @TheDJ