In the past couple days far more eloquent people have spoken about the current srcset “fiasco” with calmer voices, analyzing the situation with a maturity and fairness that frequently escapes my grasp when I’m hastily penning a post and drawing a comic.

If you haven’t read them already, I would ask that you take some time to read Jeremy Keith’s Secret Src and Jeffrey Zeldman’s The Unbearable Lightness of HTML5. I don’t think either pretends to be a neutral moderator in this debate between the WHATWG’s methodology as practiced versus the appeal of angry developers for the “users before authors before implementers” priority that the WHATWG preaches. But at the same time they clearly make an effort to understand the motivations of Ian Hickson and the browser makers, mention the merit of their position where it exists, and treat their intentions with some reasonable charity.

They also do a good job of explaining a complex situation in comprehensible, non-combative terms.

I personally don’t do well with the sensations of helplessness and the apparent disregard that Hixie and the browser makers seem to show towards developers by the WHATWG’s process. I don’t believe that ends justify means, and I personally believe that something as central to my career (and to something quite central to the Internet’s functionality) as HTML deserves stewards that are trustworthy and fair.

Idealistic, I know.

Middle Child

We, the developers, are the middle child of this whole standardization process. Unlike the users, who could care less about HOW a website works as long as it works, or the browser makers who have the power to decide how to implement the features of the Internet to meet their corporate goals and to fill their coffers, we developers (authors) are answerable to the ability of users about what they want (or need) in a website but have no power to guarantee that the browsers meet our needs as creators.

As antagonistic as our relationship can sometimes be with users, the fact is that we know we have to answer to them. If a site doesn’t meet their needs, they move on. They have that choice, that freedom to type in a new URL and get their news/lolcats/gossip/pictures from somewhere else. There are literally billions of web pages, and thousands if not hundreds of thousands of developers willing to replace us and to feed the users’ wants and needs.

When it comes to our needs and wants, however, we have a very limited set of vendors to turn towards. Although there are plenty of browsers in the sea, ultimately there is only a precious few that gobble up the majority of users. And although users get to pick what websites they visit, we don’t get to pick what browsers to work with. (Well, we can, and some do, but ultimately we have to go where the users are or we starve). And when it comes to our needs and wants, the browser makers know we have to deal with them. We’re making sites to work on their programs, and with that necessity means we start the lose the ability to be picky. They’ll make what they want, and we have to deal.

The Priority

The balm that is supposed to take the sting out of this awkward situation is the priority of constituencies that we allegedly follow when web standards are created. Users come first, as it’s their consumption of the web in the first place that provides any of us with a job. Informed by their desires and needs, we authors (developers) are then next in the food chain. We take their needs and wants and use that as the impetus to create apps and sites. If we ignore their needs, our work fails, creating a simple reinforcement of our service to them. Ostensibly, the next step is that the implementers (browser makers) then in turn serve us. We inform them of the features and techniques we need them to build their browsers for in order to make our jobs easier and then to get the users to visit our sites (on their browsers).

As good as this situation sounds on paper, in reality it’s something different in practice. The WHATWG never stops in reminding us that if the browser implementers don’t want to add a specific feature, there’s no way to compel them. Therefore, whenever a conflict of interest appears between a developer-crafted solution or a browser maker-crafted solution to a given use case, the browser maker’s option is chosen first by the WHATWG. Frequently it happens with far less scrutiny or careful examination.

It’s this exact sort of situation that has resulted in this week’s general outbreak of developer rage (mine included).

Ends and Means

I might be willing to consider an implementer first ideology (unlikely, admittedly, but it’s possible) if everyone involved was behaving in a fashion that appeared ethical and respectable. But this recent situation is one of many that shows that lack of respect at the minimum, and frequently a lack of ethical behavior as well (I’ll attempt to explain why I’m making this sort of claim further on).

Unlike big corporations, who exist to make a profit and historically do so at the expense of the common man, and justify their actions by the end result of “make more monies”, I don’t believe that the ends can, or should, justify the means by which those ends are achieved.

Everyone involved: Hixie, the WHATWG, browser makers, developers; all of us want a usable HTML standard that lets us make better websites/apps. That’s the end. I’m willing to say that’s a noble end that everyone wants. But where things break down are the means. And that’s where my charity in tolerating their methodology fails, causes me to start ranting and agitating the community for extreme responses.

The New HTML Standard

So we’re in this quagmire now. The people who respect developer input and with a process that is more inclusive reside at the W3C, which maintains the HTML5 Standard that functions as a static snapshot of our unversioned HTML at a given point in time. The person who makes decisions by arbitrary dictatorial fiat with inconsistently applied requirements that favor browser makers over developers is Ian Hickson over at WHATWG, responsible for the HTML Living Standard which the majority of the major browser vendors are using as the basis for their implementations of HTML.

