Das Pakyow-Projekt erfüllt diese Anforderung nicht, zeigt aber einen interessanten Ansatz für Views. Sicher nicht der erste oder gar einzige seiner Art, aber einer mit konkreter Umsetzung. Zudem scheint eine weitere Entwicklung in Richtung Client- und Server-Seite möglich, da Entwickler Bryan Powell bei dem Thema recht euphorisch wirkt.

<article data-scope="post">
  <h1 data-prop="title">My First Post</h1>
  <div data-prop="body">Lorem ipsum dolor sit amet</div>
</article>

Das einfache Beispiel führt dabei zum selben Ergebnis wie das folgende HAML-Beispiel, nur dass die obigen Data-Attribute für spätere Updates erhalten bleiben.

- @posts.each do |post|
  %article
    %h1= post.title
    %div= post.body

Man beachte die Each-Schleife: Das obige Template erzeugt das Article-Element für jeden Post der Datenquelle.

Das obige Beispiel hat gegenüber der HAML-Notation entscheidende Vorteile.

Der Template-Entwickler kann die Templates mit beliebigen Inhalten befüllen (siehe oben „My First Post“) und ohne Backend-Logik ein sinnvolles Ergebnis sehen. Template und Backend sind besser getrennt.

Der wesentliche Vorteil ist aber, dass das Template mit einfachen Datenstrukturen, üblicherweise einem JSON-Dokument, bestückt werden kann. Eine solch relativ einfache Template-Engine ließe sich für Server (z. B. in Ruby) und in Javascript für den Client realisieren. So kann der Server den mit korrekten Werten befüllten View ausliefern. Weitere Updates würde er nur als JSON schicken, welches der Browser anhand der gegebenen Data-Notationen ins DOM einbaut.

Der Backend-Entwickler muss sich somit nur noch um die JSON-Struktur sorgen. Ob die Response als HTML oder JSON ausgeliefert wird, ließe sich weitgehend im Framework abstrahieren.

Für mich als Rails-Gefangenen ist das Hauptproblem mit Pakyow, dass es Rails ersetzen statt ergänzen würde. Einen Ansatz zur Integration konnte ich bisher nicht finden, so dass hier eigene Überlegungen notwendig wären.

Eine schöner Ansatz, der zumindest einen großen Teil dieses Gebietes abdeckt, bietet Adaptive Images. Die Software habe ich nicht getestet und sie dürfte für viele ohnehin nicht nutzbar sein, da sie PHP und einen Apache Webserver erfordert. Die Idee ist aber gut und einfach umsetzbar.

Client: Cookie mit Bildschirmdimensionen setzen

Wer generell gegen Cookies und Javascript ist kann jetzt aufhören zu lesen. Via JS setzen wir im Head ein(en?) Cookie mittels JS, in dem die maximale Bildschirmgröße gespeichert wird:

document.cookie = 
    'resolution=' + Math.max(screen.width,screen.height) + '; path=/';

Da wir das Maximum wählen, können wir sicher sein, dass Bilder auch nach dem Kippen des Gerätes ins Querformat noch ordentlich aussehen.

Das war es auch schon. Der Browser sendet ab sofort bei jedem Aufruf die Auflösung mit. Auch bei Bildern, ob aus Img-Element oder CSS.

Server: Bildanfrage abfangen, Bild in neuer Größe erzeugen und umleiten

Serverseitig muss die Anfrage nun auf irgend ein Serverprogramm umgeleitet werden. Dieses kennt den Pfad zum Bild und die gewünschte Dimension. Es nimmt also das Bild, skaliert es herunter und speichert es. Nun schickt es dem Client eine Weiterleitung auf die optimierte Datei. Diese kann sogar permanent sein, da sich die Dimensionen eines Browsers in aller Regel nicht ändern.

Die Skalierung des Bildes ist nur beim ersten mal für eine bestimmte Größe nötig. Später wird auf die bereits erzeugten Varianten verwiesen.

Nur ein Ansatz

