Last modified: 2014-11-20 09:22:41 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 32101 - (hidpi) High-density display issues (tracking) xhdpi hdpi Retina high-resolution HiDPI
(hidpi)
High-density display issues (tracking) xhdpi hdpi Retina high-resolution HiDPI
Status: NEW
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
gci2014
: easy, tracking
: 35660 60236 60503 (view as bug list)
Depends on: 26211 27574 35337 35338 35342 47523 52019 53875 59699 60948 62709 63872 69944 70538 3840 31486 31837 32132 32302 32449 35163 35164 35334 35335 35336 35340 35341 35343 35344 35345 35346 36198 37849 45036 49440 55477 56969 62954 65715 67423 69705 71763
Blocks: tracking 27911
  Show dependency treegraph
 
Reported: 2011-10-31 21:55 UTC by Brion Vibber
Modified: 2014-11-20 09:22 UTC (History)
18 users (show)

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


Attachments

Description Brion Vibber 2011-10-31 21:55:05 UTC
Various relevant docs:


Android general screen resolution/density guide:
<http://developer.android.com/guide/practices/screens_support.html>

CSS 3 media queries general docs:
<http://www.w3.org/TR/css3-mediaqueries/>

Mozilla developer network CSS 3 media queries docs:
<https://developer.mozilla.org/en/CSS/Media_queries>

Blog post with some details about using -webkit-device-pixel-ratio for density (note the "resolutions" in the table are sample screen pixel widths/heights, not dpi -- the density ratios are right though :)
<http://www.fiveminutes.eu/targeting-hight-screen-densities-with-css-media-queries/>

Sizes for iOS icons at low and high densities:
<http://developer.apple.com/library/ios/#qa/qa1686/_index.html>

Mac OS X resolution-independence guidelines; '@2x' file naming style relevant for iOS too:
<http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/HiDPIOverview/Introduction/Introduction.html>
Comment 1 Brion Vibber 2011-10-31 21:58:19 UTC
Adding bugs relating to things that should be higher-res or vector in PDF and printing output as well.
Comment 2 Brion Vibber 2011-11-21 02:30:45 UTC
More reference materials...

Windows 8 slate devices have high-resolution targets at 140% and 180% of original size (meant for 1920x1080 and 2560x1440 tablets respectively, compared to a base 100% at 1366x768):
<http://msdn.microsoft.com/en-us/library/windows/apps/hh465362(v=vs.85).aspx>
Comment 3 Krinkle 2012-03-22 10:34:01 UTC
Mobile devices, in particular Android hdpi & xhdpi and the (new) iPhone/iPad Retina display.
Comment 4 Marcin Cieślak 2012-04-03 12:58:38 UTC
*** Bug 35660 has been marked as a duplicate of this bug. ***
Comment 5 Marcin Cieślak 2012-04-03 13:01:55 UTC
Regarding https://gerrit.wikimedia.org/r/#change,3687 - would that be a good solution to have a server side fallback instead of client side?

So we could provide a link to "http://static.conte.nt/image" and decide on the server side if a client has "Accept: image/svg+xml" there?

Not sure if old clients send such header, or maybe some are sending
"Accept: image/*" confusingly.
Comment 6 Brion Vibber 2012-04-03 14:54:38 UTC
one of the things we do with small icons is embed them into the stylesheetd as dsta URIs to reduce the number of files that have to be fetched; not sure if thst combines well with a server-side detection solution. not sure how consistent accept headers are though that's testable.
Comment 7 Daniel Friesen 2012-04-03 18:42:30 UTC
Accept: unfortunately won't work. I had a feeling already. I did a test awhile ago when wanting to test for jpeg2000 or apng support and had disappointing results.

I did a quick test of the latest Firefox.

And for normal pages it sends:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
While for <img> tags it sends:
Accept: image/png,image/*;q=0.8,*/*;q=0.5

There is no direct svg support indicated. So image/png will dominate svg.
Comment 8 Pau Giner 2012-04-04 07:49:18 UTC
"Icon Fonts" can be useful for certain cases: 
http://css-tricks.com/examples/IconFont/ 


