SitePoint just released an article discussing the multiple layout specifications that the W3C is recommending that web browser vendors implement.
My position? The W3C is nuts.
It's obvious if you attempt to read the specifications that the committees involved are trying too hard to please everyone. Worse, they're including every possible edge case that occurs 0.0012% of the time out in the wild.
So when we're done we’ll have a nice "simple" specification, just like the one that eventually became SOAP. You remember SOAP, the "human-readable" service-oriented-architecture definition language that no human can generate, and most machines can't read. SOAP, the spec that's so bad that the rest of us immediately started thinking about REST and JSON so we could avoid it entirely.
You, see, the problem is that we're trying to solve ALL of the problems, when in actuality our lives would be immeasurably easier if we'd just take out the top two or three of them.
Problem: Multi-column CSS-based layouts with footers are a major pain in the... well... they're painful, okay?
Solution: How about having an absolute positioning mode that DIDN’T take the DIV out of the flow? That way we could position our columns where we want them, and the enclosing element would then expand to hold them. Then any other elements that might be beneath that element (like footers) would be pushed down.
Can't be that hard. After all, we used to be able to manage it when we did tables.
Problem: Faux-columns and unequal column heights.
Solution: Add, say, a “parent” option to height, so that a DIV could be told to automatically expand to be the height of its parent element, with appropriate padding and margins of course.
Bingo. You’ve fixed 95% of the problems with multi-column layouts and equal-length columns. No more floating negative-margin faux-image maybe-the-browser-will-like-it-and-maybe-it-won't hacks.
Or maybe you have better solutions to the above issues. Fine. Trot 'em out.
Either way, I’d much rather see them recommend a few enhancements and modifications along those lines that we can implement and test quickly, as opposed to designing a super-complex one-size-fits-all specification that's so complex it will take forever to implement, and a savant to understand.
So let's try out a few things and see how they work. If they cause more issues than they fix, then we'll just deprecate them in the next spec and they can hang out along with our old friends BLINK and LAYER.
If not, then we're ahead of the game, and we can tackle the next couple of things on the list, like CSS variable substitution.
What's your viewpoint?
Comments