That puts us developers in a very awkward position of petitioning the dictator with the strong likelihood of being ignored and actively mistreated, or collaborating with the inclusive organization that nonetheless doesn’t see nearly as much traction with the browser makers (although I do believe they have an impact I think that it’s a slower one).

What’s a developer to do? Why work at all on the <picture> elements of tomorrow if they’re only going to be ignored for a srcset that sees far less scrutiny before its adoption?

I’ve proposed “occupying” HTML. I’m not naive enough to believe that a purely democratic solution is the best one, and that the optimal solution is the one with the most voices. We need intelligent, scrutinizing people like Hixie to actively doubt the soundness of our proposals. We need input from the browser makers on the feasibility of implementing our solutions on their end, and to hear their views from the experience they have gained by actually building browsers.

In short, sometimes we need the WHATWG. Besides, it won’t go away just because we wish it to do so.

So I’m going to cool my rhetoric just a bit and make a proposal of a new HTML standard that all of us, browser makers and developers, standard organizations and bloggers, can all agree on and benefit from.

Don’t worry, this standard doesn’t require too complex of a specification document. In fact, I’m going to lay it out here and now.

The New HTML Standard:

1. (H)onesty

I might also term this one as “Integrity”. My major objection with the current srcset situation is that the “communication process”, as some have deemed it, has shown another instance of what I believe is a pattern of dishonest behavior on the part of the WHATWG, through omission at the least if not through direct fabrication.

Part of Tim’s WTFWG post focused around a situation where the developer group responsible for developing the <picture> proposal were (they thought) instructed to create a Community Group to develop the proposal as part of the WHATWG process. As Jeremy Keith later outlined in his Secret Src post (linked at the start of this article), that was in fact not the case. The person proposing the Community Group was not representing the WHATWG, and a CG isn’t part of any WHATWG process.

Ian and friends get a pass, then, on actively misdirecting the developers into this particular fruitless cul-de-sac of labor. But what I wonder at, and believe is a big part of this “communication issue” of theirs, is that Ian and the others in the WHATWG saw this community group be built and go about its business, yet never spoke a word to correct their misinformation.

In short, they knowingly allowed them to occupy themselves on a pointless endeavor without raising their voice to correct false information.

To me, I see only a modest amount of distinction between permitting this charade to go on and actively lying to the group themselves. If one man knows a vial is poison, and chooses to say nothing but smile and watch as a bystander is told by the person next to him that the poison is delicious punch, and then drinks that poison, are they not culpable?

Trust between developers and browser makers is at an all time low. We’re wasting energy and time fighting each other because we no longer can trust the motivations or process of the WHATWG and the browser makers due to actions (or inaction) exactly like this.

We need to be more honest. We need to act with integrity. This constant smoke and mirrors approach to distracting developers while the browser makers go behind their backs isn’t an acceptable way for adults to behave. If we believe we’re being approached honestly, and dealt with honestly, then we’re far more likely to be sympathetic to browser makers and their own counter-proposals.

2. (T)eamwork

I don’t believe a democracy will build HTML.

At the same time, ignoring the merit of collaboration for the sake of a standard built by dictatorial fiat is is a foolish, shortsighted measure that can only be summarized as egotistical. No matter how intelligent and hard-working Ian Hickson is (and I do believe he is both), he can’t see a given problem from all angles by himself, nor replicate the output of a dozen or a hundred developers working in concert towards a goal.

Whether or not Standards are a place that egos reside, they certainly shouldn’t be.

Perhaps HTML needs a sole gatekeeper. I don’t believe it does, but I’ll admit that the possibility exists. That doesn’t mean that HTML development doesn’t need cooperation among several (preferably many) individuals each bringing their own intellect, experience and creativity to solve problems.

Bear in mind that “experience” part. Ultimately some of HTML5′s greatest battles have been over issues like accessibility, a topic that Ian has little to no formal experience or body of knowledge about. Yet despite this he is infamous in the accessibility community for his pattern of making choices that directly impact the accessibility features of the language based on his own judgement and seemingly arbitrary solutions at the expense of decades of experience in the subject by dedicated, educated professionals who deal with accessibility challenges every day.

How does that make sense? How does that make for a better HTML standard?

Outside of accessibility, look at the recent adaptive image issue. There are merits and flaws to both <picture> and srcset. Yet when it comes to usability, the former is far more capable of being learned, adopted, and easily used in the day to day workflow of developers than the latter. Even Jeremy Keith, who is far more knowledgeable about HTML today than I will ever be, has a hard time understanding exactly how srcset works, and has very real, very legitimate concerns about how it will fit the methodologies developers currently have with dealing with responsive designs (such as how it doesn’t appear to play well with em- or percentage-based layouts).

