Wie wir an den bisherigen HTML5-Artikel gesehen haben, ist HTML5 nicht etwas für die ferne Zukunft, sondern es bereits im Hier und Jetzt angekommen. Alle modernen Browser unterstützen wichtige Teile des Funktionsumfangs schon heute und kein Browserhersteller macht Anzeichen, das Aufrüsten einzustellen. HTML5 ist die Gegenwart, HTML 4.01 und XHTML 1 die Vergangenheit. Da stellt sich natürlich die Frage, was die Zukunft denn nun anstelle von – oder ergänzend zu – HTML5 für uns bereit hält. Was bringt CSS3? Wohin wird sich JavaScript entwickeln? Und wann kommt HTML6?
Aufgrund der im Geolocation-Artikel angesprochenen Probleme, “HTML5” genau zu definieren (allgemeiner Sprachgebrauch versus Spezifikationen versus Mehrfach-Spezifikationen) ist es nicht ganz einfach, eine Zukunftsvision zu formulieren. Klar ist allein: die Anzahl der nützlichen APIs in Webbrowsern wird in Zukunft nicht weniger werden. Viele neuere Browserreleases enthalten allerlei von HTML5 inspirierte Schnittstellen, die sich, wenn sie sich auf breiter Front durchsetzen sollten, als nützlich erweisen könnten – genannt seien als Beispiel die von Chrome bereits unterstützten Dateisystem- und Notification-APIs. An Spielzeug wird es dem experimentierfreudigen Webentwickler in Zukunft sicher nicht fehlen.
Etwas spannender ist die Frage, wohin das Nebeneinander von W3C und WHATWG führen wird. Die beiden Spezifikationsausfertigungen, die zwischenzeitlich beide als einigermaßen gleichberechtigte HTML5-Specs verstanden werden konnten, entwickeln sich mittlerweile in unterschiedliche Richtungen. Während das Werk der W3C-Arbeitsgruppe auf einen Snapshot des aktuellen HTML5-Entwicklungsstandes hinaus zu laufen scheint, hat die die WHATWG ihre Fassung zum „Living Standard“ erklärt und dokumentiert darin auch das Neueste vom Neuen. Was immer es an Neuentwicklungen im HTML-Universum gibt, die WHATWG-Spezifikationen nehmen sie nahtlos auf, während sich das W3C auf eine saubere Darstellung des stabilen Status Quo von vor ein paar Monaten konzentriert.
Das Ganze scheint für den Moment stabil, aber was passiert, wenn das W3C mit HTML5 fertig ist? Die WHATWG-Line besagt, dass HTML5 das Ende der Geschichte ist und dass alle Neuerungen nahtlos darin einfließen. HTML6 wird es demnach nie geben, eine versionierte Entwicklung von HTML sei angesichts der ständigen und schnellen Entwicklung von Webtechnologie überholt. Genau deshalb gibt in in “HTML5” auch kein Leerzeichen vor der 5 im Namen – das ist keine Versionsnummer, sondern “HTML5” ist ein eigenständiger Name. Diese Pläne kollidieren natürlich leicht mit den althergebrachten Versionierungsplänen des W3C. Wie all das endet, ob das Nebeneinander zementiert wird oder man sich vielleicht eines Tages auf eine gemeinsame Arbeitsgruppe (oder zumindest eine gemeinsame inhaltliche Linie) einigt, ist noch nicht abzusehen.
CSS3 wird manchmal mit HTML5 in einen Topf geworfen – manche sprechen sogar von “Web8” als Kombination aus HTML5 und CSS3. Allerdings ist diese Zusammenfassung schon etwas weit hergeholt, denn nicht nur haben beide Technologien historisch nichts miteinander zu tun, auch ist die Zielsetzung unterschiedlich. Während HTML5 die Welt mit Webapplikationen revolutionieren möchte, hat CSS3 eher allgemein gehaltene Neuerungen an Bord, die nicht nur für Webapplikationen, sondern auch für ganz normale Webseiten taugen. Neue Gestaltungsmittel kann man immer gebrauchen.
Diese neu eingeführten Gestaltungsmittel sind sehr zahlreich; die Anzahl der CSS-Eigenschaften hat sich im Vergleich zu CSS2.1 mehr als verdoppelt. Es gibt neue Möglichkeiten Farben anzugeben, Farbverläufe können erstellt werden, mehrere neue Layout-Techniken werden eingeführt und auch die Schriftgestaltung kommt nicht zu kurz. All das ist sowohl für Webseiten als auch -Applikationen nützlich und nur wenige Ausnahmen wie die appearance-Eigenschaft brechen aus dieser allgemeinen Auslegung der Neuerungen aus. Mit appearance kann man HTML-Elementen das aussehen von nativen UI-Elementen geben und so zum Beispiel Links wie Checkboxen aussehen lassen:
appearance
a { appearance:checkbox; }
Das ist vermutlich für normale Websites von eher überschaubarem Nutzwert, kann aber helfen, Look & Feel von Webapplikationen besser an native Apps anzupassen. Allerdings ist die Unterstützung für appearance noch in allen Browsern nur sehr rudimentär vorhanden, was aber nicht für alle CSS3-Features gilt.
CSS3 ist keine monolithische Spezifikation, sondern ist in Module aufgeteilt. Diese Module werden komplett unabhängig voneinander entwickelt und sind verschieden weit gediehen und von so-gut-wie-Standard-Spezifikationen bis zum experimentellen Erstentwurf ist alles dabei. Der W3Viewer bietet ein bequemes Interface für den Modul-Dschungel. Aufgrund des Modulsystems gibt es ähnlich wie bei HTML5 keinen Tag X, an dem CSS3 fertig ist. Einige Teile wie das Farben-Modul oder CSS3-Selektoren sind seit Jahren stabil und in modernen Browsern einheitlich implementiert, andere haben noch einen langen, steinigen Weg vor sich.
Als Brendan Eich seinerzeit von den Netscape-Bossen genötigt wurde, innerhalb weniger Tage eine Programmiersprache für den Browser zusammenzuschustern, erschuf er mit JavaScript etwas, das es (in der Theorie) leicht macht, schnell kleine Scripts für Websites zu schreiben. Geplant war, dass Java-Applets für alle größeren Aufgaben aufnehmen und JavaScript nur für Kleinigkeiten zum Einsatz kommt. Die Geschichte nahm dann doch einen etwas anderen Verlauf und während Java-Applets heute wie ein Relikt aus der Altsteinzeit wirken, ist JavaScript (dem Web und HTML5 sei Dank) heute die verbreitetste und vielleicht schon wichtigste Programmiersprache der Welt. Das Problem daran ist, dass JavaScript für diese Aufgabe einfach nicht gebaut wurde.
Eich hatte nur wenige Tage Zeit, eine komplette Programmiersprache zu erfinden und für diese Umstände ihm ist JS sehr gut gelungen. Dennoch hat JavaScript einige Macken: null hält sich für ein Objekt, with {}produziert absolut Unvorhersehbares und unter welchen Umständen this in einer Funktion welches Objekt referenziert, ist komplizierter als Quantenfeldtheorie. Hinzu kommt, dass die Möglichkeit, jedes Objekt zu jeder Zeit beliebig zu verändern, heute mehr ein Ärgernis als ein Feature ist. Bastelt man nur ein kleines Script für eine Webseite, ist es ein Segen, dass man mal eben schnell Prototypen nativer Objekte erweitern oder Methoden überschreiben kann. Bei großen Webapplikationen gerät dies jedoch zu einem Problem, da man die Robustheit kritischer Programmteile nicht mehr garantieren kann. Des weiteren leiden Mammutprojekte wie Mini-Scripts unter dem etwas schmalen Sprachumfang von JavaScript, der das Schreiben von unnötig viel Boilerplate-Code nötig macht. Rettung naht in Form von ECMAScript5 und ECMAScript Harmony.
null
with {}
this
Der Name des Standards, der den JavaScript-Implementierungen der Browser zugrunde liegt, lautet ECMAScript und ECMAScript5 (kurz ES5) ist die nächste auf uns zukommende Ausfertigung von JavaScript. Hier werden mit kleineren Verbesserungen einige der Geburtsfehler von JS ausgebügelt. So wird ein Strict Mode, in dem z.B. with {} nicht mehr erlaubt ist, eingeführt und es werden dringend benötigte Funktionen wie Array.isArray() nachgerüstet. Das Einfrieren von Objekten ermöglicht die robustere Ausgestaltung von Scripts und es lassen sich Getter- und Setter-Methoden für einzelne Objekt-Eigenschaften definieren. Die ES5-Spezifikationen sind seit Ende 2009 fertig und Browser der neuesten Generation (Internet Explorer 9, Firefox 4, Chrome 10) unterstützen es bereits in großen Teilen.
Array.isArray()
ECMAScript Harmony ist einer der diversen blumigen Namen für die auf ES5 folgende ECMAScript-Version. An Harmony wird zur Zeit fleißig gearbeitet und der genaue Funktionsumfang ist noch nicht sicher, doch dass diesmal Änderungen von erheblicher Tragweite auf uns zukommen, ist abzusehen. Mit let statt var wird man Variablen deklarieren können, die nicht an einen Funktions- sondern an einen Blockkontxt gebunden sind, das arguments-Objekt wird eingestampft, es wird ein Modulsystem und Iteratoren geben. Viel von all dem steht bisher nur auf dem Papier, oder, wie im Falle von Brendan Eichs Wunschzettel Harmony Of My Dreams im Netz. Eine Ausnahme bildet die mächtige Proxy-Metaprogrammierungs-API, die man bereits heute vollumfänglich im Firefox 4 ausprobieren kann.
let
var
arguments
Wie wir gesehen haben, ist die Zukunft in Form von HTML5, CSS3 und JavaScript-Updates bereits in den modernen Browsern gelandet. Damit entstehen neue Möglichkeiten für Entwicklung von Webapplikationen und in etwas geringerem Umfang gibt es auch neues Spielzeug für den Bau althergebrachter Websites. Was aber sind die Auswirkungen auf jene, die die neuen Webapps und -Seiten bauen?
Der Alleskönner-Webworker könnte in näherer Zukunft aussterben seltener werden. Jene, die neben dem Webdesign auch das HTML erledigen und das Endprodukt in ein CMS einprogrammieren, werden es angesichts der zunehmenden Komplexität aller WWW-Technologien und der damit verbundenen Themenbereiche (Performance, Barrierefreiheit) schwer haben. Spezialisierung ist das Zauberwort! Dies dürfte auch deshalb nötig sein, weil es immer schwieriger werden wird, auf den einzelnen Spezialgebieten auf dem neuesten Stand zu bleiben.
An das, was wir heute als “HTML5-Chaos” wahrnehmen, also dass extrem viele Neuerungen von Browsern extrem unterschiedlich gut unterstützt werden, können wir uns nämlich langfristig gewöhnen. Die Phase, als der Internet Explorer allein den Markt beherrschte und es statt ständiger Weiter- und Neuentwicklung stabile Standards gab, war eine Anomalie. Die aktuelle Entwicklungsgeschwindigkeit, die ein wenig dem im ersten Browserkrieg vorgelegten Tempo gleicht, scheint der Normalzustand des WWW zu sein, der nur dann unterbrochen wird, wenn ein Browser Marktanteile im 90%-Bereich verzeichnen kann und damit die Innovation blockiert.
Da dieses Szenario zur Zeit nicht abzusehen ist (es gibt mehr Browservielfalt als je zuvor) kann man die ruhigen Zeiten wohl zu den Akten legen – immer vorausgesetzt, man ist tatsächlich daran interessiert, die Möglichkeiten der Browser voll auszuschöpfen. Wer in Zukunft nur halbwegs statische Webseiten umzusetzen gedenkt, kann die Lage etwas entspannter sehen. Alle anderen dürfen in Zukunft wie zu seligen Netscape-Zeiten wieder intensiver mit den kleinen und großen Eigenheiten der diversen Browsern zu ringen haben.
Peter Kröner ist selbstständiger Webdesigner und -entwickler, Autor des HTML5-Buchs und Dozent für alle Fragen rund um HTML5 aus der Nähe von Osnabrück. Auf peterkroener.de bloggt er über alle Themen rund um Web(zukunfts)technologie.
Microsoft hat einen Wettbewerb für HTML5-Entwickler gestartet. Bei Interesse schaut einfach bei www.beautyoftheweb.com/#/unplugged vorbei.
Im Oktober letzten Jahres hatte ich auf unsere umfassende Blogserie zu Internet Explorer Einstellungen hingewiesen. Wir haben diese Reihe jetzt auch um die Einträge zu Internet Explorer 9 aktualisiert und auf Wunsch in herunterladbaren Dokumenten für die Offline-Nutzung zusammengefaßt:
IE8:
IE9:
Vielen Dank an das deutsche Internet Explorer Support-Team, welches sich die Mühe gemacht hat, jede einzelne Einstellung auf Deutsch zu dokumentieren.
Have fun! Daniel
HTML5 bietet uns mit vielen neuen JavaScript-APIs das Rüstzeug, um die Webapplikationen der Zukunft zu bauen, aber auch für normale Websites sind interessante Features an Bord. Neben einer Unzahl kleiner und kleinster Änderungen, die jedem Webentwickler das Leben einfacher machen, gibt es auch eine Handvoll waschechter Neuheiten, namentlich neue HTML-Elemente. Diese sind dringend nötig, denn die HTML5-Vorgänger HTML 4.01 und XHTML 1 beinhalten beide eine Auswahl an Elementen, die 1997 festgelegt wurde und auf das Web von heute nicht mehr so recht passt.
Die durchschnittliche Website von Anno 1997 ist mit dem, was wir heute so sehen vom Aufbau her nicht zu vergleichen. Sofern man sich damals überhaupt eine ausgetüftelte Seitenstruktur zulegte, setzte man diese mit Frames um – das war damals auch das absolut angemessene Mittel der Wahl. Im Web von heute erfolgt die Einteilung einer Seite durch das HTML selbst, was zur Folge hat, dass Websites heute zu 90% aus dem<div>-Element zu bestehen scheinen. Uns das ist eigentlich ein absolut unnötiges Ärgernis, denn mittlerweile haben sich gewisse Mittel der Strukturierung etabliert. Fast jeder Seite hat irgendwelche Formen von Kopf-, Fuß-, Haupt- und Seitenbereichen. HTML5 gibt uns erstmals eigene HTML-Elemente hierfür.
<div>
Der erste Neuling ist das <section>-Element. Es nimmt an allen den Stellen den Platz des <div>-Elements ein, an denen ein inhaltlicher Abschnitt von einem anderen getrennt werden muss. Das <div> ist damit nicht ausgestorben –an jeder Stelle, an der man einfach irgendein Container-Element braucht, ist es weiterhin das Mittel der Wahl. Das <section>-Element ist allein für die Einteilung in Sinnabschnitte da. Ein naher Verwandter ist das <article>-Element, das ebenfalls Sinnabschnitte einteilt, aber für in sich geschlossene Serien-Inhalte steht, etwa für Blogposts, Forennachrichten oder Kommentare unter einer News-Meldung. Für angefügte Informationen steht das <aside>-Element bereit, das sich beispielsweise auf Website-Ebene für Seitenleisten oder innerhalb eines Abschnitts als Containerelement für Metainformationen anbieten würde.
<section>
<article>
<aside>
Für Kopf- und Fußbereiche von sowohl ganzen Seiten als auch einzelnen <section>-und <article>-Elementen stehen <header> und <footer> bereit. Beide dürfen ihrerseits keine <header>- oder <footer>-Elemente enthalten, unterliegen aber sonst keinen Einschränkungen. Das <nav>-Element dient letztlich zur Auszeichnung von Navigationen. Es sollte nur auf wichtige Navigationsblöcke verwendet werden – nicht jeder kleine Link braucht ein eigenes <nav>.
<header>
<footer>
<nav>
Ein mit den neuen Elementen ausgezeichnetes Blog könnte wie folgt aussehen:
<header> <h1>Das HTML5-Blog</h1> <nav> <a href="/">Startseite</a> <a href="/about.html">Über dieses Blog</a> </nav> </header> <section id="hauptspalte"> <article> <h2>Ein toller Beitrag über HTML5!</h2> <p>Text Text Text</p> <aside class="metainformationen"> <p>Geschrieben am 12.08.2010</p> </aside> </article> <article> <h2>Ein älterer Beitrag über HTML5!</h2> <p>Text Text Text</p> <aside class="metainformationen"> <p>Geschrieben am 10.08.2010</p> </aside> </article> </section> <!-- Ende der Hauptspalte --> <aside id="sidebar"> <h2>Sidebar</h2> <section> <h3>Tagcloud</h3> <p>Tags Tags Tags</p> </section> <section> <h3>Blogroll</h3> <p>Link Link Link</p> </section> </aside> <!-- Ende der Sidebar --> <footer> <p>© 2011 HTML5-Blog</p> </footer>
Die neuen strukturierenden Elemente verhalten sich in (modernen) Browsern ähnlich wie <div>-Elemente. Sie haben auf den ersten Blick keine besonderen CSS-Eigenschaften und verhalten sich wie generische Block-Elemente. Tatsächlich haben aber einige der Neulinge (<section>, <article>, <aside>) große Auswirkungen auf die Überschriftenstruktur der Webseite und tun nebenbei noch etwas für die Barrierefreiheit.
Die neuen strukturierenden Elemente haben eingebaute ARIA-Attribute. ARIA (Accessible Rich Internet Applications) ist eine Spezifikation der Web Accessibility Initiative des W3C, die neue HTML-Attribute für barrierefreie Webanwendungen festlegt. Mit ihnen lassen sich aus generischen HTML-Elementen zusammengebaute Widgets für Screnreader und andere Assistenztechnologien verarbeitbar gestalten. Ein Beispiel:
<div id="fortschritt"> <div id="anzeige">25%</div> <div style="width:25%;" id="abgespielt"></div> </div>
Diese Konstruktion wird mit etwas CSS schnell zu einem sehr ansehnlichen Fortschrittsbalken – vorausgesetzt man hat zwei gesunde Augen. Screenreader würden hier nur einen Haufen unzusammenhängender <div>-Elemente zu sehen und entsprechend wäre der Nutzer des Screenreders aufgeschmissen. Aber ARIA hilft:
<div id="fortschritt" role="progressbar" aria-valuemin="0" aria-valuemax="100" aria-valuenow="25" > <div id="anzeige">25%</div> <div style="width:25%;" id="abgespielt"></div> </div>
Die wai-*- und role-Attribute machen es möglich, dass Assistenztechnologien wie Screenreader unser Widget nicht nur als Fortschrittsbalken erkennen, sondern sie geben auch gleich alle zur Interpretation der Anzeige nötigen Zahlen mit.
wai-*
role
Eine genauere Einführung in WAI-ARIA würde an dieser Stelle den Rahmen sprengen; als empfehlenswerte Lektüre sei an dieser Stelle die deutschsprachige Einführung in WAI-ARIA verlinkt. Wichtig ist für uns, dass erstens HTML5 WAI-ARIA nahtlos integriert (man also die ARIA-Attribute nutzen kann ohne dass der HTML-Validator meckert) und dass zweitens viele Elemente in HTML5 eingebaute ARIA-Eigenschaften haben. So hat etwa das <nav>-Element immer das eingebaute role-Attribut navigation. Man muss es also dort nicht selbst eintragen und wenn man etwas anderes als navigation angeben würde, wäre es ein Fehler (und eigentlich ja auch recht widersinnig). Nur bei wenigen Elementen darf man das eingebaute role-Attribut überscheiben – so hat etwa das <article>-Element die vorgegebene Rolle article, darf jedoch alternativ auch die Rollen application, main oder document tragen.
navigation
article
application
main
document
Die komplette Liste der vorgegebenen ARIA-Attribute ist den HTML5-Spezfikationen zu entnehmen. Zu beachten ist, dass noch nicht alle Browser diesen ganzen Problemkomplex perfekt beherrschen – über die Einzelheiten gibt html5accessibility.com Auskunft.
Während man die HTML 4.01 und XHTML 1 durch die Elemente <h1> bis <h6> auf sechs Überschriften-Ebenen beschränkt ist, kann man in HTML5 unendlich viele Überschrift-Ebenen – und das obwohl man weiterhin nur die Elemente <h1>bis <h6> zur Verfügung hat. Wie das? Nehmen wir erst mal als Beispiel den folgenden HTML-Schnipsel:
<h1>
<h6>
<h1>HTML5</h1> <h2>Neue Elemente</h2> <h3>Das Section-Element</h3>
Die so abgebildete Dokument-Struktur ist die Folgende:
HTML5 Neue Elemente Das Section-Element
Der Abschnitt “Neue Elemente” ist ein Unterabschnitt von “HTML5” und “Das Section-Element” ist ein Unterabschnitt von “Neue Elemente”. Würde man nun die neuen HTML5-Elemente zum Einsatz bringen um den Schnipsel strukturieren, würde das Ergebnis wie folgt aussehen:
<h1>HTML5</h1> <section> <h2>Neue Elemente</h2> <section> <h3>Das Section-Element</h3> </section> <section>
Der Clou ist nun, dass auch dieses HTML die Struktur des Schnipsels korrekt abbilden würde:
<h1>HTML5</h1> <section> <h1>Neue Elemente</h1> <section> <h1>Das Section-Element</h1> </section> <section>
Jedes Mal, wenn ein neues <section>-, <article>-, <aside>- oder <nav>-Element geöffnet wird, beginnt darin die Zählung der durch <h1> bis <h6> bezeichneten Überschrift-Ebenen von neuem, allerdings eine Hierarchieebene tiefer als in dem umgebenden Abschnitt. Moderne Browser wie der Internet Explorer 9 oder der Firefox 4 zeigen die so ermittelte Struktur auch optisch an. Obwohl in dem Dokument nur <h1>-Überschriften vorkommen, werden sie im folgenden Screenshot entsprechend ihrer Position in der Gesamtstruktur abgebildet, so dass die untergeordneten Überschriften das Aussehen von <h2> und <h3> annehmen:
<h2>
<h3>
Wenn in dem neu geöffneten Abschnitt keine <h1> vorhanden ist, beginnt die Zählung bei der höchstrangigen Überschrift die zu finden ist, so dass tatsächlich jeder der genannten Codeschnipsel gültiges HTML5 ist – allerdings ermöglicht nur das letzte Beispiel mit seinen <h1>-Überschriften und den verschachtelten <section>-Elementen die Verwendung unendlich vieler Überschrift-Ebenen. Zumindest ist das die Theorie. Noch unterstützen nicht alle Browser dieses HTML5-Feature und auch wie Suchmaschinen und Screenreader nach HTML5-Muster aufgebaute Dokumente verarbeiten, ist noch nicht umfassend erforscht. Vorsicht ist also geboten.
Neben den neu eingeführten Elementen werde durch HTML5 einige alte Bekannte reaktiviert, die im Strict-Modus von HTML 4.01 und XHTML 1 eigentlich schon abgeschafft waren. So sind etwa <i>, <b> und <hr> in HTML5 wieder da, allerdings mit einer semantischen Bedeutung und nicht als reine Designelemente. Zwar werden sie im Browser noch immer dargestellt wie seit jeher, doch dieser Darstellung kann man bekanntlich mit CSS zu Leibe rücken. Was bleibt ist die neue semantische Bedeutung der ehemaligen Präsentationselemente. Einige Beispiele:
<i>
<b>
<hr>
<s>
Die komplette Liste der auf diese Weise umdeklarierten Elemente würde zusammen mit den vielen Detailänderungen an anderen alten Bekannten den Rahmen dieses Artikels sprengen. Einen guten Überblick bietet HTML: The Markup Language Reference, eine zusammengestrichene Fassung der HTML5-Spezifikationen, die nur Informationen über neue und geänderte HTML-Elemente enthält – kryptische JavaScript-APIs bleiben außen vor.
Die neuen (und alten, aber umdeklarierten) HTML5-Elemente kommen dem von Div-Suppen gestressten Webentwickler wie gerufen, aber es ist nicht alles Gold was glänzt. Ältere Browser, insbesondere die Internet Explorer 6 bis 8, sind auf die neuen semantischen Elemente nicht gut zu sprechen und wie Suchmaschinen eines Tages die Umstellung zur Auswertung von Überschriften nach HTML5-System managen werden, weiß auch noch niemand. Es ist also Vorsicht geboten und man sollte in jedem Fall sein HTML5-Markup gründlich testen. Und validieren sollte und kann man sein Werk auch – der gute alte HTML-Validator kann HTML5 genau so gut prüfen wie HTML 4.01 oder XHTML 1.
Heute schrieb mir ein Leser eine Email und bat darin um weitere Informationen zu einem Problem, welches beim Installieren von Windows 7 Service Pack 1 auftreten kann:
Hallo Daniel, ich habe eine "kleine" Bitte an Dich. Im heise News-Forum wurde am 11.3. eine Meldung eingestellt, dass sich Berichte über Probleme bezüglich der Installation des SP1 für W7 Rechner in einer Domäne häufen (www.heise.de/.../Probleme-mit-Windows-7-Service-Pack-1-1206714.html). Dort wurden auch BLOGS aus der Microsoft Umgebung zitiert. Kannst Du in Deinem BLOG dazu Stellung nehmen ? Wie akut ist das Problem aus Deiner Sicht tatsächlich ? Allein das die Meldung bei heise an einem Freitag eingestellt wird vermittelt mir eher das Gefühl, das es "mal wieder" um "Einschaltquoten" ging... ist dort leider sehr auffällig. Trotzdem denke ich eine Stellungnahme von MS zu diesem vermeintlichen Problem wäre nicht schlecht, denn auch ich werde von Kunden zum Thema gefragt. Danke für Deine Bemühung im Voraus.
Eine Reihe weiterer Webseiten griffen das Thema auch schon auf:
Der für den Heise-Artikel verantwortliche Redakteur Axel Vahldiek hatte mich eine halbe Stunde vor Veröffentlichung des Artikels am Freitagnachmittag ebenfalls um eine Stellungnahme gebeten. Nach Rücksprache mit unseren Supportkollegen schrieb ich ihm ein paar Stunden später als erste Antwort, dass bei uns im Support das Problem schon bekannt ist und wir es bereits analysieren.
In Deutschland gab es bis jetzt nur wenige Anfragen, das Problem scheint eher vereinzelt und selten aufzutreten. In den allermeisten Fällen konnte unser Support das Problem schnell lösen. Folgende (von uns aktualisierte) Informationen stünden für betroffene Kunden, direkt zur Selbsthilfe greifen wollen, zur Verfügung:
Der im Heise-Artikel beschriebene Link zu weiteren Lösungshilfen aus dem Blog meines Kollegen Joseph Conway ist mittlerweile abgelöst worden durch einen neueren, in den unsere bisherigen Erkenntnisse eingeflossen sind:
Weitere Informationen stellt auch der Autor Günter Born auf seinem Blog zusammen:
Update am 05.04.2011
Zur Zeit sind mehrere Problemquellen als Ursache verdächtig. Bis die genauen Gründe für dieses Problem gefunden sind, lautet die gegenwärtige Empfehlung für die Installation von Service Pack 1, das Service Pack separat von allen anderen Updates einzuspielen, die notwendigen Reboots zeitnah durchzuführen und den Updatevorgang nicht zu unterbrechen (auch wenn dafür ein wenig Geduld erforderlich ist).
Das Problem kann dann auftreten, wenn ein Anwender das Service Pack 1 installiert, den Computer nicht neu startet, wenn er dazu aufgefordert wird und danach weitere Updates einspielt. Während der Service Pack-Installation pflegt Windows eine Liste von Aufgaben, die es zu erledigen gilt. Einige können sofort durchgeführt werden, andere erst nach einem Neustart. Eine derartige Liste ist die Primitive Operation Queue (POQ). Aufgaben in der POQ, welche nach einem Neustart auszuführen sind, werden in der Datei pending.xml gespeichert.
Das oben genannte Problem tritt dann auf, wenn Windows während der Service Pack Installation nicht neu gestartet wird und weitere Updates danach eingespielt werden. Die Aufgaben in der POQ-Liste werden dann ein zweites Mal ausführt. Der zweite Ausführungsversuch schlägt jedoch fehl, da die POQ-Liste bereits abgearbeitet wurde und erzeugt den Fehler “0xc0000034”.
Windows behandelt jeden Fehler in diesem Pukt des Updateprozess als Blocker und der Servicing Stack hält den Computer an. Das Problem kann demnach auch auftreten, wenn man das Service Pack zusammen *gleichzeitig* mit weiteren Updates über WSUS ausrollt.
Service Pack 1 sollte daher separat von allen anderen Updates eingespielt und die notwendigen Reboots zeitnah durchgeführt werden.
Kunden, die schon von der Fehlermeldung 0xc0000034 betroffen sind, sollten den Lösungsvorschlag aus dem KB-Artikel Your computer may freeze or restart to a black screen that has a "0xc0000034" error message after you install Windows 7 Service Pack 1 or a Windows Vista service pack umsetzen oder sich direkt an unseren Support wenden, wenn sie die Schritte zur Selbsthilfe nicht selbst umsetzten können. Der Support (Chat/E-mail/Telefon) für Windows 7 SP1 ist (bis auf die Telefongebühren) kostenfrei: https://support.microsoft.com/oas/default.aspx?prid=14174&gsaid=642673.
Unsere Teams arbeiten mit Hochdruck an der Problemanalyse und werden entsprechende Empfehlungen unverzüglich zur Verfügung stellen, sobald wir die Hintergründe genau verstehen und eine Lösung erarbeitet haben.
Gefühlte 90% aller HTML5-Demos im Web verwenden das Canvas-Element. Das machen sie auch nicht ohne Grund, denn das Element und seine APIs ermöglichen etwas Spektakuläres, das vorher in Browsern nicht möglich war: das Zeichnen und Animieren beliebiger Formen und Farben, bis auf den letzten Pixel kontrollierbar. Das Canvas-Element eröffnet ganz neue Möglichkeiten, die weit über das über die bunten Kästchen hinausgehen, die man allein CSS und JavaScript durch den Browser schubsen kann, von statischen Diagrammen bis zum 3D-Shooter kann man alles rendern, was das Herz begehrt. Beispiele gefällig?
Gefühlte 90% aller HTML5-Demos im Web verwenden das Canvas-Element. Das machen sie auch nicht ohne Grund, denn das Element und seine APIs ermöglichen etwas Spektakuläres, das vorher in Browsern nicht möglich war: das Zeichnen und Animieren beliebiger Formen und Farben, bis auf den letzten Pixel kontrollierbar.
Das Canvas-Element eröffnet ganz neue Möglichkeiten, die weit über das über die bunten Kästchen hinausgehen, die man allein CSS und JavaScript durch den Browser schubsen kann, von statischen Diagrammen bis zum 3D-Shooter kann man alles rendern, was das Herz begehrt. Beispiele gefällig?
<video>
Bei so vielen Möglichkeiten versteht es sich von selbst, dass das Element über eine nicht gerade kleine Sammlung von API-Methoden verfügt, die man nicht mal eben zwischendurch auswendig lernen kann. Hinzu kommt, dass die API auf recht niedrigem Level ansetzt und nur die Funktionalität bietet, die es für jeden Anwendungsfall bieten muss.
So gibt es etwa keine Funktion, die einen Kreis zeichnen kann, denn nicht jede denkbare Canvas-Anwendung braucht so etwas – möchte man eine Kreisfunktion haben, muss man sie sich selbst schreiben. In den meisten Fällen wird man als Webentwickler nicht mit den normalen Canvas-Funktionen arbeiten, sondern mit Frameworks, die auf die Standardfunktionen aufsetzen.
Die größten Herausforderung liegen in den Besonderheiten von Pixelgrafik-Animationen und der händischen Programmierung dieser. Das Implementieren von Framebuffern oder Framerate-Limitern war bisher nicht täglich Brot eines Webentwicklers, aber wer mit dem Canvas-Element flüssige Animationen erschaffen möchte, kommt um diese Sorte fremdartiger Probleme nicht herum. Es gibt also viel neues zu lernen – packen wir es an!
Es liegt in der Natur der Sache, dass wir im Rahmen dieses kleinen Artikels nicht den vollen Umfang der Canvas-API besprechen können. Selbst eine bloße Funktionsreferenz ohne zusätzlich Erklärungen würde viele Seiten füllen. Wir werden uns also auf einige konkrete Anwendungsbeispiele beschränken und daran Teilaspekte des Canvas-Elements beleuchten. Zunächst müssen wir aber ein solches Element in unser HTML5-Dokument setzen:
<canvas id="canvas" height="480" width="600"> Dein Browser kann kein Canvas-Element. Dir entgeht unser tolles Anwendungsbeispiel! </canvas>
Der Text zwischen dem öffnenden und dem schließenden <canvas>-Tag wird nur dann angezeigt, wenn der Browser das Element nicht darstellen kann. Die height- und width-Angaben verhalten sich wie bei einem <img>-Element – sie geben zwar die Größe des Elements vor, können aber von entsprechenden CSS-Regeln auch überstimmt werden.
<canvas>
<img>
Öffnet man diese Konstruktion jetzt in einem halbwegs modernen Browser (Firefox 3.5+, Opera 10+, Safari 4+, Chrome oder Internet Explorer 9) sieht man aber erst mal gar nichts. Das Canvas-Element ist in der Tat nichts weiter als eine leere Leinwand, die wir mit JavaScript befüllen müssen – ohne Programmierung läuft nichts. Also programmieren wir doch einmal etwas:
window.onload = function(){ var canvas = document.getElementById('canvas'); if(canvas.getContext){ var context = canvas1.getContext('2d'); context.fillStyle = "rgb(255, 0, 255)"; context.fillRect(20, 20, 300, 240); } }
Das Ergebnis sieht dann schon mal zumindest nicht nach Nichts aus:
Zur Erläuterung: Zeile 1 des Codeschnipsels (window.onload...) sorgt nur dafür, dass der folgende Code erst ausgeführt wird, wenn die Seite fertig geladen ist. Dann wird mit document.getElementById() eine Referenz auf das Canvas-Element in der Seite geholt und in Zeile 3 wird geprüft, ob das Element die Methode getContext() kennt. So kann zwischen Browsern mit Canvas-Unterstützung und jenen ohne unterschieden werden.
window.onload...
document.getElementById()
getContext()
Die getContext()-Methode dient dazu, Zugriff auf die Zeichen-APIs (Kontexte genannt) des Canvas-Elements zu bekommen. In Zeile 4 wird auf diese Weise der Kontext mit der ID 2D in der Variablecontext gespeichert. Der 2D-Kontext ist der Standard-Zeichenkontext von HTML5, ein 3D-Kontext ist aber auch in Entwicklung. Der 2D-Kontext bietet uns mehrere Zeichenfunktionen und -Attribute, mit denen wir unsere Canvas zum Leben erwecken können.
2D
context
In Zeile 5 wird ein solches Attribut, fillStyle (legt die Füllfarbe für alle folgenden Zeichenoperationen fest), auf Magenta festgelegt und Zeile 6 zeichnet mit dieser Farbe im Hinterkopf ein 300×240 Pixel großes Rechteck, dessen linke obere Ecke um je 20 Pixel auf X- und Y-Achse von der linken oberen Ecke des Canvas-Elements verschoben ist. Fertig ist unser „Hallo Welt“ für Canvas!
fillStyle
Der schwarze Rahmen wurde übrigens mit herkömmlichem CSS eingefügt. Da das Canvas-Element ein HTML-Element wie jedes andere ist, kann man es uneingeschränkt mit CSS und JavaScript traktieren – jQuery-Animationen und CSS3-Transformationen inklusive.
Auch wenn dieses Beispiel eher wenig praktische Relevanz hat, zeigt es einige der wichtigsten Prinzipien: Erstens laufen alle Zeichenoperationen über die API des Kontexts, nicht des Elements selbst, und zweitens müssen die Variablen für Zeichenoperationen erst gesetzt werden, bevor gezeichnet wird. Wir entscheiden uns erst für Magenta als Farbe und zeichnen danach.
Zeit für ein paar Beispiele mit (ein wenig) mehr Praxisbezug. Ein besonders praktisches Feature des Canvas-Elements ist, dass man es nicht zwingend händisch mit bunten Rechtecken füllen muss, sondern (unter anderem) per <img> eingebundene Bilder als Datenquelle nutzen kann. Und hat man diese Bilder einmal auf die Canvas gebracht, kann man sie Pixel für Pixel manipulieren.
Mit der Kontext-Methode drawImage() kann man ein im Dokument vorhandenes Bild auf die Canvas bannen. Man nehme dazu ein Bild sowie Canvas-Element …
drawImage()
<img id="original" height="320" width="406" src="original.jpg" alt=""> <canvas id="canvas" height="320" width="406"></canvas>
… mache gebrauch von der drawImage()-Methode …
window.onload = function(){ var original = document.getElementById('original'); var canvas = document.getElementById('canvas'); if(canvas.getContext){ var context = canvas.getContext('2d'); // Original-Bild auf die Canvas zeichnen context.drawImage(original, 0, 0); } }
… schon kann man das Bild 1:1 kopieren (Original-<img> links, Canvas-Element rechts):
So weit, so unspektakulär. Hat man aber erst mal das Bild auf ein Canvas-Element gebracht, kann man mit der MethodegetImageData() Zugriff auf die Farbwerte jedes einzelnen Pixels bekommen und kann diese dann nach Herzenslust manipulieren. Als Argumente für getImageData() muss man die Eckpunkte des Canvas-Ausschnitts angeben, für den man die Pixel abgreifen möchte (Koordinaten der linken oberen Ecke + Maße des Ausschnitts).
getImageData()
Zurück erhält man ein Objekt, dessen Eigenschaft data ein Array mit den Farbwerten aller Pixel im Ausschnitt enthält –erst kommt der Rot-Wert des ersten Pixels, dann der Grün-Wert des ersten Pixels, der Blau-Wert des ersten Pixels, der Alpha-Wert des ersten Pixels, dann der Rot-Wert des zweiten Pixels und so weiter.
data
Wenn man in diesem Array nun alle RGB-Werte modifiziert (z.B. die Farben einfach umdreht) und das Endergebnis mit putImageData() wieder zurück auf die Canvas schreibt, macht das Ergebnis schon etwas mehr her:
putImageData()
window.onload = function(){ var original = document.getElementById('original'); var canvas = document.getElementById('canvas'); if(canvas.getContext){ var context = canvas.getContext('2d'); // Original-Bild auf die Canvas zeichnen context.drawImage(original, 0, 0); // Pixeldaten auslesen, in imgData speichern var imgData = context.getImageData(0, 0, canvas.width, canvas.height); var r, g, b, i = 0; // Alle Pixel durchlaufen ... while(i < imgData.data.length){ // ... Rot-Wert umkehren ... imgData.data[i] = 255 – imgData.data[i++]; // ... Grün-Wert umkehren ... imgData.data[i] = 255 – imgData.data[i++]; // ... Blau-Wert umkehren ... imgData.data[i] = 255 – imgData.data[i++]; // ... und den Alpha-Wert unverändert lassen i++; } // Verändertes imgData auf die Canvas zeichnen context.putImageData(imgData, 0, 0); } }
An dieser Stelle ist erwähnenswert, dass aufgrund der Same-Origin-Policy Bilddaten nicht auf lokalen Daten (z.B. c:\foo.html) hin- und herkopiert werden können; der Aufruf über einen richtigen Host (z.B. localhost) ist Pflicht.
c:\foo.html
Das Canvas-Element ist ein HTML-Element wie jedes andere, man kann es via CSS stylen, anklicken, und JavaScript-Funktionen in die normalen DOM-Events einhängen. Also ist eine dynamische Malfläche, Paint im Browser, kein Hexenwerk. Man nehme ein Canvas-Element und ein paar <div>-Elemente nebst CSS-Styles …
<style> div, canvas { cursor:crosshair; border:1px solid black; float:left; margin:1em; } div { cursor:pointer; height:40px; width:80px; } </style> <canvas id="canvas" height="320" width="406"></canvas> <div id="red" style="background:red;"></div> <div id="blue" style="background:blue;"></div> <div id="green" style="background:green;"></div>
… und schon steht die Oberfläche für unser Canvas-Malprogramm:
Die bunten Boxen dienen zur Auswahl der Farbe, mit der auf dem Canvas-Element gemalt werden soll. Sie zum Funktionieren zu bringen ist einfach: beim Klick auf eine Farbbox muss sich nur context.fillStyle (wir erinnern uns, das ist der Wert, der die Füllfarbe für alle folgenden Zeichenoperationen festlegt) passend ändern.
context.fillStyle
var context = document.getElementById('canvas').getContext('2d'); // Rote Farbe wählen document.getElementById('red').onclick = function(){ context.fillStyle('red'); } // Blaue Farbe wählen document.getElementById('blue').onclick = function(){ context.fillStyle('blue'); } // Grüne Farbe wählen document.getElementById('green').onclick = function(){ context.fillStyle('green'); }
Schon fehlt nur noch die Programmierung des Zeichnens selbst. Hierfür nutzen wir das Mousemove-Event auf dem Canvas-Element und schalten bei den Mousedown- und Mouseup-Events zwischen „aktivem“ und „inaktivem“ Modus hin- und her, so dass nur gezeichnet wird, wenn auch tatsächlich die Maustaste gedrückt ist.
Ein hilfreiches Detail, das das folgende Codeschnipsel nutzt, ist dass die Kontext-Variable in ihrer Eigenschaft canvas immer eine Referenz auf das Canvas-Element, zu dem der Kontext gehört, bereithält. So ist die Programmierung der Events ein Kinderspiel:
canvas
// Aktiv-Modus hin- und herschalten var active = false; context.canvas.onmousedown = function(){ active = true; } context.canvas.onmouseup = function(){ active = false; } // Nur zeichnen wenn "active" true ist, d.h. die Maustaste gedrückt ist context.canvas.onmousemove = function(event){ var x = event.clientX - context.canvas.offsetLeft; // Mausposition X var y = event.clientY - context.canvas.offsetTop; // Mausposition Y if(active){ context.fillRect(x - 5, y - 5, 10, 10); } }
Und fertig! Schon kann man drauflosmalen:
Abspeichern kann man sein fertiges Meisterwerk im übrigen ganz einfach per Rechtsklick → Datei speichern unter.
Die beiden bisher gezeigten Beispiele sind etwas krude ausgefallen. Der Grund dafür liegt in der Canvas-API selbst, die sich wie eingangs erwähnt auf die allernötigsten Funktionen beschränkt. Sie kennt von Haus aus keine Objekte oder Animationsfunktionen, hat keine Methode für Kreise an Bord und macht einem ganz allgemein das Leben schwer. So muss man selbst für simpelste Grafiken wie dieses Strichmännchen …
… in Canvas-Code mit den diversen Pfad-Funktionen viel zu viel tippen:
// Körper context.beginPath(); context.moveTo(240, 100); context.lineTo(240, 200); // Beine context.lineTo(190, 250); context.moveTo(240, 200); context.lineTo(290, 250); // Arme context.moveTo(240, 150); context.lineTo(190, 150); context.moveTo(240, 150); context.lineTo(290, 150); // Linien ziehen context.lineWidth = 4; context.strokeStyle = '#CC0000'; context.stroke(); context.closePath(); // Kopf context.beginPath(); context.arc(240, 80, 35, 0, Math.PI * 2, false); // Linien ziehen und füllen context.fillStyle = '#CC0000'; context.fill(); context.stroke(); context.closePath();
Was tun? Frameworks oder andere Hilfsmittel bauen! Die Canvas-API ist gar nicht dafür gedacht, dass man direkt mit ihr Grafiken programmiert, sondern dass JavaScript-Bibliotheken auf sie aufsetzen oder dass IDEs den Canvas-Code generieren. Ein Framework zu programmieren ist kein Hexenwerk; mit nur 60 Zeilen Framework-Code lässt sich das Strichmänchen dank verketteter Befehle gleich viel einfacher zusammenbauen:
// Körper context.moveTo(240, 100).lineTo(240, 200); // Beine context.lineTo(190, 250).moveTo(240, 200).lineTo(290, 250); // Arme context.moveTo(240, 150).lineTo(190, 150).moveTo(240, 150).lineTo(290, 150); // Linien ziehen context.set({'lineWidth': 4, 'strokeStyle': '#CC0000'}).stroke().closePath(); // Kopf context.beginPath().arc(240, 80, 35, context.deg2rad(0), context.deg2rad(360), false); // Linien ziehen context.set('fillStyle', context.get('strokeStyle')).fill().stroke().closePath();
Canvas-Frameworks gibt es bereits wie Sand am Meer. Einige sind, wie das gezeigte Verkettungs-Framework, eher allgemeiner Natur, andere auf spezielle Aufgabengebiete zugeschnitten. Eine kleine Auswahl:
Das Canvas-Element haucht unseren Browsern ganz neue Möglichkeiten ein – wo man buchstäblich jede nur denkbare Grafik rendern kann, sind der Kreativität keine Grenzen gesetzt. Zwar sind einige fiese Klippen, die zum Beispiel das Themen Barrierefreiheit und Performance betreffen, noch nicht endgültig umschifft, doch alles in allem ist das Canvas-Element ein Werkzeug, mit dem wir in naher Zukunft sicher viel Vergnügen haben haben. Es funktioniert in allen modernen Browsern zuverlässig (mit diesem Trick sogar in den Internet Explorern 6 bis 8) und bietet viel Potenzial – was will man mehr?
Da das Thema “64-bit” auch vor dem Internet Explorer nicht halt macht, hat sich Eric Lawrence (Program Manager des Internet Explorer Teams und Autor der Fiddler Software) vor einiger Zeit mit einem Q&A dem Thema angenommen, hier nun die deutsche Übersetzung:
F: Kann ich eine 32-bit Version des Internet Explorers auf einem 64-bit Windows installieren? A: Auf 64-bit Windows Betriebssystemen sind sowohl die bekannten 32-bit als auch die neuen 64-bit Komponenten installiert. Dazu zählt auch der Internet Explorer. Aus Kompatibilitätsgründen ist der 32-bit Internet Explorer auch als Standardbrowser konfiguriert.
F: Wie kann ich feststellen, welchen Internet Explorer ich aktuell verwende? A: Dies lässt sich auf mehreren Wegen feststellen:
F: Wie kann mittels server- (z.B. .NET) bzw. clientside (z.B. Javascript) Scripting/Coding herausgefunden werden, welche Internet Explorer Version eingesetzt wird?A: Die einfachste Methode ist das Auswerten des User-Agent Strings:
vgl. hierzu “Detect IE Bitness (32-bit/64-bit)”
F: Warum ist die 64-bit Version des Internet Explorers nicht der Standardbrowser auf 64-bit Systemen? A: Das Problem mit 32-bit vs. 64-bit ist, dass es nicht möglich ist eine 32-bit DLL im Kontext eines 64-bit Prozesses zu laden und umgekehrt. Da die meisten ActiveX Controls und BHOs aber in 32-bit erstellt werden/wurden, würde einem Nutzer der 64-bit Version ggf. Funktionalität genommen. Damit also die User Experience unverändert bleibt, hat das Internet Explorer Team die Entscheidung gefällt, dass - vorerst - als Standardbrowser der 32-bit Internet Explorer genommen wird.
Neben diesen offensichtlichen Gründen gibt es noch einen weiteren Grund: Der JustInTime (JIT) Script Compiler wurde (noch/derzeit) nicht für die 64-bit Version des Internet Explorer’s portiert (auch in IE9 nicht!). Daher ist grade bei aufwändigen Javascript Applikationen die 32-bit Version vorzuziehen.
F: Gibt es denn trotzdem sinnvolle Gründe für den Einsatz von Internet Explorer 64bit?A: Es gibt derzeit eigentlich keine wirklichen Gründe. Hier ein paar Gründe die wir öfter hören, die sich aber insb. durch die geringere Anzahl an ActiveX Controls erklären lassen und diesen Gründen sind wir bei der Änderung des default Verhaltens nach der Installation von ActiveX Controls im Internet Explorer 9 entgegen getreten:
F: Warum wurde dann überhaupt eine 64bit Version des Internet Explorers erstellt? A: Da der Internet Explorer, bzw. die Mehrzahl seiner Komponenten, Bestandteile des Betriebssystems ist. Diese Komponenten sind insb. die Netzwerkkomponenten (URLMon für das Handling aller Namen und der verwendeten Zonen, WinINET für die Netzwerkkommunikation), sowie die Rendering Engine (MSHTML) und bedingt (s.o.) auch die Scripting Engines (JScript(9) und vbscript). Da ein Windows Betriebssytem ohne diese Komponenten nicht auskommen kann, wurde diese selbstverständlich für die 64-bit Systeme portiert und das Portieren der “iexplore.exe” war dann der geringste Part.
Hier ist also erkennbar, dass derzeit der Internet Explorer 64-bit eher für das Betriebssystem als für den Benutzer erstellt wurde. Dies mag sich in der Zukunft ändern, derzeit können wir dies aber noch nicht absehen.
Gastposting von Stephanus Schulte, Windows Platform Support Escalation Engineer bei der Microsoft Deutschland GmbH.
Anmerkung von Daniel Melanchthon am 21.03.2011:
Der eine oder andere hat vielleicht schon mitbekommen, dass Internet Explorer 9 seit heute in der finalen Fassung vorliegt und unter www.internet-explorer9.de heruntergeladen werden kann. Nachdem ich die letzten zwei Tage mit technischen Briefings rund um IE9 verbracht habe, endet damit für mich hoffentlich auch eine Zeit mit sehr wenig Schlaf. Am Montag hatten wir im Hamburger Planetarium eine eindrucksvolle Kulisse für den Launch:
Gemeinsam mit unseren Partnern RTL, Freenet und TÜV Trust IT stellten wir den geladenen Pressevertretern, Bloggern und anderen Teilnehmern Internet Explorer 9 vor. Nach den Vorträgen und einer allgemeinen Frage- und Antworten-Runde beantwortete ich noch in Einzelinterviews die noch offengebliebenen Fragen von einer Reihe von Reportern.
Anschließend ging es dann in das Konzert von Katy Perry in der Alsterdorfer Sporthalle. Da merkt man deutlich, wie alt man mittlerweile geworden ist :-) Wer sich jetzt fragt, was wir mit Katy Perry zu tun haben: Microsoft stellt zum Start von Internet Explorer 9 unter www.hol-dir-die-stars.de exklusiv vor dem offiziellen Verkaufsstart 100.000 Downloads von Katys neuem Dance Hit “E.T.” (Benny Benassi RMX radio-edit) kostenlos zur Verfügung. Auch ohne Internet Explorer 9 zeigen wir acht weitere Videos und exklusiv das Livekonzert aus London 2010 in HD.
Heute Morgen ging es dann früh nach München, wo ich auf der nächsten Presseveranstaltung als Sprecher auftrat. Danach folgten weitere Interviews. Zwischendurch habe ich noch eine Reihe von Fragen auf der Internet Explorer-Facebookseite beantwortet.
Da ich über Internet Explorer 9 schon eine ganze Menge geschrieben habe, möchte ich hier die Gelegenheit nutzen, einen Blick hinter die Kulissen des Entwicklungsprozesses zu werfen:
Wenn es ein HTML5-Feature gibt, von dem jeder schon gehört hat, dann ist es die Geolocation-API. Sie demonstriert eine wichtige Wahrheit über HTML5, nämlich dass das Thema, obwohl es “HTML” im Namen trägt, doch vielmehr mit JavaScript als mit HTML-Tags zu tun hat. Der Grund ist klar: wie im ersten Teil der Artikelserie erwähnt, soll HTML5 einer der Bausteine für die Webapplikationen der Zukunft sein und diese Applikationen werden viel Arbeit in den Client, also den Browser, verlagern. Und wenn man den Browser programmieren möchte, ist eben JavaScript die Waffe der Wahl.
Die Geolocation-API spezifiziert eine einheitliche DOM-Schnittstelle, über die Scripts Geoinformationen vom Browser beziehen können. Dem Browser ist dabei freigestellt, woher er diese Informationen nimmt – sie könnten aus altmodischer IP-Lokalisierung stammen, aus den Standortinformationen des Betriebssystems abgefragt werden oder im Falle von Mobilgeräten aus dem eingebauten GPS-Chip oder der aktuellen Funkzelle stammen.
Der Vorteil für den Webentwickler ist, dass man einerseits eine einheitliche Schnittstelle in allen Browser zur Verfügung hat und dass man sich andererseits selbst keine Gedanken mehr um einzelne Geolocation-Techniken machen muss: man bestellt einfach die Koordinaten und der Browser liefert sie aus der besten Quelle, die ihm zur Verfügung steht.
Bei der Geolocation-API handelt es sich dabei wirklich um eine stabile und in allen (modernen) Browsern vorhandene Schnittstelle, vom Firefox 3.5 bis zum Internet Explorer 9 bieten alle Surfprogramme gute Unterstützung. Die Spezifikationen selbst haben seit Ende 2010 den Status “Candidate Recommendation” und stehen damit kurz davor, zum fertigen Webstandard geadelt zu werden. Und da neben aller Verbreitung und Stabilität die auch die Benutzung der API ausgesprochen einfach ist, gibt es nichts, was uns von ihrem Einsatz abhalten sollte … bis auf vielleicht die Frage, ob man die Geolocation-API überhaupt als HTML5 bezeichnen sollte.
Für die Geolocation-API gibt eine eigene Spezifikation und sie wird weder in den HTML5-Spezifikationen des W3C noch im WHATWG-Dokument erwähnt. Man könnte es also machen wie die Betreiber von isgeolocationpartofhtml5.com und behaupten, dass die Geolocation-API gar nicht HTML5 genannt werden dürfte. Fraglich ist allerdings, ob eine so präzise Trennung nützlich oder überhaupt möglich ist. Zunächst besteht das Problem der doppelten Spezifikationen. Was bei der WHATWG Teil von HTML5 ist, kann bei beim W3C als separate Spezifikation laufen, wie es zum Beispiel bei Microdata (WHATWG HTML, eigene W3C-Spezifikation) oder dem 2D-Kontext des Canvas-Elements (WHATWG HTML, eigene W3C-Spezifikation) der Fall ist. Ist das nun HTML5 oder nicht? Andere Technologien wie Web Storage haben ihre Ursprünge in HTML5, wurden aber irgendwann einvernehmlich in einen eigenen Spezifizierungsprozess ausgelagert. Hier könnte man also nur behaupten, dass Web Storage kein HTML5 sei, sofern man angibt, auf welche exakten Koordinaten im Raum-Zeit-Kontinuum man sich bei dieser Aussage bezieht – denn die Spezifikation ändern sich ja ständig.
Wenn man die “echtes gegen falsches HTML5”-Debatte ernsthaft zu führen versucht, landet man offensichtlich schnell in Absurdistan. Hilfreicher ist es, das Wort “HTML5” weniger als Bezeichnung für eine bestimmte HTML-Version wahrzunehmen, sondern als als Dachbegriff für alles zu verstehen, was unserem Browser neue Fähigkeiten einimpft. Das ist so ähnlich wie beim Begriff Ajax. Einst stand dies als Akronym für eine Programmiertechnik namens “Asynchronous JavaScript and XML”, heute findet man unter diesem Label alle Arten von JavaScript-Kunstwerken, von denen nur die wenigsten etwas mit asynchronen Requests und fast gar keine etwas mit XML zu tun haben. Genau so eine Begriffsumbildung, bei der eine einzelne Technik Namensgeber für eine ganze Klasse von Technologien wird, ist auch bei HTML5 passiert. Damit jetzt aber genug der HTML5-Theorie und frisch ans Werk!
Die Geolocation-API erweitert window.navigator um das geolocation-Objekt, das wiederum drei Funktionen rund um Geokoordinaten enthält. Die wichtigste dieser Funktionen ist getCurrentPosition(), die, wie der Name schon andeutet, dem Auslesen der aktuellen Position dient. Das Finden der Position läuft dabei asynchron ab. Man übergibt getCurrentPosition() eine Callback-Funktion als Argument, der ausgeführt, sobald die Positionen gefunden wurde. Der Callback wiederum erhält als Argument ein Objekt mit den Geoinformationen:
window.navigator
geolocation
getCurrentPosition()
1: // Funktion die bei erfolgreicher 2: // Positionsbestimmung ausgeführt wird 3: var erfolgCallback = function(koordinaten){ 4: // "koordinaten" enthält die Geodaten 5: console.log(koordinaten); 6: } 7: 8: // Position bestimmen 9: window.navigator.geolocation.getCurrentPosition(erfolgCallback);
Bevor die Position bestimmt werden kann, muss der Browser den Nutzer um Erlaubnis für die Übermittlung der Daten fragen; heimliches ausschnüffeln ist nicht möglich. Wird die Erlaubnis erteilt, wird erfolgsCallback() ausgeführt und bekommt als Argument ein Objekt mit den Eigenschaften timestamp und coods übergeben. Die timestamp-Eigenschaft enthält, wie sollte es anders sein, den Zeitstempel für die Koordinaten, die in der coords-Eigenschaft stecken. In diesem Objekt findet man folgende Informationen vor:
erfolgsCallback()
timestamp
coods
coords
accuracy
altitude
altitudeAccuracy
heading
latitude
longitude
speed
Natürlich werden sich nicht bei jeder Positionsbestimmung für alle genannten Messungen Werte finden lassen. Wer an seinem PC in einem Keller sitzt, für den wird sich naturgemäß keine Geschwindigkeit oder Richtung finden lassen, anders als bei jemandem, der sein mit einem Accelerometer bestücktes Smartphone unter freiem Himmel spazieren führt. Konnte eine Messung nicht durchgeführt werden, ist ihr Wert im Koordinaten-Objekt null.
Für eine dauerhafte Positionsüberwachung bringt die Geolocation-API mit watchPosition() eine Funktion mit, die im Prinzip einem setInerval()-Wrapper für getCurrentPosition() entspricht. Sie akzeptiert die gleichen Argumente wie getCurrentPosition() und gibt eine Timer-ID zurück, die man in der Funktion clearWatch() verwenden kann, um eine laufende Überwachung wieder einzustellen:
watchPosition()
setInerval()
clearWatch()
1: // Positionsüberwachung starten 2: var ueberwachung = window.navigator.geolocation.watchPosition(erfolgCallback); 3: 4: // Überwachung nach einer Minute wieder einstellen 5: setTimeout(function(){ 6: console.log('Stoppe Überwachung'); 7: window.navigator.geolocation.clearWatch(ueberwachung) 8: }, 60000);
Und das, die drei Funktionen getCurrentPosition(), watchPosition() und clearWatch(), ist eigentlich schon die gesamte Geolocation-API. Alles was noch fehlt ist Fehlerbehandlung und Konfiguration der Positionsbestimmung.
Bei der Positionsbestimmung kann viel schiefgehen. Nicht nur könnte sie an technischen Problemen scheitern, sondern es wäre ja auch denkbar, dass ein Nutzer sich dazu entschließt, seinen aktuelle Aufenthaltsort nicht preiszugeben. Diese und andere Fehler kann man einfach abfangen, indem man einen Fehler-Callback definiert und diesen als zweites Argument an getCurrentPosition() bzw. watchPosition() übergibt. Der Fehler-Callback ist keine Pflichtangabe, sondern kann auch weggelassen werden. Als Argument erhält die Callback-Funktion ein Objekt mit zwei Eigenschaften, dem Fehlercode code und einer Fehlermeldung message:
code
message
1: // Funktion die im Fehlerfall ausgeführt wird 2: var fehlerCallback = function(fehler){ 3: console.log('Fehler ' + fehler.code + ': ' fehler.message); 4: } 5: 6: // Position bestimmen 7: window.navigator.geolocation.getCurrentPosition(erfolgCallback, 8: fehlerCallback);
Die Fehlermeldung ist ein kurzer, für den Webentwickler gedachter Text mit Fehlerinformationen und der Fehlercode ist immer einer der folgenden Werte:
Wann Fehler Nummer 3, die Zeitüberschreitung, eintritt, kann man selbst steuern. Als drittes Argument kann man an getCurrentPosition() bzw. watchPosition() ein Konfigurations-Objekt übergeben:
1: // Funktion die im Fehlerfall ausgeführt wird2: var configObjekt = {3: enableHighAccuracy: true, // Super-Präzisions-Modus4: timeout: 3000, // Millisekunden bis zum Timeout5: maximumAge: 5000 // Lebenszeit Daten-Cache in ms6: }7:8: // Position bestimmen9: window.navigator.geolocation.getCurrentPosition(erfolgCallback,10: fehlerCallback, configObjekt);
Die enableHighAccuracy-Angabe im Konfigurations-Objekt legt fest, ob auf Kosten der Geschwindigkeit eine genauere Positionsbestimmung durchgeführt werden soll. Unter timeout kann man bestimmen, nach wie vielen Millisekunden ohne Erfolg der Timeout-Fehler stattfinden soll und maximumAge erlaubt es schließlich, die Haltbarkeit des API-internen Caches zu steuern.
enableHighAccuracy
timeout
maximumAge
Überschaubarer Umfang, große unmittelbare Nützlichkeit und umfassende Verbreitung: Die Geolocation-API ist eins der pflegeleichteren HTML5-Features. Manches anderes, was noch nicht bugfrei in allen Browsern gelandet ist, von seiner Konzeption her etwas fremdartig daherkommt oder einfach nur schwieriger zu verwenden ist, macht auf den ersten Blick nicht ganz so viel Spaß, ist aber auch zu bändigen. Neu sind diese Probleme nicht: das DOM an sich, also unsere gesamte Browser-Schnittstelle, ist eigentlich eine Katastrophe, doch dank Tools wie jQuery kann man es benutzbar machen. Wo HTML5 ähnliche Herausforderungen für uns bereit hält, sehen wir dann im nächsten Teil dieser Serie.
Nachdem ich ein wenig unterwegs war, möchte ich die Ankündigung vom Windows Team Blog zum Anlass nehmen und kurz bestätigen, dass Internet Explorer 9 genau ein Jahr nach der ersten Platform Preview am Montag, dem 14.03.2011, fertig ist. Genauer gesagt, unsere Partner, meine Kollegen und ich stellen ihn auf einer Presseveranstaltung in Hamburg vor.
Bis dann! Daniel
HTML5 ist seit einiger Zeit in aller Munde und jeder hat so seine eigene Vorstellung davon, was es eigentlich bedeutet. Sicher ist nur: HTML5 wird das, was man unter einem Webbrowser versteht, gründlich verändern und es wird mit Sicherheit kommen –Alternativen wie XHTML 2 sind aus dem Rennen. Vieles an HTML5 ist etwas komplizierter, als man von Webstandards gewohnt ist. So gibt es nicht eine HTML5-Spezifikation, sondern gleich zwei, die auch nicht identisch sind und von unterschiedlichen Arbeitsgruppen geschrieben werden. Und weil selbst das noch viel zu einfach wäre, wird ein großer Haufen sonstiger Technologien, die eigentlich nichts mit den beiden HTML5-Spezifikationen zu haben, ebenfalls gerne zu HTML5 gerechnet.
Neben der Kardinalfrage „Was kann HTML5?“ ist vor allem interessant, ab wann HTML5 einsatzbereit ist und wie es zu der schon beschriebenen, etwas chaotischen Konstellation kommen konnte. Dieser Artikel ist der Auftakt zu einer kleinen Serie, die diese Fragen erkunden soll. Was einzelne Teile von HTML5 leisten können, werden wir in den Beiträgen, die im Laufe der nächsten zwei Wochen erscheinen, erfahren. Die Frage nach einem Termin für HTML5 lässt sich hingegen in einem Satz beantworten: HTML5 ist genau genommen schon längst da und mit dem Erscheinen des Internet Explorer 9 werden alle Browser HTML5 (in unterschiedlichem Umfang) unterstützen. Die Frage nach der etwas unübersichtlichen Gesamtsituation beantwortet sich schließlich aus der Entstehungsgeschichte von HTML5, denn ein geplantes Kind ist es nicht.
Was viele nicht wissen, ist, dass kein Browser der letzten 20 Jahre jemals HTML so unterstützt hat, wie es eigentlich in den Standards steht. Tim-Bernes Lee hatte seine Web-Auszeichnungssprache seinerzeit als eine SGML-Anwendung konzipiert und das Verhältnis zwischen SGML und HTML muss man sich so vorstellen, wie das zwischen XML und XHTML – ersteres ist eine allgemeineren Auszeichnungssprache, mithilfe derer eine spezialisiertere Auszeichnungssprache umgesetzt wird. Doch die Kombattanten des Browserkrieges hatten besseres zu tun, als korrekte SGML-Parser zu schreiben (z.B. <blink> und JavaScript erfinden) und konstruierten stattdessen eigene Algorithmen, die sich dadurch auszeichneten, dass sie auch extrem fehlerhaftes HTML problemlos schluckten. Der so genannte Tag-Soup-Parser war geboren.
<blink>
Das sind eigentlich nur technischen Details, aber natürlich steht es einem World Wide Web Consortium nicht gerade gut zu Gesicht, wenn alle Welt ihre Standards so dreist ignoriert. Also plante das W3C einen HTML-Reboot namens XHTML. Statt auf SGML sollte das Web in Zukunft eben auf XML basieren und durch den frischen Neustart sollte das Nebeneinander von HTML-Standard und gelebter Browser-Praxis ein Ende finden. Das 1997 spezifizierte HTML 4.01 wurde 2001 mit XHTML 1 ohne inhaltliche Änderungen in XML-Form gegossen und die Arbeiten an XHTML 2 begannen. Alles war also bereit für eine glorreiche XML-Zukunft im WWW, wären da bloß nicht die Browserhersteller gewesen.
Um das Jahr 2004 herum zeichnete sich bereits ab, in welche Richtung sich das Web bis heute entwickeln würde. Das Browser-Monopol des Internet Explorer 6 würde fallen und Konkurrenten wie Apple, Mozilla und Opera würden die technische Innovation im WWW nach den langen Jahren der IE-Dominanz wieder beleben. Ebenfalls war klar, dass die HTML-Fähigkeiten des Durchnittbürgers nicht radikal weiterentwickelt hatten und es im Web auch in Zukunft fehlerhafte Dokumente geben würde. Und schließlich erscheinen die ersten Webapplikationen am Horizont, komplexe, auf HTML, CSS und JavaScript basierende Anwendungen, die die technischen Möglichkeiten von HTML 4.01 und XHTML 1 bis zum äußersten ausreizten.
Der vom W3C angestoßene Wechsel zur neuen technischen Basis XHTML schien den Browserherstellern angesichts der sich abzeichnenden Entwicklung nicht als der richtige nächste Schritt. Dringender als solch ein Umbau erschien es, HTML (und damit den Browsern) neue Fähigkeiten einzuimpfen, mit denen man für die Webapplikationen der Zukunft gerüstet wäre. Hinzu kommt, dass X(HT)ML an sich einige gravierende Nachteile mit sich bringt. Ein einziger Fehler im Dokument führt dazu, dass gar nichts angezeigt wird und Internet Explorer bis zu Version 8 können XHTML überhaupt gar nicht verarbeiten. Die Zukunftsvision des W3C wäre also für Gelegenheits-HTML-Autoren sowie Fans von Webapplikationen oder dem IE eine recht finstere gewesen.
Die Browserhersteller trugen ihre Bedenken in den W3C-Gremien vor, stießen jedoch auf wenig Gehör. So kam es, dass am 4. Juni 2004 Vertreter von Apple, Mozilla und Opera eine eigene, vom W3C unabhängige Arbeitsgruppe mit dem Namen WHATWG (Web Hypertext Application Technology Working Group) gründeten. Das Ziel der WHATWG die Entwicklung von Technologie für Webapplikationen von HTML-Basis, mündete in dem, was wir heute als HTML5 kennen.
WHATWG und W3C existierten seither nebeneinander und während erstere HTML5 entwickelten, entwarf man bei letzteren XHTML 2, einen nicht abwärtskompatiblen Nachfolger von XHTML 1. Bei diesem Wettstreit um die Zukunft des Webs stand das W3C freilich nach der Gründung der WHATWG auf verlorenem Posten – während die Spezifikationen für XHTML 2 ein Papiertiger blieben, bauten die Browserhersteller fleißig die in der WHATWG beschlossenen HTML5-Features ein, testeten und verfeinerten sie. So kam es wie es kommen musste – 2007 gab das W3C auf, adaptierte HTML5 und schloss zwei Jahre später auch seine XHTML-Arbeitsgruppe. Seither steht fest: HTML5 allein gehört die Zukunft im Web.
Die Frage bleibt nun, was eigentlich HTML5 genau ist, denn die “Adaption” der Spezifikationen durch das W3C bestand darin, dass die HTML5-Spezifikationen kopiert und seither parallel zu den WHATWG-Entwürfen weiterentwickelt werden. Es gibt also heute zwei (nicht identische) HTML5-Spezfikationen, eine vom W3C herausgegebene und eine aus der Feder der WHATWG – wobei interessanterweise aber beide Arbeitsgruppen vom gleichen Mann angeführt werden. Wie genau sich diese beiden Versionen zueinander verhalten und welche Fassung man unter welchen Umständen als maßgeblich ansehen könnte, würde an dieser Stelle den Rahmen sprengen und außerdem gibt es noch ein weiteres, wichtigeres Problem: Vieles was heute als “HTML5” bezeichnet wird, steht weder in den einen HTML5-Spezifikationen, noch in den anderen.
Als die Weiterentwicklung der Browser in den letzten Jahren wieder Fahrt aufnahm, wurde an allen technologischen Fronten Gas gegeben und das, was W3C und WHATWG in ihren HTML5-Spezifikationen festlegen, ist nur ein Teil davon. Wollte man eine Karte des gesamten HTML5-Universums malen, könnte sie so aussehen:
Der große blaue Kreis innen ist HTML5 nach Version des W3C. Dieser Kreis wird vom grünen WHATWG-Kreis komplett umschlossen –beide Spezifikationen sind nicht identisch, aber im Großen und Ganzen ist W3C-HTML5 eine Teilmenge von WHATWG-HTML5. Kleine blaue Kreise bezeichnen Technologien, die eigene Spezifikationen beim W3C haben. Jene, die innerhalb des grünen WHATWG-Kreises dargestellt werden, sind also wie HTML5 zwei mal spezifiziert, einmal durch das W3C und einmal als Teil von WHATWG-HTML5. Zuletzt gibt es den großen gelben Kreis, der alles versammelt, das eigentlich nichts mit HTML5 zu tun hat, aber trotzdem so genannt wird. Das ist eine (grobe und löchrige) Übersicht über den HTML5-Kosmos und jeder Kreis repräsentiert neue Features für unsere Browser.
Nun könnte man prima darüber streiten, welche Technologie nun “echtes” oder “falsches” HTML5 ist, ob W3C oder WHATWG als maßgeblich zu betrachten sind oder ob dieser Zustand überhaupt tragbar ist. Da aber auch das den Rahmen dieses Artikels sprengen würde, fragen wir uns lieber, was HTML5 uns überhaupt bringt.
Die Wurzeln von HTML5 liegen in einem WHATWG-Entwurf namens „Web Applications 1.0“. Damit ist schon gesagt, wohin die Reise geht – Technologien für die Entwicklung von Webapplikationen sollen geschaffen werden. Zwar enthält HTML5 auch so manches Feature, das für normale, halbwegs statische Webseiten interessant sein könnte, aber Applikationsentwicklung ist der Fokus. Browser sollen universelle Anwendungsplattformen werden und müssen daher unter anderem in das umgebende Betriebssystem integriert werden und lernen, auch ohne Internet-Verbindung zu funktionieren. In Zukunft werden wir fast unsere gesamte Computer-Arbeit in dem Surfprogramm unserer Wahl verrichten können. So selbstverständlich, wie viele Menschen heute schon ihre gesamten Texte bei Google Docs schreiben, wird in Zukunft auch Bildbearbeitung, Audioschnitt, CAD und das Bearbeiten von Videos via Internet Explorer, Firefox oder Safari stattfinden, was natürlich auch für das Computerspiel der Zukunft gelten dürfte.
Für all das müssen unsere Browser viele neue Dinge lernen – sie müssen in der Lage sein, clientseitig Binärdateien einzulesen, beliebige Grafiken hardwarebeschleunigt zu rendern und sie müssen natürlich Ton und Film wiedergeben können. Damit das alles möglich wird, bringt HTML5 (unter anderem – es gibt noch viel viel mehr) folgende Technologien mit sich:
Letzte Frage: Warum sollte man denn all das, was heutzutage als normales Programm ganz wunderbar funktioniert, denn unbedingt zu Webapplikationen umbauen wollen? Neben dem Faktor Bequemlichkeit, den die Nutzer bei Webapplikationen genießen – da sich Applikation und Daten im Web befinden, sind sie jederzeit überall verfügbar – sind Webapps auch aus Prinzip cross-plattform-kompatibel. Was man mit HTML, CSS und JavaScript baut, funktioniert auf jedem Computer dieser Welt, der Internet-Anbindung und einen Browser hat. Warum eine iPhone-App programmieren, wenn man eine Läuft-Überall-Webapp haben kann? Das Ziel von HTML5 ist es, Browser soweit aufzurüsten, dass man Webapplikationen programmieren kann, die nativen Anwendungen in nichts nachstehen.
Die Browserhersteller sind sich zwar auf breiter Front einig, dass Webbrowser in Zukunft keine tumben Dokumentbetrachter, sondern universelle Anwendungsapplikationen sein werden, doch noch ist es nicht so weit, dass man bis auf einen Browser sämtliche Programme von seiner Festplatte werfen kann. Die unterschiedlichen Browser unterstützen unterschiedliche Teile von HTML5 – und das auch noch unterschiedlich gut. Hinter den Kulissen gibt es auch noch offene Fragen (zum Beispiel zu Verhältnis von WHATWG und W3C) und sowohl Browserhersteller als auch Webentwickler müssen sich in der HTML-Welt erst noch einfinden.
Während dieser Findungsprozess vor sich hin läuft und die diversen Standardisierungs-Komitees die weiteren Bausteine für die Webapplikationen der Zukunft zurechtlegen (CSS3 und ECMAScript5/Harmony seien genannt) haben wir Webentwickler Stand 2011 nur ein paar wirklich universell einsetzbare HTML5-Technologien zur Verfügung und auf genau diese werden wir uns im Rahmen dieser Serie konzentrieren. Dinge wie das Canvas-Element oder die Geolocation-API funktionieren in allen aktuellen Versionen der verbreiteten Browser und werden sich wohl auch nicht mehr ändern. Sie sind also solide Bausteine für die Webapplikationen der Zukunft und auch bereits der Gegenwart.
Weltweit betrachtet liegt der Marktanteil von Internet Explorer bei ~57%. Leider surft weltweit aber immer nach jeder vierte IE-Nutzer mit dem Steinzeitbrowser Internet Explorer 6. IE6 ist mittlerweile 10 Jahre alt. Er unterstützt keine modernen Webstandards. Er bietet eine antiquierte User Experience. Ihm fehlen viele Sicherheitsfunktionen, die in modernere Versionen Einzug gehalten haben.
IE6 entstand lange Zeit bevor moderne Webstandards wie HTML5 das Licht der Welt erblickt haben. Die Weiterentwicklung des Webs wird durch IE6-Anwender aufgehalten und viele Webentwickler werfen Microsoft vor, zu wenig zu tun, um die weltweite Verbreitung von IE6 einzudämmen.
Microsoft hat sich dazu bekannt, alles uns mögliche zu tun, den Marktanteil von IE6 weltweit so schnell wie möglich zu verringern. Wir haben jedoch auch Supportverpflichtungen gegenüber Kunden zu erfüllen und können nicht einfach IE6 zentral – möglicherweise auch gegen den Willen der Kunden - abschalten.
Daher möchten wir mit der Fertigstellung unserer neuesten Browserversion Internet Explorer 9 die Gelegenheit nutzen, die Aufmerksamkeit erneut auf die Verringerung des Marktanteils von IE6 zu lenken. Dafür starten wir den Internet Explorer 6 Countdown. Diese Webseite soll den Fortschritt dieser Aufgabe messen und weltweit sichtbar machen. Für Deutschland haben wir hier relativ wenig zu tun, da der Anteil mittlerweile schon auf <3% gesunken ist. Aber in einigen Ländern wie China, Indien, etc. ist noch viel zu tun.
Für Kunden, welche Probleme beim Wechsel von IE6 zu einem moderneren Browser wie IE8 oder IE9 haben, stellen Unterstützung zur Verfügung:
IE6 Countdown: http://www.ie6countdown.com/
Die Kompatibilität mit schon existierenden Webseiten ist für Webentwickler ein wichtiger Faktor. Internet Explorer 8 führte deshalb Dokumentkompatibilitätsmodi ein, die es ermöglichen, den Browser anzuweisen, Seiten genauso zu rendern, wie ältere Versionen dies tun würden. Dadurch können Entwickler wählen, wann sie ihre Webseiten so aktualisieren möchten, dass der einmal geschriebene Quellcode in allen modernen Browsern gleich angezeigt wird.
Auch in Internet Explorer 9 können Dokumentkompatibilitätsmodi genutzt werden. Um einen Dokumentmodus für eine Webseite festzulegen, fügt man mithilfe des META-Elements einen X-UA-kompatiblen httpequiv-Header in die Webseite ein.
ACHTUNG: Beim "X-UA-Compatible"-Header wird nicht zwischen Groß- und Kleinschreibung unterschieden, aber er muss im Header der Webseite (im Abschnitt "HEAD") vor allen anderen Elementen außer dem TITLE-Element und anderen META-Elementen stehen. Ansonsten greift der Header nicht und die Webseite wird im IE9-Dokumentenmodus angezeigt.
Folgendes Beispiel zeigt, wie man "EmulateIE7" als Dokumentkompatibilitätsmodus einstellen kann:
<html> <head> <!-- Mimic Internet Explorer 7 --> <title>My Web Page</title> <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" /> </head> <body> <p>Content goes here.</p> </body> </html>
Das Content-Attribut gibt den Modus für die Seite an. Vielleicht kann man aber nicht immer den Quellcode der Webseite um solch ein Meta-Tag erweitern. Daher gibt es eine zweite Möglichkeit, den Dokumentenkompatibilitätsmodus zu setzen. Man kann im Webserver einen benutzerdefinierten HTTP-Antwortheader für die gesamte Website (oder auch nur Teile davon) definieren.
Ein HTTP-Antwortheader besteht aus den Informationen, die ein Webserver der Datei beifügt, die er als Reaktion auf eine HTTP-Anforderung an den Browser sendet. Diese Informationen umfassen in der Regel Angaben zum Erstellungsdatum, der Größe und dem Typ der Datei, die zurückgesendet wird.
Für die am häufigsten genutzten Webserver Apache und IIS haben wir beschrieben, wie man den Webserver konfigurieren kann, dass sämtliche Webseiten einen benutzerdefinierten HTTP-Antwortheader gesetzt bekommen:
Der im Webserver festgelegte Standarddokumentkompatibilitätsmodus wird durch eine Meta-Tag im Header der Webseite überschrieben, da der innerhalb der Webseite festgelegte Modus Vorrang vor dem durch den Server festgelegten Modus hat.