Foundation-sites: retina named query

[nlap]

Any thoughts on changing the pixel ratio for the retina named query?

I'm running a 4K display on Windows at 175% scaling. I think it's pretty common to run HiDPI at 150-175% scaling. Would be nice to have Interchange use high res images at those scales too, out of the box. Currently the retina named query is 200%+ scaling:

only screen and (-webkit-min-device-pixel-ratio: 2), only screen and (min--moz-device-pixel-ratio: 2), only screen and (-o-min-device-pixel-ratio: 2/1), only screen and (min-device-pixel-ratio: 2), only screen and (min-resolution: 192dpi), only screen and (min-resolution: 2dppx)

I see a 1.3 pixel ratio used a lot

[ncoden]

Hi @nlap,

I agree with you this would be useful. However, websites are probably adjusting the picture they provide to the x2 pixel ratio, and it would be hard for them to migrate. So I think we should extend the breakpoint mixin to support any ratio, and maybe provide several breakpoint names (retina-1-5, retina-2 alias retina, and retina-3).

@zurb/yetinauts I would appreciate your opinion the following points:

I searched for a non-Apple name to easily describe these screens. I found hidpi. Maybe we should switch to it (hidpi-1-5, hidpi-2 alias retina, hidpi-3)

Also, I found a lot of apprehensions about the size of "retina" pictures for low or limited 3G connection. Does Foundation have a check of speed to prevent loading "retina" pictures when it is too slow ?

[nlap]

Good points. I agree that changing retina itself could have unintended consequences. I like the idea of adding new breakpoints names, and changing the interchange docs so people start to use them. Changing to vendor-neutral hidpi is probably a good call too.

Re. connection speed: Not much I think we can do here. Mozilla has a limited API for connection speed detection, but it's not in any other browsers AFAIK. Best bet to support your low bandwidth users is to make sure your site works in reader modes, opera mini, etc. - or make an AMP page.

[ncoden]

There is tools to detect slow connection speed in JS (see http://stackoverflow.com/a/9011781/4317384). Meanwhile I checked the code and didn't found something like this in Foundation or Interchange. I think this would be a great feature.

@kball What do you think ?

[kball]

Hmm.. that is an interesting idea... essentially the equivalent of a media query but for connection speed... there are definitely some non-obvious decisions to be made (do we test full page load time (which will vary widely by page, site, hosting environment, etc), or provide a way to add a 'known image' load time (which would require adding a new asset)... or do we have a "known quantity" public resource that will give perhaps more fidelity of general connection speed (e.g. 3g or whatever) but may not account for e.g. this site is hosted across the world from me and is slow for me in particular.

The other complicating factor would be that if we incorporated this into e.g. interchange we'd now have to manage a matrix rather than a single dimension (ie connection speed AND screen size).

That said, I can definitely see the potential value of having something packaged up here. @zurb/yetinauts what do you think? Would you use a 'connection speed' detector in Foundation? What would your usecases be?

[ncoden]

KISS.

All we want to do is to prevent loading retina images on slow connections, because in that _specific case_ the better of the image does not worth the additional waiting time required to load it, no needs for a matrix. So at first, we can simply measure the Foundation js file load time.

Later, we could improve the "connection speed" utility: add helper classes, like show- and hide- like breakpoints, or allow to provide custom measuring functions (to measure the whole page or something else).

[kball]

How would we measure the JS file load time? We don't have anything to start the timer until the file has started to load, at which point we'd already have missed a bunch of time

[ncoden]

We don't want to measure the _load time_ precisely, but the _load speed_ to recognize _very slow connections_.

[nlap]

I think the connection speed discussion is important for interchange, but it definitely seems more complicated than the pixel ratio change. Not sure it necessarily needs to block the latter?

I like your suggestion @ncoden, for better named queries that don't break current behaviour.

What's the next step on that? I'm new - I don't want to be presumptuous :) Do we need to discuss the pixel ratio further? Should the connection speed be a new issue, or keep it here as part of bigger interchange changes?

I'd be happy to take on a PR if we go with just the smaller change pixel ratio change first.

[ncoden]

@nlap You can open a PR to provide the small Sass changes. I can open a new issue to talk about an additional "connection speed" feature.

[colin-marshall]

@ncoden I like the idea of renaming the queries to something more universal than "retina." Could we use "3k", "4k", "5k?" Or would that not work since that seems to only apply to larger screens and would exclude mobile devices?

I also like the concept of the bandwidth test if we could get it working without being so complex that it adds to the load time. That would be a great thing to implement.

[nlap]

retina is the Apple marketing name. They also termed HiDPI, but it's pretty widely used outside of Apple. Microsoft tends to use High DPI.

I think hidpi with the scaling multiplier is a good bet. Tells the developer how much to scale their images, and it matches the underlying media query. "4k" etc. screens could still be running at native resolution without any scaling.

hidpi-1-5, highdpi-2 (alias of current retina, and just hidpi), hidpi-3

[ncoden]

I do not think hidpi alone makes sense. And it would lead to issues like this one with folks wanting to change the hidpi default resolution.

[ncoden]

@nlap Fixed in #9661. Is it what you expected ?

[nlap]

Yes, awesome thanks! I hadn't had a chance to take it on yet. Should interchange docs be updated at the same time?

[ncoden]

Ideally yes. I forgot about this part of the documentation, thank you.

Edit: for now, HiDPI breakpoints are only available in Sass. More work would be required to make them working in Interchange. @nlap Is it what you expected ?

[DanielRuf]

Hi @nlap,

@nlap Is it what you expected

can you give feedback and also on the PR?

[nlap]

Oh sure, this has just been off my radar for a while. I posted in the PR.