Last modified: 2014-09-10 05:18:31 UTC
Some icons in the compact personal bar need to flipped for RTL UI: * notifications * notificationsHover * talk * talkHover
These should be flipped in software not as seperate RTL assets.
(In reply to Jared Zimmerman (WMF) from comment #1) > These should be flipped in software not as seperate RTL assets. Does MediaWiki already have such a capability? Or is it something that we need to develop? Auto-flipping is generally a good idea, as long as it is not forced on all images. Until now we usually created separate LTR/RTL image pairs here it was needed. For the new Wikipedia Android app Yuvi made it flip automatically except where the image file name includes "noflip". IIUC, this is an Android capability. I am not aware of anything like that in MediaWiki.
The next update will replace the svg icons with wikifont characters. We'll need to use something like backward { display: inline-block; -moz-transform: scale(-1, 1); -webkit-transform: scale(-1, 1); transform: scale(-1, 1); } To reflect the individual icon characters for 90% of the icons and have alternate RTL versions of a few that use elements that can't be flipped like the echo mention which uses an @ symbol inside the symbol.
(In reply to Jared Zimmerman (WMF) from comment #3) > The next update will replace the svg icons with wikifont characters. I wonder why? SVG icons are a lot easier to work with and edit, and it's easy to provide a raster fallback for older browsers for them.
From talking to Shahyar it sounded like the webfonts was more performant and offered greater browser compatibility I'll add him to this bug in case he has anything to add.
We need IE support and consistent cross-browser scaling. Using web fonts gives us that. We also get to apply CSS color to web fonts.
(In reply to Shahyar Ghobadpour from comment #6) > We need IE support and consistent cross-browser scaling. Using web fonts > gives us that. We also get to apply CSS color to web fonts. Can they flip by themselves? Or will RTL glyphs have to be created? Will this be supported by CSSJanus? If not, will other LESS trickery be used to automatically apply LTR/RTL transformations?
SVG images are supported by IE 9 and newer; with the technique used in MediaWiki, IE 8 and older receive raster PNG images instead. I find it hard to imagine that anyone would be using these browsers on a computer with a hidpi screen anyway. Font icons have the obvious drawback of requiring you to use non-semantic text in page content (which might confuse screen readers and is problematic when coupled with the way we do CSS caching) or ::before / ::after selectors in CSS which are not supported by old IE (which you say you want to support). In addition, cross-browser support requires generating like four files in different formats (if I remember correctly). Keeping them all synchronised, or even just editing them at all, is a major pain especially in an open environment like ours. Font icons do have the advantage of making it possible to use different colors for one icon asset, but… are you seriously going to use one icon in different colors in your design? I don't see how they would be noticeably more or less performant than alternative techniques – can you elaborate? MediaWiki's ResourceLoader includes facilities for automatic embedding of images inside the CSS styles, reducing the number of HTTP requests, which is usually the only argument against using separate source files for separate icons.
1. Sorry, I didn't mean to imply an issue with DPI. What happens is the images are displayed as full-size backgrounds, since these browsers don't support background-scaling. For it to work, you would have to use <img> tags, not CSS images, which is neither semantic nor uniform across platforms. 2a. They don't confuse screen readers because they don't actually contain any text. 2b. The :before/:after selectors for glyphs work well because IE 6 & 7 simply won't render them, as opposed to rendering incorrectly-sized images or having to download multiple <img> sources. This is an acceptable graceful degradation. However, we could easily support them with MS proprietary CSS expressions. 2c. These fonts are generated. I don't see how this is a problem, given that we generate PNGs from SVGs anyways. 3. Yes. Disabled state, color change on hover/focus, inverting color on light vs. dark backgrounds, etc. 4. Separate files are still used because data URIs are not supported by IE 6 and 7. In addition, these massive blobs of text don't compress very well in CSS, and bloat the request size. A font would be downloaded once and cached, whereas any small change to CSS would necessitate redownloading of all the images as data URIs. In addition, rendering images is more CPU and memory intensive than rendering text.
I am still very, very uneasy about this, but I have to admit you have a point. I'm not convinced that the benefits outweigh the drawbacks, but I don't really see anything that would make it reasonable to block this. If no one has better points, then I guess we'll just have to try and see. (In reply to Shahyar Ghobadpour from comment #9) > 4. Separate files are still used because data URIs are not supported by IE 6 > and 7. These files are not loaded by modern browsers, and including these links costs us next to nothing. > In addition, these massive blobs of text don't compress very well in > CSS, and bloat the request size. Most of the icons are smaller than a kilobyte in size, and I'm pretty sure gzip does a good job on them. It could do an ever better one if we didn't base64-encode them if not necessary, I think Matt was working on that recently.
(In reply to Bartosz Dziewoński from comment #8) > SVG images are supported by IE 9 and newer; with the technique used in > MediaWiki, IE 8 and older receive raster PNG images instead. I find it hard > to imagine that anyone would be using these browsers on a computer with a > hidpi screen anyway. Minor correction: Although IE9 does support SVG backgrounds in CSS, background-image-svg does not support it due to how it's implemented. See http://pauginer.tumblr.com/post/36614680636/invisible-gradient-technique ("The price to pay is that some browser versions (such as IE9 or Firefox 3.5) that are also capable of rendering SVG but do not support gradients will display the fallback version.")
