I love this post of Dustin’s about how Google uses a shortened version of the DOCTYPE string to save bytes, even though it makes a validator say their pages are invalid. I don't personally get too worried about a few bytes, but that's a Very Big Deal™ to Google, and this is a perfect example of what I mean by "use web standards and best practices when they make sense, and don't when they don't." Here, they've found a better solution for them than the understood "best practice." That's awesome. Visit site »
Eric’s got some great thoughts on how we can use JavaScript to get some of the CSS functionality we’d like to see. Some of it is a little bit pie in the sky and maybe not completely practical (for example, I don’t believe Gecko makes unrecognized CSS properties accessible from JavaScript) but the general concept is great. It’s all about getting shit done in an elegant way, rather than putting all the focus on doing things exactly how the standards would suggest — and you know I like that. Visit site »
A nice interview with Emily Lewis, who I first met a year ago in Dallas and re-connected with in Atlanta a few weeks ago. She’s a passionate and talented web standards advocate with a lot to say. I like people with a lot to say. Check her out on Twitter, too. Visit site »
More great thoughts on markup and CSS coding practices, this time from my homey J.B., who I am (apparently) doing a world tour with this month. Visit site »
Good stuff by Andy Clarke. I would suggest if you can’t live with these browser differences, you’re not really understanding the way modern CSS is supposed to work. Visit site »
A really nice article by Molly Holzschlag clearly articulates the three groups that are independently defining web standards these days, outlining the pros and cons of each. The big question, of course, is, “which group should we follow into the future of the web?” The clear answer is “none,” as they all have deal-breaking cons. I really wish I had time to worry about the future of the web. Sadly, I don’t, so I’m left to just deal with today, and that basically means implementing whatever parts of specs work in the browsers that matter to users, and doing so in the most elegant, backwards-and-future compatible way possible (but always recognizing that given a choice between now and the future, now wins every time). Good read. Nicely done, Molly. Visit site »
As well it should. Good luck with the new direction, ALA team! Visit site »
A really smart post on the “unsemantic” nature of CSS frameworks that deal with layout, by Darren Jones, who created the Sparkl framework. The best line in the article is this:
Remember [layout class names] don’t add any semantic value, but your page doesn’t lose any semantics by having them either.
This is the point I wish people would remember. Class names aren’t actual semantics, they’re fake semantics. They’re just a way for you to add some useful hooks for scripts and styles to hang on (and possibly for other people to mash with, in the case of something like microformats). Validators, screen readers, browsers, and the like couldn’t give one iota of a damn what your class names are. Likewise, is it really worth getting bent out of shape about too many div and span elements? Remember, these elements were specifically designed to have no meaning. It doesn’t matter if there is one div or five hundred, the net gain is no meaning.
Sure, it makes sense to use less presentational class names whenever you can and to only use as many divs as you need to, but if the aesthetics of your fake semantics and counting div elements starts to overtake getting your design just right, on time and under budget, then I'd say your priorities are out of whack. Visit site »
WHATWG offers a clarification about the 2022 “final” date for HTML 5:
There has been a certain amount of controversy over the supposed date of 2022 for HTML 5 to be “finished”. It is somewhat important to realise the significance that should be attached to this date: None at all.
This, of course, begs the question, “then why mention it at all?” Who knows, but I’ve certainly been guilty of mentioning things I later wished I wouldn’t have, so I’ll give them a pass. Beyond that, this goes to show that it’s all exactly as I thought: HTML5 will indeed by “final” in 2022, but it’s really only browser support that matters to us web designers and developers. Bits and pieces of HTML5 are already showing up in browsers and more should be showing up over the next few years, so get out there and use them! Stop reading specs and fussing over dates and build some fucking web pages already. Visit site »
Holy fuck. And we wonder why it’s hard to get people to take web standards seriously. The joke we’ve all been making for years just became a reality: HTML 5 will be finished in 2022. Wow. I didn’t even bother reading the rest of the interview. What’s the point? I officially no longer care about web standards. Visit site »
Handy bits by Simon Willison to make Django work a little cleaner when using forms with an HTML doctype (instead of XHTML). Personally, I think Django should default to HTML, but I bet this matter was argued ad nasuem in some Google Groups thread a year ago and XHTML won out (almost certainly at the chagrin of James Bennett). Am I right? Am I? :) Visit site »
Again from Jeremy’s great live blogging of An Event Apart San Francisco, here’s Eric on CSS frameworks. I’m glad to see someone else broaching this topic, and in general it looks like Eric did a great job of rounding ‘em up. A few bits and responses:
If you’re going to use a framework, it should be yours; one that you’ve created. You can look at existing frameworks for ideas and hack at it. But the professionals in this room are not well served by picking up a framework and using it as-is.
Generally speaking, I agree. I have made great use of Blueprint — but it’s worth nothing that almost all of the basic concepts were created by me (along with Nathan and Christian). As Blueprint has progressed, it’s gotten farther and farther away from what we created, and I’ve been less enthralled by it. The point is: something you created yourself is always going to be more useful to you than something you didn’t.
Four of them use psuedo-namespaced class names beginning with grid- or container- or span- (which you would apply to a div!?).
I’m not sure if the parenthetical is Jeremy or Eric speaking, but this is also worth noting: in the original CSS framework Nathan, Christian, and I created, you were not necessarily supposed to apply those classes to a div. The classes were for any element, and there was no encouragement to liter your markup with extraneous div elements. The original Blueprint retained this philosophy, but later changed it, asking people to always use div elements as columns. I find this to be incredibly wrong, and I always override this Blueprint functionality when I use the framework. If you are going to use a div for every layout column/row/unit/whatever, you may as well just use tables. I hope everyone knows and understands that when I was touting Blueprint, it was before the made the boneheaded decision to require the use of a div element for every column. Visit site »
Alex smashes all the silly arguments CSS spec editor Bert Bos tried to use against the concept of CSS “variables” (really constants). I’m sorry, but anyone who thinks CSS variables are a bad idea just isn’t living in the real world of web development these days. Go Alex! Visit site »
Bert is, of course, referring to symbolic constants, which many people seem to want to call “variables,” even though they’re really not. Anyway, he contends that the idea of constants in CSS is flawed, in large part because added complexity makes CSS more difficult to learn. I think this is kind of absurd. CSS is easy to learn. Really easy, in fact (I’ve said for years that the only hard part of HTML and CSS is browser bugs. Take browser bugs out of the equation, and CSS is child’s play). If symbolic constants are really so complicated that non-programers can’t grasp them (which they’re not), then they simply don’t have to use them.
But even more importantly than that: why is keeping CSS easy to learn so damned important? The only people that need to know CSS are web developers. This notion of keeping it simple so “regular people” can read and understand it is silly. Doctors, lawyers, and pharmacists don’t keep their specs and documentation simple so regular people can understand it, because regular people don’t need to understand it. Why does the W3 seem to place such an emphasis on making CSS palatable to everyone? Visit site »
Kenny suggests that “developing with web standards is now a standard,” and that we all need to stop focusing on getting people to write standards-compliant code and start focusing on getting the browser makers to give us the new shiny and the W3C to finish some of it’s long-proposed specs. I agree completely. Visit site »
Suddenly it seems like respected web designers everywhere are starting to catch on to what I’ve been saying for a couple years now: established standards and best practices are great, but they are simply a means to an end, and we should always challenge them in cases where it seems like a different means to the same end might be more effective. “Perfect” can be, at times, the enemy of “good”.
I don’t necessarily agree with everything in Martin’s article, but I’m glad to see other big names beginning to jump on the pragmatic, but still standards-oriented, approach. Visit site »
nGen Works is unquestionably one of the best bunch of guys I’ve met in this industry, and they’re looking for a great production person to join their team. If you’re a great HTML/CSS/JS person, you definitely want to check out this job. nGen is based in Jacksonville, FL, but the job description says, “relocation optional.” Visit site »
Safari is probably the most reliable browser out there when it comes to rendering things as a standards-aware developer would expect, but there are those rare times when you need to target it specifically with some unique rules. For those cases, this article will point you in the right direction. Visit site »