Whenever someone posts one of those "How to you like my app" posts, and I have to scroll horizontally, I mention it. And I usually get shouted down. They tell me to "graduate" from 800 x 600.
My argument has never been that any resolution is any better than any other. It's been that your app should work no matter what resolution your visitor arrives at.
This article is one excellent solution to that problem.
Ehh. Here are all of the following "shoulds" that I hear:
- Your app should work at any resolution
- Your app should work on any browser
- Your app should work on any platform, even grandma's old PII running Windows 98
- Your app should work on dialup, and be sexy for broadband
- Your app should be accessible to the blind
- Your app should not break when new browser versions are released
...and so on and so forth.
I am perfectly willing to write such a beast. Are you perfectly willing to pay for the hundreds of hours it would take to do it?
Every app designer is unfortunately forced to make some tradeoffs. In some cases, they make many tradeoffs, usually because nobody's willing to pay them to meet the needs of every user out there.
Not coding for 800x600 in these days of high resolution, high-bandwidth design, is a logical tradeoff.
For what it's worth, in this completely unscientific survey, much less than 1% of all visitors to my site use 800x600. There are 15 more popular resolutions ahead of it. In fact, twice as many people show up on a mobile device with 396x320 resolution (aka iPhone).
The counter-argument to liquid-layouts is the fact that you need to specify a min-width which is not supported in all browsers (easy fix for jscript sure, but certainly not hack-free).
So for individuals like myself, who run at 1920x1200, legibility is a significant issue unless I manually resize my browser window which is about as much of a pain in the ass as scrolling horizontally.
Sadly, there is no perfect solution when designing for the web. Horses for courses.
In OSX, the layering nature of windows to make drag-n-drop more usable sometimes becomes counter-productive.
There are times when I find I just want to focus on a single item and block everything else out, which forces me to either maximize Safari, or close down all my applications.
I don't care for Spaces too much right now, it's kind of buggy with Photoshop/Illustrator.
I'm a fan of the multi-monitor model. Two 20" LCDs are often cheaper than one 40" (not the same area, I know) and can be much more useful. My typical setups are:
screen one: rotated vertical with code
screen two: horizontal with command line and the app splitting horizontal real estate.
Did not want to be anonymous in agreement, but felt strongly enough that I wanted to comment and yet did not have time when commenting to go into reasoning (only had a few moments before I had to go elsewhere). Hence, the basic agreement. Was going to elaborate more later (i.e. now) but now don’t think it’s needed as points have been made by others since.
...also, in the same vein one can ask what your comment accomplishes that a downmod would't have? :)
It'd be a mess if not only a lot of people left purely opiniative (?) comments because they don't have time to elaborate but this was also generally deemed good behavior.
If you were about to post insightful commentary later couldn't it wait (in fact it did wait since your in-the-meantime comment was clearly no substitute)? Especially since others have expressed what you would have.
"...also, in the same vein one can ask what your comment accomplishes that a downmod would't have? :)"
I find it surprising that you'd ask that just after clarifying your motives. Would you have posted that answer if I had just downmodded you?...
I agree. Your points are well made. Sorry. Lesson learned (next time won't be so hasty). I'll make efforts to improve signal/noise and quality/quantity ratios :)
Lastly, if you/anyone just downmoded the comment I wouldn't know who/why so would not have answered like that. Instead I would have discussed points/issues/reasons, as I generally try to do in other posts I make.
It's not so much as failing of CSS as a technology as it is an indication that CSS is not the language designers want it to be.
What really sucks is that it's actually pretty close to that language. Everything's fine until you hit the cross-browser compability issues or realize it's missing a few primitives (like the ability to easily create columns). Then you want to tear your hair out. And/or resort to hacks.
Exactly. I think CSS started out as more of a typesetting layout, and has been stretched into this other beast.
To me, it doesn't make much sense to spend many hours of cursing and headaches trying to force CSS to do something that a very basic HTML table can do in just a few seconds.
When I say "percentage based scaling", I mean "simply resizing elements to fill the screen". That's what's rudimentary.
A nice scaling toolkit would let you intelligently use all that width. You might be able to change how things flow, change how much content shows in various elements, etc, etc. Making wider columns usually sucks.
The whole reason the movement away from tables began is because complex layouts (nested tables) do not render correctly in different browsers and it does not separate style from content like CSS does.
Tables also makes it harder for crawlers/interpreters to understand the page as content may not be hierarchically correct due to layout issues, etc.
If you use tables, you don't have to avoid CSS. They compliment each other. I agree that nested tables are ugly, but they're also completely necessary now because of CSS. Using tables to render your main multi-column layout wouldn't require any nesting. Also, tables are more likely to render in different browsers (including mobile browsers) than a complex CSS layout.
Given the number of CSS hacks and extra HTML tags in exactly the right order that is necessary for most column layouts the end result is almost always less complex with a table.
Tables should really be used for data that requires it e.g. number sets etc., and not for layout.
True, using tables for layout in some sites is much simpler than CSS but people who do that usually do so today because they do not know how to do it in CSS properly.
Either way, all is fine, until they start using tables within said layouts (e.g. for number sets or even more mutli-columning in subsections) and things start to get problematic. This is especially evident when they try to use the content in various sites or try to change formatting for cross-browser related issues (often best solved by having base style sheets for various browsers).
Just my experience and thoughts, ultimately use whatever is best for you, and you are comfortable with :)
IE and FF handle column widths in tables rather differently, which can cause some problems with table based layouts. I've been round this circle recently and ended up back with a 'pure' CSS approach
| ...and it does not separate style from content...
I often hear this mantra, but why is it really important?
I think it's a good goal, but not to the extent that a designer is spending a ton of extra hours working on a layout simply to try to ensure this perfect separation of style from content.
...well you may as well ask why MVC (or MVP or similar) is important.
They all share the base reasons, which is the seperation of concerns, which ultimately leads to systems/solutions being easier to develop/maintain/extend/change.
I suppose I should clarify. I didn't mean to imply that content-vs-presentation was unimportant; I think it is important. I meant to ask, is it always important enough to justify all the extra cost associated with it?
It's presented as this cardinal rule: the web designer shalt not mix layout and content, nor shall the designer obfuscate thy code with any table, less it is presented in the form of a database view. (+1 for dramatic license.)
And I would be all for that, IF the development platform that we were all forced to use actually supported that in a helpful way.
But, it doesn't. Give me a little time, and I'm pretty sure I can come up with at least one presentational trick that is absolutely, positively impossible with cross-browser CSS -- and I'll even allow you to use all the CSS hacks you can come up with. But, the very same presentational effect is a piece of cake with a single HTML table.
MVC, or MVP, are sound ideas ... where they're made practical by the development environment. However, it's possible to write perfectly easy-to-maintain code for a business without strictly following those models, and if you're dealing with some framework or development environment that makes the MVC model difficult, then I think it's foolhardy not to make some practical considerations in lieu of this stainless ideal.
EDIT: I just remembered the CSS layout that I wanted so badly and never could figure out. It drove me nuts, but this was a couple of years ago and somebody might have figured it out since. All I wanted was two columns; first was completely liquid, the second was liquid with a minimum width; auto scroll bars (but not displayed unless necessary); and -- the part I couldn't get to work -- a single line border drawn between the two. For some reason, no matter what I tried, introducing that line border caused one browser or another to add scrollbars, or draw it short, or something else idiotic. Three days of Googling, CSS hackery, and other nonsense later, and I wrote a table in just about a minute that did the job fine.
Where I work, we separate layout and content quite religiously because they're done by different people. A mess of table based HTML may make things easier for the layout guy, but it makes it more difficult for the content people to work with later on.
For example, let's say the HTML guy makes a page where product data should go. What exactly that product data is, he does not know when he's making the page. It doesn't matter, he can just make the HTML and fill it up with some Lorum Ipsum text. Then when it's time to put the actual product data in, this will take ten minutes at most for the content people to do if the HTML is clean and minimalist, while it will take a few hours if it's nested tables or worse (Dreamweaver generated crap or somesuch).
In the end, the cost of having someone do HTML properly, meaning using HTML for content only and dealing with presentation in CSS, which the content people will never see, offsets the costs of having developers wade through messy HTML every time they need to change something.
Tables would make that not work so well on, say, an iPhone. The way it currently works, the "content" column is going to be the first thing visible when the browser's not wide enough to fit all three.
Tables render better on mobile browser than pure CSS layouts. Mobile browsers are very smart about tables and almost always do the right thing. CSS is just too complex to get a good result when you need to scale down to a small screen.
...sometimes. When you put three cells next to each other in a table, you're telling the user agent "this is a row of related data". It's difficult to intelligently choose how to lay those out if there's not space for them to appear side by side.
That CSS layout leaves a bit more up to the user agent. The primary content appears first, if there's not space to position each column next to the primary content, it drops down below.
My argument has never been that any resolution is any better than any other. It's been that your app should work no matter what resolution your visitor arrives at.
This article is one excellent solution to that problem.