Termine für Januar, Februar und März 2013

Veröffentlicht am 16. Januar 2013

Der Erklärbär ist wieder auf Tour! Falls ihr euch mit HTML5- und CSS3-Wissen betanken lassen möchtet, habe ich im ersten Quartal exakt je eine solche Gelegenheit für euch auf Lager:

  • 4. - 6. Februar in München: HTML5-Schulung bei der Open Source School. Mein bewährtes drei­tä­gi­ges HTML5-Standardprogramm stattet die Teilnehmer im Druckbetankungsverfahren mit so gut wie allem aus, was man zu HTML5 wissen muss. Von semantischem Markup bis hin zu Canvas-Programmierung ist alles dabei. Geboten wird ein großer Praxisanteil, kleine Arbeitsgruppen und ein Buch gibt es obendrein.
  • 7. - 8. Februar in München: CSS3-Schulung bei der Open Source School. Mein zweitä­gi­ges CSS3-Standardprogramm katapultiert die Teilnehmer in das CSS3-Zeitalter, in dem Webfonts und Farbverläufe fließen. Einen großer Praxisanteil, kleine Arbeitsgruppen und ein Buch als Bonus gibt es auch hier.

Das HTML5-Programm wird zur Zeit grundlegend aktualisiert, unter anderem kommen mittlerweile auch Indexed DB, getUserMedia und viele andere neuere Spielereien vor, die nicht im Buch stehen.

Ein neues Element für HTML5: <main>

Veröffentlicht am 2. Januar 2013

Wie sicher den Wenigsten entgangen ist, wird fleißig an einem neuen Element für HTML5 gearbeitet. Das <main>-Element soll for the identification of the main content area of a document genutzt werden und damit die bekannten HTML5-Elemente <section>, <header> und Konsorten ergänzen. Stand heute ist das Ganze eigentlich noch nichts weiter, als ein Vorschlag zur Erweiterung des bestehenden Standards, doch da weitgehend Konsens über die Einführung des neuen Elements besteht, kann man sich <main> durchaus schon genauer anschauen.

Wozu <main>?

Das neue Element bietet genau wie alle anderen neuen HTML5-Elemente zwei Dinge: zum einen ist es ein zusätzliches Sprachmittel für die Auszeichnung von Website-Teilbereichen, zum anderen hat es eingebaute ARIA-Funktionen, die wenn das neue Element korrekt benutzt wird, automatisch der Barrierefreiheit der Seite guttun. In Sachen Optik und Verhalten entspricht es genau wie <section> und Konsorten dem, was man vom guten alten <div> kennt.

Gedacht ist <main> für die Auszeichnung des jeweiligen Hauptinhalts einer Seite; im Falle eines Blogs wäre das zum Beispiel die Spalte mit allen Artikeln:

<!doctype html>
<meta charset="utf-8">
<title>Katzenbilder24.com</title>

<header>
  <h1>Katzenbilder-Blog</h1>
  <nav>
    <ul>
      <li><a href="/">Start</a></li>
      <li><a href="/about">Über</a></li>
    </ul>
  </nav>
</header>

<main>
  <article>
    <h2>Flauschiges Kätzchen</h2>
    <p>Text, Bild...</p>
  </article>
  <article>
    <h2>Pelziges Kätzchen</h2>
    <p>Text, Bild...</p>
  </article>
</main>

<aside>
  <section>
    <h2>Tagcloud</h2>
    <p>Tags, Tags, Tags</p>
  </section>
  <section>
    <h2>Blogroll</h2>
    <p>Links, Links, Links</p>
  </section>
</aside>

Anders als <section> hat <main> keinen Einfluss auf die Überschriftenstruktur (Outline) einer Webseite und es darf auch nicht in anderen Abschnitts-Elementen vorkommen – es soll den Hauptinhalt einer Seite markieren, nicht den Hauptinhalt eines Abschnitts der Seite. Ein korrekt verwendetes <main>-Element hat demnach keine <article>, <aside>, <footer>, <header> oder <nav>-Elemente als Vorfahren und ist das einzige Element seiner Art auf der Seite.

