- IE6? PNG transparency doesn't work right.
- CSS is a complete mess of a system, which doesn't specify how to handle a whole variety of different issues correctly. That'd be things like:
- Scrollbars in overflow blocks
- Centering of elements without resorting to margin tricks.
- Z-Order handling (I mean, come on, a z-index? That's a little retarded).
- Things which should be easy currently require at least a day of trial and error to get right (I mainly blame CSS for this)
- Fonts can't be downloaded. Still. After 14 years. (Without browser-specific extensions).
- CSS doesn't separate layout from the document any better than HTML did.
How do we fix it?
I want to see a new way of building web pages that completely ditches the old crap. Here's what I want to see:
A Tic-Tac-Toe style Layout Model
Every block should consume space from its parent using a tic-tac-toe grid type of arrangement. You should be able to specify which elements in that grid can stretch, and which ones are corner pieces which don't. And the center should fit the content.
Of course, we'd need ways to break out of this system and absolutely position elements - but this will handle the 99% case of the layouts people put together.
We'd also want a "flow-around" algorithm that lets you flow text around these elements, regardless of the layer they're on.
Once you've built an element out of component pieces (like, for example, a nice button which stretches to fit the text on it, and has a drop shadow, etc), that element should be groupable. You can then modify the location of the entire group. In terms of rendering and mouse-handling, the group would render as a single unit.
You could also group groups together. Think of the way that most vector illustration programs work.
Once you've built an element out of pieces, you use a template to refer to it on your page. For example, if we have a Panel with a title, and a content block, and an associated sidebar, it'd look something like this:
My Cool Panel!
Templatized sidebar element goes here
... and you'd only define it once. So if you wanted to have a web-part interface, you'd just have one of these which had the
Where the templating idea becomes even more interesting is when you start using a content map with the templates. For example:
BREAKING NEWS: Sarah Palin - part woman, part fish! This just in - Sarah Palin is part woman! Sidebar headline! Main text of the article goes here
So that's your content page. It's layout free.
Now we need a layout to go with it:
Needless to say, we could just leave the contentsrc parts off, and seek through the content based on the name, which would give us something like this:
... and if we want to go a step further, we can default to filling all of the element's template values from the contentsrc, in which case our definition collapses to this:
Of course, we could also use a separate web page for the content - eg.:
... and we could even have, on the same page, a list of current stories, which we find the contents for by index, inserting the appropriate elements in a loop.
The other handy thing is, once you have the text separated out, it's easy to define a text-flow. All you do is use the same content src in subsequent elements, and the browser should be able to layout the text between the blocks, making multi-column layouts a breeze.
Content Map Semantics
Content maps start getting important in other ways once you start considering the semantic web. For example, with our story above, you can easily produce a view of the site for blind people. Throw in a layer that lets you transform the content map, and you end up with a way to build a wiki and format it however you want.
You even get downlevel support for free. Want a simple version of the site that works on mobile devices? Strip out all the flashy stuff, and create a simple template which handles it.
A few Notes
Look, I'm not saying that this system as laid out is perfect. It's not fully fleshed out for a start, and would require a few months of hard thinking by a talented team to get there. But it's certainly a lot better than the blind alley we've ended up going down with HTML. Let's fix it. Soon.
Oh, and as far as the spec goes: The spec should be LAW. It should be reviewed by all implementors, and refined until there is no room for misinterpretation. Too many things are left to chance in the current specs.
One more thing: The W3C? Useless at this point. They're working way too slow to be of help to anyone, and they insist on carrying on down the horrible path they're on instead of fixing what's busted.
Simon Cooke is an occasional video game developer, ex-freelance journalist, screenwriter, film-maker, musician, and software engineer in Seattle, WA.
The views posted on this blog are his and his alone, and have no relation to anything he's working on, his employer, or anything else and are not an official statement of any kind by them (and barely even one by him most of the time).