Fragen zu HTML5 und Co beantwortet 19 - Flexbox-Umbrüche, magische Body-Backgrounds, ES6-Promises, Main-Element • Peter Kröner • Webtechnologie

Fragen zu HTML5 und Co beantwortet 19 - Flexbox-Umbrüche, magische Body-Backgrounds, ES6-Promises, Main-Element

Veröffentlicht am 10. März 2015

Achtung: dieser Beitrag ist alt! Es kann gut sein, dass seine Inhalte nicht mehr aktuell sind.

Lange keine Fragen mehr beantwortet! Das lag nicht an einem Mangel an Input, sondern vielmehr daran, dass ich vor lauter JavaScript-Schulungen kaum zum Schreiben (von Blogposts, nicht von Antworten auf E-Mails) gekommen bin. Mit dieser Sammlung aus Problemen rund um HTML, CSS und JS hat das zum Glück ein Ende. Wenn auch ihr eine Frage zu Frontend-Technologien habt, nur her damit: eine E-Mail oder ein Tweet genügen!

Flexbox-Umbrüche erzwingen

Kann man Flexboxen gezielt umbrechen lassen um zum Beispiel nach jedem dritten Element einen Umbruch zu erzwingen?

Kurze Antwort: in der Theorie sollte es ganz einfach gehen, in der Praxis funktioniert es nicht ganz so gut. Die Flexbox-Spezifikationen sehen Umbrüche mit den ganz normalen CSS-Umbruch-Eingenschaften vor:

A break is forced wherever the CSS2.1 page-break-before/page-break-after or the CSS3 break-before/break-after properties specify a fragmentation break.

Ein Umbruch nach jedem dritten Kindelement sollte demnach kein Problem sein:

.container > :nth-child(3n) {
  break-after: always;
  page-break-after: always;
}

Der Haken an der Sache ist, dass einerseits break-after in so gut wie keinem Browser funktioniert, andererseits page-break-after in Chrome und Internet Explorer keinen Einfluss auf Flexbox zu haben scheint. Nur im Firefox funktionieren die Umbrüche wie vorgeschrieben.

ES6-Promises inspizieren?

Die Promises von ECMAScript 6 bieten offenbar keine Möglichkeit, ihren Status auszulesen. Wie kann ich trotzdem herausfinden, ob ein Promise resolved oder rejected ist?

Fast alle denkbaren Features von Promises lassen sich mit Hilfe der guten alten then()-Methode umsetzen. Die einfachste Lösung für das Inspektions-Problem besteht darin, eine Wrapperfunktion für Promise() zu bauen. Diese gibt ein ganz normales Promise zurück, das aber durch die Wrapper-Funktion mit Eigenschaften wie isResolved und isRejected ausgestattet ist:

// http://jsbin.com/funepe/2/edit?js,console
function SuperPromise(executor){
  var promise = new Promise(executor);
  promise.isResolved = false;
  promise.isRejected = false;
  promise.then(function(){
    promise.isResolved = true;
  }, function(){
    promise.isRejected = true;
  });
  return promise;
}

Die Wrapper-Funktion sorgt mit ihren then()-Callbacks dafür, dass bei Statusänderungen die Eigenschaften isResolved und isRejected ein Update bekommen:

var myPromise = new SuperPromise(function(resolve){
  setTimeout(resolve, 1000);
});

console.log(myPromise.isResolved); // > false

myPromise.then(function(){
  console.log(myPromise.isResolved); // > true
});

setTimeout(function(){
  console.log(myPromise.isResolved); // > true
}, 1000);

Das ist die einfachste Lösung. Wer besonders fancy sein möchte, kann sich auch einen Promise-Proxy bauen (Firefox) oder, sobald Browser ES6-Klassen unterstützen, eine class SuperPromise extends Promise basteln, aber das Grundprinzip bleibt gleich.

Magische Body-Backgrounds?

Wie kann dieser Effekt sein? Ich gebe dem 0 Pixel hohen Body-Element einen Farbverlauf und die ganze Seite wird mit einem sich wiederholenden, 8 Pixel hohem Verlauf überzogen? Was geht da vor sich?

Bei diesem Effekt handelt es sich um eine Kombination aus verschiedenen CSS-Sonderregeln für ganz bestimmte Elemente. Wenn ein <html>-Element keinen eigenen CSS-Hintergrund hat, übernimmt es den Hintergrund vom <body>-Element (genau genommen die computed values). Das <body>-Element hat seinerseits einen Standard-Margin von 8 Pixeln, was (durch collapsing marging) auch dafür sorgt, dass das <html>-Element auch ohne jeden Inhalt 8 Pixel hoch ist.

Unser <html>-Element hat jetzt den Hintergrund vom <body>-Element sowie 8 Pixel Höhe durch den Margin des <body> erhalten; 100% Breite hat es als Block-Element sowieso. Der Farbverlauf wiederholt sich nun bis zum Ende der Seite, weil der Hintergrund des Wurzelelements einer Seite (im Falle von HTML <html>) als Hintergrund für die gesamte Renderingfläche verwendet wird. Dabei wird der Hintergrund jedoch immer noch so gerendert, als wäre er für für sein eigentliches Element (<html>) bestimmt und ggf. wiederholt, bis die ganze Renderingfläche bedeckt ist.

<main> oder nicht <main>, das ist hier die Frage

Vor dem Aufbau des HTML-Gerüsts meiner neuen Webseite habe ich mir den Quelltext vieler anderer Seiten angeschaut. Inzwischen wird kräftig Gebrauch von <header>, <section>, <artice>, <aside> und <footer> gemacht, aber kaum jemand nutzt <main>! Da wird fast überall immer noch ein <div>-Wrapper verwendet oder das <section>- oder <article>-Element per ID und WAI-ARIA-Role zum <main>-Element umgebaut. Kannst du mir mal erklären wieso man überwiegend so verfährt und nicht einfach <main> nutzt?

Ich nehme an, dass der Grund für den spärlichen <main>-Einsatz bei allen möglichen Webseiten (inklusive meiner eigenen Seite) der gleiche ist: das Element ist vergleichsweise neu! Während es <header>, <footer>, <section>, <artice>, <nav> und <aside> schon seit Anbeginn der Zeiten (und damit auch während des großen HTML5-Hypes) gab, ist <main> erst später dazugekommen und daher weniger verbreitet und weniger bekannt.

Das <main>-Element ist aber tatsächlich das semantisch korrekte Element für den Hauptinhalt, funktioniert in jedem Browser, ist seit HTML 5.0 offizieller Webstandard, hat eingebaute WAI-ARIA-Features und sorgt, verglichen mit einem umgebogenen <section>-Element für besser lesbaren Quelltext. Bei einem neuen Projekt würde ich es also auf jeden Fall einsetzen. Andererseits sind die wirlich messbaren Vorteile, die man durch den Einsatz von <main> erlangt, eher überschaubar, weswegen bestehende Seiten (wie auch meine eigene) es eher selten nachträglich einbauen. Es gilt die alte Informatiker-Faustregel: never change a running system.

Weitere Fragen?

Auch eure Fragen zu HTML5, JavaScript und anderen Webtechnologien beantworte ich gerne! Einfach eine E-Mail schreiben oder Twitter bemühen und ein bisschen Geduld mit der Antwort haben. Ansonsten kann man mich natürlich auch als Erklärbär zu sich kommen lassen.

Kommentare (1)

Fred ¶

23. März 2015, 14:19 Uhr

Super Artikel und schön geschrieben!