I know, this is probably beating a dead horse and downright inflammatory. But I want you know what you all think. What is it? I vote for a dynamic layout somewhere between 900px-700px. Anything more than that and you are making text too wide to read comfortably.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
What is the "perfect" width for the web?
- Thread starter beautifulcoder
- Start date
- Sort by reaction score
In times like these, there is no right width for a website anymore, although there isn't anything wrong with fixed width layouts.
You can't predict what device a user will visit your site on.
Flexible layouts with either ems or precentages are more or less the way to go.
If you use pixel based layouts, then use media queries to fix and adjust the element's width.
Also you can and definitely should use widths on text elements to ensure good readability. Eleven words per line is a good rule of thumb, it certainly depends on the languages the text is.
You can't predict what device a user will visit your site on.
Flexible layouts with either ems or precentages are more or less the way to go.
If you use pixel based layouts, then use media queries to fix and adjust the element's width.
Also you can and definitely should use widths on text elements to ensure good readability. Eleven words per line is a good rule of thumb, it certainly depends on the languages the text is.
Depends on your audience. Macrumors forum seems to size between 800 and 1250.
You shouldn't have any set width at all.
True responsive design uses CSS media queries to make your site adapt to whatever viewport your visitor is browsing on. Make it so the content on the website fills the screen regardless of the screen size. You can use the media queries to resize objects, text, position, or change just about any element's style around all depending on the screen size.
@media (max-width: 480px) { all your styles for small (phone) screens here }
@media (min-width: 481px) and (max-width: 768px) { styles for mid sized screens/tablets }
etc etc.
Hmmm... i like 960px wide.
Why? Because it is divisible by so many numbers.
Been using it for about 5 years now, with no problems.
Perfect, though, doubtful, you'll find a 'perfect' width, but one that will work right now. Make sure you code your site so that you can update it very easily: REM, ect.
It seems the current trend is for the intranets visitors to use 1366x768. 960 fits nicely in there with a little border on each side.
1920x1080 is climbing up fast though and 1280x1024 is holding steady ( but 960px width still looks good on those as well ) So changes maybe in our near future.
Why? Because it is divisible by so many numbers.
Been using it for about 5 years now, with no problems.
Perfect, though, doubtful, you'll find a 'perfect' width, but one that will work right now. Make sure you code your site so that you can update it very easily: REM, ect.
It seems the current trend is for the intranets visitors to use 1366x768. 960 fits nicely in there with a little border on each side.
1920x1080 is climbing up fast though and 1280x1024 is holding steady ( but 960px width still looks good on those as well ) So changes maybe in our near future.
Last edited:
Excellent response and I concur, 100%.
Even if the layout is not intended for mobile device viewing, a liquid layout that adapts to screen width is a best practice. By no means a rule, of course. In terms of static width I find 960 to be practical, noting there is no ideal, and not just because 960design here is named that.
That's wise, as an FYI for those following -- the media queries which factor in screen resolution really are more about responsiveness (as you noted) than mobile detection, in my opinion. For developers who want more accurate mobile detection the user agent string and vendor codes are my preference noting once or twice a year these have to be updated based on market change. This is an approach preferred by some because many mobile phones are extremely high resolution these days and don't forget landscape mode. Some companies in my experience prefer mobile detection and redirection to their very highly customized mobile only site or app, but still use media queries for basic responsiveness just like you do.
NO single approach works for everyone, is the point.
BTW, I favor server side processing and caching of images based on image styles that are set to match and properly scale to the same values used in common media queries. This is far better than dynamic Javascript based DOM image resizing on the fly or creating alternate images MANUALLY or simply allowing the CSS to resize. Many popular CMS's allow use of GD or other graphics libraries to process the images server side and cache them once uploaded as part of the content submission process.
Thanks for your comment!
I use a combination of media queries for layout styles and server side for sending more suitable image sizes and moving elements around; pushing the main menu into the page footer on feature phones, or not serving jQuery / JS to them for example.
It drives me bonkers when people think a media query is all you need for RWD. Most of the image proposals so far either rely on JS or load two images (which is worse than just sending the full sized image). RWD would be a lot easier if people didn't want images on their sites.
Would you care to expand on this? I can't quite get the process you are describing in my head. I have media queries inside a single stylesheet rather than several stylesheets served according to a media query on the link element.
Most CMS's have ways to upload images into content or a file area, including defining and selecting which image style to use which converts the image to a certain size. For example, thumbnail or cropped or scaled to whatever dimensions. Setup an image style matched to each media query in the CSS. When the content is submitted, the image is processed server side and variations of it based on all defined media types are created once and stored in a well organized cacheable file image area. The correct image is then used in the final rendered HTML based on media query at runtime. Modules or extensions are developed to handle this, of course.
I understand the creating and caching of multiple versions of the master image but ...
It's this bit that confused me, and still does, if I've a single stylesheet that is passed to the browser then without something in the browser (usually Javascript) sending viewport information back then the server has no way of determining which media query is in effect when the CSS is parsed. Also there would need to be some way to react to the user resizing their browser.
It's this bit that confused me, and still does, if I've a single stylesheet that is passed to the browser then without something in the browser (usually Javascript) sending viewport information back then the server has no way of determining which media query is in effect when the CSS is parsed. Also there would need to be some way to react to the user resizing their browser.
CSS3 media queries do not have to be Javascript (typically used for orientation change, resizing no longer necessary for this method), but it does not matter if it's all generated dynamically.
The module/plugin handles the setup of media query definitions and creates the image selectors mapped to each query:
1) Using a simple naming convention for image names or paths
2) Or, by creating and referencing a sub-theme or sub-folder named to match the media query
As CSS cascades one can still apply custom styles to images as they see fit but leave the stylesheet media query and image path/location or naming to the plugin. Quality CMS's will then minify and compress all the CSS to reduce bandwidth.
960GS without a doubt is the best to design to for ensuring compatibility across devices and platforms.
978GS is also common while I've seen a significant shift to the responsive grid during the last 18 months.
978GS is also common while I've seen a significant shift to the responsive grid during the last 18 months.
I probably didn't explain my lack of understanding particularly well
The browser has the information about viewport size etc. How does this information get back to the server so that it can serve up the correct images? HTTP headers don't contain this info, there has to be something on top of the standard protocols to do this. UA sniffing only gets you so far.
A search for "rwd images" comes up with quite a few solutions including the proposed picture element but most (all?) require something to send that information back - Adaptive Images seems to be the best regarded of these. Quite a few also require two HTTP requests, one for the default image then one to serve up the optimum version.
If I have a stylesheet containing my media queries and linked like this:
PHP:
<link rel="stylesheet" type="text/css" href='style/style.css' media="screen" >Containing something like:
PHP:
@media (max-width: 500px) {
html {
background-image: images/width-narrow.png;
}
}
@media (min-width: 501px) and (max-width: 640px) {
html {
background-image: images/width-slim.png;
}
}
etcSince the stylesheet gets parsed before most of the rest of the page it would mean that the server monitors the requests and then serves up appropriate images depending on whether width-narrow, width-slim, etc are requested. It does mean that the server has to retain state for each connection though, probably through sessions.
Is this what you mean? If it isn't then I still can't see how the parts of the system link up.
You should have qualified that statement with "desktop devices and platforms" as it clearly ISN'T the best for mobile devices.
I probably didn't explain my lack of understanding particularly well
All the CSS3 related to media queries is generated dynamically as a stylesheet by the module and exported to your CSS folder, similar to how you can use PHP to create Javascript. , i.e.:
@media only screen and (max-device-width: 480px) {
}
The you can edit it as you see fit. But how did it get there and why 480? It's all done via the module setup.
Your CMS likely already has image styles, i.e. thumbnails on uploaded images. Just create other styles in the same way using the module setup for various media queries (i.e. above is "Max480" which scales images to 480px wide) and the CMS handles the image insertion automatically by saving a 480xwhatever image in a sub-folder in your file or CDN called "Max480" for example. It all works *together* with the module generating the basic images and preliminary CSS, not you.
End result: A fully mobile site with any media queries you want, images automatically scaled to match each query and cached in an image folder for maximum performance.
I am not going to go into the actual coding as to how to accomplish this and which CMS's allow this -- this is why module developers like me make their money! But do you get the basic concept now? If not, I tried!
Last edited:
Thanks for replying Jim (I realise it's early morning in your part of the world )
I get the CMS/server side of things: create breakpoints in a config file; run the module; etc. It's how the browser passes the server the requisite info that I can't see with this setup.
As far as I'm aware you can't specify media queries on the img element to pull in the appropriate file (this is what the proposed picture element will do) but you can specify a set of background-images for an element only one of which will apply at any given time through the media queries.
Will always show 'foo/bar.jpg', (this is the case I'm interested in and can't see how auto generated server side content gets to the browser) whereas:
And auto generated CSS like
Would be able to display the appropriate image. I do this for some of my menus.
Chris Coyier's blog post describes it better - http://css-tricks.com/on-responsive-images/
Is this second scenario what you are describing?
)I get the CMS/server side of things: create breakpoints in a config file; run the module; etc. It's how the browser passes the server the requisite info that I can't see with this setup.
As far as I'm aware you can't specify media queries on the img element to pull in the appropriate file (this is what the proposed picture element will do) but you can specify a set of background-images for an element only one of which will apply at any given time through the media queries.
Code:
<img src='foo/bar.jpg'>Will always show 'foo/bar.jpg', (this is the case I'm interested in and can't see how auto generated server side content gets to the browser) whereas:
Code:
<div id='funny-img'</div>And auto generated CSS like
Code:
@media only screen and (max-width: 480px) {
background-image: 'foo/bar-mobile.jpg';
}
@media only screen and (min-width: 481px) and (max-width: 900pc){
background-image: 'foo/bar-tablet.jpg';
}Would be able to display the appropriate image. I do this for some of my menus.
Chris Coyier's blog post describes it better - http://css-tricks.com/on-responsive-images/
Is this second scenario what you are describing?
Last edited:
Noting the all important disclaimer that no single method is perfect, I can give away how this can be done one way, entirely server side:
WURFL. it uses the user agent string to query a database storing resolution data for known mobile devices, and it's updated often. Probably as accurate as you can get server side without the help of a client-side script/app or the popular CSS3 media queries we've both mentioned in this thread.
I am sure you can imagine the rest once a device and its resolution is detected, how dynamic things can be with little concern by a content provider. With that thought in mind, I bow out of this conversation so you don't wrangle any more trade secrets from me! I'm worse than Edward Snowden.
JKBTW, the link you provided are great ideas for marking up media queries in numerous ways, but of course let's see what is decided upon by the governing body (W3C) and which browsers will support it. That's all still part of CSS3 working draft, mostly. We all suffer until then with no viable working standards.
Ta for that.
I'll leave you with your trade secrets
I had thought of using a php include to write out an appropriate (for now) block of HTML for responsive images, then when the W3C get their act together and decide on which method they are going to pursue it's just a case of rewriting the include.
I'll leave you with your trade secrets
I had thought of using a php include to write out an appropriate (for now) block of HTML for responsive images, then when the W3C get their act together and decide on which method they are going to pursue it's just a case of rewriting the include.
Ta for that.
I'll leave you with your trade secrets
I had thought of using a php include to write out an appropriate (for now) block of HTML for responsive images, then when the W3C get their act together and decide on which method they are going to pursue it's just a case of rewriting the include.
When I build WordPress sites I use a combination of an .htaccess file, a small script and a cookie set to the current screen size. Using this I don't serve any images wider than the screen to a user, and the WordPress editor doesn't have to worry about using the right sized image for the job.
You like not being able to read Apple's website on your phone? With its too long line lengths it's an incredibly frustrating experience.
I've always thought it odd that a company responsible for one of the most popular mobile devices has a website that utterly sucks when viewed from said device.
I like that I see the same I see when I am at my Mac or at my iPhone.
When there is a mobile version, things are always different and "dumbed" down, IMO. Zooming in and moving around isn't that bad.