{"id":580,"date":"2012-04-30T00:00:00","date_gmt":"2012-04-30T00:00:00","guid":{"rendered":"https:\/\/www.bronco.co.uk\/our-ideas\/?p=580"},"modified":"2014-03-19T11:12:21","modified_gmt":"2014-03-19T11:12:21","slug":"the-browser-wars-part-2","status":"publish","type":"post","link":"https:\/\/www.bronco.co.uk\/our-ideas\/the-browser-wars-part-2\/","title":{"rendered":"The Browser Wars &#8211; Part 2"},"content":{"rendered":"<p>In the past week Opera have followed through on their   plans to begin supporting the <code>&ndash;webkit<\/code> vendor prefix. This is in reaction to the monoculture surrounding the   sole support of webkit by developers, primarily on mobile websites.<\/p>\n<p>Opera&#8217;s reasoning is that its users are being unfairly   discriminated against by developers and, though they say it&#8217;s not an ideal solution, they must strive to provide the best experiences for their   users.<\/p>\n<h2>What&#8217;s a Vendor Prefix?<\/h2>\n<p>Vendor prefixes are used in CSS for the testing of new and experimental features that have yet to be standardised. Each rendering engine   has their own prefix:<\/p>\n<ul>\n<li><code>-webkit<\/code> = WebKit running on Google Chrome and Apple Safari<\/li>\n<li><code>-moz<\/code> = Mozilla Firefox<\/li>\n<li><code>-o<\/code> = Opera<\/li>\n<li><code>-ie<\/code> = Internet Explorer<\/li>\n<\/ul>\n<p>As specifications and standards take some time to finalise developers have increasingly started to adopt the prefixes in their websites   choosing to either ignore or accept their experimental status.<\/p>\n<h2>Do we care about Opera?<\/h2>\n<p>As a desktop browser Opera is the smallest of the &#8216;big five&#8217; with only 2% market share. With these numbers many will be unconcerned with   them supporting <code>-webkit<\/code>. But it&#8217;s not their desktop browser where the change has begun; it&#8217;s their mobile browser, which   still holds a healthy market share.<\/p>\n<p>The impact of Opera doing this alone is debatable but it&#8217;s the precedence they set and which others such as Mozilla and Microsoft may   follow that is of greater concern. Between them these two companies hold approximately 50% of the desktop browser market.<\/p>\n<p>If Firefox and Internet Explorer move to support the webkit vendor prefix (and we conveniently ignore previous versions of these   browsers) we will eventually have almost 90% of the population using a browser that supports <code>-webkit<\/code>.<\/p>\n<h2>That makes things easier for developers, right?<\/h2>\n<p>There is an argument to say that developing for one vendor prefix is quicker and easier but that&#8217;s a fairly short term view; we have to   look at the long term.<\/p>\n<p>The vendor prefixes were created to allow browsers to experiment with new features and as browsers developed different solutions a   consensus in partnership with the W3C would be formed. A single standard would then be developed and all browsers would adopt this standard and   drop the prefix.<\/p>\n<p>It&#8217;s this competition between the browsers that ensures we not only find the best solutions for what is being developed but also fosters   creativity in developing brand new features that have not yet been conceived. The past success and dominance of Internet Explorer 6 proves how a   monoculture can harm progress.<\/p>\n<p>Though the browsers may still support their own vendor prefixes you have to consider how long they will choose to do this and how   different the implementation would be to that of <code>-webkit<\/code>. A browser manufacturer is not going to spend additional time   creating a different solution to that found in WebKit browsers especially when they must ensure the <code>-webkit<\/code> solution is   perfect.<\/p>\n<p>When a browser chooses to adopt a feature native to its competitor and then masquerade as its competitor the implementation of this   feature has to perfectly mirror that of their competitor. Not doing so doesn&#8217;t only ensure mass developer backlash but also could break many   websites that were otherwise working perfectly.<\/p>\n<h2>Repeating History<\/h2>\n<p>It&#8217;s clear we cannot learn from past mistakes as this change mirrors closely one of the major battlegrounds of the Browser Wars in the   90&#8217;s. At the time features were being developed at a rapid pace much like they are today but at the time User Agents were being used to deliver   different styles to each browser based on what they could support.<\/p>\n<p>User Agents are a text string that a website can use to determine information about the browser that is being used to view the   website.<\/p>\n<p>User Agents were a popular way for developers to determine the browser a person was using and deliver an optimised version of a website   to them. This was in reaction to some browsers implementing features incorrectly if at all. Once these browsers caught up they would spoof the   user agent by including their competitors name within their user agent string alongside their own.<\/p>\n<p>This causes many more issues than we would experience with vendor prefixes but the result is still one that many would not like to   see.<\/p>\n<h2>Is there a solution?<\/h2>\n<p>Some developers are dropping prefixes out of laziness while others do so purposefully. We cannot force developers into changing the way   they work though certainly those dropping prefixes out of laziness should most certainly be pushed to improve.<\/p>\n<p>It isn&#8217;t until the browsers feel their users are being correctly treated that we could reverse this trend. However once all browsers   have begun to start implementing support for <code>-webkit<\/code> we won&#8217;t see them drop support any time   soon.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In the past week Opera have followed through on their plans to begin supporting the &ndash;webkit vendor prefix. This is in reaction to the monoculture surrounding the sole support of webkit by developers, primarily on mobile websites. Opera&#8217;s reasoning is that its users are being unfairly discriminated against by developers and, though they say it&#8217;s [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2],"class_list":["post-580","post","type-post","status-publish","format-standard","hentry","category-web-and-ux"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.bronco.co.uk\/our-ideas\/wp-json\/wp\/v2\/posts\/580","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.bronco.co.uk\/our-ideas\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.bronco.co.uk\/our-ideas\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.bronco.co.uk\/our-ideas\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.bronco.co.uk\/our-ideas\/wp-json\/wp\/v2\/comments?post=580"}],"version-history":[{"count":0,"href":"https:\/\/www.bronco.co.uk\/our-ideas\/wp-json\/wp\/v2\/posts\/580\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.bronco.co.uk\/our-ideas\/wp-json\/wp\/v2\/media?parent=580"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.bronco.co.uk\/our-ideas\/wp-json\/wp\/v2\/categories?post=580"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}