Dies ist natürlich nur ein Ansatz. Welche Bilder skaliert werden sollen und wodurch diese vom Server erkannt werden muss für jede Website geklärt werden. Zudem sollte man sich Normgrößen überlegen, damit nicht unzählige Varianten ein und der selben Datei wegen zwei Pixeln Unterschied auf der Platte landen.

Gegenüber verbreiteten Ansätzen gibt es einen zentralen Vorteil. Browser müssen nicht erst alle kleinen Bilder laden um im Nachhinein via Javascript zu erfahren, dass sie diese durch für ihre Größe angemessene Varianten ersetzen sollen. Hier lädt der Client ein Bild und der Server liefert ihm was er braucht.

Der Ansatz funktioniert nicht ohne Javascript und Cookies. Sind diese deaktiviert oder nicht vorhanden, erhält der Browser eine Standardversion des jeweiligen Bildes. Die Website funktioniert somit dennoch wie erwartet, nur die Optimierung fehlt.

Semantische Fragwürdigkeit bei der W3C

Das W3C-Beispiel wirkt etwas ungewöhnlich, da man <kbd> in sich selbst verwendet:

Beispiel B

<p>Please, press <kbd><kbd>Shift</kbd>+<kbd>A</kbd></kbd></p>

Mir fällt es schwer, die Semantik zu deuten, vor allem wenn man Beispiel A hinzu nimmt:

Beispiel A

<p>Please, input "<kbd>Yes</kbd>" or "<kbd>No</kbd>"</p>

Die Bedeutung des Elements variiert folglich stark, je nachdem in welchem Kontext es genutzt wird:

1. Wird das Element verwendet, ohne Kind von sich selbst zu sein und enthält sich selbst nicht als Kind, so soll der Nutzer den Inhalt als einzutippenden Text verstehen (Yes).
2. Wird das Element als Kind von sich selbst verwendet, so ist der Inhalt als einzelne Taste zu verstehen (Strg).
3. Wird das Element verwendet, ohne Kind von sich selbst zu sein, enthält jedoch weitere KDB-Elemente als Kinder, so ist enthaltener Reintext als Zusatzanweisung zu verstehen, die die Beziehung angegebener Tasten beschreibt (+).

Und das betrifft nur die einfachste Schachtelung. Man stelle sich vor, der Nutzer müsste während der Texteingabe noch eine Tastenkombination drücken… Vielleicht…

<kbd>object.get<kbd><kbd>Strg</kbd>+<kbd>Leertaste</kbd></kbd></kbd>

…?
Liebe W3C, hier sollte man noch mal drüber nachdenken. Oder überhaupt mal drüber nachdenken. Wer weiß, woher das Element kommt. Irgendwie ist ja nicht mal definiert, was KBD denn heißen soll. Keybord vielleicht?

Stylesheets für einzelne Tasten

Wenn ich jetzt also eine einzelne Taste mit Rahmen versehen will, steht die Frage nach dem CSS-Selektor. Die extreme Kontextabhängigkeit macht die Auswahl nahezu unmöglich. Hier müsste man für sich selbst (und ggf. die ganze Redaktion einer Website) die Festlegung treffen, dass einzelne Tasten immer als <kbd> in einem <kbd> angegeben sind und dass das Element maximal einfach verschachtelt werden darf. Dann ließe sich die einzelne Taste mit kbd kbd selektieren.

Für mich ist dies eines der wenigen Male, in denen ich bewusst mit dem Standard brechen und stattdessen mit dem Strom schwimmen werde: Das Element <kdb> beschreibt hier eine einfache Taste der Tastatur.

Mein CSS für eine solche Taste sieht folgendermaßen aus:

kbd {
	font:inherit;
	font-family:monospace;
	font-size:.9em;
	border:1px solid #ccc;
	background:#fdfdfd;
	padding:0 .3em;
	margin:0 .1em 0 0;
	border-radius:2px;
	box-shadow:1px 1px 0 #ccc;
}