This doesn’t mean that srcset couldn’t win out in the end as the better option with some further modification. And despite overall developer rage, there are people like Keith who are motivated to help improve proposals like srcset even if it wasn’t their first pick. But they didn’t get that chance to robustly shake out the bugs before it was adopted into the spec with none of the hoop-jumping that <picture> and other community proposals have been subjected towards.

There’s are many developers that want to help HTML become the best it can be. Let them actually, genuinely help. Don’t callously disregard their efforts while blindly accepting browser maker proposals that have seen less vetting and testing.

Take advantage of the team!

3. (M)odesty

It’s very evident that Ian Hickson is not a humble man. He has consistently engaged in a pattern of adding features to HTML that he has self-designed instead of using ones developed by communities of experienced professionals who know far more about the given use cases, challenges and situations involving the problems his solutions are allegedly addressing.

See anything involving HTML and accessibility as proof of this. Or consider the debacle that was centered around <time>.

Asking Ian Hickson to be humble is probably akin to asking a lion to become a vegetarian. But when it comes to something as vital to the central communication medium of the 21st century, it rapidly becomes clear that there’s no room for one single man’s opinion to be the dominating factor.

I understand that we owe WHATWG in general and Ian Hickson in particular a lot of thanks for the existence of HTML5 at all. When the W3C permanently stalled on moving the standard forward, it was the WHATWG’s methods that helped get the ball rolling again. But as vital as that start was, the methods that fueled it aren’t appropriate, nor desirable, for maintaining the standard now that it’s in motion.

There’s a lot riding on HTML standards being decided today, as they will be in use for quite some time to come. When we consider the large scale impacts that flawed accessibility implementations can cause, we need to stop valuing our own egos over the wisdom of experienced teams that can help ensure that the standard that ends up being crafted actually meets the need of the users.

Who are, again, of higher priority than us anyhow.

This should apply to the browser makers themselves as well.

Google and Apple and Opera make browsers. They work on making browsers every day. I’m not questioning that, nor am I suggesting that I know their job better than they do. I can say in all modesty that I cannot replicate their efforts.

But when it comes to making websites, they cannot hold a candle to the flame that is the experience of us developer dogs that are in the trenches every damn day. Websites are our bread and butter. Websites are the source of our paycheck.

I put meat on the table with websites. Do you understand me, son?

So no matter how much experience they have in making browsers, when a large and experienced team of professional developers designs a solution to a problem that represents a common use case that we have to deal with, the browser makers need to get a little more modest and actually listen to us.

I’m just saying that I’m sure browser makers really thought <blink> and <marquee> were good ideas at the time.

We know our job, guys. Just lend us your ears and let down your walls of ego. Even if you decide not to adopt proposals we make (for browser-related reasons that we don’t understand) you just might learn enough of our problems to modify your own solutions to better fit our needs.

4. (L)iability

By which I mean accountability.

I’m accountable to the users (and of course, my clients). Every day they (hopefully) use the websites I make. It doesn’t matter how I code a site, or what my personal preferences on feature selections are. If they can’t use the site, if they can’t use the site, then I’m doing a disservice to my clients and frustrating the users.

I don’t like flash video players. I prefer <video>. But I also know that at present sometimes I need to make use of the former for certain use cases, and use the best tool for the job to meet the user’s needs.

By the same token, the browser makers are accountable to us. I don’t care how hot, fast, and feature-rich your browser is. If I don’t have a good way to take those features and add the implementation of them to my work flow, they’re not going to end up in the final product and the users will never see them in my websites.

Srcset may be a good tool. But it’s not presently one that seems very easy for me to grok, or use. I’m furthermore worried about how to adopt it into a percentage-based responsive design. <picture>, by contrast, is easier to use, easier to understand, and for the most part it does what I want it to do (and more importantly behaves the way I expect it to behave). It uses syntax that is familiar to me and lowers the barrier for me to adopt it into my workflow.

The priority of constituencies isn’t supposed to be lip service. It’s a formalized way to express something that is common sense. I need to build sites that fit the needs of users. Browser makers need to build tools that I can actually use.

It’s true that without browser maker buy-in, a feature can be in a standard surrounded by glowing letters and angels and it will still never actually end up in a browser. I get that. But there’s also no point in building solutions that don’t see wide adoption because they’re an awkward fit, don’t fit our use cases, or don’t fit our workflow.

You are ultimately accountable to us, reliant upon our willingness to champion your features and encourage their adoption by our peers in the community.

Am I Being Unreasonable?

