Hacker News new | past | comments | ask | show | jobs | submit login
1140px grid system. Time to scrap 960px? (cssgrid.net)
131 points by ramanujam on Nov 9, 2010 | hide | past | web | favorite | 65 comments



The thing that always bugs me about fluid layouts is line-lengths for pieces of text. In that example, the line length of the main text varies between about 280px (when the window is around 800px wide) and about 720px when the window gets smaller. That's quite a range.

In terms of typographic design and readability - that can be a problem - not sure what the solution is, but I do find it to be an issue.


But the font size also changes, so the change in number of words per line isn't as dramatic.

However, there is a point when you shrink the page where the number of words is about twice, but probably few devices actually have that width.


"Don't define height and width of images inline".

Not a good practice!

http://code.google.com/speed/page-speed/docs/rendering.html#...


I recently tried to switch to using non-fullsize browser windows, which is pretty much the reason for windows I think, but so many sites force huge page widths that it becomes unusable.


I always use a ~1024w browser window on a 1920w screen and have no problems.

For MS Windows users, I think "Maximise Everything" is ingrained at this point, which gets increasingly ridiculous on high res screens since we don't have resolution independence.


There's diminishing returns on increasing column width; the human eye starts to get strained if reading columns wider than ~60 characters. If the increased page width is applied to design elements and increasing font size, sure. That's not so bad of an application.

However, the English language's z pattern is inherently vertical, meaning that a page should naturally have space on either side; forcing a window to fullscreen just to have a 33% column of text is asinine, and shows that the designer is a prick for thinking strictly for XP and Windows' maximize button.

You're right about Windows' "Maximize Everything" being weird, it seems more and more like it was a good stopgap for people switching over from DOS and needing all the pixels possible on a tiny screen. OS X's natural flow for page windows may get confused from time-to-time, but it's a much better solution for dealing with vertically-biased windows in a widescreen environment.


> the human eye starts to get strained if reading columns wider than ~60 characters

Weird, I had no problem reading your comment even though HN is formatting it for me at around 180 chars.


It's not necessarily something you notice. It gradually gets a bit more difficult once you start getting past that point. And you won't necessarily think "oh, this is so hard to read" either (at least at large-but-still-reasonable widths). It'll just end up being a factor you weigh (if not consciously) when deciding "okay, I've had enough with reading this" and go on to the next thing.


Hope for the future: Windows 7 introduced a new hotkey that resizes windows to take up either the left or right half of the screen: WIN+LEFTARROW or WIN+RIGHTARROW.


There are also drag cues: drag to the top to maximize, to the left or right to maximize 100% vertically and 50% horizontally on the current screen, or when resizing a window drag to an edge to maximize in that dimension.


Thank you.

I use Multiple Monitors/UltraMon and the support for doing this with the mouse is lost (not sure if multiple monitors or b/c of Ultramon).

I guess I should have know there was a hot key.


There's also a tool called Winsplit Revolution which does the same thing. It's like Divvy on the Mac.


Unfortunately, half the screen (on a typical monitor) is not even wide enough to view a "modern" 1000px+ Web page.


Or you could just move the window to the left or right side and it will do just that, no keys involved.


I'd love to understand why someone would mod down my comment. I believe it's my first time, it's insightful so there was no reason to mod it down is it?


At a guess they don't realise that triggers a size snap and thought you meant simply do it manually.


Oh, thanks, I guess I can see that happening now that you say it! Should have been clearer like gxti did sometime after.


Im sorry if this was a joke and I didn't get it, but Windows 7 does exactly that


You misread the comment; read the first sentence as "[there is] hope for the future", not "[this is my] hope for the future"


The problem is that if you don't maximize everything, you'll wind-up with a series of windows which overlap in a less than useful fashion - menus, scrollbars and headlines get obscured and you need to mouse-around-the-screen to do anything.

There are dual problems here. Window Managers are designed to give a "comforting intuitive interface" rather than an interface which lets you do things quickly. But also, manufacturers pump out wide screens intended for video viewing rather than long screens which are suited for text viewing. This also means a good portion of web pages use fixed-width pages to keep from being stretched to unreadability. But these also keep the text from being read from a narrow screen (sure, they could set a max width with CSS but fixed-width also lets the designer guarantee their design looks exactly as they wish).