Als Bonus hat <main>, wie alle anderen neuen HTML5-Elemente auch, fest eingebaute ARIA-Eigenschaften. Das bedeutet im Endeffekt, dass man bei der korrekten Verwendung von <main> ohne zusätzlichen Aufwand eine zugänglichere Webseite erstellt, da das neue Element automatisch ein role="main" trägt. Dank <main> wird es in Zukunft ziemlich schwierig, diese Annotation zu vergessen.

Braucht man <main> überhaupt?

Einige haben argumentiert, dass man das neue Element gar nicht bräuchte, denn es wäre ja möglich, den Hauptinhalt einer Webseite einfach dadurch zu kennzeichnen, dass man ihn „den Rest“ sein lässt. Beispiel:

<!doctype html>
<meta charset="utf-8">
<title>Katzenbilder24.com</title>

<header>
  <h1>Katzenbilder-Blog</h1>
  <nav>
    <ul>
      <li><a href="/">Start</a></li>
      <li><a href="/about">Über</a></li>
    </ul>
  </nav>
</header>

<article>
  <h2>Flauschiges Kätzchen</h2>
  <p>Text, Bild...</p>
</article>
<article>
  <h2>Pelziges Kätzchen</h2>
  <p>Text, Bild...</p>
</article>

<aside>
  <section>
    <h2>Tagcloud</h2>
    <p>Tags, Tags, Tags</p>
  </section>
  <section>
    <h2>Blogroll</h2>
    <p>Links, Links, Links</p>
  </section>
</aside>

Auch ohne <main> ist klar, was hier der Hauptinhalt ist; alles, was nicht in <header> und <aside> steht, also die Ansammlung der Article-Elemente. Dank role-Attribut ist auch der Barrierefreiheit so viel Genüge getan, wie es mit dem neuen Element der Fall wäre. Es gibt aber vier gute Argumente, die für die Einführung des neuen Elements sprechen:

  • Ein Bereich, der der Hauptinhalt einer Webseite ist, kommt auf vergleichsweise vielen Webseiten vor. Vermutlich auf den meisten. Insofern ist es naheliegend, hierfür ein eigenes Element einzuführen, denn schließlich haben andere häufig auftretende Konstruktionen wie z.B. Navigationen ja auch ihre eigenen Elemente.
  • Aus eigener Erklärbär-Erfahrung kann ich berichten, dass HTML5-Neulinge, wenn man sie Markup schreiben lässt, fast immer den Hauptinhalt in ein Extra-Element Marke <section id="main"> kapseln. Es scheint so zu sein, dass es autorenfreundlich wäre, dafür ein passendes Werkzeug d.h. das neue Element bereitzustellen.
  • Es wäre zwar möglich, manuell role="main"-Attribute zu vergeben, aber es ist zu bezweifeln, dass das wirklich auf breiter Front passiert. Mit dem neuen Element kann das nicht mehr vergessen werden, was (korrekte Verwendung des Elements vorausgesetzt) ohne zusätzlichen Aufwand der Zugänglichkeit der Webseite guttäte – weniger Arbeit für den Autoren, mehr Spaß beim Benutzer.
  • Die HTML Design Principles sagen ganz klar: In case of conflict, consider users over authors over implementors over specifiers over theoretical purity

Bis auf die theorietreue Sparsamkeitsfraktion würden also alle Beteiligten von der Einführung des <main>-Elements profitieren. Bleibt also nur die Frage: wann kommt die Einführung?

Welche Browser unterstützen <main>?

Zur Zeit gibt es das neue (wirklich sehr neue) Element nur als Experimental-Implementierung in Preview-Versionen von Firefox und Chrome. Das ist allerdings nicht zwingend ein Problem, da die Funktionalität von <main> händisch nachgerüstet werden kann. Vorausgesetzt der Browser verarbeitet das Element prinzipiell richtig (was alle Browser außer IE 6, 7 und 8 machen sollten), so muss es nur richtig formatiert und mit den passenden ARIA-Attributen versehen werden. Heißt also: display:block im CSS vergeben und bei der Benutzung in HTML nicht das Attribut role="main" vergessen. Dies wird zwar, sobald alle Browser das neue Element nativ unterstützen, doppelt gemoppelt sein, aber das ist, wenn überhaupt, ein Problem, dessen Lösung man sicher guten Gewissens auf diesen fernen Zeitpunkt vertagen kann.

