Tag: HTML5

I’m wrapping up being embedded with the Web Platform Team this week.  It’s been an awesome experience, and I want to share some of what I learned. Here’s some of it. 

Getting a feature into browsers is hard.

For the past few months I’ve been showing off a bit of this team’s work while talking to people.  CSS Regions, CSS Shaders, CSS Exclusions are the ones I usually hit. I always get hit with the question “When will this be in browsers?”  I never give a good answer to this, because I’ve never gotten a good answer to this, because there are not good answers to this.

So why is that? Because getting a feature into a browser is one of those iceberg things where what you see on the outside is only a fraction of the work involved.  

The engineers told me repeatedly that some of the prototypes for advanced features were demonstrable after a few weeks of work on their part.  They’re smart people who can do awesome things fast. But the prototype is just one piece of that, for us it only works in a specific build of WebKit, and can only handle what the engineers were trying to accomplish in the first place.

So how do go from there to other browsers as a whole?  Well you write a spec.  The spec tells the browser manufacturers what you want the feature to do, what the API of the feature will look like, what options are available, etc.  You write the spec and share it with other browser groups and they will tell you the spec is impossible because they’re engineers.  So, you whip out your prototype and show that it isn’t impossible. Take that, browser makers!

So to punish you for that, they tell you your spec is awful, and you need to rewrite the whole thing.  

This part of the process seems to go on multiple times. 

Then as you are perfecting your spec, some bleary-eyed engineer at one of the browser manufacturers pokes his head out of his cube and says “Look at this awesome thing I did!” and it will look a lot like the feature you have specced out. He or she didn’t see all the work on the spec, because they were too busy making the exact same thing happen. Except the API will be completely different.  And not, “they name this thing height, and we call it clientHeight” different.  No, it will be like the episode of Star Trek: the Next Generation where they find that culture that talks in metaphor, so you’ll call it “clientHeight” and they call it “Hixie and Zeldman at Tenagra.” 

So now you need to “reconcile” your APIs.  And by reconcile, I mean “argue that your way is better until you make the other guys ear gush out pink fluid.” Then who ever is left standing just does it the way they wanted. 

Then it gets into a few browsers, and people start using it.  Then they start complaining that other browsers don’t have it. This puts pressure on browser makers to implement the spec. Then someone creates a good polyfill to get the feature to work in said browser, and the pressure deflates. 

And that my friends is how an feature idea becomes a browser feature.

Now obviously I jest in some of this.  People aren’t always arguing or asking for rewrites out of revenge. All of the people in this process are passionate about what they do, and want to see things implemented in the web developer friendliest, most secure, most contingency meeting way possible.  But sometimes they are human beings who want to reduce their own work, follow their own agendas, and put browser maker concerns over browser developer, or browser users concerns. It’s human, it isn’t malicious, and a lot of time noise will make them do the right thing.

So my friends, when you ask “When will this feature be in browsers?” and I say, “I’m not sure” here’s why. 

For two weeks, I’m embedded with the Web Platform team here at Adobe.  What does that mean?  It means, I’m acting like I’m part of the team, going to all the scrum meetings, taking a (very small) bit of work off their hands, and trying desperately not to screw anything up. 

For those that don’t know, the Web Platform team at Adobe is the group responsible for writing the specs, implementing the code, and shepherding the technologies that make up Adobe’s contributions to the W3C and WebKit. If you’ve seen our work on  CSS Regions, CSS Exclusions, CSS Shaders, CSS Compositing, or CSS Transforms then you have seen the fruits of this team’s labor.  I’m embedded with a subset of that larger group – the engineers that actually write the code.

I’m going to post some of my first week observations tomorrow or Monday, but I figured I’d put things out to you guys. Is there anything you’d like to know? Any part of the process that you’d like more insight into? Anything that you’d like investigated or answered while I’m here?

And don’t worry, the team might be in your browser rendering your coolness, but I will not be. The work I’m doing is all HTML work that will be run by the browser.  So no worries.