My browser windows have been approx 1/2 of my screen width for as long as I can remember, at least on desktop machines.

(terminals and emacs through, more like 1/3)


Even on a 1024x600 netbook?


No, the netbook is usually maximized (ubuntu netbook remix), but back when I had a PowerBook duo, the end of the 030era, I was running windows about 400px wide on a 640 px screen. Screens have gotten bigger, but for desktops, vie generally been at about 1/2 the screen, and laptops at 1/2-2/3 or so. I've gotten into some epic... Discussions of fluid layouts and how just because my browser was reporting lots a pixels, the layout wasn't getting them.


Usually my browser windows are about 700 pixels wide. That’s half of my horizontal pixels.

The vast majority of websites are no problem (text columns are usually no more than 700 pixels wide for readability reasons, I don’t care when I have to scroll horizontally to access other columns because my trackpad supports two-finger scrolling), some inherently need more pixels (The Big Picture wants to display big pictures and there is nothing wrong with that) and some just break (i.e. text becomes completely unreadable). I would be very happy if someone would fix those tiny minority of sometimes otherwise very fancy websites.


I recently tried to switch to using non-fullsize browser windows, which is pretty much the reason for windows I think

Yes, the idea that you would using multi, non-maximized windows at one time is behind the design of window managers.

Now, this model of interacting with a computer has been a success in the sense that it's how most computers are now organized today. However, this model has been a complete failure in the sense that few people ever use non-maximized windows because they coordinate so badly.

This is the reason browser tabs have replaced browser windows and indeed why the browser as an interface is easier to understand than the desktop interface ("just get me to a browser window and then I'll know where to go...").


Our new app is designed fluid with a min-width of 728px, which means it will fit inside iPad, while stretch out on desktop. With "Responsive Design"¹ you could also show/hide features depending on the screen estate.

¹ http://www.alistapart.com/articles/responsive-web-design/


That article sums it up nicely. If you have employ a flexible design from the start, it is really simple to use media queries to automatically adapt your site to the user's browser.

I usually develop for three main sizes. The standard 960, the iPad, and smart phones. And typically only have to tweak specific elements.


I'm sad that fluid designs are not more common. This is how HTML was intended. I like to play with the size of my windows to fit whatever I'm doing side by side. The only thing I think is acceptable is a maximum text width for those with the "maximize" disease, but please, no minimum...


How about just choose a grid that best fulfills the needs of the project?

I don't mean to be curt, but using an existing grid saves you half an hour at best and might not even be a good match for your needs. The solutions that let you dial in a width and column count are better, but there's so many kinds of grids that it seems like prematurely restricting your solution.


I'd like to use fluid more but unfortunately for us I don't think it would ever work because my boss is too anal over appearance. It's hard not use absolute heights and widths with the designs he comes up with. I think 1140 to 960 fluid would be great thing to try though. Still gotta optimize for 960px so you look good on tablets and other smaller screens. I think trying to be fluid below 960px is just stupid. Right now mobile sites need to be fast and efficient and you can't speed things up enough by just changing your CSS, the underlying HTML must also be compact.


Many netbook screens come in 1024x600, so I wouldn't plan for everyone to have 1280 columns just yet. TFA talks about mobile versions degrading gracefully, but not about desktop browsers on small screens.


You can get the exact same experience of a small screen desktop browser by shrinking your browser window, which it handles quite nicely.

The headline is misleading. The point of this layout is that we can go ahead and take advantage of large screen sizes without leaving behind smaller screens.


Terrible idea. 1024 works very well with the iPad. Unless your app is specifically designed to display large amounts of data I think improving the tablet's browsing experience is too important.


Did you try resizing the site? It uses css media queries to resize the content all the way down to mobile phone resolution.

For more information read: http://www.alistapart.com/articles/responsive-web-design/


This is not a tech problem. It is a design problem.

Good design can't just be "resized". You essentially have to redesign it from the ground up. It takes a significant amount of work. I would rather just use 1024 and have it work on tablets + notebooks + desktops, and then do something separate for mobile. Mobile is such a radically different experience compared to a typical computer you almost have to do it.