I don’t think I am. I’m asking people to be more honest, work together, check their egos at the door and remember that ultimately our livelihoods all come from the bottom up. We developers rely on the users, and in turn the browser makers rely on us.

That’s an HTML Standard that I think we can all agree to. That’s the sort of reactionary activism I’m asking from everyone in the community: developers and browser makers.

Work with us. Communicate with us. Learn from us. Respect us. I guarantee that in return we will treat you in kind.

In his post that I linked at the top of this article, Jeffrey Zeldman said something that I believe is both very humble for admitting his own potential faults, and suggests an experiment for Hixie to consider.

In theory, if we are frustrated with Mr Hickson’s arbitrary dictates or feel that they are wrong, we can take our ideas and our grievances to the W3C, who work on HTML5 in parallel with the WHATWG. We should probably try that, although I tend to think things will continue to work as they do now. The only other way things could change is if Hixie wakes up one morning and decides benevolent dictator is no longer a role he wishes to play. If I were in charge of the future of the web’s markup language, with not just final cut but every cut, I’m not sure I’d have the courage to rethink my role or give some of my power away. But perhaps I underestimate myself. And perhaps Hixie will consider the experiment.

Ian, I’ve said very little about you that is kind. I know that. But if you took Zeldman up on his experiment, and took me up on being part of this HTML Standard I propose, you would prove me utterly wrong about every unkind word I’ve ever spoken.

That’s some crow I would gladly eat.

In a way I should be grateful to Ian “Hixie” Hickson for being an egotistical tyrant. Without his inability to acknowledge that a consensus-driven, well-crafted and usable solution built by a group of well-meaning, hard-working people could actually somehow be better than his own personal opinion, he’s pulled me out of my long-hiatus and back to to the drawing board.

Today’s comic is in fact three comics. No single idea could encompass everything. In all three Hixie gets top billing as the editor-for-life of HTML’s “living spec”. The first comic features Naepalm, chinchilla alter ego of fellow Mindflier Janae Wiedmaier. The second one includes the irreplaceable Justin McDowell. Lastly we see Matt May, Dylan Wilbanks and Ethan Marcotte joining forces with the Squirrel in a bid to take down the HTML king.

(Today’s comics as per usual aren’t meant to imply that the people represented therein endorse my views. I’m saying it outright today because I’m feeling particularly vitriolic and don’t want my words to reflect on them.)

The Situation

For those of you just tuning in, today’s outrage focuses around Hixie’s decision to adopt a problematic, late-arriving, Apple-proposed attribute of the <img> tag into the HTML standard as the solution to the adaptive images issue. In the process he again reinforces his inability to heed the creed of HTML’s priority of constituencies (end users over authors over implementers) while also tossing away the hard work of a community group of developers that built a very functional, very usable solution to that problem in the form of the <picture> element.

If you’d like a summary, you can check out the aptly titled WTFWG by Tim Kadlec, or take a look at Zeldman’s take on the situation over here, which links into an A List Apart article by Mat Marquis on the topic.

I wish this was a new situation. Or that it was surprising. Or that I didn’t feel like I was repeating myself each time I mention Hixie in blog or comic form. The fact is that as the Editor of HTML, Ian keeps doing this. And we keep letting him.

The Puppet

At one point I attributed this issue solely to his gigantic ego and clearly overwhelming case of not invented here syndrome. Now I’m frankly convinced that although these qualities contribute to the problem, the real issue is that he’s the puppet of the browser vendors, namely the three most involved in WHATWG: Apple, Opera, and Google. Although the priority of constituencies dictates that implementers (aka, browser vendors) should be lower priority than developers (who are in turn answerable to end users), it seems that without fail Hixie will bow to the vendors before considering any work on the part of developers at a solution, no matter how reasonable, well-built and documented that solution is.

That’s not a kind accusation, that a man is a puppet. But clearly every attempt to work with the WHATWG has always resulted in developers being treated as second-class citizens to the browser makers. And let’s make it clear: this is our job. We make websites for a living, and the tom-foolery that Ian is engaged in is directly impacting our present and future workflow. We work on making websites every damn day. We know what works for us, and what doesn’t.

And he doesn’t care in the slightest.

“Work With Us”

At this point, Hixie and his backers are relying on the same smoke and mirrors to distract people. Present use cases. Keep engaged with the WHATWG and let them know your technical objections. Get involved in their IRC. But the fact is we as developers have done this over and over and over. Yet at the end of the day, regardless of the hard work put in and all the proof jammed into the pudding, it all amounts to naught. Hixie spends twelve seconds coming up with his own solution or takes what the browser makers gives him and uses that instead.

It happened with metadata. It happened with the <time> element. It’s happening now with responsive images.

