In der Firma hab ich das schon erledigt. Da steht jetzt "Ein Haufen Scheiße"

Neuer Name und Image polieren reicht heutzutage leider nicht. Meine Idee für Microsoft, entwickelt den "sichersten Browser" der Welt und implementiert die neuesten Webstandards.

Nachdem Microsoft die Entwicklung des IE mit Version 7 wieder aufgenommen hat, habe ich den Hass auf den IE nie verstanden. Vor allem nicht, als alle damals anfingen den grottenlangsamen FireFox zu installieren.

Versteh ich auch nicht. Das können nur Leute sein die den aktuellen IE nie benutzt haben. Beim webkit JavaScript Benchmark lässt der IE 11 alle anderen um Längen hinter sich.

Der IE 11 kann alle Webstadards und zwar in der Stadard Schreibweise und nicht mit so einem Mist wie - moz und -webkit.

1. Alle Webstandards kann Internet Explorer noch lange nicht.
2. Du hast nicht verstanden wozu diese "Vendor Prefixes" überhaupt sind. Siehe hier

Der IE 11 kann alle Webstadards und zwar in der Stadard Schreibweise und nicht mit so einem Mist wie - moz und -webkit.

[…]
Updating Internet Explorer in Windows Phone 8.1 Update

We gathered all of this compatibility data and then we began to plan what changes we should make to IE. The remainder of this blog post discusses some of the most important changes and the rationale for why we made them. The issues affecting mobile web sites fall primarily into five main categories:

• Faulty browser detection not recognising IE as a mobile browser and giving the desktop experience
• Using only old webkit-prefixed features that have been replaced by standards
• Using proprietary webkit-prefixed features for which there is no standard
• Using features that IE does not support with no graceful fall-back
• Running into interoperability bugs and implementation differences in IE

Changing the User Agent string

One of the most significant issues we saw was related to sites not detecting that IE on Windows Phone is a mobile browser and therefore providing desktop content. This often results in sites displayed with tiny text that you need to zoom in to read and then pan around. It also often means more data is transmitted over the phone's data connection because the content isn't mobile optimised. Images are large and many more ads are downloaded and shown.

[…]

We updated the User Agent string in IE on Windows Phone to increase the number of sites that would correctly deliver the best mobile content. This continues an unfortunate pattern that all browsers have had to deal with and most web developers have run into. For example, there is an interesting discussion from as early as 2006 in a WebKit bug entitled "Safari lies. Reports itself as Mozilla, Gecko and KHTML too." When we shipped IE11 on the desktop, we added the token "like Gecko" to the string because it significantly improved compatibility with desktop sites. Chrome and Opera claim to be like Gecko and Safari in order to be compatible with web content.

Mapping legacy webkit-prefixed features to IE implementation

After changing the user agent string so that IE receives the same content as other phone browsers we could begin to analyse issues that were breaking mobile experiences. The first important problem we identified was that many mobile sites only send webkit-prefixed content for CSS gradients, flexbox, transitions, and animations. These are features that IE11's web standards-based engine already supports for sites with cross-browser mark-up. As Mozilla found, WebKitCSSMatrix is commonly used on mobile devices. IE supports MSCSSMatrix. Many sites also use window.orientation instead of the emerging standard screen.orientation. The second problem we found here is that sites also often use old syntax in their code. For example, using the old gradient syntax instead of the updated standards based approach.

In Windows Phone 8.1 Update, we added a mapping of popular webkit-prefixed APIs to the standards based support already part of IE11. This means that sites that only send WebKit code are translated into standards based code as the page loads. We are not planning to support all webkit-prefixed APIs. We have added mappings for the ones that are so prevalent in mobile sites that the web won't work without them.

Adding support for non-standard proprietary features

We found a small number of non-standard features popularised by Apple on the iPhone in widespread use. These features are not currently on a standards track but browsers that don't support them can't provide a good experience for top sites on the mobile web. One example is -webkit-appearance, which allows a page to modify the styling of an element to match native applications. As Mozilla points out, "not only is it non-standard, but its behavior changes from one browser to another." Unfortunately, without some level of support for these non-standard proprietary features, web sites are more difficult to use.

New features supported in IE

