Wikimedia/UsageStatistics -> MediaWiki/Usability

Paragraph margins when printing :

Can someone explain why, the paragraph margins, when printing, must ABSOLUTELY be fixed to 1em ?
Ask your self what will happen when we have texts (notably in Wikibooks and Wikisources, for which pages have specified another margin than the default one ?

The problem is within the "/skins-1.5/common/commonPrint.css" file that contains :

p, .documentDescription {

margin: 1em 0 ! important;
line-height: 1.2em;

}

And that should really do ONLY this :

p, .documentDescription {

margin: 1em 0;
line-height: 1.2;

}

I.e. without the added "! important" that forbids all other settings within MediaWiki skins (e.g. Monobook.css, chick.css) as well as all other settings that may be needed within articles.

The "! important" is ABSOLUTELY NOT justified, because it breaks with no benefit the layout of texts that are correct when viewed on screen.

Be careful with the "! important" specifier in CSS, because it is also against all accessibility rules specified and documented by W3.org and other sites: this specifier should NEVER be used by sites themselves, it is reserved for per-user customization and adaptation.

Please review ALL the "! important" settings in CSS stylesheets.

For example, we have documents for which we absolutely don't want any margin between two paragraphs (when <p> is used explicitly in texts rather than implicitly with the default <p> that gets generated for blocks of texts separated by blank line that don't start by a special MediaWiki character like "=" for section titles, or * for lists, or ";" for defined terms, or ":" for indented blocks and definitions, or "|" for tables).

In that case, the source document simply uses <p style="margin:0"> before that paragraph : we get the expected result on screen, but this rule in commonPrint.css breaks things, and the document's settings are simply ignored when printing it. We have similar settings for poems, or verses.

