There are several layout issues caused by [[ http://ejohn.org/blog/sub-pixel-problems-in-css/ | rendering ]] [[ http://meyerweb.com/eric/thoughts/2010/02/10/rounding-off/ | 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:
# **`rem`s instead of `em`s 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 [[ https://git.wikimedia.org/blob/mediawiki%2Fcore/HEAD/resources%2Fsrc%2Foojs-ui-local.css | 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.
# **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 [[ http://caniuse.com/#feat=calc | 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.
# **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.
# **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`.
# **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.