Skeleton 2.0 CSS Framework
51–60 of 124 posts
Re: Skeleton 2.0 CSS Framework
#52This looks great. I love the simplicity of it and how classnames are handled and just the overall lightweight feeling. Sidetone: I had to go to the github page to see browser support, maybe you can add it to the website. Thanks
Re: Skeleton 2.0 CSS Framework
#53"Skeleton: A Dead Simple..." - I see what you did there :)
Re: Skeleton 2.0 CSS Framework
#54Hey man, super cool to see you come back to the project after so long. Skeleton was the only understandable framework that was on the go when I started developing, and it really helped me get to grips with RWD. Every time I'd start new projects I'd come back to Skeleton for reference and now have my own extended version thats always being refined, ExoSkeleton ;) Thanks a mil the work you put in man, Cheers!
Also rad that you extended it. That's what it's about - making it your own :)
Re: Skeleton 2.0 CSS Framework
#55Earlier quoted context omitted.
I read a lot on my phone and I don't have great eyesight. If I cannot zoom the website I'm looking at, I often cannot read it.
I honestly hadn't considered this case. Let me dig into it and see if I can find a solution that works best all around.
Re: Skeleton 2.0 CSS Framework
#56Would love to see a compare/contrast.
Re: Skeleton 2.0 CSS Framework
#57Why have a max width of 960px? "The grid is a 12-column fluid grid with a max width of 960px"
960px was the "standard" for so much time (before RWD was a thing) that I still use it as the default width when designing new stuff. Maybe this is a bow to the old masters of our craft.
Re: Skeleton 2.0 CSS Framework
#58Looks 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…
It removes the 300ms delay while the browser waits for a double-tap (to make sure you really meant to click on that link and not zoom in), which is supposed to be a huge UX improvement.
If that's the case, it seems like throwing out the baby with the bathwater, since it does have the accessibility issue and removing the delay can be better-achieved on ALL devices with some of the JS libraries that others have linked to.
Here's a blog post I found that talks about the limitations of this "avoid touch delay by disabling zoom" technique: http://timkadlec.com/2013/11/Avoiding-the-300ms-click-delay-...
Re: Skeleton 2.0 CSS Framework
#59Looks 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…
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 adapt gracefully to different screens using media queries, then what you probably want instead is for the browser to just reflow the layout according to the new page width.
In practice, many sites don’t adapt using media queries, and so popular mobile browsers may adjust the zoom level instead. That means whatever you could see horizontally before the orientation change is still what you can see afterwards but bigger/smaller.
One way to force the adaptive behaviour is to use the viewport settings so the zooming isn’t allowed. However, that also interferes with deliberate zooming by the user. Sometimes you see all kinds of complicated workarounds for that, such as detecting an orientation change and temporarily blocking zooming, or detecting an attempt to zoom and then disabling the restriction temporarily so if the user repeatedly tries to pinch-zoom then subsequent ones work. Sadly, a lot of developers just copy-paste the viewport hack without realising the full implications, and that is when we see problems for users who really do want to zoom in.
None of this is ideal, but as far as I know we still don’t have a reliable, standardised way for sites to specify how orientation change should be treated for best results, so for now viewport hackery seems to be the best known workaround.
Re: Skeleton 2.0 CSS Framework
#60Looks 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…
Thanks for opening the issue. Gonna dive into those very soon. appreciate you taking the time to add it to the list :)