Last modified: 2014-09-10 05:18:31 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 64789 - CPB: Compact personal bar should have RTL version of icons
CPB: Compact personal bar should have RTL version of icons
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
VectorBeta (Other open bugs)
unspecified
All All
: Unprioritized normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: rtl CPB
  Show dependency treegraph
 
Reported: 2014-05-03 10:09 UTC by Amir E. Aharoni
Modified: 2014-09-10 05:18 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Amir E. Aharoni 2014-05-03 10:09:22 UTC
Some icons in the compact personal bar need to flipped for RTL UI:

* notifications
* notificationsHover
* talk
* talkHover
Comment 1 Jared Zimmerman (WMF) 2014-05-03 23:38:54 UTC
These should be flipped in software not as seperate RTL assets.
Comment 2 Amir E. Aharoni 2014-05-03 23:45:02 UTC
(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.
Comment 3 Jared Zimmerman (WMF) 2014-05-03 23:53:05 UTC
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.
Comment 4 Bartosz Dziewoński 2014-05-13 09:31:31 UTC
(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.
Comment 5 Jared Zimmerman (WMF) 2014-05-13 17:47:01 UTC
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.
Comment 6 Shahyar Ghobadpour 2014-05-13 17:56:40 UTC
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.
Comment 7 Amir E. Aharoni 2014-05-13 20:35:10 UTC
(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?
Comment 8 Bartosz Dziewoński 2014-05-13 20:52:36 UTC
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.
Comment 9 Shahyar Ghobadpour 2014-05-13 21:11:45 UTC
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.
Comment 10 Bartosz Dziewoński 2014-07-16 23:46:10 UTC
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.
Comment 11 Matthew Flaschen 2014-08-25 22:02:57 UTC
(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.")

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links