The fact is that Ian doesn’t give a shit.

He’s going to do it his way, or failing that he will do what Google and the other browser makers in the WHATWG tell him to do. He’s not going to look at what the developers have built and give that solution a thumbs-up. As John Foliot said: “Dev community, if you continue to author to the WHAT WG doc, you lend your tacit support to heir hixie. Look where that gets you.”

Enough Is Enough

Being part of their process is being part of the problem. I’ve never seen things resolved by following the WHATWG’s “process”, as it amounts to little more than distracting developers while he goes off and implements a less functional, more complex solution to the problem.

Don’t deal with Hixie. Don’t deal with the WHATWG. Directly object to the browser vendors. “Occupy” HTML by making use of the consensus-built techniques that already have functional polyfills. Do what makes sense, and what works for you.Sooner or later, the browser vendors will be tired of the grief sent their way and tell Hixie to roll over.

<time> wasn’t fixed because we followed the WHATWG’s process.

I’m going to say it: I don’t believe that WHATWG is part of the solution anymore. As I’ve been told by others, democracy isn’t always the best approach. Sure, ok. But so far when it comes to the community-build, consensus-driven approach and Hixie’s brain, the community’s solution has proven more effective more often.

I’m going with the community, not the puppet.

• Firstly, there was a great comment thread on my post including voices such as Divya’s. Check it out.
• In particular, you should read John Foliot’s response at the end.
• Jeremy Keith’s Pursuing Semantic Value is a must-read. In it he agrees with Divya’s core message, notes an issue with tone, and guides you through the process of where his agreement with that core message takes him to a very different conclusion.
• Steve Faulkner replies to Jeremy’s article with a comment that grows up to being a full-sized article of its own: HTML5 Semantics and Accessibility.
• Paul Irish, a veritable Chuck Norris of web development, also wrote in response to Jeremy Keith with Semantics in practice and mapping semantic value to its consumers.
• John Foliot responds to Divya in a detailed, no-holds barred post that examines the merit (or lack thereof) of her speaking points about semantics in My Thing About the Thing That Thing Wrote About Thing.

If you have time, you should read all of these. They’re all written by intelligent people getting into the heart of the HTML5 semantics debate with more clarity and detail than I could ever manage.

Divya Manian is a bright cookie. When it comes to the web, you can say with complete assurance that she knows her s***. She’s in that category of people that makes me insanely jealous of their creativity and intelligence.

All of which makes me think that somehow she’s trolling us today.

Our Pointless Pursuit of Semantic Value is a shortsighted piece, placing the value of markup solely upon the capabilities of browsers (and other user agents) today at the expense of tomorrow. It’s the sort of article that I would have perhaps expected from the internal website developer of a large corporation at the turn of the century that only permitted its employees to use Internet Explorer 6.

When I started getting paid to make websites instead of pizza, I was bombarded non-stop by the value of making websites that weren’t locked into the limits of the less-capable browsers of the moment (some of which, like the big blue e, were more than a little antiquated), but was instead encouraged to embrace forward-looking mentality of making the best of emerging features where I could and creating a fallback position where necessary. I can’t remember if we called this graceful degradation or progressive enhancement (I’ve heard the two used and misused so much that they blur in my brain), but nowadays we just call this technique “common sense”.

Did I make special span tags on elements that had rounded corners, placing background graphics on four separate corners so that the Great Blue Mentally Misunderstood Beast of the Internet could have pretty edges? Hell, no! I used border-radius and knew that somehow, someday, all browsers would eventually understand it meant I wanted pretty, round corners to nuzzle up against and whisper sweet nothings to at night.

I’m aware that HTML isn’t CSS, and what applies to one doesn’t necessarily apply to the other. But I’m fairly convinced that if anything, the principle applies even more with HTML today than it did with CSS yesterday. Barring a few legacy browsers that need to ride the HTML5 Shiv/Shim Short Bus, using a div or a header isn’t going to have any impact on a browser’s ability to properly render an element. Which means there’s no harm being done by using a semantic element before user agents get around to taking advantage of its extra meaning.

If I had to summarize Divya’s points in her article (I recommend you read it rather than relying on what’s bound to be a dramatic oversimplification on my part), it is that we shouldn’t bother with semantics because:

1. Semantics Are Hard
2. Current Browsers, Search Engines and Assistive Technology Don’t Understand It, So Don’t Bother
3. Spending As Little as 40 Minutes To Learn About HTML5 Markup Is A Waste Of Time

Semantics Are Hard