Wie immer gilt aber, dass in Sachen HTML5-Markup keine übermäßige Eile geboten ist. Alle „alten“ Webseiten werden auch in Zukunft ohne <main> ganz wunderbar funktionieren – nur wenn ein Redesign ansteht, lohnt es sich, über den Einsatz des neuen Elements nachzudenken.

HTML 5 wird 2014 Webstandard - Was bedeutet das, was ändert sich?

Veröffentlicht am 29. November 2012

Man liest, das W3C plane HTML 5.0 im vierten Quartal 2014 fertig, d.h. in einen stabilen Webstandard verwandelt zu haben. Features die sich nicht in diesen Zeitplan quetschen lassen, sollen nach HTML 5.1 verschoben werden, mit dem dann Ende 2016 zu rechnen ist. Das klingt erst mal recht unkompliziert, aber da allerorten mit dem Begriff „HTML5“ etwas unbedacht umgegangen wird (auch in dem W3C-Plandokument) ist etwas unklar, was konkret denn nun 2014 fertig sein soll. Und natürlich lohnt es sich zu fragen, welche Auswirkungen diese Erhebung zum Standard denn haben wird. Ich hatte das bereits in der letzten Folge von Working Draft aufgedröselt, aber der Vollständigkeit halber möchte ich hier nochmal aufschreiben, was es mit diesem Plan auf sich hat und was er für HTML5 zu bedeuten hat.

HTML5 oder HTML 5?

Man kann „HTML5“ entweder mit oder Leerzeichen vor der Fünf scheiben. Die Schreibweise ohne Leerzeichen ist im WHATWG-Lager usus, Freunde des W3C haben es lieber mit Leerzeichen. Die WHATWG ist, wir erinnern uns, jene Arbeitsgruppe der Browserhersteller, die ursprünglich die Entwicklung der ganzen schönen neuen Webtechnologien losgetreten hatten. Die HTML-Arbeitsgruppe des W3C befasst sich mit einem Teilaspekt der WHATWG-Spezifikationen – jenem, der sich vorrangig mit HTML5 im Sinne von HTML befasst. Von diesen beiden Arbeitsgruppen ist weiterhin der allgemeine Sprachgebrauch zu unterscheiden, der den Begriff HTML5 noch viel weiter fasst. Ein Bild sagt mehr als tausend Worte:

Grafik, die das Verhältnis von diversen Webtechnologie-Spezifikationen zueinander illustriert

Der große grüne Kreis ist die Spezifikation der WHATWG, und der große blaue Kreis innen ist die Spezifikation des W3C. Wenn man die Inhaltsverzeichnisse beider Spezifikationen vergleicht, wird der Unterschied klar: währen die WHATWG auch diverse JavaScript-APIs spezifiziert, enthält das W3C-Dokument fast nur HTML im Sinne von HTML. Das heißt aber nicht, dass das W3C sich nicht auch um die JS-Apis kümmern würde, nur ist es eben so, dass einiges, was bei der WHATWG Teil von HTML5 ist, beim W3C in einem eigenen Spezifikationsprozess bearbeitet wird (z.B. der Canvas 2D-Context bei WHATWG und W3C). Der große gelbe Kreis bildet den allgemeinen Sprachgebrauch ab, der unter HTML5 alles vereinigt, was es schönes neues im Browser gibt, von HTML-Tags bis hin zu clientseitigen Datenbanken. Das ist das, was Otto Normalverbraucher mit „HTML5“ meint.

Was wurde beschlossen (und wie schreibt man es)?

Das, was das W3C in seinem Plan für 2014 anpeilt, ist die Anfertigung eines Snapshots vom Dokument der W3C HTML-Arbeitsgruppe (großer blauer Kreis). Die Spezifikationen sollen bis Ende 2014 so weit stabilisiert werden, dass man es zur Recommendation, d.h. zu fertigen Standard erklären kann. Alle anderen Dokumente inklusive der HTML5-Spezifikationen der WHATWG sind davon nicht betroffen. Weil das W3C-Dokument sich vor allem um Parser und HTML-Tags und weniger um Browser-APIs dreht, würde dieser neue Webstandard dann auch tatsächlich eine neue Version von HTML darstellen. Dieser neue Standard hätte dann auch die Schreibweise „HTML 5“ verdient – hier wäre die 5 eine echte Versionsnummer und nicht wie bei „HTML5“ nur Teil eines Namens. Und wenn man schon wieder Versionsnummern hat, so spricht auch nichts mehr gegen Folgeversionen wie 5.1 und weiteres.

