Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Comments for Doing Science On The Web


One of the issues is that most of our solutions are often based on "Good will" and "Good behavior" principles which are not very solid once confronted with the social, diverse and economic aspects of the Web.

On the Web Compatibility project, we get to deal with the effects of how the Web is being used now and it is carried on through times. The issues for vendor prefixes are well-known, we have written about them for quite a while now.

I guess maybe a way to explore a new system, a new policy for them would be to see how resilient it is to the current issues.

Vendors using them as a competitive advantage Prefixes used in production releases of browsers Web developers who cares only about a browser X and its last new features Web developers who can't fix a Website because the client doesn't want to pay or the client just doesn't exist anymore (Clients change often Web agencies) Non maintained JS/CSS libraries Old JS/CSS libraries on legacy Web sites. Browser vendors maintaining the prefixed version even when the unprefixed version is already deployed.

btw this last one would go a long way in improving the situation. Currently if WebKit rendering engines were stopping to support -webkit-/WebKit version for gradients, flexbox, background-size, transition, it would break instantly 20% of the sites on the Chinese and Japanese Web, but that would help to fix a lot of Web sites.

btw Alex, I would be happy to discuss about this in Saporro at W3C TPAC if you are there and gives you not a solution but a panorama of Web compatibility issues we currently have.

by karl at
What about a modified prefix that has a vender-determined self-destruct date encoded?

.className { -2015-10-20-featureName: 5px ofAwesome; expected-ProductionVersion: 5px ofAwesome; }

It would allow for the self-destruct mechanism control of the browsers, while allowing full control for the developers to determine if they want to participate without any registration process.

by Michael at

Hey Dave,

The "antithetical to the web" thing comes up a lot, and yes, I get the problem with multiple engines running their own experiments. We aren't there yet, and it's a problem with many possible solutions (e.g.: what if the W3C ran the infrastructure once we understood it well enough?).

We're also aware that we don't really understand if these limits or experiment lengths are are set right today. They're a conservative starting place. That said, I'd love to understand if you think (e.g.) CodePen would ever be above one of those traffic limits; seems unlikely?

I'm proposing this because it's the only way I know to avoid the collective action problem you've outlined. If you know of another solution, would love to talk about it. But it has to be something other than wishing the incentives that browsers and developers live within were somehow different.

Regards

by alex at
Long but nice post. People might disagree but I don't like prefixes. If all the browsers are supporting them why they need the vendor prefix.

And @Michael good idea for next MI movies, if they decide to use web developer as theme of movie :)

by Ravish at
I think I disagree with this approach.

Developer keys to use features seems sorta antithetical to the Web. A future where I have to be registered to develop on every browser just to play with new features kind of bums me out. But even beyond that, it seems like a huge hurdle to get people to do this. This is actually the worst part about Native App Development. Global Usage Caps are tricky to me. Like a Catch22. Features without cross browser adoption can't be shipped to production. Self-Destruct is an interesting concept. But as a website developer, I rarely have time to pick up features on day one. I probably have work or clients occupying most of my time. It may be a month+ before I read the HTML5ROCKS RSS feed. A feature I want could already be destroyed by the time I read about it. I realize this is probably designed to help browsers ship and get feedback faster, but for a developer like myself it seems arbitrary, like a bottle episode TV trope.

I realize vendor prefixes quickly became an untended teenage wasteland. But those CSS features and some JS APIs got adopted very quickly (maybe to quickly, to your point) and were able to achieve statistical significance. From my point of view, where it botched up seemed to be a lack of collective prioritization among all the browsers.

Why couldn't features enabled in Developer versions of browsers and/or be selectively enabled by developers for feedback. And then transparently presented in a UI (like a Developer Feature Kanban)? Here's a quick mockup

http://codepen.io/davatron5000/pen/rVEXMz

Seems like you'd be calling attention to features you need feedback on. And then developers could get excited about using them. Usage/Cross-browser support stats could also be included. As a developer, it's quite a bit of legwork to see how well a feature is doing at any given point in its lifespan.