Divya points out a piece by Mark Pilgrim on the difficulty of semantics. So, Semantics is hard. So what? Last I checked, I was a professional doing a job for a living. It’s my job to know what part of a website is its navigation or is its primary content. HTML5 isn’t really demanding much brainpower from me on deciding what element to use for what job. I’m fairly confident that the general meanings of header, footer, nav, time, audio, video, progress and summary elements are easy enough to grasp as a person who works with websites for a living. Agreed, article and section are a bit confusing, but I don’t think by and large that HTML5 semantics are a byzantine labyrinth of alien thought impressions that cannibalize the minds of sane men.

Current Browsers, Search Engines and Assistive Technology Don’t Understand It, So Don’t Bother

When I was making a few years back, Internet Explorer didn’t understand border-radius. Yet, despite that, I used it in making websites. And not only does IE now understand (and render) those pretty corners, but many of those websites still exist, using the same code I wrote back then. If I had chosen to not use border-radius because of the limitations of the time, the sites wouldn’t look good today because of my short-sightedness.

HTML5 is still settling down into its patterns. Some of the meanings are still being locked in. It’s not “done”, as evidenced by Hixie’s arbitrary and somewhat bizzare attempt to remove the time element from the spec. Does this mean that I shouldn’t be using elements from the specification because it’s not done now? Of course not! The sites I’m making today will not only be live for years, they very likely won’t see a redesign for much of that lifetime. Relying only on what’s “finished” now would be a disservice to my clients today, preventing them from benefiting from features for years because of a technicality on the spec’s status or the full support level of browsers.

AT, browsers, search engines, they will all catch up with taking meaning from semantics at some point in the future. When they do, would you rather that your website was ready for them, or would you like to spend time (and money) re-coding your mess of divs into something slightly more relevant? There is no harm in using divs now (when other, more semantic elements might be better). But there is a very good chance that it will put your site at a disadvantage later, when the technology catches up.

Saying that I shouldn’t use semantic markup because AT, browsers or search engines aren’t consistently taking advantage of it in the present is like saying that I shouldn’t use video or audio elements because some browsers aren’t taking full advantage of them yet. It’s limiting my future benefits by over-adhering to the present. How many of Divya’s CSS tricks shown at her presentations at conferences work on all current browsers? In all likelihood, none of them. Does that mean they don’t have value, and shouldn’t be used?

How is making use of semantic markup any different?

It’s not.

Spending As Little as 40 Minutes To Learn About HTML5 Markup Is A Waste Of Time

I am shocked that she said this. I’d almost characterize it as insulting. We are professionals in a career that demands continuing education.

At the end of the very same post, Divya suggests that developers learn Javascript. Which is good advice. Learn it. Love it. But how can you advocate the value of self-education while simultaneously characterizing spending forty minutes of your time to familarize yourself with the meaning of some of HTML5′s elements as a waste of time?

Sometimes the choices we make in markup don’t result in manna from heaven. Personally, I don’t attempt to adhere to sensible, semantic markup for the sake of SEO (which I consider a bunch of snake oil bulls*** anyhow) or for accessibility purposes. I do it because there’s an inherent value in attempting to do something in a consistent and correct fashion. There is meaning and purpose in constantly attempting to improve one’s level of craftsmanship.

There is nothing pointless in pursuing good standards, including adding semantic value to your website. Even if there was no future benefit to properly, professionally crafted markup (and there will be), there’s an inherent value in taking pride in your work and producing a product that is more elegant than that of your hurried, slapdash competitor.

There is meaning in striving for meaning.

Or as Karl commented in Divya’s post:

inadf, rjfsnsl nx pjd yt zsijwxyfsi jfhm tymjw. ny’x ymj xthnfq htsywfhy ns gjybjjs tzw nijfx. dtz fwj rncnsl uwthjxxnsl fsi rjfsnsl. vznyj xfi.

Edit: Roughly twenty minutes after I posted this, the W3C took action on the issue, insisting that the <time> element be placed back into the specification. You can read about it here. But please read on. It’s a good primer for the next time something like this happens.

Contrary to what you may have already heard, the <time> element hasn’t disappeared from HTML.

Yes, officially <time> is currently not part of the HTML spec. (Thanks to the muddle that is “HTML Living Specification” I’ll be honest and admit I’m not sure if is no longer part of HTML5 or it’s in some sort of Schrodinger’s Cat quantum-zombie state of existing in HTML5 but missing in the “ongoing HTML” that the WHATWG is proud to keep rolling down the conveyor belt.)

That doesn’t mean it’s not being used by authors (how’s Drupal builds, 2.6 million WordPress installs and the Boston Globe for you?) nor does it mean that is it not being used by user agents (ever-plucky Opera supports it).

What it means is that a single human being has decided that he doesn’t care for time one wit, and that a rather vague element called <data> can replace it instead.

This human is none other than Ian “The Benign Leviathan Dictator For Life” Hixie, editor for the HTML specification.

