Thank you so much for the hard work. I've been using Skeleton for a personal project even though it hadn't been updated in over 2 years. As a (mostly) backend developer, Skeleton has proven to be the best possible starting point for me to learn on; there's nothing tricky about it.
Just wanted to say thanks for making this. Skeleton introduced me to the basics of responsive design and my company now uses it in several applications.
When I came back to web design after seven years' absence, Skeleton was the first framework I used. I was blown away by frameworks and responsive design -- these weren't really things in 2004 -- and I loved the lightweight, clean structure. (I have to admit I also really liked the serif font you initially used. Serifs, so underappreciated...) Thanks!
Hi Dave, great work on Skeleton. Was the original project a side-project or was it in use for projects at Twitter and / or Medium? Wondering about how it seems to be a sort of antithesis to Bootstrap (as in no preprocessor / small footprint / sane defaults).
Haha, just a side project. Weirdly bootstrap, foundation and skeleton all have similar roots together, but a story for another day. I made it cause it was what I wanted to start projects and seemed like there might be others :)
Oh and as for Twitter and Medium - nope! Just for personal stuff on the side, though it definitely worked its way into small parts of those properties.
Hi Dave, I love Skeleton, have been using it exclusively as a base for my web projects over the past 2 years and have it on around 20 client sites. Look forward to taking Skeleton 2.0 for a spin next week!
Dave, I'm still in love with Skeleton, and 2.0 looks very nice. And it's great timing as I'm including it in the update to our web development recipes book.
Thanks for the 2.0 update Dave! I having been using Skeleton as a starting point for side-projects for a couple of years now. I really like how light it is compared to Bootstrap.
Thanks for continuing development on Skeleton! My current blog design is largely based on Skeleton 1.x, but it looks like I'll be updating it this week.
Rad man - So, it should ALMOST be a straight drag and drop replacement of the normalize/skeleton.css for the old grid/layout/reset.css, but if you were doing nested columns that's gonna get you. Please let know how it goes – hi@getskeleton.com
Skeleton is the only "sane" CSS boilerplate framework I've encountered. It's incredibly minimal -- the entire framework is so small and elegant that I can crank out websites without delving into the subtleties of the documentation. I find it really intuitive to use, and while I don't do a lot of web dev, when I do it's almost always with Skeleton.
Anyways, I'm so glad you're working on Skeleton again! Congrats on the 2.0 release, and thanks for all of the hard work!
I'd rather keep my styling in my stylesheet. Using mixins rather than styling classes allows a developer to look in a single place - the SCSS - to determine how something looks.
* Fluid (by default, but you can set a fixed width or max-width if you want)
* Responsive
* Unlimited number of breakpoints (you can define your own Media Queries)
* Mobile-first compatible (block width is 100% by default)
* Content-first compatible (you can swap columns and you can define your own breakpoints for each content in your page to fine-tune and optimize your content readability: not only 'tablet' or 'smartphone' breakpoints)
* Semantic (as much as a pure CSS grid could be ;) )
* Very simple (just have to define blocks and groups of blocks)
* Unlimited number of columns (no 12 or 16 columns restrictions: blocks just require a width in percentage)
* Unlimited nested grids
* Manage consistent gutters (gutters can be defined in pixels or ems, which is better than percentage-based solutions because it allows consistent gutters even in nested grids)
* Automatic rows (when a row is full, the next blocks go to a new row without doing anything)
* No dependencies
* Compatible with CSS frameworks such as Twitter Bootstrap or Zurb Foundation (you can use the Bootstrap or Foundation components such as buttons, tabs, etc. and use the Pocket grid for other layout)
* Compatibility: IE6+, Firefox, Chrome, Safari, Opera, and mobile browsers (iPhone, iPad, Android...)
Aside from what has already been said (SemUI is a MASSIVE piece of CSS), Semantic UI is also not semantic.
<article> is semantic
<div class="article full width"> is not semantic, it's describing how it should appear.
You can break half of the examples page by just clicking everywhere and typing and such. I currently have three buttons stuck in the middle of their two positions, textboxes being broken, etc. It needs work.
Also it's rarely a good thing if your goddamn landing page makes an i3 stutter when rendering it. Doesn't really scream lightweight or efficient (although the biggest culprit is that background header video)
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 (unfortunately -- makes it very difficult when I'm on my iphone sometimes), and am not sure why people do this. Is it just "common wisdom" that has been copy-and-pasted down through the ages without anyone questioning it, or does it provide some benefit that outweighs the (pretty big) drawback of reduced accessibility?
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 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.
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 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?
... does this imply that the orientation change issue isn't a problem if you use media queries properly?
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.
For people using Chrome on Android phones you can force enable zoom by going into settings -> accessibility -> force enable zoom.
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.
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.
Fascinating... I never heard about this side-effect of disabling zoom! I did some googling and from what I can tell, this only applies to some Android browsers, not iOS?
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.
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" options in their browsers or on their phones, which solves this problem from my point of view.
I created an account just so I could say that as a legally blind person, I cannot use some websites without being able to zoom in. It is extremely frustrating when I encounter a site that has disabled zoom. Please don't do it!
>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.
Chris_Newton's comment seems to have possible workarounds that can fix this issue. I'll trust your decision whatever you go with though, and thanks for Skeleton!
An option to increase text size in the interface is probably going to be even better than allowing zoom, since it will reflow the text and not require the user to scan left and right around the zoomed-in text.
Of course, this is how our browsers used to work before the makers decided to remove or hide that feature. I've never seen it on a mobile device. Does anyone understand the reasons behind that move? Even if you think page zoom is 'better' than text scale, surely it doesn't make sense to disable the latter altogether?
I've struggled with these issues before, and have tried then backed away from the same maximum-size solution.
Fortunately, #2 can be resolved easily by setting input,textarea{font-size:16px}. There are problems with 16px for all inputs (especially if using a custom font with different metrics than the default), but it preserves a significant usability feature. A fair trade, even if it means using system default inside of inputs.
Regarding blurry images, I favor suboptimal delivery of content over failure to deliver every time.
Thank you for considering this. Skeleton is a great framework and I know a lot of people use it as a boilerplate. Regardless of your ultimate decision, I really do appreciate you looking into it.
Nice, looking forward to using this. I'm a CSS/JS framework creator myself (Ionic), but often when working on simple websites with a designer I just need a nice grid and some clean defaults. Congrats on 2.0!
This is a really solid framework. A couple of humble suggestions:
1. Package up your site itself on github as one of the examples. Mixing up some elements of your base site with some of the landing bits would make for a solid base for a lot of people.
2. Get a compatibility table together stat. To help you out, I did a quick test of both your main site and the landing page. Nothing in depth, just the basics. The following browsers worked properly:
On Windows (8.1 unless noted):
Firefox Stable 34.0.5
Firefox ESR 31.3.0
Opera 26.0.1656.32
Google Chrome Stable 39.0.2171.95
Internet Explorer 11
Internet Explorer 10 (Windows 7)
Internet Explorer 9 (Windows Vista)
On Ubuntu 14.0.4:
Firefox Stable 34.0
Chromium 39.0.2171.65
Google Chrome 39.0.2171.95
On Android 4.4:
Google Chrome 39.0.2171.93 (both landscape and portrait, phone and tablet)*
Firefox 34.0 (both landscape and portrait, phone and tablet)*
* Note that the UI navbar didn't stick on the phone for either browser despite the phone having a 1920x1080 resolution vs the tablet's 1024x768 resolution. I think this is by design on your end
The following browsers did not work properly:
Windows XP - Internet Explorer 7 and 8 - Failed to load custom images at top hero secion (custom CSS not contained in skeleton), alignment issues of buttons, full nav list visible (not part of skeleton issues), example grid completely broken (shows as full width divs), very broken visually but still usable
Windows XP - Internet Explorer 6 - issues above plus more visual issues. semi-usable
This is awesome! Browser chart more than just a quick list might be nice. Adding it as an outstanding issue to my long list of improvements. Appreciate the feedback!
You're welcome. Based on my testing, I think you don't even really need a detailed chart, just a compatibility list. You'd be safe listing it as compatible with:
Mozilla Firefox (desktop and mobile)
Google Chrome (desktop and mobile)
Chromium
Internet Explorer 9 and later
Opera (desktop and mobile)
Safari (desktop and mobile) [this is an almost-positive guess but test to be sure]
You could then work backwards a bit on version numbering, trying older versions until you see where it breaks. You could put Firefox 31+ for now (since I tested 31 ESR), but that would be misleading since I'd wager it works quite a ways back on Firefox. Same with Chrome, Opera, and Safari. You could even just leave those versions off as users generally have the latest version of Firefox, Chrome, and Opera. Safari is another story since it's OS-tied like IE is, so you have a lot more users using an outdated version of desktop Mac OS X's Safari than outdated Firefox or Chrome users on the same OS versions. Leopard users are stuck on Safari 5.0.6 and Lion users are stuck on Safari 6.1. If you can get your hands on really just those two versions to double check, you'd be set and could list it as Safari 5+.
I may test back a bit as I'm playing with using Skeleton for an older site using Drupal with a single-page theme. I can drop you a note if I do.
I don't believe it is, but maybe I should go about getting it into Bower. I have no idea how I would go about that, but one of the Bower creators coming over to play smash bros...will ask him.
Inclusion in Bower and cdnjs.com would be stellar. It would also likely result in wider adoption.
@dhgamache Thanks for making Skeleton. I use frequently rely on Zurb Foundation, but this looks like a compelling alternative for many of my use cases.
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.
What's the reason behind not doing nested grid columns? Seems like a fairly common usage pattern as I've seen. What's the recommended way of doing something where something like Bootstrap would use nested columns?
Hey 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 ;)
I really appreciate this :) Seems like Skeleton's greatest benefit is sometime to newcomers to RWD and knowing it helped someone learn a little means the most to me.
Also rad that you extended it. That's what it's about - making it your own :)
I realized a few weeks ago that Dave Gamache started a 2.0 branch. Skeleton was always nice to use and very lightweight.
Great to see it is back.
It is a nice boilerplate that doesn't come in that heavy as bootstrap.
Two questions: Are there hover-classes for tables etc. that can easily be applied? What about striped/alternating rows? And how come I can only nest lists 2 levels deep?
1. There are not hover classes for tables. I'm not in love with table hover classes, BUT, zebra-striping (like every other row) seems like it could by useful. That said, I don't want to create subclasses of any components really (buttons is one exception). It also should be super easy to implement w/ Skeleton – tr:nth-child(even) { background-color: red }
2. List nesting was just because I basically never go deeper than two levels and I wanted to properly indent them. Didn't want code bloat for something I think would be rarely used.
I'm not the author, but there are no hover classes for tables or alternating rows, as seen in the source, which is very readable [0]. Also, each additional level of list-nesting requires additional CSS, so it's actually impossible to support arbitrarily nested lists as seen in most word processors.
I like simplicity but skeleton is missing a few essential things for me.
1) Vendor prefixing. Like "sk-columns sk-column-5".
Uikit does this, but Foundation and Bootstrap do not. I really wish they did.
2) Preprocessor support in Sass and Less. They are so similar, it is easy to support both.
The grid class naming really really needs some cleanup! No one wants to automate something that has to output integers as integer names like "five" or "six". What is wrong with "sk-col-5" or "sk-col-6"?
> All measurements are still base 10 though so, an <h1> with 5.0remfont-size just means 50px.
So why not just use px?
EDIT, answering my own question: "font-sizes and spacial relationships can be responsively sized based on a single <html> font-size property".
So how does this work? Do you just set html font-size 62.5% for "normal" font-sizes and then change that with media queries in order to increase size for mobile etc? Is this best practice for font-sizes nowadays?
I was wondering about this too - anything smaller than 16px base size is a bad idea in my opinion. Also, Raleway as a body font? Not an ideal choice, it's too thin for low DPI displays. Other than that, I like the fact that it's very lightweight and reduced to the basics.
I've been using Skeleton for a while, so it's nice to see an update. I have a 1200px wide version, so if anybody's interested, I'll post it on my GitHub page.
:) Awesome man. Fwiw, the new version makes it super, super, super easy to scale since the grid is % based now. Can just change the max-width of the .container and voila. Done.
This might be a dumb question, but what are the pros and cons of choosing something like Foundation over Skeleton?
Is it a tradeoff of simplicity vs features - are there any features in particular that Skeleton misses out on? I've been using Foundation recently, but the thought of a simple, 400 line CSS framework is very appealing.
Hey Dave, really appreciate your work. Skeleton was just what I needed when I first started getting to grips with web design - it's been an invaluable tool to me while learning the trade. To see you've released an update is a joy, can't wait to dig in and start using it. Thanks a lot!
A bit OT, but it appears the 'class' attribute has now become the home for DSLs for styling. I wonder if there are better ways of doing this because after a while it becomes difficult to process mentally.
Maybe these projects should actually create their own markup language and release a transformer to HTML.
That's effectively what React Bootstrap [1] is. I'm wondering if there's a nice way to make a factory-like version of something similar which takes DSL definitions and generates the necessary components for you to use in a sandbox.
Or custom element types for Emmet [2] which expand to the appropriate HTML.
You can do quite a bit with naming conventions. Classes are case sensitive. So, you can for example use uppercase camel case for your building blocks and lowercase camel case for the things they are made of.
There are also dashes and underscores. I use underscores for "modifiers". That is, classes which modify the look of some building block. E.g. "Button" is the usual one and "Button _large" is a large one.
Custom elements will hopefully help to make this kind of structure a bit more popular. Right now they still have a few rough edges though.
I've read through the source (400 lignes, really short) and it's a real piece of art.
I forced myself to understand 100% of what each line was doing, and learnt a bunch of little things on the way.
I'll definitely use it in my next project, I love it!
This 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
Thanks! Browser support is under a "catch all" more tab on site, but really should be in docs. I'll make it happen soon, though hopefully the readme is clear for now.
great to see it coming back. for those that still something tad bigger (also feature wise), but not yet a bootstrap big, there's http://responsivebp.com/
I'm hoping the update really helps anyone who's been using Skeleton for a while or anyone trying to get into RWD.
Thanks :)