Dies sollte auch in verschiedenen Größen zu brauchbaren Ergebnissen führen und auch inline den Text nicht zerreißen, wie das Beispiel Strg + a an dieser Stelle zeigen soll.

Strg + a

Strg + a

Strg + a

Widmung

Dieser Artikel ist Yannick gewidmet, der mich für meinen W3C-Verrat sicher direkt in die Hölle zu den Internet-Explorer-Entwicklern wünschen wird…

Ein Inline-Element (span, img, b, u, i, em…) in einem Blockelement (div, p, h1…) vertikal zu zentrieren ist nicht leicht. Zwar gibt es die CSS-Eigenschaft vertical-align, aber leider ist deren Verhalten recht eigen:

div { height:50px; }
span { vertical-align:middle; }

Ein recht ernüchternder Anfang. Dann vielleicht die selbe Höhe verwenden:

div { height:50px; }
span { vertical-align:middle; height: 50px; }

Klappt auch nicht. Span ist ein Inline-Element und hat als solches gar keine Höhe. Die Angabe hat keinerlei Auswirkung.

Abhilfe schafft stattdessen die leider weniger bekannte Eigenschaft line-height:

div { height:50px; }
span { vertical-align:middle; line-height: 50px; }

Checkbox und Label auf gleicher Höhe

Ein ähnliches Problem stellt sich oft, wenn man Checkbox und Label auf der selben Höhe haben möchte. Nicht selten lässt sich auch mit vertical-align kein gleichmäßiges Bild erzeugen:

Auch hier ist oft die unterschiedliche Zeilenhöhe schuld. Eine Korrektur führt zur gewünschten Höhengleichheit:

input { vertical-align:middle;line-height:1em; }
label { vertical-align:middle; }

table.overview#mainoverview>thead(>tr>th*4)+tbody>tr>td*4

Nun drückt man (bei den meisten Implementierungen) Strg+e und die Eingabe wird automatisch erweitert:

<table class="overview" id="mainoverview">
  <thead>
    <tr>
      <th></th>
      <th></th>
      <th></th>
      <th></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td></td>
      <td></td>
      <td></td>
      <td></td>
    </tr>
  </tbody>
</table>

Installation in Sublime Text 2

cd ~/.config/sublime-text-2/Packages/
git clone --depth 1 https://github.com/sergeche/emmet-sublime.git

Sublime neustarten und fertig.

Installation in WordPress

Auch in WordPress lässt sich Zen-Coding verwenden, wie ich im Artikel HTML-Editor in WordPress mit Zen-Coding verbessern schon einmal beschrieben habe.

<a href='http://picomol.de/' rel='external'>Valentin</a>

Einfache Anführungszeichen um Attribute? Was aber noch schlimmer ist: Der HTML-Standard erlaubt eine solche Notation: By default, SGML requires that all attribute values be delimited using either double quotation marks (ASCII decimal 34) or single quotation marks (ASCII decimal 39). Danke W3C, ist natürlich sehr hilfreich wenn man sowas auch noch beachten muss. Vielleicht war XHTML doch keine so schlechte Idee…

<div id="page_wrap" class="container row">
 <header class="row span_12">
  <hgroup class="row span_12">
   <h1 class="col span_4">Site Title</h1>
   <h2 class="col span_8">Site Description</h2>

Fünf Elemente, zehn Klassen, eine ID? Diese netten Zusatzinformationen führen zu 193 statt 68 Zeichen. Ich weiß nicht, wer einmal beschlossen hat, Stylesheets vom Markup zu trennen. Und ich weiß auch nicht wie lange das her ist. Aber ich bin mir sicher: Das hat er oder sie sicher nicht gewollt.

Auch Style-Klassen sind Designinformationen…

… und haben im Markup nichts zu suchen. HTML hat im wesentlichen genau eine Aufgabe: Den Inhalt der Seite zu transportieren. Zudem können noch zusätzliche Informationen angegeben werden, etwa wo sich Dateien befinden, welche Scripts oder eben auch Stylesheets enthalten. Diese Dateien sind optional, es steht jedem zu sie wegzulassen.

