<!DOCTYPE html>
<!-- ========================================== kroc camen of camen design ============================================= -->
<title>code · How the World Could Solve the Vendor Prefix Problem in One Month</title>
<link rel="stylesheet" type="text/css" href="/design/design.css" />
<meta name="viewport" content="width=device-width, maximum-scale=1.0, user-scalable=no" />
<link rel="alternate" type="application/rss+xml" href="/code/rss" title="Just code" />
<link rel="canonical" href="/code/-x" />
<!-- =================================================================================================================== -->
<header>
	<h1><a href="/" rel="index">
		Camen Design
	</a></h1>
	<nav><ul>
		<li><a href="/">all</a></li>
		<li><a href="/projects">projects</a></li>
		<li><a href="http://forum.camendesign.com">forum</a></li>
	</ul><ul>
		<li><a href="/quote/">quote</a></li>
		<li><a href="/writing/">writing</a></li>
		<li><a href="/blog/">blog</a></li>
		<li><a href="/photo/">photo</a></li>
		<li><a href="/code/" rel="tag">code</a></li>
		<li><a href="/art/">art</a></li>
		<li><a href="/link/">link</a></li>
		<li><a href="/poem/">poem</a></li>
		<li><a href="/audio/">audio</a></li>
	</ul><ul>
		<li><a href="/web-dev/">web-dev</a></li>
		<li><a href="/annoyances/">annoyances</a></li>
		<li><a href="/eve/">eve</a></li>
		<li><a href="/code-is-art/">code-is-art</a></li>
		<li><a href="/inspiration/">inspiration</a></li>
		<li><a href="/windows/">windows</a></li>
		<li><a href="/gift/">gift</a></li>
		<li><a href="/gaming/">gaming</a></li>
		<li><a href="/mac/">mac</a></li>
		<li><a href="/osnews/">osnews</a></li>
		<li><a href="/c64/">c64</a></li>
		<li><a href="/linux/">linux</a></li>
	</ul>
	<a rel="previous" href="/code/splitscreen">
		older article →
	</a><a rel="next" href="/code/transliteration">
		← newer article
	</a></nav>
</header>
<!-- =================================================================================================================== -->
<article><header>
	<!-- date published or updated -->
	<time pubdate datetime="2012-06-13T18:33:00+01:00">
		<sup>6:33<abbr>pm</abbr> • 2012</sup>
		<abbr title="June">Jun</abbr> 13
	</time>
	<!-- categories -->
	<ul>
		<li><a href="/code/-x" rel="bookmark tag">code</a></li>
		<li><a href="/web-dev/-x">web-dev</a></li>
	</ul>
</header>
<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
<section>
<h1>How the World Could Solve the Vendor Prefix Problem in One Month</h1>
<p>
	<strong>Stop trying to solve more than one problem in one go, it won’t work.</strong> Proposals for the solution
	to vendor prefixes have tried to solve additional problems with vendor prefixes (that is, vendor behaviour &amp;
	spec change) by adding more complexity, ‘features’ and meaning to prefixes. Stop making things complicated.
</p><p>
	Let’s solve one thing, simply, and right now.
</p><p>
	I am asking you, browser vendors, to add “-x” as an alias to your vendor prefix in your web browser. That means
	that any instance of <samp>-x-feature</samp> in the CSS will be treated as <samp>-webkit-feature</samp> in WebKit,
	<samp>-moz-feature</samp> in Gecko, <samp>-o-feature</samp> in Opera and so on and so-forth.
</p><p>
	Why does this solve the vendor prefix problem?
</p>


<h2>1. Incomplete Features Are Still Incomplete</h2>
<p>
	It’s good practice to always include the un-prefixed declaration at the bottom of a list of vendor
	prefixes—thusly:
</p>

<pre><code>-webkit-feature: myway;
   -moz-feature: myway;
    -ms-feature: myway;
     -o-feature: myway;
        feature: highway;</code></pre>

<p>
	But that relies upon waiting until that feature becomes unprefixed and does nothing to do away with the multiple
	list of vendor prefixes until that time.
	<br /><br />
	How about:
</p>

<pre><code>-x-feature: myway;
   feature: highway;</code></pre>

<p>
	?
	<br /><br />
	That reduces the repetition whilst each browser still sees its own feature (<samp>-webkit</samp>,
	<samp>-moz</samp> <abbr title="et cetera">&amp;c.</abbr>)
</p>


<h2>2. Vendors Will Be Vendors and That Will Not Change</h2>
<p>
	You cannot threaten, cajole or otherwise incite Apple (or any vendor) to stop being a massively successful company
	that will do what it damn well likes.