This technique can be used for single-color scalable icons (e.g., fold/unfold menu icons, custom bullets in unordered lists, etc.).
It represents an alternative to SVG which is less powerful but more compatible since Webfonts can work in most browsers (desktop and mobile).
Comment 9 Daniel Friesen 2012-04-04 08:53:07 UTC
(In reply to comment #8)
> "Icon Fonts" can be useful for certain cases: 
> http://css-tricks.com/examples/IconFont/ 
> 
> 
> This technique can be used for single-color scalable icons (e.g., fold/unfold
> menu icons, custom bullets in unordered lists, etc.).
> It represents an alternative to SVG which is less powerful but more compatible
> since Webfonts can work in most browsers (desktop and mobile).

Looks like something we should open up a new bug on integration into ResourceLoader for. We could probably do something really nice making it easy for skins to enable those and switch icon fonts.

Though there are plenty of spots we're still going to need svg for. Images that aren't one colour silhouettes. And of course actual uploaded svg images.

Also that author seams to be trying to short shrug off the possibility of flaws and pretend that none exist without letting anyone else have a say or letting the reader make their own decision on what disadvantages/advantages they want:
- Icon fonts are 1-color silhouettes, so they can't be used anywhere your design calls for an actual non-simple icon. At that point you have to use .svg.
- A .svg can be used as a background image, icon fonts can't. So for all the author prances about how this works in IE6... it doesn't. Because IE doesn't support :before till IE8. You 'can' use it in a way that works in IE6, but that only works if you use the gibberish inside the page content. Which of course if you do that negates his argument that this can be done in a way that's friendly to screen readers. So your stuck with either missing browser support or killing accessibility. Not a very nice tradeoff to have to decide on when a .png + .svg bgimage setup would work for both cases.
- In fact, I'm very wary of his argument that this works for screen readers. He seems to be under the common misinterpretation that screen readers work like text browser and don't support css. Real screen readers nowadays work using real browsers (ie: They use IE, Firefox, etc...). This means that despite his argument that the gibberish is hidden in css it's possible that screen readers may still end up reading them. The argument that "Some fonts even map the characters to the best ones possible" is also flawed because a screen reader will not necessarily treat <unicode flag icon> the same as "Flag".

Browser Shots doesn't seam to want to do IE8 or IE6 right now but this is what his page looks like in IE7:
http://api.browsershots.org/png/original/9f/9faaa11fef73f703f4b2461f489475b2.png
Comment 10 Tomasz Finc 2012-04-04 18:14:42 UTC
Resource loader bug is already open @ https://bugzilla.wikimedia.org/show_bug.cgi?id=31675
Comment 11 Marcin Cieślak 2012-04-05 00:45:34 UTC
(In reply to comment #7)
> Accept: unfortunately won't work. I had a feeling already. I did a test awhile
> ago when wanting to test for jpeg2000 or apng support and had disappointing
> results.
> 
> I did a quick test of the latest Firefox.
> 
> And for normal pages it sends:
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> While for <img> tags it sends:
> Accept: image/png,image/*;q=0.8,*/*;q=0.5
> 
> There is no direct svg support indicated. So image/png will dominate svg.

Linking relevant Firefox bug (https://bugzilla.mozilla.org/show_bug.cgi?id=662169) from 2004. Excellent read on assumptions made in 2005. 

"We should look at what other browsers, especially IE, do, and try to follow the RFCs where we can do so without undermining whatever asymmetric advantages have helped Firefox actually gain market share.".

Oh boy.
Comment 12 Brion Vibber 2012-04-11 23:11:39 UTC
Moving to MediaWiki general component, as this'll affect more than just mobile view in future. Also added some keywords to the summary so I can find this tracking bug more easily. :)
Comment 13 wikimedia.x.0x 2012-05-04 07:46:51 UTC
Well, if it affects more than just mobile then how about changing the title of the bug?

Also, would a printer also be considered such a high resolution view?
Comment 14 Brion Vibber 2012-06-15 18:53:11 UTC
Adding 'HiDPI' keyword to summary on this tracking bug, dropping 'mobile' from title.

Printing is indeed a potential high-res target too, yes!
Comment 15 Daniel Friesen 2012-08-21 02:16:33 UTC
No-one has implemented it, but html5 has a new srcset attribute that allows for hidpi, mobile, etc... versions of images to be specified:
http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-srcset

There's a js shim too:
https://github.com/JimBobSquarePants/srcset-polyfill/blob/master/img.srcset.polyfill.js

We could output srcset hoping iOS, Android, and the like go ahead and implement it. And in the meantime ignore the fact that hidpi devices might download two images because of the js.
Comment 16 Pau Giner 2012-11-23 17:57:31 UTC
Recently I tried a technique for SVG with a regular image as a fallback that may be relevant for this issue.

The technique consists in specifying the SVG image using a multi-background CSS3 property. this property is ignored by browsers not supporting multi-background properties (which normally lack also SVG support). 
The technique is a simplified version of what is described at http://www.broken-links.com/2010/06/14/using-svg-in-backgrounds-with-png-fallback/

An example would be the following:

background: transparent url(images/fallback.png);	
background: none, transparent url(images/image.svg);	


(the 'none,' makes the second a multi-layered background)


This can be seen in action in an example I created: http://dl.dropbox.com/u/30377416/design/loading-indicator/loading.html
Comment 17 Pau Giner 2012-11-27 21:25:35 UTC
I polished a bit the technique using linear-gradient instead of an empty layer on a multi-layer background to better discriminate SVG-capable browsers.

More details and an example available at http://pauginer.tumblr.com/post/36614680636/invisible-gradient-technique
Comment 18 Dionysis Zindros 2013-01-27 19:37:54 UTC
The problem also exists for LaTeX renderings of mathematical expressions in Wikipedia. Not sure if this is the right place to leave that note.
Comment 19 Brion Vibber 2013-09-17 15:45:25 UTC
Removing dep on bug 17505 (high dynamic-range image format support), this is unrelated.
Comment 20 Quim Gil 2013-11-28 17:28:04 UTC
With a bit of help from your side, we can get this bug and all its dependencies fixed in a few weeks. The trick is to convert bugs into Google Code-in tasks:

https://www.mediawiki.org/wiki/Google_Code-In

How can you help?

Pick a bug and

1. Review the first comment to check whether it still described the issue to be solved. Otherwise post a comment summarizing the current situation, ina way that a newcomer can just land and fix it.

2. Add "gci2013" to the Whiteboard field of the bug. This way it comes under our radar.

3. CC Pau Giner, Brandon Harris and myself. We are GCI mentors and we will create a GCI task pointing to the bug.

Then wait. Eventually a student will claim the task and start working on it. Students might come here with questions. You can avoid questions by documenting better the bug report e.g. linking to the repository where the current logos are located and should be replaced. I guess you want Gerrit changes for these contributions?

Pau, Jorm, it would be great if you could coordinate this meta-task.
Comment 21 Krinkle 2013-12-09 21:17:25 UTC
Removing dupes from dependencies, and 'easy' keyword since it is a tracking bug.
Comment 22 Daniel Friesen 2013-12-16 04:01:54 UTC
Something relevant I ran into.

Firefox's "Implement `srcset` attribute on `img`" bug has been WONTFIXED:
https://bugzilla.mozilla.org/show_bug.cgi?id=870021

Instead it seems there is more interest in implementing an alternative src-n proposal.

"Implement `src-n` attribute on img element":
https://bugzilla.mozilla.org/show_bug.cgi?id=936481

src-n:
http://tabatkins.github.io/specs/respimg/Overview.html
Comment 23 Sage Ross 2014-01-19 20:01:09 UTC
Will adding assorted [X]DPI assets make a difference in cases where a user starts from a 100% view and then increases the zoom manually?

Why don't we aim for serving SVG logos and icons by default, and using the PNGs as a fallback?
Comment 24 Bartosz Dziewoński 2014-01-19 20:02:50 UTC
(In reply to comment #23)
> Will adding assorted [X]DPI assets make a difference in cases where a user
> starts from a 100% view and then increases the zoom manually?

Yes.

> Why don't we aim for serving SVG logos and icons by default, and using the
> PNGs as a fallback?

That is precisely what we are doing.
Comment 25 Sage Ross 2014-01-19 20:07:55 UTC
*** Bug 60236 has been marked as a duplicate of this bug. ***
Comment 26 Steven Walling 2014-01-28 00:02:29 UTC
*** Bug 60503 has been marked as a duplicate of this bug. ***

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


Navigation
Links