Skeleton 2.0 CSS Framework
61–70 of 124 posts
Re: Skeleton 2.0 CSS Framework
#62Re: Skeleton 2.0 CSS Framework
#63Hey ya'll - I'm Dave the creator of Skeleton. Grateful to see it on HN. I wrote about why I created v2.0 in a weird format here: https://medium.com/@dhg/dear-skeleton-452f4bb07d69 I'm hoping the update really helps anyone who's been using Skeleton for a while or anyone trying to get into RWD. Thanks :)
Also just an FYI noticed that your link to the noun project on the github page doesn't work properly.
Re: Skeleton 2.0 CSS Framework
#64Looks really awesome! One piece of feedback I have is that I don't think it's wise to put "maximum-scale=1" in the viewport meta-tag because it makes pages hard to read for people with less-than-perfect vision (because it prevents zooming in on phones). I created a github issue about this too: https://github.com/dhg/Skeleton/issues/173 Is there an actual benefit to having this on web pages? I see it a lot (unfortunat…
I can see your point, but want to add why I recently started to add this meta-tag on most of my responsive sites: 1. images start to look blurry 2. input fields change the scale of the page and seem to confuse some users (at least in some test-cases). On the other hand I try to improve accessability by making sites screen-reader-friendly and using high contrasts. I have also seen a lot of people using "bigger fonts"…
Re: Skeleton 2.0 CSS Framework
#65I've been waiting for this for years. Thank so much for this!
Re: Skeleton 2.0 CSS Framework
#66Thanks a lot! This seems like something I'm going to use a lot. Is it available in bower? That's how I manage all my front-end dependencies nowadays.
Re: Skeleton 2.0 CSS Framework
#67Looks really awesome! One piece of feedback I have is that I don't think it's wise to put "maximum-scale=1" in the viewport meta-tag because it makes pages hard to read for people with less-than-perfect vision (because it prevents zooming in on phones). I created a github issue about this too: https://github.com/dhg/Skeleton/issues/173 Is there an actual benefit to having this on web pages? I see it a lot (unfortunat…
Is there an actual benefit to having this on web pages? I see it a lot (unfortunately -- makes it very difficult when I'm on my iphone sometimes), and am not sure why people do this. There’s more than that specific viewport option, but often this kind of technique is an attempt to defeat mobile browsers that rescale your site when you rotate between portrait and landscape orientations. If the site is designed to adap…
A followup question: you say that "In practice, many sites don’t adapt using media queries, and so popular mobile browsers may adjust the zoom level instead." ... does this imply that the orientation change issue isn't a problem if you use media queries properly? If that's the case, then the maximum-scale=1 seems like a moot point (because if you're adding a meta viewport tag to your markup, you're already thinking about responsive design, right?). Or am I misunderstanding what you said?
Re: Skeleton 2.0 CSS Framework
#68Looks really awesome! One piece of feedback I have is that I don't think it's wise to put "maximum-scale=1" in the viewport meta-tag because it makes pages hard to read for people with less-than-perfect vision (because it prevents zooming in on phones). I created a github issue about this too: https://github.com/dhg/Skeleton/issues/173 Is there an actual benefit to having this on web pages? I see it a lot (unfortunat…
Maybe there is something similar on iphones?
It seems many people have trouble with this, and even though I have normal eyesight I can get annoyed when the site prevents me from zooming. It does make things easier when developing "native feeling UI" though.
Re: Skeleton 2.0 CSS Framework
#69Re: Skeleton 2.0 CSS Framework
#70Earlier quoted context omitted.
Is there an actual benefit to having this on web pages? I see it a lot (unfortunately -- makes it very difficult when I'm on my iphone sometimes), and am not sure why people do this. There’s more than that specific viewport option, but often this kind of technique is an attempt to defeat mobile browsers that rescale your site when you rotate between portrait and landscape orientations. If the site is designed to adap…
Ah, thanks for the explanation. I do vaguely recall hearing about this issue a while back, but never grokked the details. I find it interesting that people would prefer to disable zooming just to avoid wonkiness on orientation changes -- seems like a way less important issue. But hey, design is all about making choices, so I can understand how other people might weight those issues differently than I do. A followup q…
I wouldn’t quite say that. It’s more that whatever effort you put into using media queries to adapt your site somewhat intelligently for visitors with different devices is wasted if those devices ignore your media queries and just naïvely scale everything instead.
For example, one site I work on has a single-column layout that works reasonably well on smartphone-size devices. It also looks OK on a typical tablet in portrait orientation, but there it wastes significant screen space, because it increases the horizontal margins rather than letting text lines run very long. If that tablet is rotated to landscape orientation, we have enough space to switch into a two-column layout, which happens to fit the structure and content we’re showing. This lets us fit more of the content onto the screen than the single-column layout, because we don’t waste that extra space at the horizontal margins any more.
This is all good stuff, and from time to time we get favourable comments from visitors who were pleasantly surprised that the site adapted. However, without some of the trickery we do with viewports, what would happen instead (at least on some devices) is that rotating portrait to landscape would wind up showing a zoomed-in version of our single-column layout, while rotating landscape to portrait would zoom out to fit our two-column layout with much smaller text than intended, or some variation on those ideas depending on the specific device/OS/browser.
The catch with all of this is that for various reasons people might genuinely want to zoom in on our site. Maybe their eyesight isn’t great and they just want the text bigger for comfortable reading. Maybe they want to zoom in on some of the graphics or videos we show for similar reasons. So we don’t want to block intentional zooming by the user, just the browser’s “borrowing” of that feature to second-guess our carefully adaptive design.
Thus today we wind up employing the sort of workarounds I mentioned before. What I’d like to do, though, is just to define the sensible layouts for the site using media queries, and then have browsers automatically fit the most appropriate layout based on the orientation and user-selected zoom level on each visitor’s device.