</p><p>
	Vendor prefixes are necessary. There are tons of internal features of different engines that are <em>never</em>
	going to be standardised because they are not designed to be exposed to the web or are used in producing the browser
	UI or are there for just plain old competition. Standards take time and companies have to ship software.
</p><p>
	We can’t stop Apple being Apple, and we shouldn’t try stop lazy developers being lazy developers through syntax.
	That is an education problem that has to be solved at a level much higher than syntax. <samp>-x</samp> is
	incredibly lazy—for vendors and developers alike—but it’s lazy <em>and</em> good, rather than <em>lazy and
	bad</em> like vendor-specific prefixes.
</p><p>
	<samp>-x</samp> will succeed because it’s lazy in a copy-paste web development world and not busy trying to hit
	vendors or developers over the head with a shame stick, or trying to educate the world about best-practices all
	within a prefix.
</p><p>
	Imagine that in order for HTML5 to be adopted, developers had to update every HTML4 page out there? That’s what
	vendor prefixes are, in-effect, requiring. <samp>-x-</samp> is like the HTML5 doctype. Old code doesn’t have to
	change, compatibility goes both ways, we code for the future and the future supports us.
</p>


<h2>3. Specs Change, Browsers Differ</h2>
<p>
	The <samp>-alpha</samp>, <samp>-beta</samp> proposal nonsense doesn’t work because it tries to imbue spec /
	standardisation ideas in the I-don’t-care-about-this-crap-copy-paste web developer world where old code doesn’t
	get updated unless it breaks horribly.
</p><p>
	If you are using any vendor prefixed features then they <em>might</em> break in the future. That is reality and you
	can’t (and shouldn’t) try and change vendor prefixes to solve that problem.
</p><p>
	Different vendor prefixes don’t work because it assumes that every vendor implementation of a new feature will
	be—by deafult—incompatible. That means that every time a vendor adds support for a feature that matches another
	vendor, you have to fix your code <em>even when it’s working</em>. <samp>-x</samp> works because it assumes that
	vendor implementations will be the same, unless they are different. You only change your code <em>when it
	breaks</em>. With <samp>-x</samp>, when a vendor adds support for a feature, you get it for free without having to
	rewrite the whole damn ’Web.
</p><p>
	Let’s imagine this code currently only works in WebKit because only it supports that feature:
</p>

<pre><code>-x-feature: highway;
   feature: highway;</code></pre>

<p>
	And then Mozilla come along and say it should be done a different way. You can just override your code:
</p>

<pre><code>  -x-feature: highway;
     feature: highway;
-moz-feature: myway;</code></pre>


<hr />


<h2>You Can Do It, and You Can Do It Now</h2>
<p>
	Mozilla, Apple, Google, Microsoft. You could all implement this small change very easily. You only have to alias
	<samp>-x</samp> to your vendor prefix. It is not asking much. There’s no standardisation involved, there’s no
	spec (or “alias <samp>-x</samp> to your vendor prefix” is it), you don’t even have to arrange a meeting with
	each other.
</p><p>
	Apple and Microsoft both have browsers in beta (Safari 6 and IE10). Including this tiny change would open the flood
	gates to developer support. Google can ship the change in 24 hours with Chrome’s update mechanism. Mozilla could
	ship it officially in 6 weeks. There is little holding back any of you.
</p><p>
	Here is the gauntlet I am throwing down to solve the problem of vendor prefixes:
</p><p>
	<strong>Announce, or ship—officially, or as a development build—support for <samp>-x</samp> within one
	Month’s time (July 13<sup>th</sup> 2012).</strong>
</p><p>
	I believe that to be quite doable, and I hope to hear from you soon.
</p>
</section>
<p>
	<small>I <a href="/indiscriminate">don’t have</a> a twitter / reddit account, so if somebody could do the
	honours of starting it off, that would be appreciated, thanks, and if of course anybody would have the ability to
	get the vendors to actually see this, that would help too! <samp>:P</samp></small>
</p>
<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
</article>
<footer>
	<nav><a href="http://forum.camendesign.com">‹ Discuss this in the Forum ›</a></nav>
		
	<a href="mailto:kroc@camendesign.com">kroc@camendesign.com</a>
	<nav>view-source:
		<a href="/code/-x.rem">Rem</a> •
		<a href="/code/-x.html">HTML</a> •
		<a href="/design/">CSS</a> •
		<a href="/.system/">PHP</a> •
		<a href="/.htaccess">.htaccess</a>
	</nav>
	<form method="get" action="https://duckduckgo.com">
		<input type="hidden" name="sites" value="camendesign.com" />
		<input type="search" name="q" placeholder="search…" />
		<input type="submit" value="Go" />
	</form>
</footer>
<!-- =================================================================================================== code is art === -->