16. • Out-of-the-box Windows 10 browser
• Desktop, Mobile, Xbox. Hololens, IOT…
• Evergreen and constantly updated
• On par with other browsers
• Free upgrade for Windows 7 and 8 to
Windows 10
• Very, very soon this will matter to us as
developers
17. I am not here to tell
you about browser
speed and feature
comparisons…
18. Instead, I want to
report to you how
the browser was
created…
Faceymcface1 https://www.flickr.com/photos/12335386@N00/4337808731
24. “The web should just work for everyone – users,
developers, and businesses.”
25. If standard defines an API
behavior but all other
browsers behave differently, is
it a standard?
Interoperability means the web “just works”
if ($.client.profile().name === 'msie') {
var IHateIE = {
'scrollTop': context.$textarea.scrollTop(),
'pos': context.$textarea.textSelection('getCaretPosition', {startAndEnd:
true})
};
context.$textarea.data('IHateIE', IHateIE);
}
For some reason IE seems to be
calculating that differently. You
might have to put in a special
rule for IE there.
In Chrome, the error does not occur, the xml is
appended successfully and the other methods after
these two run as expected. In IE however, a
hierarchyRequestError is thrown at the appendChild
statement.
no matter HOW I passed the ko object
to the child window, something got lost.
Horrible behavior, IE...
Why does the following code throw an
'Unspecified error' (on the appendChild
line) in IE11 which I click the button?
27. Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/39.0.2171.71 Safari/537.36 Edge/12.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/600.1.25 (KHTML, like Gecko)
Version/8.0 Safari/600.1.25
Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/40.0.2214.93 Safari/537.36
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
User-Agent Strings
28. Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/39.0.2171.71 Safari/537.36 Edge/12.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/600.1.25 (KHTML, like Gecko)
Version/8.0 Safari/600.1.25
Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/40.0.2214.93 Safari/537.36
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
User-Agent Strings
29. Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/39.0.2171.71 Safari/537.36 Edge/12.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/600.1.25 (KHTML, like Gecko)
Version/8.0 Safari/600.1.25
Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/40.0.2214.93 Safari/537.36
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
34. Please don’t do UA sniffing
Please avoid UA sniffing as much as
possible
Always do feature detection
(If isolating a bug) Sniff for specific browser versions
Assume unknown browsers are good
38. Font Resource Handling
Before loading font resources, IE and
Firefox check the font server’s CORS
header, and the font’s installable header
(as per W3C specification).
This is done to ensure that the font
usage rights are honored.
WebKit does not check CORS /
installable header.before after
39. Control Appearance Overrides
Apple added ways to restyle HTML controls on the
iPhone to match OS control look and feel.
Web developers add custom markup to disable
Apple’s styles and provide their own.
-webkit-appearance: none ← Most common value.
-webkit-appearance: button
-webkit-appearance: checkbox
-webkit-appearance: radio
etc..
before after
40. Control Appearance Overrides
Some sites restyle input controls using
-webkit-appearance: none for
critical functionality.
before after
41. Gradients
Apple originally added support for gradients to WebKit using a
Core Graphics friendly syntax.
During standardization the syntax was changed leaving WebKit
incompatible with the standard. Some sites continue to use the
original Apple syntax.
Proprietary Apple Markup (still in WebKit):
-webkit-gradient(linear, left top, right bottom, colorstop(0,
#FFFFFF), color-stop(1, #00A3EF));
Webkit-prefixed W3C Standard Gradient in WebKit:
-webkit-linear-gradient(top left, #FFFFFF 0%, #00A3EF 100%);
Unprefixed W3C standard:
linear-gradient(to bottom right, FFFFFF 0%, #00A3EF 100%);
before after
67. Join in and help build a
browser for you
uservoice.modern.ie
status.modern.ie
remote.modern.ie
insider.windows.com
@codepo8
Editor's Notes
Today I want to talk about web development and what went wrong. I also want to talk about us running out of excuses to make the web an excellent medium for our users to get their information fix.
Hello, I am Chris. I’ve been a web developer for about 17 years now and delivered lots of big products and sites. Until recently I was the principal spokesperson for Mozilla, advocating HTML5 and talking about its merits for development on Desktop and Mobile.
I got a lot of people excited, but once I finished my presentations at the after parties or on Twitter I always heard the same thing. Internet Explorer keeps people from building great stuff on the web.
This even became a running gag – people asked if it is HTML5 and if it didn’t work in IE, it must be HTML.
This made me angry, as - whilst being a joke – it points at a basic misunderstanding of the web.
So I took drastic measures. I went to work for the company that seemingly holds the web back.
However, as developers we got a bit over-excited about what Safari, Chrome and Firefox offered us as new and shiny functionality. And we didn’t care if it was a standards or experimental features.
The reason is simple: most of us use Macs. That way, testing and even staying up to speed what IE supports became a chore. Something you only do in testing.
Which makes us ask the question if IE even matters. Surely if the cool people of the web use Macs, everybody else does, too?
Some statistics say differently and when you get out of our bubble, you’ll encounter more and more PCs than you thought were still around.
Even on the “captive audience” statistics, IE is on second place before Firefox and Safari.
The reason is that users click what comes with the operating system. The out-of-the-box browser matters a lot. People don’t install a different browser for the sake of web functionality. They do it because of access to services.
IE11 was not a bad browser in terms of standards support.
The problem was that we didn’t care as IE was considered the browser of the outdated OS. Microsoft advocated standards compliance, where innovation was what we wanted. It didn’t matter what new IE could do as all we saw was the old browsers we had to work around that didn’t get updated.
Well that’s over with. Windows 10 soon will come with a new browser, that does all the things we expect a browser to do.
I will not tell you about features, comparisons and speed today. Microsoft Edge is very good in comparison. But that’s boring. As a developer, I expect the out-of-the-box browser to be excellent and better than the ones that come in as guests.
Today I want to cover a few of the things that lead to the new browser in Windows 10 and what it means for web development. We’re covering four topics.
The main point was that Internet Explorer was not a browser people wanted to use, but had to . And developers really didn’t want to use at all. Patching and cleaning up the browser was not really an option. The engine it ran, Trident, was woefully outdated and full of things that people did not use as they weren’t standardised.
So instead, we created a fork of the browser, keeping all the “plumbing” that made it talk to windows, but allowing us to create a cleaner, leaner web rendering engine that is on par with the other browsers like Chrome, Safari or Firefox.
Interoperability is what all of this is about. We wanted to ensure that there is no need for another browser in Windows 10 than the one it got shopped with. That’s why we built a browser that works with the web of today and beyond.
We know that with its age, the experience of end users differed a lot to other browsers. This meant for web developers extra work and often you needed to fix your code only to work in Internet Explorer. This hurt the browser’s reputation and wasted your time. That’s why we approached re-building the browser from scratch slightly different this time.
At the center of the redesign of the browser is this mantra – the web should just work for everyone – users, developers and businesses. This sounds simple, but there are a lot of moving parts in this and at times we have to juggle competing needs. Users simply want the web to work, click the browser icon and go online. Any change is scary and everything was better before – until you get used to the change and then defend this one to the teeth the next time around. Developers want browsers to lead innovation and to give them new and shiny things all the time whilst not breaking what is already done. This becomes especially complex when the products were based on experimental implementations of technology and not agreed standards. Businesses only want their web sites not to break and not having to assign engineers to fix them. Maintenance is not fun and harder to budget than new products. In order for the web to keep succeeding, browser makers need to keep doing this tight-rope walk.
In the past the focus of Microsoft was standards compatibility. This is a necessity for a lot of enterprise customers. For those, quick iterative innovation isn’t possible as there is a need for certification and reliance on legal procedures. It also prevents us from the problem that Internet Explorer caused in the past that it did things differently to other browsers and thus leaving developers confused as to which one to follow. The problem with standards is though that they take time and lots of agreement between browser creators. A lot of standards defined by the W3C are not supported by browsers. Instead, browser vendors agreed on – in many cases – simpler versions of the same functionality. In many cases, these versions were also easier to implement for the browser maker. This leads to a lot of code on the web that “just works”, but isn’t standardised. Instead of staying in an ivory tower and claiming the Windows 10 browser supports an unused standard to the letter, we started following the crowd and making things work that are in use.
In order to make the web just work, the biggest issue is that in many cases developers send different versions of the same web site to different browsers. That way browser makers can not fix issues, as they never show up. This is a great example of this. The mobile view of this web site looks and works utterly different in Firefox, Safari and Internet Explorer. This not only means it is hard to improve the experience of the browser, it also means that developers need to maintain different versions for different browsers. In most cases, this means that one gets 90% of the effort and the others hopefully work. This is bad for the web, as it advocates the need for a certain browser or device to get the correct experience.
Trying to detect the browser is not easy. The main tool that people use is the User Agent String. This should tell you what browser is in use. The problem is though that because people relied on a certain browser to display their web sites, the user agents became longer and longer and more and more cryptic. Browsers have to pretend to be other browsers to ensure that web sites build long ago show up in them.
A lot of these “pretend identifiers” stay in the user agent string – the big one being “Mozilla/5.0” which was the identifier to determine it is not Internet Explorer.
Many of these identifiers are legacy and point at browsers that are not in use at any longer, like Netscape, Mozilla Phoenix which later on became Firefox or Konqueror.
Anyone remember Mozilla 5.0 and knows what it is? It’s actually Netscape Navigator 6, from the year 2000
Having to pretend to be a different browser for things on the web to even show up has become so normal that even the HTML5 standard advocates it. The product name and the application code name are constants and hard-wired to Gecko and Mozilla.
This is a legacy caused by web developers relying on browsers and not writing towards a standard. And it does hurt the web.
This is an actual UA sniffing example in use on the web today. It should determine if the current browser is a mobile one. It fails with Windows Phones.
User Agent sniffing is a terrible idea. You rely on a string that could be anything and can be faked and you build for a certain browser at a current moment in time. You are keeping the web from becoming truly interoperable and you’re doing the main thing we as developers hated browser makers for: telling us what browser to use.
Of course, there are exceptions when there are deadlines to be met and certain bugs to work around. However, when you sniff out a browser, at least check for the version and assume that browsers not known to you do the right thing. In other words, patch the problem, rather than blocking everything for future releases.
When creating Microsoft Edge, the team looked at interoperability and what is missing or what all browsers have in common. This diagram is not to scale but should give you an idea how much overlap there is between different browsers. Notice that what’s considered “the mobile web” is mostly about Chrome and Safari, with Android and iOS being the big players here. This leads to a lot of code written exclusively for these browsers. Opera is missing, but that’s because it uses the Blink engine of Chrome and Opera Mini – whilst being a massive mobile player – is a service rather than a browser as your code gets changed on the fly to support low-end devices.
With Microsoft Edge, the team remove all the legacy code that was exclusive to Internet Explorer and concentrated on the mobile web as the fastest growing part of the market. This is why we made Microsoft Edge pretend to be other browsers and tested the web in it. We looked at thousands of web sites and checked what didn’t work.
We receive an amazing amount of data on site compatibility and I’ll talk more about that in a moment.
To make sense of it all, we use a classification system to prioritize what we invest in to maximize its impact.
At the top of this priority list is what we call “Interop 0”, these are sites that worked in IE11 but no longer work in Microsoft Edge. Sometimes this is because we goofed, but most often it’s because we’re now getting interoperable content and need to make a change to behave like other browsers. So beyond just ensuring a site continues to work, we’re also reducing the delta in behavior of our engine when compared with other engines.
Next there is Interop 1 issues, these are ones that affect Microsoft Edge but also were broken in IE11. Often these are new standards that are being adopted by the web. So we implement them.
Next we have Interop 2, these are things that are typically emerging in standards. They may or may not be supported by any browser at the moment. Generally, sites aren’t yet adopting these features quite yet but we anticipate they will in the near future.
Finally there’s the Interop 3 bucket, these are things that are still in the idea or iteration stage or are supported but deprecated in other browsers with very low or 0 usage on the web. Some features in this bucket will eventually make it to Interop 2 once standards solidify and developer interest increases. Others are on their way out and may never get implemented in our engine.
One example of this: when loading fonts IE and Firefox check that the font is ready to be installed. Webkit doesn’t do that. This leads to a broken experience in IE11. With Edge, we deliberately violate the definition of the standard to ensure that the display of fonts works out.
FYI:
Feature 602898
http://www.w3.org/TR/css3-fonts/
CSS Fonts Module Level 3
W3C Candidate Recommendation 3 October 2013
4.9 Font fetching requirements
For font loads, user agents must use the potentially CORS-enabled fetch method defined by the [HTML5] specification for URL's defined within @font-face rules. When fetching, user agents must use "Anonymous" mode, set the referrer source to the stylesheet's URL and set the origin to the URL of the containing document.
The implications of this for authors are that fonts will typically not be loaded cross-origin unless authors specifically takes steps to permit cross-origin loads. Sites can explicitly allow cross-site loading of font data using the Access-Control-Allow-Origin HTTP header. For other schemes, no explicit mechanism to allow cross-origin loading, beyond what is permitted by the potentially CORS-enabled fetch method, is defined or required.
Another very common use on the web is to use –webkit-appearance to make things look different to what they are and override the original look and feel. This leads to broken sites in non-webkit browsers. In this case, this is not that problematic.
However, in other cases developers relied heavily on this feature and make the site impossible to use if the browser doesn’t support it. For example here were the lack of labels wouldn’t allow me to know which checkbox I activated.
Gradients are another big issue. There is a massive difference between the original Apple proposal and what ended up in the specification. Sadly enough, not many web sites upgrade the original syntax which can lead to white buttons with white text.
In addition to looking at thousands of web sites, the team also actively monitors developer channels and finds long-standing bugs in IE that need removing in Edge. One of those was the issue of child element references getting deleted when the parent element got removed with innerHTML.
To date, over 4000 of these fixes are in Microsoft Edge – and more will come.
Of course, adding new features doesn’t really make for a better browser, unless we also remove some of the cruft that slowed the browser down over the years. In the case of Edge, this meant that we got rid of a lot of IE-only code, with the biggest part being the different document modes.
It makes developers really happy to remove code. Like, really happy. So let’s take a moment to see all the things we were able to remove…
Let’s take a second to review the non-interoperable IE’isms we’ve removed thus far.
Testing lots of web sites by hand gave the team a lot of insight, but to ensure we really learn what is going on we needed to tap into more information.
The first thing the team did was to rely on the 3+ million users of the Microsoft insiders program to give us feedback what works and what doesn’t. This helped with a lot of problems with large sites. However, even that doesn’t quite scale to the size of the web. Unless the insiders are really prolific:
“So we’re done once each one of them browses 11 million pages”
That’s the bread and butter of a web crawler though, so we thought we’d use the Bing crawler to our advantage. We built a low-level version of the Edge engine and added an instrumentation layer that gives us insight on the standard and non-standard use of all the pages indexed by the crawler. We then added this information into a database and improved the engine with the results.
One of the results of this crawler experience is that XPATH – an older and seemingly obscure W3C standard not supported in IE – is used by sites and sometimes for very crucial content. For example the prices on the TomTom site.
Even worse, on this lotto site I would never know if I’ve won when the browser doesn’t support Xpath.
Instead of implementing a heavy xpath engine for a seemingly small amount of web sites, the team made an assumption: wouldn’t it be possible to do most Xpath queries these days using the CSS selector engine. CSS selectors have gotten pretty powerful in the last iterations.
As it turns out, this assumption was good: 94% of the Xpath in the wild could be traversed using CSS selectors, thus piggy-backing on the engine already in the browser.
With a bit of tweaking of the CSS engine, the team reached 97% success rate. Of course, this still leaves 3% without functionality, which could be fatal for the site.
Instead of implementing Xpath, the rest of the 3% is now covered using a JavaScript solution called Wicked Good Xpath. This is an open source engine which got converted to internal JS to the browser. We also started contributing to this library, using some of the findings of the Bing crawler to make it better.
Of course, none of this means that we’re not implementing and contributing to standards any longer – on the contrary. With a new engine implementing newer technology we have a much better chance to get some of the bleeding edge work standardised.
Status tracks 193 standards or proposals – this doesn’t include the baseline stuff supported IE8+
The HTML5 spec alone is 693 pages when printed.
Microsoft has 90 members in 58 different Working Groups (avg amongst top 5 browser makers is ~80)
So you can imagine how easy it is for browsers to behave differently or for specs to have mistakes.
For the future work we’re planning everything in the open. On status.modern.ie you can see what is being implemented, what is being worked on and what is under consideration.
These are just a few examples of what got added to Edge. This changes constantly, so make sure you come back to the status page.
More things are in the making, and it would be helpful for you to test the implementations with us.
You might wonder what “under consideration” means in the case of the Edge team. Well, like any other team, we have to juggle dependencies and demand and we are looking at various parts of this. We look at real world usage data in other browsers, as what developers want is not necessarily what they are using. We look at developer and partner feedback. We check how stable a standard is before we implement it as we don’t want to disappoint developers and of course we have to see where the time of our developers is used to the most effect.