Page MenuHomePhabricator

Sub-pixel rendering layout issues with `em` or `%` relative units (tracking)
Closed, ResolvedPublic

Description

There are several layout issues caused by rendering differences of sub-pixel values in various rendering engines.
Blurriness, width/height differences of same-height widgets side-by-side, not perfectly round circles (implemented by border-radius) are all caused by it.
The linked articles from 2009 & 2010 are not completely describing our issues, but providing some good background information on the source of the cause.

Possible solutions on trial to use:

  1. rems instead of ems together with a normalization of root font size to 10px
    • Pro: If flexibility on scaling and on being accessible is needed, (respecting user stylesheet's`font-size` settings) while ensuring design is at spec at normal zoom levels, rem with pixel fallback is the value to go. MW core is currently relying on it.
    • Con: General implementation seems problematic, because we provide OOjs UI to MediaWiki installations where we can't rely on a certain root base font size.
  2. CSS calc() as way out of sub-pixels
    • Pro: Might solve an IE specific bug introduced by miscalculation of subdecimal em values more than two digits, see T102364
    • Con: Lack of wide browser support. IE 9, Android up to 4.4.4, in short 77.24% of browser's have support currently. T123656 was addressed by using calc()
    • Con: Might run into sub-pixel values again, if not done carefully.
  3. JS when layout computation is done in rendering engine and do rounding ourselves
    • Con: Might result in negative performance impact (f.e. repaint or flicker) and in general it doesn't seem like a good idea to take over browser's duty.
  4. CSS min-width and min-height absolute values to ensure an full pixel value at 100% zoom
    • Pro: Could be applied to several widgets without major code bloat
    • Con: If used in custom MediaWiki with font-size below OOjs UI default, widgets might result larger in proportion to context. That is becoming an issue with a body font-size below 12px.
    • Note: IE has various issues with min-width/min-height in ems.
  5. Less way to let browser calculate to rounded full-pixel values by using base font-size. Approach taken in https://gerrit.wikimedia.org/r/#/c/315456/
    • Pro: Output is well rounded and design templates are easier to follow-up. It's more intuitive for developers than only relying on em
    • Con: Short outputs like 1em or 0.5em aren't used any more, although the computed value is nice, the stylesheet value isn't as appealing.

Related Objects

Event Timeline

We've started to implement min-width/min-height with pixel values as workarounds on several widgets as solution for vast majority of our users & developers.

In the short term options #4 and #5 seem to me most useful to progress, in the long term #1, switching to rem is the most forward-thinking.

Volker_E raised the priority of this task from Medium to High.Oct 24 2016, 1:35 AM

Just came across

image.png (120×310 px, 10 KB)
in GDocs, which made me smirk.

Volker_E renamed this task from Sub-pixel rendering layout issues with `em` or `%` relative units – General discussion and tracking to Sub-pixel rendering layout issues with `em` or `%` relative units (tracking).Feb 21 2019, 8:05 PM
Volker_E lowered the priority of this task from High to Low.

Reducing priority as it seems that we've got all main issues under control. Keeping task open as future tracking place.

Volker_E removed a subscriber: Nirzar.

All subtasks are closed. Resolving.