Page MenuHomePhabricator

High-density display issues (HiDPI) (tracking)
Closed, InvalidPublic

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

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

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

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.

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

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.

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

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

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.

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

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

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

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.

Is this tracking task still useful?

Is this tracking task still useful?

No reply, assuming that means we can invalidate this ancient ticket (see also https://www.mediawiki.org/wiki/Phabricator/Help#.22Tracking.22_tasks ).

See subtasks for work. Suggest creating a Goal task if we want to address multiple tickets in one go.

Bugreporter removed subtasks: T161346: MMV lacks support for HiDPI displays, T168087: W Favicon is not HiDPI compatible, T164786: Update mark on Wikimedia Blog, T147219: Wikipedia logo in Notification popup is not high-density ready, T128681: Integrate support in the mediawiki core for favicons across platforms, T133496: Blurry SVG renderings on mobile , T133489: SVG rendered with 'frame' option do not have the 'srcset' attribute with 1.5x an 2x images for high DPI screens, T86225: Graphics on the login and create account forms are not SVG, T73763: Commons, wiktionary, wikidata logos are no longer using svg/retina quality image, T71944: Table pager navigation arrows (used on e.g. [[Special:AllMessages]]) missing SVG versions, T71705: "Enlarge" icon (magnify-clip.png) missing a SVG version, T69423: MobileFrontend: Blue "issues" icon should have HiDPI version (or SVG), T67715: "a wikimedia project" and "powered by mediawiki" badges are not retina quality (make them SVGs?), T72538: Redirect arrows missing SVG versions, T65872: Wikimedia and MediaWiki footer buttons should be SVG or HiDPI, T58969: File page should use HiDPI src-set for nominal-size rendering, T61699: Better spinner icon for jquery.spinner.js, T64954: Retina image assets for list items, T51440: MobileFrontend images shown double-sized in Retina desktop, iOS 7 beta, T64709: Images in galleries should have srcset (category pages, <gallery/> tag), T62948: Several resource images missing svg version, T49523: Add 'Retina' hi-dpi display support to Extension:Score, T57477: MultimediaViewer should support hi-DPI ('Retina') displays, T55875: Notification icons are not ready for high-density displays (use SVG instead of PNG where supported), T54019: Vectorize all project logos, T47036: Update favicons to provide high res variant, T39849: VisualEditor: All icons need hi-resolution version (HiDPI, Retina display), T38198: Article images are blurry on retina display (Responsive images), T34449: Android app menu icons are SUPER HUGE on mdpi devices (G1, Kindle Fire), T29574: PDF export: Use LaTeX formulas instead of inline images, T34302: MobileFrontend fullscreen search list item borders round poorly on 240dpi Android devices, T34132: swtch Geolocation button in iphone app to high-res image, T33837: Android app draws UI elements too small on Android 4.0 Ice Cream Sandwich hdpi/240dpi display, T37345: RSS/Atom feed icon for sidebar is low-resolution, T37346: ArticleFeedback icons are low-resolution, T37343: External link icons should support HiDPI, T37344: Enhanced Recent Changes collapse/show arrows are low-resolution, T37341: Vector user icon in personal portlet should be hidpi, T37342: WikiEditor: Add SVG versions of editing toolbar icons, T37337: Ensure all site logos support HiDPI screens to avoid pixelated/blurry look, T37340: Vector: Add SVG version of collapsible sidebar arrow icon, T37338: Vector: List bullet icon should not be low-res (pixelated on HiDPI screens), T37335: Vector: Add SVG version of the watch star icon, T37336: Vector: Add SVG version of magnifying-glass icon, T37334: WikiLove: Add HiDPI version or SVG of "heart" icon, T37164: "Back" button is not high-resolution; shows blocky on retina display, T37163: Need application icon for Retina iPad (144x144px), T33486: Android app's 'W' and search icons get upscaled on hdpi devices, T28211: Add support for multiple resolutions to $wgAppleTouchIcon (iPhone classic, iPad, iPhone 4), T5840: High resolution equations for printing, Retina displays (hi-dpi).Aug 20 2021, 7:17 PM