Page MenuHomePhabricator

High-density display issues (HiDPI) (tracking)
Open, MediumPublic

Description

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


gci2014 xhdpi hdpi Retina high-resolution
See Also:
https://bugzilla.mozilla.org/show_bug.cgi?id=662169

Details

Reference
bz32101

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.
StatusAssignedTask
OpenNone
OpenNone
ResolvedNone
DuplicateNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
Resolvedm4tx
Resolvedm4tx
DuplicateNone
ResolvedPaladox
ResolvedNone
ResolvedPaladox
ResolvedPginer-WMF
Resolvedm4tx
DeclinedNone
Resolvedm4tx
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
Invalidovasileva
ResolvedNone
Resolvedbrion
Resolved rmoen
ResolvedNone
ResolvedNone
ResolvedNone
DeclinedNone
ResolvedNikerabbit
ResolvedBawolff
ResolvedNone
ResolvedNone
Openbrion
ResolvedNone
Resolvedbrion
ResolvedCkoerner
ResolvedNone
ResolvedNone
ResolvedJdforrester-WMF
ResolvedNone
ResolvedNone
OpenNone
OpenNone
ResolvedJdlrobson
OpenNone
ResolvedVolker_E
StalledVarnent
OpenNone
DuplicateNone
OpenNone
OpenNone

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:04 AM
bzimport set Reference to bz32101.
bzimport added a subscriber: Unknown Object (MLST).
brion created this task.Oct 31 2011, 9:55 PM
brion added a comment.Oct 31 2011, 9:58 PM

Adding bugs relating to things that should be higher-res or vector in PDF and printing output as well.

brion added a comment.Nov 21 2011, 2:30 AM

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

Mobile devices, in particular Android hdpi & xhdpi and the (new) iPhone/iPad Retina display.

saper added a comment.Apr 3 2012, 12:58 PM
  • Bug 35660 has been marked as a duplicate of this bug. ***
saper added a comment.Apr 3 2012, 1:01 PM

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.

brion added a comment.Apr 3 2012, 2:54 PM

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.

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.

"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).

(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

saper added a comment.Apr 5 2012, 12:45 AM

(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.

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. :)

wikimedia.x.0x wrote:

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?

brion added a comment.Jun 15 2012, 6:53 PM

Adding 'HiDPI' keyword to summary on this tracking bug, dropping 'mobile' from title.

Printing is indeed a potential high-res target too, yes!

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.

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

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

dionyziz wrote:

The problem also exists for LaTeX renderings of mathematical expressions in Wikipedia. Not sure if this is the right place to leave that note.

brion added a comment.Sep 17 2013, 3:45 PM

Removing dep on bug 17505 (high dynamic-range image format support), this is unrelated.

Qgil added a comment.Nov 28 2013, 5:28 PM

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.
  1. Add "gci2013" to the Whiteboard field of the bug. This way it comes under our radar.
  1. 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.

Removing dupes from dependencies, and 'easy' keyword since it is a tracking bug.

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

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?

(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.

  • Bug 60236 has been marked as a duplicate of this bug. ***

swalling wrote:

*** Bug 60503 has been marked as a duplicate of this bug. ***

GOIII added a subscriber: GOIII.Jul 8 2015, 11:08 PM

"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).

With the benefit of the three years or so since the above suggestion was made -- why not just add Font Awesome to the current ULS [web-]font scheme and use the glyphs in that font-family for stuff like this spinner "replacement".

Fwiw... I've added Font-Awesome support as an optional Compatibility gadget on en.wikisource; seems to work with just .css definitions (though it also could do without the auto striping of empty <i></i> tags by the wiki markup, parser or Parsoid admittedly).

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 2 2015, 11:39 PM
Jorm removed a subscriber: Jorm.Dec 26 2015, 7:20 PM
Qgil removed a subscriber: Qgil.Apr 25 2016, 7:35 AM
Krinkle renamed this task from High-density display issues (tracking) xhdpi hdpi Retina high-resolution HiDPI to High-density display issues (HiDPI).Jun 2 2016, 8:13 PM
Krinkle updated the task description. (Show Details)
Krinkle set Security to None.
Jorm removed a subscriber: Jorm.Jul 11 2016, 4:11 PM
Quiddity removed a subscriber: Quiddity.Jul 13 2016, 7:01 PM
Krinkle removed a subscriber: Krinkle.Sep 19 2017, 7:43 PM
Varnent changed the status of subtask T164786: Update mark on Wikimedia Blog from Open to Stalled.Oct 16 2017, 9:59 PM