Ein großer Teil von Website-Besuchern sind Bots, die solche Sachen in der Regel nicht interessiert. Trotzdem verdoppeln die meisten ihre HTML-Größe auf oben beschriebene Weise.

Fehlende Wiederverwendbarkeit von CSS

Auf den meisten Websites bestimmt also das HTML durch seine Klassen selbst, wie es dargestellt werden soll. Der Grund hierfür ist aus meiner Sicht der stark begrenzte Funktionsumfang von CSS: Es gibt keine Variablen, keine Vererbung und keine anderen Wiederverwendungstechniken. Sollen Header und Footer die selbe Hintergrundfarbe haben, muss diese für beide definiert werden. Das führt zu einer problematischen Code-Dopplung: Will man die Farbe ändern, muss man dies an zwei Stellen tun.

Viele Webdesigner und Framework-Schreiber versuchen daher, diese Eigenschaften, die für beide Elemente gleich sind, in eine neue Klasse auszulagern. Da CSS diese Klassenstyles aber nicht mit bestimmten Elementen verknüpfen kann, wird diese Information ins HTML ausgelagert. Auch wenn man es nicht immer direkt wahrnimmt: Solche Klassen sind ein direkter Teil von CSS.

Um dieses Problem abzuschwächen, gibt es viele interessante erweiterte Sprachen, die CSS erzeugen. Less ist sicher einer der prominentesten Vertreter, den ich aber meist in seiner PHP-Variante Less-PHP benutze.

Schlimmer geht immer: Wrapper-Elemente

Das obige Beispiel enthält mit <div id="page_wrap" class="container row"> ein noch viel schlimmeres Problem: Wrapper-Elemente. Typo 3 geht hier mit schlechtem Beispiel voran. Überschrift gefällig?

<div id="c304" class="csc-default">
 <div class="csc-header csc-header-n1">
  <h1 class="user class">Impressum</h1>
 </div>
</div>

Das sind 130 Zeichen Markup für neun Buchstaben. Und das ist durchaus üblich.

Meine Vorsätze für künftige Websites

• Akzeptieren, dass eine Gruppe von Elementen nicht umrandet werden kann, wenn es an der Stelle kein Elternelement gibt. Meist ist dort kein Extra-Div, weil es dort nicht hingehört. Wenn es semantisch nicht zusammengehört, warum sollte man es optisch gruppieren?
• Warum nicht mal Javascript? Wenn man es trotzdem nicht lassen kann, kann man die Wrapper doch einfach mit Javascript ergänzen. Auch das hält das ausgelieferte HTML rein.
• Es geht auch semantisch: Klassen und IDs sind nichts schlechtes. Sie können Informationen über ein HTML-Element enthalten. Klassen wie article, comment oder author sind Metainformationen des Inhalts und somit legitimer Teil des Markups. Stylesheets sollten solche Informationen adressieren.
• HTML-5-Elemente: Besser sind die vielen neuen HTML-5-Elemente, die solche semantischen Informationen bereits in sich tragen.
  • section
  • article
  • header
  • footer
  • figure
  • aside
  • und viele, viele mehr…
• Alte Browser fallenlassen. Schluss mit Browserweichen und Zusatz-Wrappern.
• Eine Weiche vielleicht doch: Für IE < 8 CSS und Javascript gleich ganz abschalten.

Ich träume von einer Welt, in der man Websites auch im Quelltext lesen kann…

Und heute ist es schon wieder passiert: Auf der Suche nach typischen Metainformationen für Websites habe ich – Überraschung! – nach Meta-Tag gesucht. Dass der zugehörige Wikipedia-Artikel nun aber Meta-Element hieß, kam mir ungewöhnlich vor. Nennt das jemand wirklich so? Den Artikelschreibern kam es offensichtlich auch merkwürdig vor, so dass sie auch direkt den obigen Meiert-Artikel verlinkt haben.

Und was ist nun ein Script-/Meta-/HTML-Tag?

Als Tag bezeichnet man lediglich die Dinger in spitzen Klammern. Ein Element besteht zwar aus Tags, ist aber mehr.

Tag oder Element?

Das Beispiel besteht aus zwei Elementen, einem P- und einem Em-Element. Das Em-Element beinhaltet dabei noch Text, das P-Element sogar ein weiteres Element.

Tags finden sich hier hingegen vier: Ein öffnendes und ein schließendes P-Tag (<p>, </p>) und analog zwei Em-Tags (<em>, </em>).

Meta-Elemente = Meta-Tags?

Bei Meta-Tags wird der Unterschied zunächst einmal kleiner, da die Elemente aus nur einem Tag bestehen. Element-Attribute werden zudem ebenfalls im öffnenden Tag notiert.

Element und Tag sehen somit gleich aus. Der Unterschied ist konzeptioneller Natur: Der/das Tag ist die Syntax, die das Element erzeugt. Will man nun ein Meta-Element zu einer Seite hinzufügen, so geht es darum, ein Element und somit Inhalt zu ergänzen. Es geht nicht darum, den Quelltext zu vergrößern. Tags sind lediglich Mittel zum Zweck. Meiert folgert, dass man in 90 % aller Fälle, in denen man von Tags spricht, von Elementen sprechen sollte.

Wieder was gelernt. Ist ja auch nicht schwer zu verstehen. Ob ich nun künftig immer vom Meta-Element sprechen werde kann ich aber nicht versprechen…

Referenz: Ambiance aus Ubuntu 10.10

Hier meine Vorlage:

Es ist zwar nicht mehr die aktuelle Variante, allerdings ist eine Umstellung auf die neueren Ambiance-Variante mit der jetzt gemachten Vorarbeit kein Problem mehr.

HTML-Ambiance-Theme

Meine derzeitige Umsetzung beschränkt sich, wie bereits erwähnt, auf die Menüleiste:

Oder mit offenem Menü:

Zugegeben: Das ist alles noch nicht wirklich brauchbar. Dennoch zeigt es, wohin die Reise gehen kann, wenn man sich wirklich die Mühe macht. Mit HTML 5 und CSS 3 kann man viele recht aufwändige Effekte ohne viel Arbeit realisieren: Schrift mit Schatten hinterlegen, Ecken abrunden oder Farbverläufe – so macht Designen Spaß.

FIWA Menubar

Die Menüleiste verhält sich nun ziemlich genau wie die in GTK (und somit hoffentlich auch den meisten anderen Toolkits, viele Tests konnte ich noch nicht machen):

• immer normaler Mauszeiger
• Hover-Hervorhebung nur, wenn irgend ein Teil des Menüs offen
• Untermenüs bleiben offen bis Klick irgendwo im Dokument
• ist Untermenü offen, werden andere Untermenüs schon durch darüberfahren geöffnet und das vorige geschlossen

Leider wird die Funktionsweise durch eine Screenshot kaum deutlich.

 Das Design

Für die perfekte Systemintegration benötigt man vor allem ein passendes Theme. Ich habe mich vorerst dazu entschieden, keiner speziellen Vorgabe zu folgen, um eine möglichst allgemeine Lösung zu finden, für die man später dann verschiedene Designs erstellen kann.

Einschränkungen

In Chrome und Firefox funktioniert die Menüleiste tadellos. Ich möchte mich bewusst auf moderne Browser beschränken. Im Zweifel kann lieber jemand zehn Minuten in sein IE-6-Update stecken als ich jetzt drei Stunden um es da zum Laufen zu kriegen.

Eine etwas größere Einschränkung ist da die Tatsache, dass das Menü derzeit nur zwei tief verschachtelt werden darf. Jede weitere Ebene ist etwas problematischer, da diese ja neben dem aktuellen Unterpunkt positioniert werden müssen. Aber auch das sollte in absehbarer Zeit machbar sein.

Download

Die Sache ist noch nicht im Ansatz fertig. Wer aber schon einmal hineinsehen möchte, kann das über das entsprechende Github-Projekt tun:

• SebastianG86 / FIWA auf Github