-
Standardizing Incompatibilities
Chris Eppstein says it’s time for something like Sass to be built into browsers. I sort of go back and forth on whether or not I agree. What do you think?
Visit site... -
On the term “HTML5”
Yesterday, Jeffrey Zeldman linked up a very cool project entitled html5test.com. It’s very well-done, and incredibly useful. You should check it out.
Today, the always-insightful Tantek Çelik responded to Jeffrey’s post, accurately noting that many of the items the so-called “HTML5 Test” was checking are not actually part of the HTML5 specification at all (for example, Microdata, Geolocation, and more.) Tantek goes on to say, “We as a community that is learning/relearning/teaching all this stuff need to vigilantly clarify what’s what rather than calling things “HTML5? that are not actually HTML5.”
I say: Why?
Continue reading... -
HTML5 Readiness
Very cool CSS-powered infographic by Paul Irish and Divya Manian.
Visit site... -
Ben Ward: Understand The Web
A pretty great piece by Ben Ward discussing “web apps,” and how much of what is being talked about aren’t really “web apps” at all, because they’re a very different beast than the “interconnected bits of information” that make up the web. I think it’s fair to say that “web app” may not be the best name for these things — although I’m not sure what to call them, instead. I’m in full agreement with most of what Ben says — but this last line just doesn’t fly with me: “The idea of undermining the core function of the web to achieve that is detestable.” I fail to see how building native-like apps using web technologies “undermines the core function of the web” at all. To me, it simply adds another function. Just as Cocoa apps aren’t part of the web, but rather tangential to it, I would say native-like apps that live in the web are also not part of the web, but tangential to it. They sit alongside it, not hurting the web one bit.
Visit site... -
Nicole Sullivan: CSS Wish List
Nicole continues to flesh out her ideas on how CSS ought to work. Aside from a few syntax gripes, I’d love to see this stuff in CSS — but I don’t think it’ll ever happen. It’s really unfortunate that the working group isn’t interested in hearing feedback like this. In the meantime, there’s always SASS or Less.
Visit site... -
QuirksBlog: There is no WebKit on Mobile
PPK details the myth that is the idea that “WebKit on mobile is taking over.” His point, which is totally valid, is that while WebKit is indeed becoming the dominant rendering engine on mobile platforms, each of those platforms has distinctly different versions of WebKit, so the idea that if you build for WebKit, all of these devices will render your site the exact same way is a misconception. His point is well taken, if a bit dramatic. It’s true that there are subtle differences between each version, and it’s also true that most people don’t realize this. But, in the real-world, they’re “close enough” that targeting WebKit will generally get you a very similar experience on all these platforms.
Visit site... -
James Bennett: In pace requiescat
Another thoughtful piece of the demise of XHTML2.
Visit site... -
Jeremy Keith: Misunderstanding markup
Easily the best overview I’ve seen of XHTML, XHTML2, HTML5, and the related concerns for your typical standards-oriented front-end web developer. Bottom line: the death of XHTML2 and the move to HTML5 does not mean you lose all the things you love about XHTML 1 and 1.1. Relax, folks. It’ll be okay. :)
Visit site... -
Introducing Typekit
Jeff Veen, who I have mad, mad respect and admiration for, announces his company’s new project: TypeKit. It’s basically a hosted solution for web fonts, wherein Jeff and team negotiate a license with font foundries, and then you (the average web developer) pay Jeff and team a fee in order to use the fonts. It will use standards CSS @font-face embedding, and automatically switch out Opentype for EOT based on a user’s browser. This all sounds great, but the post is a bit short on details, and I definitely have questions: will it scale? How much will it cost? What will the license look like? All concerns people have over a subscription-based music service versus the iTunes model apply, here. What happens when you unsubscribe? Are the plans per-site or per-designer? And so forth. So, bottom line: sounds like there’s a lot of potential, here, but I’ll save my fanboyish excitement for when I have more information.
Visit site... -
Jeffrey Zeldman: Web Standards Test: Top 100 Sites
I still have a hard time seeing any good reason to ever validate someone else’s code, but I guess maybe research for a book is one. Still, I don’t understand the point of posting the results here. Jeffrey says himself, “If all the home pages of the top 100 sites were valid, it would not mean that the pages beneath the home page level were valid, nor would it prove that the sites were authored semantically,” and “nothing causal or predictive can be determined from these results.” I agree with him, and that begs the question: then why post it at all? Because I know enough about Zeldman himself, I am guessing the answer is simply, “I thought it was interesting,” but I’m afraid it feels like the point is simply to publicly praise some and berate others.
Visit site... -
42 Web Design Companies
Hits most of the HTML/CSS/Javascript-focused ones I’d seriously consider.
Visit site... -
Fluid 960 Grid System
A really complete and nice-looking CSS framework that satisfies one common complaint about many CSS framework: lack of fluid-width support (I personally usually go fixed-width, but I know this is an issue for a lot of people). By Stephen Bau](http://www.domain7.com/WhoWeAre/StephenBau.html). Good stuff!
Visit site... -
The Skinny on Doctypes
I love this post of Dustin’s about how Google uses a shortened version of the
Visit site...DOCTYPEstring 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. -
Eric Meyers: JavaScript Will Save Us All
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... -
Designer In The Spotlight: Emily Lewis
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... -
When can we stop talking about “supporting” certain browsers?
Even at a progressive, Web Standards-friendly agency like Blue Flavor, the topic of which browsers to “support” comes up. Clients ask us, “Will our site be supported by IE6?,” for example. And even in the Web Standards community, there’s still a lot of talk about “dropping support” for IE6, and the like.
But doesn’t this whole idea of browser “support” kind of go against what Web Standards is all about in the first place? Because of the way we build sites (and by we, I mean me, Blue Flavor, and most readers of this site), our projects inherently “support” every browser, from Lynx to Mosaic 1.0 to Netscape to IE to Safari to the no-name browser on your crappy flip phone.
And yet, we still talk about browser “support.” What we really mean when we ask if a site will “support,” say, IE6, is “will the site look the same in IE6 as it does in the latest and greatest browser?” But we all know this is a silly question. Of course it won’t. And what’s more, it shouldn’t.
Continue reading... -
Jina Bolton: Make it modular
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... -
Five CSS design browser differences I can live with
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... -
Web Standards 2008: Three Circles of Hell
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... -
A List Apart is changing
As well it should. Good luck with the new direction, ALA team!
Visit site... -
Darren Jones: Don’t Sweat the Unsemantic Stuff
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
divandspanelements? Remember, these elements were specifically designed to have no meaning. It doesn’t matter if there is onedivor 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
Visit site...divsas you need to, but if the aesthetics of your fake semantics and countingdivelements starts to overtake getting your design just right, on time and under budget, then I’d say your priorities are out of whack. -
The WHATWG Blog: 2022
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... -
Two thousand twenty two
Today, it was brought to my attention that HTML 5 Editor Ian Hickson, in an August 27 interview with TechRepublic outlined a timetable for the “new” spec, which began life back in 2003. Hixie suggests HTML 5 will reach the “Proposed Recommendation” stage sometime in 2022. Go ahead, read it again. It’s not a typo. Two thousand twenty two.
I immediately stopped reading. Didn’t even bother with the rest of the interview. Why? Because it just doesn’t matter. The whole concept of web standards, which I once strongly advocated for, has now become so incredibly ridiculous as to be not even worth the time and attention of serious web designers and developers.
As I pointed out on Twitter today (much to the dismay of certain standardistas, who have previously asked me to name names instead of referring to a “shadowy cabal”): it ultimately doesn’t matter if HTML 5 is available next month, next year, or fifty years from now. Those of us who do real work in this industry know that the only thing that really matters is what specs and technologies are supported by the browsers real people use.
Continue reading... -
HTML5 to be “done” in 2022. This is not a joke.
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... -
django-html
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... -
Eric Meyer: The Lessons of CSS Frameworks
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
Visit site...div. The classes were for any element, and there was no encouragement to liter your markup with extraneousdivelements. The original Blueprint retained this philosophy, but later changed it, asking people to always usedivelements 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 adivfor 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 adivelement for every column. -
Alex Russell: CSS Variables Are The Future
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 Bos of the W3: Why “variables” in CSS are harmful
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 at Blue Flavor: Time for a Web-Forward Movement
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... -
Digital Web: Smart CSS Ain’t Always Sexy CSS
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 looking for a Web Standards Ninja
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... -
Targeting Safari with CSS
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... -
Boagworld interview
The wonderful Paul Boag from Headscape interviewed me for the latest episode of Boagworld, almost certainly the best web design podcast on the planet. We talk about my “controversial” views on web standards, Blueprint CSS, and more.
Unfortunately, I hate my voice, and it sounds even worse when propped up against Paul’s sexy British accent. Oh well — I think it came off pretty decent, anyhow.
Continue reading... -
WebKit now support CSS Masks
Oh man, this looks sweet. I’ll say it again: the WebKit team is totally doing the right thing here by continuing to innovate with these new features. Dear WebKit: web designers everywhere thank you!
Visit site... -
A List Apart: Issue 256 (The EveryBlock One)
EveryBlock takes over A List Apart for an issue, with Wilson Miner’s awesome piece on using web standards to create data visualizations like bar charts and sparklines, and Paul Smith showing you how to roll your own custom mapping interface. Great issue.
Visit site... -
Why the webstandards world appears to be choosing Django
I’m not entirely convinced that Django’s recent popularity has much to do with web standards, nor am I that convinced that Django is “winning” in our community over Rails or other modern frameworks — but, it’s true that Django allows those of us who value web standards to do our thing quite easily, and it’s good to hear that people are noticing that.
Visit site... -
Microsoft changes stance on version targeting default behavior
> “We’ve decided that IE8 will, by default, interpret web content in the most standards compliant way it can.”
So there you have it. This should make a lot of standards-oriented developers happy, as it makes out jobs easier. I think this is the right move by Microsoft, although I never could quite figure out very firmly where I stood on the whole topic. At the very least, it prove MS is listening to the developers, and that can only be a good thing.
Visit site... -
Your markup validator
Your markup validator, whether it’s the one on the W3C site or one built into your favorite coding tool, is a debugging tool. It should be used as such. Its job is to find errors in your code, so that you can fix them (or at least be aware of them).
Your markup validator, whether it’s the one on the W3C site or one built into your favorite coding tool, is not a measuring stick for greatness. It’s not to be used on other people’s code for the purpose of pointing out their shortcomings as a markup coder so that you can make yourself feel better than them. The fact that your code passes a validator does not make it better than the next guy’s code. There is almost never a good reason for you to be validating someone else’s code. Usually, if you’re validating someone else’s code, it’s because you’re being an asshole.
Continue reading... -
The B-List: X-No-Thanks
For anyone trying to make sense out of the whole IE8
X-UA-Compatiblenonsense, James Bennet’s explanation is almost certainly the most well-thought out and easy-to-understand one you’re going to find. I now have an opinion on this matter. I’m with James: X-No-Thanks.But even though I have an opinion, it’s not a very strong one. Why? Because, quite frankly, I’m just not that interested. If
X-UA-Compatiblelands in IE8, I’ll suck it up and spend 20 minutes putting the tag in all my sites, toss a few more curse words Microsoft’s way, and move the fuck on. Ultimately, for those of us doing standards-based work, this isn’t that big a deal. If we’re doing things right, and this actually happens, it means we have to put one measly meta tag in our code form now on. Big f’ing deal.Here’s hoping it doesn’t ever happen, though.
Visit site... -
Web standards 2007: pragmatists versus purists
Today, I finally got around to reading the brouhaha over IE 8 and it’s version-targeting system. The last blog entry I read was Jeffrey Zeldman’s In defense of version targeting, a response to Jeremy Keith’s Broken — and I started to write a lengthy comment. At some point, I realized the comment would make a better post here at JeffCroft.com. So, what follows is the piece that began life as a comment over at Zeldman.com.
This whole debate echoes what, at least to me, was the primary topic of discussion in the Web standards world in 2007: pragmatism versus purism. After the war for Web standards was effectively won, the community started turning on itself, debating the pedantics of perfection versus good enough in the “real world”.
Continue reading...