It looks like CSS3 will have some pretty cool new attributes available for us developers.  Of course, it’s all proposed and not released yet, but let’s start salivating anyway:

One really cool thing with the potential for hilarious abuse of power is a proposed scale attribute.  Use your own imagination on that one.

But that’s not the best.  The best (if truly implemented) would be a set of CSS specs for creating a multicolumn layout without having to resort to javascript trickery, fakey background images, or ridiculous amounts of div nesting.  Great news, everyone!

Found on these sixrevisions posts.

By this time, I’ve worked my head around the idea that, to many developers (and clients) out there, CSS is the one true way and tables are only good for displaying data – that is, data that they consider data and not data that someone else might consider data.  See my previous post on semantic html for more carping on this topic.  But enough negativity – I would hereby like to add my voice to the growing number of developers calling for a new future in CSS: [paraphrase] “If CSS is the golden chalice of front-end web development, how come it can interpret between pixels, point sizes, and em sizes, but it can’t add 1 + 1?”

Now, I know, purists will say that Javascript is for math, and CSS is for styling.  Just simply get a good Javascript library and do your math there.  The problem is that other purists will say that using Javascript to generate your CSS positions is pure hackery.  And yet other purists will say “everyone come to my website to check out my awesome CSS hacks!”

Let’s face up to it: there are some things that CSS is just not that good at.  The idea that you are ruining your SEO by adding three lines of table code to get your column heights equalized seems dubious.  But, I’m willing to go with that and check out some truly weird and wonderful tricks to arrive at the same solution that would take literally half a dozen lines of code using old clunky tables.  But yeah, I’m sure google’s robots are completely fooled by a table and a couple of <tr> tags… [sarcsasm alert].

Anyway, if CSS is going to be responsible for our layout and can have access to and control some of the DOM, why can’t we just do:

#layerid {
width:20%;
margin:10px auto;
height:width * 0.5;
}

That would really open things up and allow for some more creative, interactive layouts.  Hopefully, CSS 4 will allow for some of this.  It should be, in my opinion, a no-brainer.

The real dream has been that one day, HTML and XML would be combined (not just in terms of the XHTML standard), and that the web would turn into a big soup of meta information.  This would allow all sorts of wonderfully customizable content, searching, cross-threading, and possibly, someday, even help create some kind of internet based solely on context, rather than infrastructure and IP.  Positives: super-personalized web-browsing, advertisements, and content aggregation.  Negatives: super-personalized web-browsing, advertisements, and content aggregation.

But I digress.  The flock to div tags as cleaner and more semantically meaningful has been a beneficial one, but for we web developers who remember the [good?] [bad?] old days, there are more than a few cases in memory of the development community rushing en masse to the next greatest thing, and then flipping it into reverse with the release of the next IE browser / web standard / greatest thing.

It has gotten to the point where I have seen postings looking for people who write div- and css-based code – no tables allowed!

This is madness.  What is XML, after all, than a method of organizing data?  When you’re getting an XML feed from a backend, you are converting your data from a table-based format (database) to a markup-based format.  Same data (we hope).  The real question here is page layout.  Surely web developers who are using and editing one another’s code would rather see:

<div id=”header”><!– header –></div>

than

<table border=”0″ class=”table” cellpadding=”0″ cellspacing=”0″>
<tr>
<th><!– header –></th>
<tr>
etc.

But while that div is nice and neat and it allows for better accessibility, it does not do as well when it comes time for, let’s say:

this.

Also, despite the wonderful blessing that is CSS (it can be quite soothing), when something goes wrong with the style sheet, the result can be disastrous.  Of course, we all want to write code that degrades gracefully, but the fact is that, the more we ask of our code – especially as we utilize style sheets – the more risk we run that if something breaks on the backend (certainly our code would never break), or a user is tied to a hopelessly outdated browser, the result will be unintelligible.

But back to semantics, for their own sake.  Perhaps it comes down to a particular aesthetic, but the notion of a fully semantic web makes me think of those kitschy items that have the word for the item printed on them, for example a mug that says “MUG”.  Maybe there is a bit too much big-picture here, for a change.  Net neutrality’s goal is access and publishing rights for anyone with an internet connection.   It’s not hard to imagine a semantic web that wants to take choices out of our hands and push certain content in front of our eyeballs for us.

As for us developers, if the goal is good, solid code, the answer seems to be, like with much else, a healthy mix of new and old, with an eye towards every tool and its best use.