Es wäre natürlich praktisch, wenn sich die Welt darauf einigen könnte, die Schreibweise „HTML5“ für die Buzzword-Bedeutung der neuen Technologien zu reservieren und „HTML 5“ bzw. „HTML 5.0“ für die W3C-Spezifikationen zu verwenden (das W3C wirft beides in seinem Plan-Dokument wild durcheinander). So würde uns einerseits der liebgewonnene Oberbegriff erhalten bleiben, andererseits könnte man über die nächste Version einer Auszeichnungssprache sprechen (oder eher schreiben), ohne sich dem Verdacht auszusetzen, ein JavaScript-Supernerd oder gar ein überhypter Nichtsblicker zu sein. Ob es soweit kommt, wird die Zeit zeigen, aber ich werde dieses System auf jeden Fall in Zukunft verwenden.

Dokumente und Recommendations hin oder her: was ändert sich denn nun durch die Standardisierung einer neuen HTML-Version? Eigentlich nichts.

Was sind die Auswirkungen?

Webstandards sind praktisch immer deskriptiv und nicht normativ. Eine Technologie wird nicht zum Standard, indem das W3C sie aufschreibt und folgsame Browserhersteller sie implementieren, sondern es läuft fast immer umgekehrt. Die Programmierer von Browser A erfinden ein neues Feature, die Programmierer von Browser B implementieren etwas ähnliches, man einigt sich auf einen einheitlichen Kompromiss und das W3C schreibt das Endergebnis auf. Somit dürfte klar sein, dass in dem fertigen Standard nichts drin stehen wird, was neu ist, sondern er wird die dann bestehende Browser-Realität abbilden und für die Zukunft festschreiben.

Für Webentwickler gibt es also eigentlich nichts, was sich im Q4 2014 ändert. Falls auch dann jemand noch den Internet Explorer 8 unterstützen muss (Gott bewahre!), so wird er sich nichts davon kaufen können, dass es eine Recommendation für <section> gibt, denn dieses Feature wird der IE8 auch 2014 nicht unterstützen. Auch wird die Standardisierung von HTML 5.0 nicht das Ende des zur Zeit chaotischen Entwicklungsmodells oder des allgemein „unfertigen“ Eindrucks der Web-Plattform bedeuten. Zwar wird dann einiges in Browsern möglich sein, was heute nur in Chrome-Nightlies funktioniert, doch dafür werden sich die Browser-Programmierer bis dahin neue Features ausgedacht haben, über deren Nichtfunktionieren wir uns dann aufregen können.

Wenn also aus „HTML5“ demnächst „HTML 5.0“ wird und es mit dem Recommendation-Stempel versehen wird, heißt es also aus der Perspektive der Webentwickler mal wieder: Raider heißt jetzt Twix … sonst ändert sich nix.

Fragen zu HTML5 & Co beantwortet 8 – CORS, Z-Index, Drag & Drop, Default-Styles

Veröffentlicht am 29. Oktober 2012

Es hat etwas gedauert, aber ich habe wieder vier Fragen und Antworten zu HTML5, CSS3 und Konsorten für euch zusammengekratzt. Warum kriege ich in letzter Zeit so wenig Fragen? Ihr wisst doch: eine E-Mail oder ein Tweet genügen!

How to CORS?

Ich möchte einen XMLHttpRequest an eine API machen, von der ich einen JSON-String abfragen werde. Wie bekomme ich das hin, dass ich keine Probleme mit Cross-Domain bekomme?

Normalerweise werden durch die Same-Origin-Policy (also durch den Browser) Zugriffe unterbunden, die von einer Webseite aus auf eine andere Webseite mit andere Domain unternommen werden. Die Technologie um das zu ändern heißt Cross-Origin Resource Sharing (CORS) und wird bereits von vielen Bowsern unterstützt. Um sie zu aktivieren muss man aber am Server Hand anlegen und einen speziellen Header verschicken – enable-cors.org erklärt wie das geht. Möchte man auch alte Internet Explorer mitschleifen, braucht man neben dem normalen Ajax-Code auch das IE-spezifische XDomainRequest-Objekt. Genaueres dazu weiß das CORS-Tutorial von HTML5 Rocks.

