3. THE OPEN WEB PLATFORM
All layout engines implement the Open Web Platform.
The Web platform is defined by standards bodies like:
World Wide Web Consortium (W3C)
HTML and DOM
CSS
Web Hypertext Application Technology Working Group (WHATWG)
Works to give the W3C common sense when defining standards (it’s a long story…)
European Carton Makers Association (ECMA)
Defined ECMAScript, a.k.a. JavaScript
Internet Engineering Task Force (IETF)
HTTP/1.0
Web Sockets
Atom
5. THE BROWSER WARS
The first Web browser was called “WorldWideWeb”. It was made in 1991.
In 1993, Mosaic was created. Microsoft and Netscape used it to create their
own Web browsers.
Microsoft’s Internet Explorer and Netscape competed over market share by
adding 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.
6. DESKTOP BROWSER
MARKET SHARE
2001 2013
1% 2% 0%
10% 5%
Internet Explorer
18%
Firefox
Internet Explorer
Chrome
Netscape
Safari
Other 55%
Opera
20% Other
89%
7. MOBILE BROWSER MARKET
SHARE
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%
11. EMERGENCY ACTION
In 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 following
CSS modules without using -prefixes-:
CSS Transforms
CSS Transitions
CSS Animations
Mozilla decided that they will only release prefixed properties in beta
versions of Gecko.
12. CONCLUSION
It’s up to you to prevent this from getting worse!
Don’t be an ignorant Web developer.
Use good practices like:
Progressive enhancement
Feature detection
Use a different Web browser (like Firefox for Android! )
Editor's Notes
[Explain experience in Web development.]Standards are important. One person controlling it causes problems. WebKit.[Ask everyone what browser they use on their smartphones.]
I’ll give a quick summary of how the Web works today.[click][List Web browsers.]They all use layout engines.[click][Explain what layout engine are.][Explain who makes WebKit. Open source but worked on a bit secretively.]Before I go into detail about this, I just want to give a quick summary of the state of how the Web works today.Obviously, you access the Web using a Web browser, and these are the five most popular ones: Internet Explorer, Firefox, Chrome, Safari and Opera.All browsers have an underlying layout engine (or rendering engine) to make them work. Its job is to basically deal with HTTP requests, receive HTML, CSS and JavaScript files, parse them and turn them into the Web pages that the user sees and interacts with. Internet Explorer uses Trident, Firefox uses Gecko, Chrome and Safari use WebKit and Opera uses Presto. WebKit is worked on by Adobe, Apple and Google in a somewhat cooperative manner. It’s supposedly open source, but the companies still work on it quite secretively before they push their final code into the WebKit trunk builds.However, it was actually announced in the news on Ash Wednesday that Opera will be moving over to WebKit over the next few months.So lets look at the platform that these layout engines run…
[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.
Sir Tim created the first browser called WorldWideWeb.Two years later, Mosaic was created; very popular. Microsoft and Netscape licensed the tech from it to create their own Web browsers.Started aggressively competing with each other. Added non-standard things to Web platform.Sir Tim quit job and created W3C to manage standards.e.g. marqueee.g. JavaScript (Sir Tim did not want to standardise JavaScript)Microsoft bundled IE4 in Windows.A lot of Web sites used to say “Works best in Internet Explorer/Netscape”.By 2001, IE6 had a monopoly. Had to buy Windows to browse the Web.Web platform was a mess. Poorly designed features and APIs. Still left over today. Cannot be fixed.Now history is starting to repeat itself....OK, now that I’ve got that out of the way, I’m going to do something very difficult now, which is to cover the history of Web browsers in 30 seconds.In the beginning of the Web, Sir Tim created the first Web browser which he imaginatively called the WorldWideWeb.Two years later, Mosaic was created and it became very popular. The companies Microsoft and Netscape were very interested in this, and used it to create their own Web browsers. It didn’t take long before they were very aggressively competing with each other. One of the ways they competed was by adding the Web platform. While both browsers supported basic HTML elements like <h1> and <a>, they started adding their own.Actually, who remembers the <marquee> element?Microsoft practically stabbed Netscape in the back when they bundled IE4 in Windows. The Web was full of Web sites that worked only in IE. Does anyone remember back when most sites used to say in their footers “Best viewed in Internet Explorer 6” or something like that? If you wanted to browse the Web, you had pretty much no choice but to buy a Windows PC and use Internet Explorer.As a result of the war, technologies like CSS and JavaScript were rapidly created in order to compete. However, because they were rushed, the Web platform is now a mess. And while that can’t be fixed, Sir Tim quit his job at CERN and created the W3C to make sure this never happens again.But recently, two well-known companies have started to ignore the W3C. Now there is a new browser war, but this time it’s on smartphones.
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.
Same thing happens with DOM APIs in JavaScript.OWP gaining loads of new APIs; not supported straight away.So Web developers use browser sniffing.[click]E.g. Here, check if client is using WebKit. If they do, they use exciting new feature. If not, they probably use a horrible workaround.Problem: What if a different layout engine one day supports the new API?[click]Better to use feature detection.E.g. Use if statement to check if addEventListener is supported. Otherwise, use a different feature.Web developers also make this kind of mistake in JavaScript. The Open Web Platform has been gaining loads of new APIs in the past five years, but not every layout engine will support them straight away.What some developers do to get around this is to check what layout engine you’re using. This is called browser sniffing. If you’re using WebKit, you get to use the new feature, and if you’re not, you have to use a horrible workaround that probably doesn’t work as well. The problem with this approach is… well… What if you’re using Gecko, and Gecko one day supports the new API? Because the Web developer that made this script used browser sniffing, you’ll still have to put up with the work around.A better way to do this is using feature detection. With this technique, the developer checks if your layout engine supports the feature he wants you to use. If the engine doesn’t support it, then he uses the workaround.
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.