It's not necessarily the fact that site is designed to be resized or not it's more about the careful consideration of how a site will look at various sizes. Take http://hicksdesign.co.uk/ for an example. You can tell that the site was designed for various resolutions but uses the same codebase to support them. I don't think the two problems are mutually exclusive.


That is an incredibly simple website. It is possible to get away with it when you have such a simplistic website where the secondary content is almost irrelevant as far as importance go.

Now try and apply this design restriction to something other than a blog where actual interaction is required and it will fall apart fast.


The problem with this is that it assumes users want a bigger browser, which they generally don't. I browse full-screen on a 1024x768 screen because that seems consistent with the width of a standard printed magazine page.

On bigger screens, users don't want a wider browser window. Instead, they want room on the sides of the page to do other things, either sidebars within the browser or other apps outside the browser window.

960px is the perfect width so you don't get a horizontal scrollbar at the bottom of the window. It's also consistent with most other sites.

Finally, 960px looks appropriate on ipad and other tablets.


I still _regularly_ visit customers who have CRT monitors running at 800x600. I would say that the vast majority of users are still running at 800x600 on xp or lower.


I work for a 3rd world insurance services company (Uruguay).

The stats for our website are roughly:

25% 800x600 50% 1024x768

and a wide assortment for all the rest.


I don't think I've seen a fluid design that is not just filling the available space for sake of filling the available space.

If you know any I would love to see them, thanks.


Amazon's new layout shows more or fewer suhcategory/recommended products based on the width of the viewport (at least on the home page). Presumably it is more valuable/meaningful to show more products if possible and it isn't just for the sake of filling up space.


This framework goes to 1280px, and does dynamic resizing as well:

http://lessframework.com/


LessFramework only works properly for IE9, whereas the original framework above cites IE7 and IE8 compatibility. It's an unfortunate fact of web development that those browsers are important.


They must have heard you. LessFramework 3 just came out today. It does support IE 6-8, although only at the 768px layout.


960gs fluid can be altered to be 1140px wide. It just needs a max-width attribute on the container_12 class - http://goo.gl/2Jdla

*Edit: The gutters also scale with viewport size and the nested elements can be fluid too.


Asking whether or not we should "scrap" a certain resolution is missing the point. Media queries are far more exciting than "whoa, I can make my page super wide now" will ever be.

And the big gutters are a nice touch.


Wider is better...until problems begin. Apple.com's chosen 984px width is a good choice, for a variety of reasons: http://j.mp/HowWide


It boasts mobile support, but it doesn't seem to be working with the default Android browser for me (Droid 2). Is anyone else having problems?


Looks fine to me (Droid X) but seems to be loading still (not sure what)


How on Earth does this "work perfectly" for IE 7 or 8? It looks terrible at less than maximum size in either.


eww,text doesn't zoom.


I'm glad someone pointed this out. The inability to zoom the text sure makes that web page unfriendly to those of us that have trouble reading the little tiny microscopic fonts that are so popular on web pages these days.


The text zoom works for me in Firefox just fine. The zooming also is accounted for, and the site layout changes to meet the need of the enlarged text.


Good catch. On their web page, text zoom in Firefox works, but text zoom in Chrome doesn't. Chrome bug?


Nope, the CSS contains

-webkit-text-size-adjust: none; /* Stops the iPhone scalling type up */

which has the unfortunate side-effect of preventing text resize in webkit browsers.


Regardless of the CSS, any time I try to enlarge text in any browser and it doesn't do it, I get frustrated with the browser, not the website. Their is no reason I can fathom why a browser would not do this. So yeah, I'd take it as a bug in Chrome. If it's giving you the option to enlarge text, and Chrome isn't enlarging, or zooming, then it's a bug.


Same on Mac Safari. Webkit bug?


It is technically possible to make a book 2 metres wide. There's a reason why we don't.



Last used in 89 for shooting "I Shrunk the Kids Honey".


...usually.


Yeah, let's stick to 1.68 metre wide books.


The gutters are way too big for this grid to be effective.

40 px gutters? Are you serious? Gutters should be 10 px minimum and 16 maximum.


Wait. How long is a piece of string again?

10-16px sounds completely arbitrary to me.




Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: