Ich würde ja mal wieder etwas anderes bloggen, aber so lange ihr mich weiter mit Fragen zu HTML5 und Co bombardiert, muss ich die ja schweren Herzens zuerst beantworten. Das soll nicht heißen, dass ich nicht noch viel mehr Fragen gebrauchen könnte! Wenn euch etwas zu HTML5, CSS3, JavaScript, Web Components oder ähnlichem auf dem Herzen liegt, schreibt mir eine Frage per E-Mail oder via Twitter.

Masonry-Layout mit Flexbox?

Kann man mit Flexbox Masonry Layout machen?

Es gibt tatsächlich die Möglichkeit, etwas in ungefähr dieser Richtung zu machen. Grundsätzlich dient Flexbox weiterhin dem einfachen Anordnen von Boxen und ist damit eher unfancy. Allerdings ist es so flexibel, dass das komplette Aufüllen eines vorhandenen Raumes unter Berücksichtigung des Inhalts machbar ist. Der Clou ist: der vorhandene Raum ist immer eine Zeile und Flexboxen können umbrechen. Um diese Umbrüche zu aktivieren, muss in einem Flex-Container die Eigenschaft flex-wrap auf wrap gesetzt werden:

.wrapper {
  display: flex;
  flex-wrap: wrap;
}

In diesem Container können nun allerlei Kindelemente mit unterschiedlichen Maß-Verhalten platziert werden. Die Maß-Verhalten ergeben sich auf Basisgröße auf der Flex-Achse (flex-basis) sowie den Wachs- und Schrumpffaktoren (flex-grow, flex-shrink). Provoziert man durch zusätzliche Mindestbreiten (min-width) der Kindelemente Umbrüche, so gilt die durch den Umbruch neu entstandene Zeile als komplett neuer Raum, auf dem sich die nächsten paar Flexboxen breit machen – bis zum nächsten Umbruch. Das „breit machen“ erfolgt dabei auf der Kreuzachse, so dass die Elemente auch jeweils auf der vertikalen Mitte der Achse zentriert werden bzw. sich über die komplette Höhe der Zeile erstrecken können. Das Ergebnis ist dann tatsächlich einigermaßen Masonry-Layout-Like.

Block- und Inline-Elemente in HTML5

Kann ich eigentlich beim W3C oder woanders schnell herausfinden, welches Element in HTML5 ein Inline- und welches ein Blockelement ist?

Die Unterteilung in die zwei Kategorien „Block“ und „Inline“ gibt es in HTML5 nicht mehr. Stattdessen gibt es sieben neue Kategorien: Metadata, Flow, Sectioning, Heading, Phrasing, Embedded und Interactive. Elemente können in mehrere dieser Kategorien fallen. Das <a>-Element ist z.B. gleichzeitig Bürger der Kategoien Flow, Phrasing, Interactive und Palpable, während das <nav>-Element in Flow, Sectioning und Palpable zuhause ist.

Die Kategorien werden in HTML5 vorrangig genutzt, um festzulegen, welches Element in welchem anderen Element vorkommen darf (content model). Vor HTML5 galt die einfache Regel „Block-Elemente dürfen Block- und Inline-Elemente, Inline-Elemente aber keine Block-ELemente enthalten“. In HTML5 sollen aber auch Konstruktionen wie die folgende erlaubt sein:

<a href="/foo"> <!-- "Inline-Element" -->
  <h1>Foo</h1>  <!-- "Block-Element" -->
</a>

Um (unter anderem) dies punktuell zu ermöglichen ohne ein generelles Alles-In-Alles-Verschachteln zu erlauben, hat man die Kategorien einfach etwas feiner aufgegliedert. Alles was vor HTML5 an Element-Verschachtelungen möglich war, geht auch weiterhin – und eben ein kleines bisschen mehr.

HTML5 File API: File- in Blob-Objekte verwandeln?

Wie kann man File-Objekte in Blob-Objekte konvertieren? Braucht man dazu den FileReader?

Eigentlich sollte diese Umwandlung nicht nötig sein, denn File-Objekte sind nur ein Spezialfall bzw. eine „Unterklasse“ von Blob. Das kann man der IDL-Box (IDL = Interface Definition Language) an der entsprechenden Stelle in den Spezifikationen entnehmen. Jede API die Blobs verarbeitet sollte auch mit Files klarkommen:

var blob = new Blob(['Hallo Welt'], { type: 'text/plain' });
var file = new File(['Hallo Welt'], 'dateiname.txt');

// FileReader schlucken Files und Blobs gleichermaßen

var reader1 = new FileReader();
reader1.readAsText(blob);
reader1.onload = function(evt){
  window.alert(evt.target.result); // > 'Hallo Welt'
};

var reader2 = new FileReader();
reader2.readAsText(file);
reader2.onload = function(evt){
  window.alert(evt.target.result); // > 'Hallo Welt'
};

Sollte eine API oder Library auf Biegen und Brechen Files nicht annehmen wollen, so kann man ein File-Objekt via slice()-Methode in einen Blob verwandeln:

var blob = file.slice();

Das sollte aber eigentlich wirklich niemals nötig sein.

Privates in ECMScript 6-Klassen

Wenn Klassen in ES6 nur syntaktischer Zucker für Prototypen sind, gibt es dann auch keine Encapsulation mit private usw?

Etwas ähnliches wie private Objekteigenschaften sind in ES6 möglich, aber nicht durch Klassen allein. Vielmehr kann man Klassen (oder auch normale Constructorfunktionen bzw. Objekte) mit Symbols kombinieren und somit so-gut-wie-private Eigenschaften schaffen. Ein Symbol ist ein spezielles Objekt, das als Property-Name fungieren kann; etwas, das in ES5 nur Strings machen konnten:

let foo = {};
let property = Symbol();
foo[property] = 42;

console.log(foo[property]); // > 42

Jedes Symbol-Objekt ist einzigartig, so dass Namenskollisionen prinzipbedingt ausgeschlossen sind. Das ist praktisch um ein Objekt automatisiert mit Eigenschaften zu befüllen, kann aber auch für einen gesteigerten Grad an Privatheit genutzt werden  denn wer keinen Zugriff auf ein Symbol hat, kann auf die damit identifizierte Eigenschaft nicht ohne weiteres zugreifen:

let foo = {};

(function(){
  let property = Symbol();
  foo[property] = 42;
})();
  
// Wie an die 42 kommen?

Wer es drauf anlegt, kommt mit Object.getOwnPropertySymbols() an die Liste der auf einem Objekt verwendeten Symbols. So gesehen sind diese Eigenschaften nicht im Wortsinne privat, doch die als privat und als öffentlich gedachten Eigenschaften sind klar getrennt. Ein versehentlicher (oder auch nur leichtfertiger) Zugriff auf als nicht für die Öffentlichkeit gedachte Eigenschaften ist ausgeschlossen – und das ist ja der eigentliche Use Case, den es zu lösen gilt.

Ob es in ES6 (oder später) auch richtige private Eigenschaften geben wird, ist unklar. De facto existieren private Symbols bereits in den Spezifikationen, doch sie allgemein verfügbar zu machen, hätte allerlei Komplikationen zur Folge. Aktuell werden normale (d.h. einzigartige, aber nicht wirklich private) Symbols als gut genug betrachtet.

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.