Gridless: a responsive HTML5 and CSS3 boilerplate(thatcoolguy.github.com)
thatcoolguy.github.com
Gridless: a responsive HTML5 and CSS3 boilerplate
http://thatcoolguy.github.com/gridless-boilerplate/
19 comments
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.
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.
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.
Looks good, I've got few questions for you:
- Why put respond.js in the footer? (H5BP puts it up in the head with the call to Modernizr)
- Why self-close your meta and link tags if you're using HTML5?
- Why doesn't the image in the demo resize as you resize the window? (img { max-width: 100%; } fixes that)
- Why put respond.js in the footer? (H5BP puts it up in the head with the call to Modernizr)
- Why self-close your meta and link tags if you're using HTML5?
- Why doesn't the image in the demo resize as you resize the window? (img { max-width: 100%; } fixes that)
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.
ahh, my bad on #1 - it's early :)
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?
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?
Interestingly, the github page that the marketing page is hosted on, is quite responsive.
Just resized it to all different sizes and it still looks good.
Even the code snippets fold gracefully.
Just resized it to all different sizes and it still looks good.
Even the code snippets fold gracefully.
To be honest, if compass doesn't have it I just dont care at the moment.
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).
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).
Compass is slow to compile...
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 :)
The name almost seems to suggest that the use of a grid is a bad thing.
I checked out the demo, expecting to see some nice use of grid layouts but without the dreaded "silly classes."
But no. I see some OK-looking forms and tables in a fairly linear structure.
Indeed, true the name, it is gridless.
Do you need a framework for that?
"Beautiful typography with a vertical rhythm."
Even granting "eye of the beholder" and all that) , there's actually not much rhythm going on here.
I checked out the demo, expecting to see some nice use of grid layouts but without the dreaded "silly classes."
But no. I see some OK-looking forms and tables in a fairly linear structure.
Indeed, true the name, it is gridless.
Do you need a framework for that?
"Beautiful typography with a vertical rhythm."
Even granting "eye of the beholder" and all that) , there's actually not much rhythm going on here.
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.
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 ?
Could 'screen adaptive' or 'multi-screen' be a better name ?
Loved the test page. Good work!
Thank you! It's still a work in progress and I'll be adding more information on it gradually.
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.