We also have cases where some paragraphs are explicitly specified with larger margins (e.g. "2em" or "3em"(par exemple 2em ou 3em), and that are NOT section titles : here again the result is correct in screen, but this layout gets broken when the document is printed.

Of course we could write <p style="margin:0 ! important"> within documents, but that would be even more stupide, if this is only because of this stupid CSS rule in "commonPrint.css".

In other words, please drop the NON-IMPORTANT and stupid "!important" settings from "/skins-1.5/common/commonPrint.css".

I forgot to comment the change also from "line-height:1.2em" to
"line-height:1.2".

It is less critical because it is not flagged with "!important", so it can
effectively be overriden in other stylesheets, both when printing or viewing on
screen (Monobooks.css, chick.css, and custom per-site stylesheets, or user's
own stylesheets in their own /Monobook.css subpage of their user page space).

But anyway you should know that the difference is documented by W3.org (and
very well respected by browsers): specifiying the line-height in a block
element or inline element with an absolute unit (in, pt, cm, mm) or even with a
unit relative to the font-size (em, ex, %) has the severe defects that this
does not affect the line-height in subelements (it is NOT inherited, notably
when the font size is changed) :

so if you have indices or exponents that set their own font-size, these
font-sizes will continue to use the same computed line-height, even if they can
then be shown partially over the previous or next line (depending on their
background and clipping styles, they may be truncated, or could hide parts of
these other lines). The same is true when you'll have multiple scripts on the
same line, and that use different fonts: when changing font, the line-height
will not be adjusted correctly, if those change do not also set again their
local line-height.

The same is true when you have bigger fonts or when you use <big> or <small>:
their line-height is not adjusted as they should, because the paragraph's
line-height is NOT inherited in its given relative size but in its COMPUTED
absolute size. So the larger characters will overlay the previous or next line
in the same paragraph, or even the previous or next paragraphs...

Instead, drop the relative unit "em" and you'll get the same computed size,
except that it will be inherited as a multiplier for the font-size, even if it
is changed. I've NEVER seen any use of the unit "em" in line-height that is
effectively justified (and the other font-size relative unit "ex" is also
stupid and has no use for the line-height.)

The only case where you MAY need a unit, is when you set it using an ABSOLUTE
unit (generally in "pt", but could be also "in", "cm", "mm" or "px"), provided
that the font-size is also set using the same absolute unit (notably in "pt"),
but you should still be aware that the line-height will not be inherited in its
relative setting, but only in its computed absolute size (in "px", or "mm" or
"pt") independantly of the font-size that gets set later within the content: in
general, you would set this absolute line-height in points at the same location
where you set the font-size with an absolute unit in points.

On Wikimedia sites, for which accessibility should be a rule of thumb, an
absolute font-size setting should not be used within articles, so an absolute
line-height should not be used as well, but it MAY be set at the global page
level by the font-size for the whole content of the page (it should be set ONLY
for the <body> element or the element with id "content").

In other words, DO NOT specify any unit for the line-height for elements (like
p) that can be used at unpredicted random locations in the document. Use ONLY
"font-size:"-relative size WITHOUT any unit (it will be correctly inherited as
a multiplier of the current font-size, even if it changes later).

The !important for the margins was removed in r105116

Philippe, should we correct to no unit form for only inline elements ? or for all elements ?

Created attachment 9607
remove units from line-height

Patch that does this rather aggressively on all skins. I couldn't find any visible degradation in Safari and Firefox.

Attached:

Great, with the proportional line-height, we can now properly avoid lines to overlap in paragraphs, when it contains an inline item using <big>...</big> or CSS style "font-size:larger" or font-size higher than 100%: the baselineswill still align, but the line interval will be increased properly for the whole rendered line. This also affects positively superscripts and subscripts.

And this now renders correctly when using the text-zoom function of the browser (not the page-zoom which changes the effective rendered measures, but not the computed measured perceived in CSS and in the DOM). This change also corrects artefacts seen when users have to define a larger default font size in their current user stylesheet (in other words, Wikimedia is more accessible to visual impaired users that need selective zoom on text, without necessarily changng the size of images that may remain in their normal 100% zoom level with crisp and exact pixels, without creating fuzzy images like with the full-page zoom).

Even on very special sites like Wikibooks, it is better. Wikibooks is especially the type of site whose style requires selective zoom on texts, but not on the layout or in the renderered image.

Sorry correct Wikibooks into Wikisource (see it within the page mode).

Unit-less line-heights are creating inheritable proportional line-heights that follows the local effective font-size (which is inherited in sub elements).

This also allows zomming out for smaller displays (smartphones).

sumanah wrote:

Derk-Jan, do you have a moment to move your patch into a Git branch and submit it to Gerrit via developer access?

https://www.mediawiki.org/wiki/Developer_access

Re Comment #5: I forgot to reply to your demand. Technically yes, you could use unitless line-height in inline elements, but there will always be a problem if ever the line contains "big" elements, because it won't affect the line-height as it should (internally it just sets a bigger font size, but this does not affect the line-height, unless the outer elements was was with a proportional unit-less line-height.

The same will be true if there are "small" elements : the line-height will not be reduced as it should when the small paragraph spans several lines, so there will beextra blanks.

More generally, it is best or accessibility to allow the line-height being adjusted to fit exactly the computed maximum line-height of all elements in the same rendered line, notably because it is really difficult to predict the effective page margins and how many lines will be rendered for the same paragraph.

So unless we use fixed fonts, and we can be sure that those fonts will be available in all renderers (think not just about PCs, but as well about smartphones and about multiple OSes), and that these fonts contain all the necessary glyphs without using fallbacks (think about font versions, depending often about the OS versions),
fixing the line-height absolutely (which may look better for equalizing all line-heights in the same paragraph, when there are multiple font sizes, or there are other features such as subscripts and superscripts) will result in poor rendering or problems to get something that is readable.
I see absolutely no use case, on the web, for using line-heights with a unit, unless you really want an absolutely fixed layout.

For Wikimedia sites, as well as most wikis, the default style should then never use any unit when setting the line-height in the stylesheet. So unitless line-height should be used everywhere (both at the inline elements or at block elements). This is even more critical for non-Latin scripts, where there's a very wide variation between fonts usable across devices and OSes, and in every multilingual sites (where multiple scripts are used), including the English Wikipedia (that frequently cites texts in various non-Latin scripts.

Now uploaded https://gerrit.wikimedia.org/r/27043

Looks good.

Note that this ialso fixes other useful cases (not just superscripts and subscripts) :

• the case where the inner subelements implicitly need to set their own line-height, notably in multilingual texts where inner subelements may be written in another script requiring a bigger line-height as they implicitly use another font which has larger line height requirements (example: citations in Chinese, or Tibetan, within an English paragraph). This was needed for better supporting the internationalisation.

• the case where the inner subelements explicitly set a bigger font size (for example with the "big" HTML element. This generally should not occur in Wikipedia articles but it will occur within texts found in Wikisource.

Thanks for fixing it, because it avoids many undesired overlaps between lines of text (including if the content is JUST a text element, where that text element uses multiple scripts requiring multiple fonts, or a font that does not even match those specified by default or explicitly in the container).

It also avoids overlaps above or below the block element containing the paragraph : the block will be automatially adjusted if needed, by taking first within their top or bottom margin, or expanding them as needed.

Using unitless line-heights allows the line-height to be inherited so that lines will be contextually higher where needed (even if this makes the while paragraph having non evenly spaced lines).

Forcing evenly spaced lines (with a unit in the line-height) is only required in very specific contexts, where the Wikicode (or HTML markup) will explicitly set a fixed line-height using an explicit line-height with a unit for this case (this is not needed for articles, just for forms where you want to align text lines horizontally between separate columns. This is enough rare that such occurences will be explicitly CSS-styled at the begining of the paragraph or in a container <div> or <table> (or a wiki table), but I've not been able to find any article requiring this hack for forcing evenly spaced lines.

I note that there is currently line-height:1em on sup and sub elements in the English Wikipedia. Specifically to avoid uneven line height within a paragraph due to references and other sup sub elements. People found the text more difficult to read if there were unexpected 'gaps' all over the place. So there is some credit to them, though i concur that overly setting explicit line-heights is probably a bad idea.

Are you sure that superscripts and subscripts will use the same font as the rest of the text ? My opinion is that this explicit setting of line-height with a unit should be reserved only to superscripts generated for example by note calls and references, or abreviation marks like "st", "nd", "rd", for which the content of the superscript is predicatble (eventually generated by a template), but not for all general superscripts for which you don't know what is written inside (and notably is it contains text in another script or language).

Given that the default line-height now is 1.2 (instead of 1.4 before), the superscript may easily overlap the line above. There are also accessibility considerations, because some users will want to avoid all reduction of font sizes for superscripts or subscripts, to keep the text readable, even if this cause the line-gap to be unevenly distributed.

Also some browsers won't be able to reduce the font size for superscripts or subscripts below some level (for example on some low resolution screens, or on small displays like smartphones, where fonts are already small by default and there's a minimum font size defined in the browser's user preferences in order to allow text selection and better readability), and will need that the line-height becomes adaptative, without overlaps caused by an insufficient fixed line-height.

Note also that I hope that some day browsers will have a new accessibility option for allowing users to specify a minimum line-height for everything: a line-height of 1.2 is difficult to follow for many people that have vision or brain problems, they prefer texts with line height a minimum of 1.4 or 1.5, even if it takes more space on screen.

If the browser proposes this accessibility option (in addition to the minimum font sizes), then the evenly distributed line-height in paragraphs will not be sustainable without creating overlaps problems.

For the same reason, line-widths may be setup by users to not exceed some ems, because people have difficulties to follow very long lines and return to the next line (notably if the line-height is very narrow). With an accessibility option, the browsers may propose them to restrict paragraphs widths to no more than 40em or 60em (even if this creates large blank margins in the layout), even if the default is to allow arbitrary long lines in browsers.

This is a good reason why most newspapers and books prefer to use blocks rendered in multiple columns (to save paper space), as they are easier to read, especially at small font sizes (e.g. in phone diaries and dictionaries, or classified ads).

I'd like to give 3 practicle examples about these accessibility needs (for large enough line-heights, and restricted line-widths) :

1. In churches, many people complained that they could not read the Bible or the priest books during masses. So the priest preprinted the Bible extract that was read during the ceremony, just using larger fonts (e.g. 12 pica), but also doubled line-heights and no more than 60 ems per line. Aged peoples appreciate this due to their vision problems (including people that suffer from restrictions of their angle of vision).

2. In schools, young children need texts not exceeding about 40 ems of width per line. Otherwise they won't read it, and with a minimum line-height of about 1.5, sometimes 2.0. This is a problem of training of their vision when they learn to read, as they need to point the text to read with their finger.

3. When studying texts, it is also common to reprint an article with a doubled line-height, to allow manual handwritten annotations or corrections between lines of text. Or they want lines not exceeding more than a dozen of words, for allowing readable added annotations in the side margins. Very useful for text reviewers and correctors.

These problems are not solved in browsers just by zooming in or redefining the size of the "logical point" in their display settings.

Such adjustments wanted by users will be useful, and fixing line-heights to absolute values relative to the initial font size will not match these understandable desires.

I can see your point, but targeting 'just the exceptions' with CSS is rather difficult and the complaints by the 99% carry quite a bit of weight (unfortunately for those in the 1%). Also, this is a decision by the en.wp community, not mediawiki developers, so I suggest you have that discussion there :D

https://gerrit.wikimedia.org/r/27043 (Gerrit Change I0d3d7d076ba37807cdc33fa470e1bde320d224d6) | change ABANDONED [by TheDJ]

In your last edit, you write :

I have tested this on Safari and Firefox and have not observed problematic changes in layouting.

Really you should look at what happens with accessibility options enabled in the browser (for larger fonts). The effect is visible when line-height uses units (e.g. em) when unit-less line-heights is much better for allowing inheritance in sub-elements (and notably subscripts and superscripts, or <big> elements, if they specify only a new font-size, but no line-height).

line-height should almost never be used on inline elements, only on block elements, but even then, these elements may collide with elements above, if ever the inline subelements use a large font-size.

This problem is well explained in the W3C site, that explains why unitl-less values for line-height were introduced. Values of line-height with unitsfor styling elements should be used only on block elements, and only if the layout is fixed and you can reliably predict where all line-breaks will occur in the content (this also require predicting which fonts will be used to render the content, something you can't predict on Wikimedia sites, unless you convert pages to prerendered PDF and publish these PDF and not HTML pages) (but then these wikis won't be usable on smartphones, or in browsers with small displays).

Apparently you have abandonned it because of the code review comment sent which says:

Patch Set 1: There's a problem with this change, please improve
Unit-less line-height is good. However removing them from existing styles as-is is likely to cause layout problems. In this change I only see straight removals, which I suspect has unintended visible influence.
Previously they were accumulative (an em line-height on p, affected by em line-height of #content, affected by em line-height of html/body.
Preliminary -1 for caution and suspicion. Will check out soon (or someone else feel free to ignore this vote if you're certain).

But this comment is incorrect. ine-heights are not comulative when a unit-lesss line-height is specified in p, #content, html, body: the inheritance stops there on each new subelement : in addition, theses are ALL block elements, only the innermost block element will specify the line-height for its inline subelements.

So a paragraph can be styled with "line-height:1.5" and this will work when inner spans secify a bigger font. And you ''may' use units, only in "em" or "ex", for sub and sup elements if you want to preserve even lines in the paragraph (line-height:1em works for sub/sub, except when these subelements also contain big/small subelements on subscripts/superscripts with long, breakable contents spanning several lines (such as calls to footnotes using several words lie "Note 1" instead of "[1]", using <ref group="Note">...</ref>).

But even in the case of superscripts/subscripts, you should also use unitless values for them, it you want even lines for the whole paragraph containing syperscripts/subscripts.

Note that changng the line-height on superscripts/subscripts does not work very well with some languages/scripts, such as Khmer or Tibetan.

No, it was not because of that comment.

I have abandoned it, because I didn't know enough about the change to push it trough the review system. This sometimes isn't a problem if the reviewers know enough about it, that they do not require convincing, but that was not the case here.

Someone who fully understands the consequences of this change needs to push it trough the system and be available to answer questions. Otherwise, it's simply not feasible.