I have this nagging suspicion that this whole "responsive HTML" movement is driven largely by a desire for a layout that works on (a) an average desktop screen and (b) on an iPhone / smartphone. And so instead of designing two separate sites, let's design something that looks good on (a) and (b), and also has an intermediate state that we pass through when resizing the window between (a) to (b). Nobody would actually care for these intermediate states (because, frankly, who does routinely browse on a desktop at 500px in width?), but since we can generalize, let's do it. And also let's call it some fancy name and put some theory behind it.
Point being - I don't see a point in responsive layouts.
There are two extremes - the desktops and the small-screen mobile devices. These cover 99.9% of all users. Designing an uniform solution for both is not too alike to building a File I/O framework to hide the differences between reading from the local file and one on the FTP server. Sure it is nice, but why? It just conceals the important differences and creates whole bunch of new problems.
I absolutely do browse at about 500px width on workstation (with 30" 2560x1600 displays).
I typically resize my browser window when reading this site, for example. For reading text, a fairly narrow column is easier to read (and easier to stack next to a bunch of work-related windows too).
I just measured how narrow HN gets and it is 535px (Safari, typical font settings).
Even if we were to stipulate that I am a weirdo and that most people using a PC leave the browser wide, I still don't think you are correct on the numbers. Even just considering smartphones and PCs, we really do already have a huge variety of screen resolutions, already. Consider that 320, 480, 640, 960 are the possible pixel widths of just the last two models of iPhone. Then throw all the other smartphones with different screen technologies and slightly different screen sizes, and you get just about every meaningful increment from 320 up to 960, and now you are in laptop PC territoty.
Throw in the upcoming iPad clones, plus (I hope) a new crop of decent 7" tablets, and I don't think your 99.9% estimate is even close (I'd hazard a guess of something like 75% and decreasing, but who knows).
So, while I don't personally make websites, I do use a lot of them (on screens ranging from 3.5" to 30"), and I really appreciate the responsive HTML movement as a customer.
Add another extreme -- the 1024x768 tablet (ipad), the 1024x600 (nook color) tablet, the 1280x800 tablet (xoom), or the wild ranges of DPI's out there; some of these devices have ludicrously high DPI, such as the iPhone 4. How about the fact that two out of three of these devices are rotated frequently and the content must reflow?
Responsiveness is important, and so is graceful support for a wide range of ratios, DPI's and reflow. The ultimate lesson of the so-called Web 2.0 movement has been that user experience really does matter.
1. Respond.js is not in the footer, it is inside the <head> tag. See here: https://github.com/thatcoolguy/gridless-boilerplate/blob/mas...
2. HTML5's syntax is not very strict, but I prefer closing void elements because I think it improves readability.
3. I chose not to add any responsive image style by default because of IE problems and Windows' rendering. I'm thinking of adding that soon.
The source formatting kinda threw me off with the entire head being tabbed and the empty body, maybe add a little dummy HTML inside the body like the H5BP?
I don't really see the need for a Compass version right now, but you can try to port it anytime. It'll be easy, since Gridless doesn't have any pre-made grid systems or classes.
I'm a Compass contributor and lover and I'm working on a framework which will provide the ultimate set of tools for front-end engineers.
Currently it's still undocumented and there are no examples; the project will gradually grow after I find some time to write some tests, but you can check it out here: https://github.com/kuroir/Survival-Kit
Survival Kit is to Compass(SASS) what Rails is to Ruby(Core-Library).
I must ask, why the name “Gridless”? Surely HTML/CSS frameworks and grid systems are completely different things? The name almost seems to suggest that the use of a grid is a bad thing. Just the way I perceived it :)
You're right, Gridless is not really the best name for this boilerplate, but I'm not good in choosing names :(
The problem with grid systems is that they include classnames and ids which should be unique to each project. You can still use grids, but please don't use span-x classes, customize the classnames and ids to suit to your project. And doing that isn't impossible or extremely hard, there are a lot of tools out there for that: Sass/Compass, LESS, Blueprint's compress.rb script etc.
Awesome! I have been thinking about making something like this, but it looks like you did a better job than I would have. Responsive design is an idea who's time has come.
Thanks :) I really think responsive web design and one web is the future of web design. There are some situations where a specific mobile website will be needed, but in the (near) future these will be very rare IMHO.
If you have any cool ideas let me know with a pull request or something.
On a slightly unrelated note, I think the term 'responsive' is unnecessarily overloaded. I thought there were some performance problems with the normal HTML5 boilerplate !
Could 'screen adaptive' or 'multi-screen' be a better name ?
Point being - I don't see a point in responsive layouts.
There are two extremes - the desktops and the small-screen mobile devices. These cover 99.9% of all users. Designing an uniform solution for both is not too alike to building a File I/O framework to hide the differences between reading from the local file and one on the FTP server. Sure it is nice, but why? It just conceals the important differences and creates whole bunch of new problems.