There are a few 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:
- {T102127}
- {T123656}
- {T114052}
ToggleSwitchWidget is not the only affected widget. 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:
* **Using `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.
* **Using CSS `calc()` as way out of sub-pixels**
** **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.
* **Using 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.
* **Using 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`.