nDieser Artikel ist Teil einer Serie:n
- n
- Fragen zu HTML5 & Co 1
- Fragen zu HTML5 & Co 2
- Fragen zu HTML5 & Co 3
- Fragen zu HTML5 & Co 4
- Fragen zu HTML5 & Co 5
- Fragen zu HTML5 & Co 6
- Fragen zu HTML5 & Co 7
- Fragen zu HTML5 & Co 8
- Fragen zu HTML5 & Co 9
- Fragen zu HTML5 & Co 10
- Fragen zu HTML5 & Co 11
- Fragen zu HTML5 & Co 12
- Fragen zu HTML5 & Co 13
- Fragen zu HTML5 & Co 14
- Fragen zu HTML5 & Co 15
- Fragen zu HTML5 & Co 16
- Fragen zu HTML5 & Co 17
- Fragen zu HTML5 & Co 18
- Fragen zu HTML5 & Co 19
- Fragen zu HTML5 & Co 20
- Fragen zu HTML5 & Co 21
- Fragen zu HTML5 & Co 22
- Fragen zu HTML5 & Co 23
- Fragen zu HTML5 & Co 24
- Fragen zu HTML5 & Co 25
- Fragen zu HTML5 & Co 26
- Fragen zu HTML5 & Co 27
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
n
nn
n 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!n
nnn
Flexbox-Umbrüche erzwingen
nn
n
n Kann man Flexboxen gezielt umbrechen lassen um zum Beispiel nach jedem dritten Element einen Umbruch zu erzwingen?n
n
n
n 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: n
n
n
n A break is forced wherever the CSS2.1
page-break-before
/page-break-after
or the CSS3break-before
/break-after
properties specify a fragmentation break.nn
n
n Ein Umbruch nach jedem dritten Kindelement sollte demnach kein Problem sein:n
n
.container > :nth-child(3n) {n break-after: always;n page-break-after: always;n}
n
n 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.n
nnnnnn
ES6-Promises inspizieren?
n
n
n 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?n
n
n
n 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:n
nn
// http://jsbin.com/funepe/2/edit?js,consolenfunction SuperPromise(executor){n var promise = new Promise(executor);n promise.isResolved = false;n promise.isRejected = false;n promise.then(function(){n promise.isResolved = true;n }, function(){n promise.isRejected = true;n });n return promise;n}
n
n Die Wrapper-Funktion sorgt mit ihren then()
-Callbacks dafür, dass bei Statusänderungen die Eigenschaften isResolved
und isRejected
ein Update bekommen:n
n
var myPromise = new SuperPromise(function(resolve){n setTimeout(resolve, 1000);n});nnconsole.log(myPromise.isResolved); // > falsennmyPromise.then(function(){n console.log(myPromise.isResolved); // > truen});nnsetTimeout(function(){n console.log(myPromise.isResolved); // > truen}, 1000);
nn
n 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.n
nnnnnn
Magische Body-Backgrounds?
n
n
n 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?n
n
n
n 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.n
n
n 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.n
nnnnnn
<main> oder nicht <main>, das ist hier die Frage
n
n
n 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?nn
n
n 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.n
n
n 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.n
nnnnnn
Weitere Fragen?
n
nAuch 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.
Schreibe einen Kommentar