I could give you an explanation on how this scenario came to exist, but two Brits who are far more informed than I am (and likely slightly smarter) have made their own summaries. If you like knowing what’s going on (and I do) then go read them. These pair of fine gentlemen, Jeremy Keith and Bruce Lawson, both guest star in today’s comic as the good Doctor thanks to a little spot of regeneration, where they’re fighting the good fight against Hixie’s <data>leks.

Virtually every problem I have with a single person wielding so much power over such a fundamentally important pillar of the web as HTML can be summed up in this incident. <Time> is officially out, despite the lack of merit or consensus in that decision. And it took just one man to make that happen. Either through a lack of awareness or a genuine disregard for what authors are already doing, Ian has claimed incorrectly that <time> isn’t seeing adoption, isn’t useful, and should be canned. And because the only balance to his power is a rather tedious process to oust him, there’s no official remedy to bringing <time> back into the HTML fold than trying to convince him that its existence is a good thing.

From what I understand, it’s easier to keep red shirts alive on away missions than it is to change Ian’s opinion on something.

Fortunately, there’s a big difference between having no official remedy and having no remedy whatsoever.

As “authors”, we are the 99% of HTML5. We can follow Jeremy Keith’s sage advice:

We can make a stand and simply carry on using the time element in our web pages. If we do, then we’ll see more parsers and browsers implementing support for the time element. The fact that our documentation has been ripped away makes this trickier but it’s such a demonstrably useful addition to HTML that we cannot afford to throw it away based on the faulty logic of one person.

So as I said, <time> hasn’t disappeared from HTML. It’s still there on millions of sites already. And nothing is stopping us from putting it on millions more. It’s our chance to send those <data>leks packing. As soon as this post is finished I’m going to edit my site’s theme to make use of <time>. Hixie can go stuff it.

Occupy HTML5.

In a perfect world, Ethan Marcotte would star opposite of me in a web design-themed, buddy cop action comedy called Beep and the Squirrel.

Actually… I’m writing that one down, just in case.

Until that glorious moment, I’ll enjoy his raw intellect and seasoned wit while envying his creative talent in a suitably stalker-like fashion. (Unless you’re reading this, Ethan, in which case I assure you that I am in no way digging through your refuse bins looking for cast-off brilliant ideas and toothbrushes.)

While we’re in the vein of borderline creepy idol worship, I’m going to agree with Ethan’s succinct tweet on the W3C’s CSS Conditional Rules Module Level 3 Working Draft (which I’ll reduce to the much easier to remember abbreviation “CCR Module”, hereafter nicknamed the “More Cowbell” document). I feel cold.

I’m still perusing the document. Although any judgement leveled while shooting from the hips (hello, ladies) is bound to be rife with bad summaries and skewed views, in my opinion the module doesn’t seem to solve any problems that aren’t already being solved in a better fashion by good CSS practice or other techniques. It’s a lazy man’s shortcut to “supportin’ olla them thar browsers”.

As Dylan Wilbanks said, these aren’t the conditionals I’m looking for.

Just look at @supports, for the love of cheese (or dairy-free cheese alternative for vegans and the lactose intolerant). It lets you test if a browser supports a feature, before (in their examples) you then go and use the feature. What? How bizarre is that? I know in their examples you can get far trickier with not and or and doogie howser, but seriously?

When it comes to the problems that CSS is supposed to solve, although @supports and its ilk would work, they seem to encourage bad or unnecessarily laboriously bloated CSS documents instead of streamlining the process. And when it comes to @document I believe that the authors are trying to make CSS solve problems it wasn’t intended for.

Look, if you’re trying to get your CSS to be flexibly supported across different browsers and devices, I recommend checking out Ethan’s Responsive Web Design, or at least actually using your skullmeat instead of slapping shoddy shortcuts into your CSS. Capiche?

The end product, “HTML5 is a beautiful mess” is now up at SitePoint. I’d be tickled pink if you took the time to listen.

As you may recall, I discussed ranted about this subject on Monday with the strip The HTML5 Show (AKA a Mess) and the related post.

Mostly, HTML5′s a mess in the political sense. The organizations behind it (W3C and WHATWG) are increasingly in conflict with one another. Additionally, in my opinion, Ian Hickson is increasingly disregarding any attempt at a legitimate process and simply putting what he pleases in the spec, as he pleases.

The podcast touches on that matter, and spins out to the state of the actual implementation of HTML5 itself, whether there’s a challenge in getting designers and developers to start using it, the issues of accessibility in <canvas>, and how delightful it’d be to move past plugins.