There are several standards-based features that IE11 didn't support that are used infrequently on desktop sites, but are in common use in the mobile web. Once we made IE11 receive more mobile content we determined that we would need to add these features. For example, window.locationbar is defined in HTML5 but rarely used on desktop sites. We prioritised implementing several new features based on the mobile sites they enabled.

One of the larger API-related issues affecting compatibility with mobile sites is support for touch. In IE10, we shipped support for Pointer Events, which is now a Candidate Recommendation at W3C, and we updated the implementation in IE11 to incorporate changes in the spec. Using Pointer Events provides many performance and functional advantages to sites that wish to use either mouse, touch, pen or other pointer inputs and we continue to recommend this as the best API for sites that work for users across all of their devices.

On the mobile web, most sites have been coded to use the older Touch Events model and users expect those sites to just work. In the IE11 update, we added support for touch events so that these sites would work correctly. Our research has shown that on the desktop web, enabling touch events on a device that also supports a mouse (like Windows tablets and 2 in 1 devices) causes more problems—for example, we found that mouse and trackpad support is broken on about 10% of top sites when Touch Events are enabled. Many sites don't expect to be able to receive touch events and mouse events and only support one or the other. We have joined other browser vendors in the W3C Touch Events Community Group to work through these issues for the web at large. We'll talk more about pointer and touch events in a future post.

What can you do?

Many of the changes we've made are specifically targeted at consuming legacy or vendor prefixed content published on these sites. It is not our goal to support all the -webkit- vendor prefixed APIs. While we will continue our outreach efforts to encourage these sites to adopt standards-based mark-up, the support we've added is necessary today for the mobile web to just work. You can help here too if you see sites using non-standard code: we are collaborating with Mozilla at webcompat.com to record broken sites. These sites often cause issues across multiple browsers including Firefox and IE and it is easy for you to report problematic sites.

If you are a web developer, run your site through the scanner tool on http://modern.ie. This tool will identify common coding problems including issues with vendor prefixes and help you fix your code.

When taken all together, the changes we have made to IE in Windows Phone 8.1 Update dramatically improve compatibility with the most popular mobile web sites. The update is rolling out to those of you already on the Windows Phone 8.1 Preview for Developers and will roll out to consumers with devices running Windows Phone 8.1 in the coming months. We have also published a comprehensive list of all the changes in the IE Developer Guide on MSDN.

Im Gespräch war vor ein paar Jahren Microsoft-intern durchaus auch, bzgl. der Rendering-Engine für den Internet Explorer nicht mehr auf die eigene zu setzen sondern auf WebKit. Schlussendlich hatte man sich bei Microsoft bzw. beim IE-Team aber dann dagegen entschieden und dafür, bei der eigenen zu bleiben und diese weiterzuentwickeln, wie man sehen kann.

Da kann ich nur sagen "Gott sei dank" wenn ich die JavaScript Performane vergleiche.

Wie kommst du darauf das die JS-Performance von IE 11 so überwältigend sein soll?

Dann nenn mir doch mal einen.

At #web3d2014 Microsoft announce they joined #khronos and will participate in #webgl working group. Warm welcome to @frankolivier and team!

Hell just froze over. RT @neilt3d: At #web3d2014 Microsoft announces they joined #khronos and will participate in #webgl working group.

@neilt3d @frankolivier How many decades did this take? I mean, how late are they to the party?

Einen? Hier hast du eine ganze Liste von nicht implementierten Standards im Vergleich IE, Firefox und Chrome in den jeweils aktuellen Versionen:

Richtig lesen hilft manchmal. Der erste den ich mir gegriffen habe, tab-size ist editors draft: W3C schreibt: The following features are at risk, and may be droped during CR period. Wir reden hier von W3C Standards!!!

Wenn du Editors Drafts benutzt bist du selber Schuld.

Ein einziges Beispiel ist natürlich stellvertretend für die ganze Liste.
Wie gesagt, du hast nicht verstanden wozu Vendor Prefixes sind.

Nur sollte man dann das auch so kommunizieren.

ExtremeTech (02.08.2012): Valve: OpenGL is faster than DirectX — even on Windows

@ MacTechNews:

"eindeutig nicht positiv"?

Was ist denn das für ein Deutsch? Wie wäre es mit:

"eindeutig negativ"?

das war 2012; mittlerweile dürfte es wohl anders sein.

Soweit ich weiß, ist das zwischen DirectX und OpenGL immer ein Ping-Pong-Spiel.