[Explain experience in Web development.]Standards are important. One person controlling it causes problems. WebKit.[Ask everyone what browser they use on their smartphones.]
[Explain the Open Web Platform; what’s in it.]Web pages a nightmare to develop if it was different code for each browser. Write once and run everywhere.OWP defined by specs from different orgs. Members of orgs are representitives from different companies, e.g. Microsoft, Google, Mozilla and the BBC.But how is the OWP created?All of these layout engines support the Open Web Platform, which are technologies like HTML and the DOM API. Every layout engine has to support the same standard technologies, because otherwise Web pages would be a nightmare to develop. And this is why the Web platform is such as success: in theory, you can write one piece of HTML or CSS and expect it to look and work in exactly the same way on every layout engine in every browser on every operating system.The Open Web Platform is defined in specifications written by members of organisations like the W3C. Its members are from companies like Google, Microsoft, Mozilla and the BBC.I’ll explain how standards are created at the W3C…
Working Drafts: start.Last Call: Spec mostly feature complete. Deadline set to sort out last remaining problems.Candidate Recommendation: Supposedly done. The spec can be implemented. Test cases written.Recommendation: Supported in at least two browsers; given stamp of approval by Sir Tim.Adrian keeps saying that you shouldn’t use a standard unless it’s a recommendation. But he’s wrong. In big specs, some new features may be fully supported while others aren’t.Standards are defined in specifications. At the W3C, specifications start out as Working Drafts. As they’re being written and refined, anyone can give feedback and suggest changes or additions.Once the spec is mostly feature complete, it goes into the Last Call stage, where everyone is given a deadline like six months or so to sort out any remaining issues.When a spec reaches Candidate Recommendation, it’s pretty much done. Now browser vendors can implement the new feature as a finished product, so it doesn’t need to be marked as “experimental”.A spec becomes a Recommendation when it’s implemented in at least two layout engines and Sir Tim gives his stamp of approval. Adrian told you in CS150 that HTML5 as a Candidate Recommendation isn’t a “formal” Recommendation, but it is. It’s been predicted that it won’t become a recommendation until 2014, but you need to start using it now! But that’s a side note, so I’ll move on.
Microsoft stopped developing IE after IE6. Why?[click]Because they won.Innovation on OWP had stopped. Not supporting new standards. A scary time!Released IE7 5 years later. But damage was done.[click]Market share healthier. Microsoft are nice now; proudly support Web standards. IE10 very good.Took us a decade to get to this point; Mozilla and other browser vendors.Let’s look at smartphone browser market share…After Microsoft released IE6, they said they weren’t going to develop any new versions. They thought they now had control over the Web and that they had killed it. That meant that innovation in the Open Web Platform had stopped, because the only dominant Web browser – IE6 – wasn’t being updated to support the newest standards. Now that was a scary time! It took five years before Microsoft released IE7, but by then the damage was done.Thankfully, the market share is much healthier now and Microsoft have realised that they need to comply with standards to compete with other browsers. But it took a decade for us to get to this point, thanks to the efforts of Mozilla and eventually other browser vendors.Now lets look at the market share on smartphones and tablets…
Mobile market share looks even. [Go over each segment.]But if we combine them to show the layout engine market share…[click]Looks familiar? Similar to 2001 for desktop browsers.Am I the only person that finds that scary?Very little choice given.Apple and Google have power to control OWP; decide what’s added.Web developers only bother to test Web sites in WebKit; use stuff that only works in WebKit; stops users from switching browsers.[Ask what desktop Web browser everyone uses.]People ask me why I don’t use Chrome. I don’t want to be a part of this 86%! You’re all using WebKit on your phones. You’re all contributing to this death spiral!Web developers make mistake thinking market share is important; it’s not. Must treat all layout engines equal.I’m just wondering: What type of smartphone does everyone here have? What’s their default Web browser on it?Let’s have a look at the market share for mobile devices.Does this look familiar? This graph almost exactly matches the same one from 2001. Am I the only person that finds this scary? Users aren’t being given much browser choice on their phones, and look what’s happened as a result! Just like Microsoft in the late 90s, now Apple and Google have the power to control the Open Web Platform for their own selfish needs. It gives them control over the Web platform; they alone get to decide what technologies get added and removed. WebKit’s dominance has encouraged Web developers to only test their Web sites in WebKit; and to use proprietary features that only work in WebKit - without any compatibility for other layout engines. And that has a knock-on effect that discourages users from switching browsers.People always ask me why I don’t use Chrome. Well this is why: I don’t want to be a part of this 86%! Those of you that are using Safari or the built-in Android browser: you should be ashamed! :P A lot of Web developers make the mistake of thinking that market share is important when designing Web sites, but it’s not. They need to design for all Web browsers equally. However, you do need to consider market share when you’re using experimental technologies.
Example of experimental feature used in CSS.[Explain CSS Transitions spec.][click]This is what it looks like. Notice the red part I’ve highlighted.[Explain vendor prefixes.]Browsers must remove support for prefix when the spec reaches Candidate Recommendation.This example is common for mobile Web sites. But it only works in WebKit browsers.Should avoid experimental features, but if they must be used, this is how it should be done:[click]This way, most popular layout engines are supported. Once spec reaches CR, the unprefixed version is used. Unless the syntax changes!Example on the left is common practice. It’s annoying. Happens on desktop Web sites a lot as well.A lot of Web developers are lazy and ignorant. But because WebKit has monopoly, they don’t care. It’s called “experimental” for a reason!The W3C say CSS Transitions don’t need the prefix any more; WebKit doesn’t ever remove support for prefixes; defeats the point of prefixes.I’ll give you an example of the experimental features that I was talking about. One of the newest CSS features is transitions, which lets you do things like let backgrounds slowly fade from one colour to another. When browser vendors implement an experimental feature in a W3C spec, they have to put what’s called a “vendor prefix” in front of it. Here’s an example of what a prefix looks like. Once a spec becomes a Candidate Recommendation and a browser vendor has fully implemented it, the prefix has to be removed from their layout engine.However, there’s just one problem with this example. This CSS rule will only work in WebKit, despite the fact that other layout engines also support transitions. Also, when WebKit stops using the prefix, this rule will no longer work. This is how the rule should be implemented. This one uses prefixes for the most common layout engines, and once the prefix is no longer needed, the standard CSS property is used.The problem is: this has example on the left has become a really common practice in the Web development community, and it really annoys me. Lazy and ignorant Web developers working for large companies think that this is acceptable, because WebKit has the majority in market share on smartphones. Any Web developer that does this should be ashamed! Experimental features are called “experimental” for a reason: they could change any time; and they have. They shouldn’t really be used in mainstream Web sites anyway, because they just exist as a beta test to allow Web developers to test them and report any bugs.But what’s interesting is that the “transition” property – for reasons I’ll explain later – doesn’t have to have the experimental prefix anymore. That means the browser vendors are allowed to stop requiring Web developers to use the prefixes. But – surprise, surprise – WebKit still uses them. Google and Apple are still enforcing authors to use the proprietary prefixes. The whole point of prefixes is to remove them ASAP once the feature is no longer experimental.
Example of browser sniffing.[click]Facebook in WebKit.[click]Facebook in IE9 on Windows Phone and Firefox for Android.Facebook Web devs assume that if you visit the site in WebKit, you’re using a smartphone. Otherwise, you’re using an old feature phone.So there’s two versions of the Web site.Better to use progressive enhancement.[Explain progressive enhancement]And what’s the result of this? If you browse the mobile Web on anything other than WebKit, you will have a crappy experience on many Web sites.For example, here’s how Facebook’s mobile Web site appears in WebKit. Now here’s how Facebook appears in Firefox for Android and Internet Explorer for Windows Phone. What’s basically happened here is that Facebook can’t be bothered creating their Web site using a technique we call “progressive enhancement”, where Web pages are designed to work on older layout engines, but progressively improve with richer features if your layout engine supports newer and newer technologies. Instead, Facebook has created two versions of their Web site. If you use WebKit, you can use the awesome version. If you use anything else, you get to use the crappy old Web site that was originally designed to be used on feature phones.
Last year, people noticed WebKit was a big problem.Decided emergency action was needed.Mozilla and Opera decided to support some of the proprietary CSS prefixes; but means non-standard features become standard.Daniel Glazman (co-chairman of the W3C’s CSS Working Group) thought that was a step too far; published an official Call For Action, where he basically pleaded to Web developers to stop using all these experimental CSS properties that only work in WebKit. He explained how it is too late to fix the mobile Web and that we may not recover.[click link to show Call For Action]Mozilla and Opera didn’t follow through with their plan. (phew!)Instead, the CSS Working Group decided break their own policy and allow browser vendors to ship four new features (animations, transitions, transforms and gradients) without vendor prefixes; even though it was before their specs became candidate recommendations. This plan didn’t work, though, because – as I said earlier – WebKit refuses to remove support for CSS prefixes. There are still loads of properties that have prefixes, and to make matters worse, we can’t remove the prefixes on some of them because Apple has intellectual property rights on them!Mozilla now has a policy thatthey won’t release experimental features in Gecko unless they’re switched off by default in Firefox releases. But you can still use them in their Aurora and Nightly builds.It was decided that emergency action needed to be taken to fix the problems caused by WebKit’s dominance. Mozilla and Opera decided that they would support some of the proprietary -webkit- prefixed properties in Gecko and Presto. But that’s obviously bad, because that means these non-standard features will have become standard.Daniel Glazman, who’s the co-chairman of the W3C’s CSS Working Group thought that was a step too far, and published an official Call For Action, where he basically pleaded to Web developers to stop using all these experimental CSS properties that only work in WebKit. He explained how it is too late to fix the mobile Web and that we may not recover.Thankfully, Mozilla and Opera didn’t follow through with their plan. Instead, the CSS Working Group decided break their own policy and allow browser vendors to ship animations, transitions, transforms and gradients without vendor prefixes before their specs became candidate recommendations. This plan didn’t work, though, because – as I said earlier – WebKit is still using the prefixes on them. But there are still loads of properties that have prefixes, and to make matters worse, we can’t remove the prefixes on some of them because Apple has intellectual property rights on them!Mozilla now has a policy thatthey won’t release experimental features in Gecko unless they’re switched off by default in Firefox releases. But you can still use them in their Aurora and Nightly builds.
WebKit will be a problem for a long time.Don’t know if situation improved from last year, but still a threat to OWP.Control of OWP shouldn’t be with a company; should be with everyone.So in conclusion….Use the Web platform; not the WebKit platform. Web is for all; test for all browsers.Use things like progressive enhancement and feature detection; less likely to get problems.Up to you to reduce WebKit’s market share. Use a different browser with different layout engine.Can’t switch layout engines in iOS.Because Opera is gone, only alternative on Android is Firefox. But it’s awesome and faster than Chrome!If using Windows Phone, no choice except IE.Now Opera gone; relying on Mozilla and Microsoft to rescue us from a WebKit future. Can they do it?Despite all the efforts and evangelism made by the W3C, the problem still exists. I don’t know if the situation has improved since this time last year, but the problem is still there and it’s still a threat to the standards of the Open Web Platform. We can’t let Apple, Google and Microsoft control it; the control should belong to everyone.So in conclusion…Don’t design Web sites just to work on WebKit. You need to test them in all popular modern browsers.If you use good practices in Web design like progressive enhancement and feature detection, you’re not likely to get any problems in the different layout engines.And finally, we need to stop letting WebKit have the majority of the market share, so we need to encourage people to switch browsers. Now that’s kind of hard when the only browser you can get on iOS is Safari, but you do have more choice on Android. Firefox and Opera are on there (but Firefox is the best, obviously!). Also, you could encourage people to get a Windows Phone and force them to use IE10.
WebKit vs. the mobile Web
WEBKIT Is there a second browser VS. wars?THE MOBILE WEB
THE STANDARDS PROCESSWorking Draft Last Call Working Draft Candidate Recommendation Recommendation
THE BROWSER WARSThe first Web browser was called “WorldWideWeb”. It was made in 1991.In 1993, Mosaic was created. Microsoft and Netscape used it to create theirown Web browsers.Microsoft’s Internet Explorer and Netscape competed over market share byadding new proprietary features to their own Web platforms. e.g. <marquee>Microsoft practically defeated Netscape by the time IE6 was released.This had devastating consequences on the Open Web Platform.
DESKTOP BROWSERMARKET SHARE 2001 2013 1% 2% 0% 10% 5% Internet Explorer 18% Firefox Internet Explorer Chrome Netscape Safari Other 55% Opera 20% Other 89%
MOBILE BROWSER MARKETSHARE 2013 2013 (layout engines) 1% 1% 3% 3%1% 10% 10%2% Safari Android WebKit Chrome Presto Mini BlackBerry Tident 22% Opera Mini 61% Unknown Internet Explorer Other 86%
EMERGENCY ACTIONIn early 2012, Mozilla and Opera decided they should support some -webkit- prefixes to improve compatibility.Later, the W3C’s CSS Working Group published a Call For Action.Later, the CSS Working Group allowed browser vendors to ship the followingCSS modules without using -prefixes-: CSS Transforms CSS Transitions CSS AnimationsMozilla decided that they will only release prefixed properties in betaversions of Gecko.
CONCLUSIONIt’s up to you to prevent this from getting worse!Don’t be an ignorant Web developer.Use good practices like: Progressive enhancement Feature detectionUse a different Web browser (like Firefox for Android! )