If I have one beef with the whole podcast, it’s the fact that I’m talking with a pair of Brits. Which, as every movie-going American knows, instantly sound more clever due to their crisp accents. Also, if the transcript is any guide, my sentences tend to roll off the rail quite a bit, inflicting casualties to adherents to the English language.

So, if you have the time, please go have a listen, and then please come on back here and post any thoughts you had at my butchery of verbs, the points that the participants brought up (or even better, the points we didn’t) and how lovely Bruce Lawson’s voice is.

And, by George, that was a really good feeling.

Entitled: “The Ghosts of Web Standards Present: CSS3, HTML5 and Mobile”, the whole thing ran about an hour and fifteen minutes. Fortunately people laughed at all of my jokes, so it wasn’t too torturous. I talked about the varying level of support in modern browsers for new CSS3 and HTML5 features (and how that shouldn’t matter), as well as my thoughts on the need to be ready for mobile devices today in our designs. If I did it again, I’d probably put more advanced CSS3 techniques and HTML5 tricks in, as I uncovered a whole slew of new things I’d not experimented with before while doing research for it.

Although the slides don’t contain the majority of my witty dialog (I’m so modest), I’ve put them up (after some corrections and modifications) for you to look at if you’d like. The background will flash into it’s proper place two seconds after the page loads, by design (I had some issues with the popdown request for the geolocation interfering with the way the background looked on the slide projector).

The Ghosts of Web Standards Present

As you’re likely familiar with my opinion on this topic, I think you can predict the results.

On October 27, 2009, Ian “Hixie” Hickson, editor-for-life of HTML5 (yes, my bias is showing) decided that there were
“no outstanding emails or bugs on the spec”, and flipped the switch on the spec declaring it in Last Call. Just in time to meet the October deadline. Hooray!

As it stands, his status flip may be premature. Or, perhaps, his viewpoint of reality. If you look at the W3C’s HTML issue tracker, you can see it’s got a lot left on it. In response to comments about this difference between the W3C and WHATWG on whether HTML5 had actually reached Last Call, Ian commented “…we have different issues lists and different criteria for going to Last Call.”

Looking at what’s left to resolve, it’d seem the difference in criteria is that the W3C would prefer the job was done properly, as opposed to being done quickly.

I’m inclined to agree with Shelley’s thoughts. Maybe Ian is trying to reassert some control. Maybe he just isn’t concerned with issues like providing unsighted web users with the information they need to understand tables on a website. Either way, it creates the appearance of a move meant to serve himself, not others.

That’s not a reassuring quality to see in our leviathan.

I’ve used quotation marks on “resolves” because the English language lacks punctuation to indicate sarcasm. I can only imagine what such a strange mark would look like, the black sheep that was expelled from the childhood home of Exclamation Point and Question Mark after a dispute with his stern father, Period. What would life on the streets do to such a symbol?

I considered using italics, but I didn’t want to look too sassy.

The @summary attribute has been the source of no little discomfort during the gestation process of HTML5, a token of sorts that is lauded, derided, despised and fought over in what seems like an endless battle. I discuss, in my own rambling fashion, my view of the civility of the issue here, which in turn references Bruce Lawson’s post on the topic, Alternate text in HTML5. It’s been the source of no small amount of contention, which I think John Foliot describes nicely over here.

Despite this, for some reason I’d (perhaps foolishly) thought that some sort of accord had occurred with @summary, allowing it to exist in HTML5 as a non-obsolete, conforming part of the spec (albeit with a great deal of snark involved).

I’d recently learned that not only was peace not occurring, but that @summary had found itself into the middle of another fracas. It seems that in an attempt to get HTML5 to reach Last Call status on schedule, Ian is marking unresolved issues in the bug tracker as “WONTFIX”, insisting that people with problems talk to the chairs, and moving on.

One such example of this in action is available for your reading pleasure in this W3C bug report. For those of you in a hurry, I’ll sum it up: People (such as the PFWG) have issue with @summary being marked in the HTML5 validator as “obsolete but conforming” along with a warning message.  Ian Hickson, man of action, disagrees with the PFWG’s opinion, won’t change the (inaccurate) flag, and has decided that the issue (among others) is resolved and simply marking it “WONTFIX.” Apparently it will keep this status, despite the large amount of opposition to this stance.

This is, as John Foliot puts it (in the same report)  “An affront to the web accessibility community that existing accessibility solutions that the current editor disagrees with have the status of WONTFIX simply because the editor disagrees.”

I’m not sure, in the end, if @summary does or does not deserves the bad rap Ian’s trying to attach to it. But I do know, though, that I’m tired of seeing one “benevolent dictator” being capable of deciding the future of the open web single-handedly by sidestepping all the prior discussions and opposing views regarding HTML5 with a simple “WONTFIX” status.