Z-Index und Opacity

Ich bin gerade mit dem nachlesen der siebten Fragerunde zu HTML5 und Co auf deinem Blog fertig geworden. Zum Thema, Transformation und z-Index war ich sehr verwundert, konnte mich aber an ein ähnliches Problem erinnern. Ich habe einfach mal die transformation-Anweisungen durch eine opacity-Angabe ersetzt. Siehe da ich habe das selbe Problem. Frage nun: ist es aus dem selben Grund? Gibts sowohl für die eine oder andere einen Workaround?

Ja, das ist in der Tat ganz ähnlich. Die Mechanik hinter Transformationen und Opacity ist fast die gleiche: die Kindelemente eines betroffenen Elements werden mit dem Elternelement zusammengerendert und nur dieses Gesamtwerk wird transformiert bzw. von Opacity-Effekt betroffen. Zitat Spezifikationen:

Conceptually, after the element (including its descendants) is rendered into an RGBA offscreen image, the opacity setting specifies how to blend the offscreen rendering into the current composite rendering [...] Since an element with opacity less than 1 is composited from a single offscreen image, content outside of it cannot be layered in z-order between pieces of content inside of it. For the same reason, implementations must create a new stacking context for any element with opacity less than 1. If an element with opacity less than 1 is not positioned, implementations must paint the layer it creates, within its parent stacking context, at the same stacking order that would be used if it were a positioned element with z-index:0 and opacity:1.

Von einem Workaround ist mir nichts bekannt. Das Außer-Kontext-Rendern ist offenbar ein unumgängliches Funktionsprinzip von Transformationen und Opacity.

Drag & Drop – kein Drop-Event im Firefox

Hast du eine Idee, wieso das Drop-Event von HTML5 Drag & Drop im Firefox nicht gefeuert wird? In Chrome funktioniert es ohne Probleme.

Kurze Antwort: das Problem lässt sich lösen, indem man das dragover-Event abfängt und mit preventDefault() abbricht, in etwa so:

dropziel.ondragover = function(evt){
    evt.preventDefault();
};

Lange Antwort: während einer Drag-Operation feuert eine ganze Menge Events und viele von denen muss man, wenn man die API verwenden möchte, einfach abbrechen, damit andere Events funktionieren. Das klingt erst mal verquer, hat aber schon so seinen Sinn. Es sollen schließlich die meisten Elemente in einer Seite keine Ziele für Drag & Drop sein und es ist ganz sinnvoll, auf diesen gar nicht erst drop-Events zuzulassen. Um ein Element zum potenziellen Ziel zu machen muss daher zunächst das dragover-Event abgebrochen werden.

Warum das neuerdings in Chrome nicht mehr nötig ist, darüber kann ich nur spekulieren. Entweder ist das ein Bug oder die Chrome-Entwickler finden ganz einfach diese Event-Abbrechen-um-Events-stattfinden-zu-lassen-Geschichte so blöde, dass sie sich bewusst dagegen entscheiden. Ich würde ihnen daraus auch keinen übergroßen Vorwurf stricken, denn die API ist im Originalzustand einfach zu bekloppt.

Wo stehen die Default-Styles?

Gibt es irgendwo eine Übersicht, welches Default-Styling für welche HTML5-Elemente existiert?

Diese Übersicht gibt es praktischerweise direkt in den HTML5-Spezifikationen. HTML5 hat den Anspruch, neben Tags und Attributen auch das ganze im Browser befindliche Drumherum zu spezifizieren – von URL-Parsern über Download-Algorithmen bis hin zu DOM-Features ist alles dabei. Und da dürfen die Default-Styles natürlich nicht fehlen.

Weitere Fragen?

Eure Fragen zu HTML5, JavaScript und anderen Webtechnologien beantworte ich gerne! Einfach eine E-Mail schreiben oder Twitter bemühen und ein bisschen Geduld haben – falls ich gerade unterwegs bin, kann es mit Antwort manchmal etwas dauern, doch früher oder später schreibe ich garantiert zurück.