With so many devices I just check iPhones and 1366x768, the rest I don't tailor, just make sure my CSS handles all sizes well (by dragging arround the viewport in the chrome dev tolls device preview thingy)
This is pretty cool for a basic preview but it really doesn't solve the bigger issue of devices handling basic CSS inconsistently in many situations.
Example is sizing things using "vh" and "vw". On iOS this has been, and still is, completely broken. It is "supported" but if you try to size something at "100vh" it will scale multiple views without additional CSS on breakpoints or some JavaScript hacks.
For me this is just a glorified "Responsive Design Mode" which is already built into Chrome and Firefox dev tools.
iOS feels like the new IE when it comes to this stuff.
For example:
> iOS 7 Safari recalculates widths set in vh as vw, and heights set in vw as vh, when orientation changes.
If you really want iOS customers to feel at home, a lot of the time you have no option but to specifically target all their screen sizes with media queries.
I use Firefox, which also has a responsive mode, but unless I'm missing something, the built-in tools don't load multiple copies of the website in different sizes side-by-side.
I have my own version of this tool (trivial javascript + iframes), and I use it frequently for one-glance CSS changes.
It's similar to Ruby's Bundler in that it uses a lockfile with a list of exact versions of dependencies. As a result, you get a more deterministic setup. At least that's the main benefit I see here.
I wish this didn't use iframes, since so many applications set the X-Frame-Options header. That said, if I were using this against my own sites, I suppose I could just not serve that header.
Exactly - loaded it up with my site - all blank, thought about it for a second realized we disable Frame loading. That's becoming so common now, any tool using frames is really at a disadvantage.
20 comments
[ 4.5 ms ] story [ 74.3 ms ] threadExample is sizing things using "vh" and "vw". On iOS this has been, and still is, completely broken. It is "supported" but if you try to size something at "100vh" it will scale multiple views without additional CSS on breakpoints or some JavaScript hacks.
For me this is just a glorified "Responsive Design Mode" which is already built into Chrome and Firefox dev tools.
For example:
> iOS 7 Safari recalculates widths set in vh as vw, and heights set in vw as vh, when orientation changes.
If you really want iOS customers to feel at home, a lot of the time you have no option but to specifically target all their screen sizes with media queries.
2. iOS 7 was released September of 2013; that's ancient history in the iOS ecosystem
3. the installed base of iOS 10 is a smidge under 80%; iOS 7 is likely around 1%: https://developer.apple.com/support/app-store/
Yes, they've made great strides with JavaScript future support... But they still have some major issues! [0]
Let me just draw out a few from that list that are supported by Chrome, not Safari on iOS 10.3, that really should have support:
* No public key pinning
* No paged media queries
* No ChaCha20 for TLS
* No FLAC, no Ogg Vorbis support
* No png favicons, because Apple is special and needs their own format that doesn't comply with anybody else
* No download attribute.
* No resize attribute for CSS.
[0] http://caniuse.com/#compare=ios_saf+10.3,and_chr+57
But this looks like just a way to try viewing web pages on small screens.
I have my own version of this tool (trivial javascript + iframes), and I use it frequently for one-glance CSS changes.
http://www.blog.distelli.com/single-post/2016/12/14/Why-we-s...