Webdesign: Wunschliste

Webtechnologien sind einen weiten Weg gegangen. Framesets kamen und gingen, Perl wurde gross, und dann schnell verlassen, HTML5 trat auf die Bühne, Microsofts IE starb endlich, die whatwg und die w3c begannen, verschiedenene Wege zu gehen, Javascript gibts immer mehr auch auf dem Server und ich habe noch immer nicht die Dinge, die ich wirklich wünsche, bzw. viel neues kommt halb kaputt.
Deshalb folgt hier meine Wunschliste. Vielleicht liest es jemand und kann am Zustand was ändern.

Import

Eine Sprache, die nicht den Import von Modulen erlaut, ist schlichtweg nur lächerlich! Eine website könnte aber so aussehen:

<!DOCTYPE html>
<html lang="de">
<head>
	<meta charset="UTF-8">
	<meta name="description" lang="de" content="Webdesign Wunschliste">
	<title>Webdesign Wunschliste</title>
	<import src="components.html" query="head .headComponent">
</head>
<body id="top">
	<import src="components.html" query="body .preContentComponent">
<main>
	<h1>Webdesign Wunschliste</h1>
	<p>bla bla...</p>

</main>
	<import src="components.html" query="body .postContentComponent">
</body>
</html>

Wie ist das zu verstehen? components.html Ist eine ordinäre html-Seite. Aus dieser werden Teil-Bäume aus deren Dom entsprechend der query-Regeln extrahiert und die Collections an entsprechender Stelle eingefügt, wobei das import-Element aus dem DOM entfernt wird. query hat hier die Form eines CSS Selectors. Folgende Queries sollten also möglich sein.

query="element > element[lang=de]"
query="element .someClass"
query="#someId, someOtherId"
query="selector, otherSelector"

Im Unterschied zu embedded Content wird das DOMContentLoaded Flag erst gesetzt, wenn alle imports getätigt wurden. Jeder wird sofort die Schönheit der Syntax einsehen. Nicht nur kann ich in der components.html meine Navigation pflegen, ich kann auch alle Sprachversionen unterstützen. UND... da es sich um eine normale html-Seite, also statischen Inhalt handelt, ist das wunderbar zu cachen.

Als geborener Pessimist glaube ich nicht daran, so was noch zu erleben. Meine vorläufige Lösung lautet deshalb:

<!DOCTYPE html>
<html lang="de">
<head>
	<meta charset="UTF-8">
	<meta name="description" lang="de" content="Webdesign Wunschliste">
	<title>Webdesign Wunschliste</title>
	<script src="../js/main.js"></script>
</head>
<body id="top">

<h1><small>Webdesign:</small> Wunschliste</h1>
<p>bla bla</p>
</body>
</html>

Das hat einige Nachteile.

Wichtigste Vorteile sind:

Und darum solls eigentlich gehen: HTML-Authoring soll einfach und übersichtlich sein.
So, das war mein wichtigster Wunsch, und bis der erfüllt ist, werde ich darauf beharren: HTML ist als Sprache einfach nur lächerlich!

Was für läppische details :(

Wir haben die Elemente Details/Summary um endlich das Kleingedruckte zu verstecken - Grossartig!
Offenbar hat niemand daran gedacht, dass ein solches Element auch einen sekundären Button haben darf.

hier ist mein Vorschlag für ein besseres <details>


<details id="d1" name="group1">
  <summary>Label</summary>
  viel blabla
  <label for="d1">schliessen</label>
</details>

<details id="d2" name="group1">
  <summary>Label</summary>
  viel blabla
  <label for="d2">schliessen</label>
</details>

Richtig, ein label für details!
Und das Verhalten...

Das nächste Problem, das die Verwendbarkeit von details einschränkt, besteht in der Weise, in welcher seine Rolle im DOM festgelegt ist. Das Element darf nämlich nur eingesetzt werden, wo flow-content erwartet wird. Es kann also nicht verwendet werden für Fussnoten-ähnliche Notizen oder um abbr zu erläutern.
Ohne dass diese Rolle änders definiert wird, erweist sich details als weitgehend nutzlos.
Einstweilen sehe ich keinen Grund, überhaupt details zu verwenden. Dazu ist es schlicht zu limitiert.
Vielleicht erklärt das auch, warum Microsoft das Element nicht in Erwägung zieht.