Netz - Rettung - Recht (Artikel mit Tag haml)

Markup mit HAML

nospam@example.com (Thomas Hochstein) — Mon, 08 May 2017 07:15:00 +0000

Websites bestehen - hoffentlich - in der Regel aus (wenigen) Templates, die dann mit (vielen verschiedenen) Inhalten gefüllt werden. So arbeiten Blogs und CMS, so arbeitet auch ein static site generator. Die Templates können dabei HTML-Dateien sein - müssen es aber nicht, wie ich schon anno 2015 beschrieb.

Bei der Arbeit mit meinen Webseiten habe ich mit HTML-Templates angefangen, die ich dann in der Regel mit Markdown gefüllt habe - oder, um in der Diktion von nanoc, dem von mir verwendeten static site generator, zu bleiben: die Layouts in layouts/ waren HTML-Dateien, die Inhalte in content/ in der Regel Markdown, beides (soweit erforderlich) kombiniert mit embedded ruby (ERB). Beim Compilieren durchliefen die Layouts dementsprechend einen ERB-Filter, die Inhalte zwei Filter (Markdown und ERB).

Direkt mit HTML macht die Arbeit aber - gerade bei ein wenig komplexeren Gestaltungen - auf die Dauer nur wenig Spaß: ständig muss man Tags öffnen und schließen (gut, dabei unterstützen Editoren), und die Übersicht leidet. Daher habe ich mich nach kurzer Zeit entschieden, statt auf HTML auf HAML zu setzen, eine Template-Sprache, die von HTML abstrahiert.

Ein typisches Seitengerüst wie

<!DOCTYPE html>
<html lang='de'>
  <head>
    <meta charset='utf-8'>
    <meta content='IE=edge' http-equiv='X-UA-Compatible'>
    <meta content='width=device-width, initial-scale=1' name='viewport'>
    <title><%= @item[:title] %></title>
  </head>
  <body>
    <header>
      <div class='header-container'>
        <div class='row'>
           [...]
        </div>
      </div>
    </header>
    <div class='main'>
      <h1>Überschrift</h1>
      <p>
        Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed
        diam nonumy eirmod tempor invidunt ut labore et dolore magna
        aliquyam erat, sed diam voluptua. At vero eos et accusam et
        justo duo dolores et ea rebum. Stet clita kasd gubergren, no
        sea takimata sanctus est. 
      </p>
    </div>
    <footer class='footer'>
      [...]
    </footer>
  </body>
</html>

sieht in HAML so aus:

!!!
%html{:lang => "de"}
  %head
    %meta{:charset => "utf-8"}
    %meta{:content => "IE=edge", "http-equiv" => "X-UA-Compatible"}
    %meta{:content => "width=device-width, initial-scale=1", :name => "viewport"}
    %title #{@item[:title]}
  %body
    %header
      .header-container
        .row
          [...]
    .main
      %h1 Überschrift
      %p
        Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed
        diam nonumy eirmod tempor invidunt ut labore et dolore magna
        aliquyam erat, sed diam voluptua. At vero eos et accusam et
        justo duo dolores et ea rebum. Stet clita kasd gubergren, no
        sea takimata sanctus est. 
    %footer
      [...]

Das ist kürzer, klarer strukturiert - und die logische Struktur wird unmittelbar erkennbar. Außerdem wird das Ende eines Elements nicht durch ein schließendes Tag, sondern das Zeilenende (beziehungsweise das Ende einer Einrückungsebene) gekennzeichnet. HAML schließt Tags im generierten HTML daher selbständig. Nie mehr vergessene Tags, die sich öffnen, aber nicht wieder schließen! Fehler kann man im Prinzip nur noch beim Einrücken machen - aber fehlerhafte Einrückungen führen zu einem Fehler beim Compilieren und werden daher sofort erkannt. Zudem erhält das aus dem Template generierte HTML wunderbare Einrückungen, die es ebenfalls gut lesbar machen.

Für Templates ist HAML demnach hervorragend geeignet - für Inhalte allerdings nicht so sehr. Die große Stärke - die klaren Einrückungen - wird bei Texten, die immer wieder innerhalb von Blöcken Textauszeichnungen enthalten, zu einer großen Schwäche.

Man denke an folgendes Beispiel:

<p>
  Lorem ipsum dolor sit amet, consetetur <strong>sadipscing</strong>
  elitr, sed diam nonumy eirmod tempor invidunt ut labore et
  <em>dolore magna</em> aliquyam erat, sed diam voluptua. At
  <a href="https://netz-rettung-recht.de/vero/"><strong>vero</strong></a> eos et accusam et justo duo
  dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus
  est. 
</p>

Das sieht in HAML dann so aus:

%p
  Lorem ipsum dolor sit amet, consetetur
  %strong sadipscing
  elitr, sed diam nonumy eirmod tempor invidunt ut labore et
  %em dolore magna
  aliquyam erat, sed diam voluptua. At
  %a{:href => "/vero/"}
    %strong vero
  eos et accusam et justo duo
  dolores et ea rebum. Stet clita kasd gubergren, no sea takimata
  sanctus est.

Das ist … weniger schön, und beim Schreiben nicht mehr angenehm, sondern schnell die Hölle.

Es fragt sich also, was man am besten tut, wenn Markdown allein für Inhalte nicht genügt, weil es bspw. keine Elemente wie <section> oder <span> kennt und auch Tabellen nicht ohne weiteres abgebildet werden können. Man könnte natürlich wieder auf HTML zurückgreifen, das sich bekanntlich mit Markdown mischen lässt.

Oder man nutzt ein weiteres Feature von HAML: es unterstützt nämlich Filter, d.h. die Verwendung anderer Markupsprachen innerhalb eines Templates. So kann man die Verwendung von HAML auf die Templates und Strukturen beschränken und die Inhalte - bspw. - in Markdown beisteuern:

  %body
    %header
      .header-container
        .row
          [...]
    .main
      %h1 Überschrift
      :markdown
        Lorem ipsum dolor sit amet, consetetur **sadipscing** elitr,
        sed diam nonumy eirmod tempor invidunt ut labore et *dolore
        magna* aliquyam erat, sed diam voluptua. At [**vero**](/vero/)
        eos et accusam et justo duo dolores et ea rebum. Stet clita
        kasd gubergren, no sea takimata sanctus est.
    %footer
      [...]

Best of both worlds!

Außerdem unterstützt HAML embedded ruby - statt HTML-Templates und Markdown-Inhalten bleiben also nur noch .haml-Dateien, die einen HAML-Filter durchlaufen. Fertig - Markdown und ERB gibt es quasi gratis dazu. (Und Textile, LESS, SASS und vieles andere, wenn man das möchte, auch.)

Markup-Formate konvertieren

nospam@example.com (Thomas Hochstein) — Mon, 16 Feb 2015 05:55:00 +0000

In meiner Reihe “Webdesign anno 2015” habe ich versucht, einen Überblick über Techniken und Tools zu geben, die letztlich jedermann die Gestaltung moderner, gut aussehender Webseiten ermöglichen. Das hatte natürlich einen konkreten Anlass: ich bin dabei, allmählich und sehr langsam - im Rahmen der mir bleibenden zeitlichen Möglichkeiten - verschiedene ältere Webpräsenzen zu überarbeiten und inhaltlich wie optisch und technisch auf den heutigen Stand zu bringen.

Eine große Erleichterung ist dabei die automatische Konvertierung von “klassischem” HTML in HAML und/oder Markdown. Ein machtvolles Werkzeug für solche Konvertierungsaufgaben ist pandoc; es geht aber oft auch eine Nummer kleiner, ganz simpel per cut & paste online:

Convert HTML to HAML
HTML zu Markdown konvertieren:
to-markdown

Wenn nur eine Handvoll Seiten - oder Teile einer Seite - zu konvertieren sind, reicht (mir) das vollständig aus.

Templates und Template Engines

nospam@example.com (Thomas Hochstein) — Mon, 02 Feb 2015 05:30:00 +0000

HTML und CSS, Frameworks wie Bootstrap, Web- und Iconfonts, LESS oder SASS bieten viele Möglichkeiten zur Gestaltung standardkonformer, gut lesbarer und auf verschiedenen Endgeräten nett anzusehender Webseiten. Eine größere Webpräsenz komplett “von Hand” zu pflegen macht allerdings wenig Spaß - und ist auch alles andere als professionell oder eine gute Idee.

Denn regelmäßig ist eine Website oder auch eine Webapplikation gekennzeichnet durch ein “Grundkorsett”, das mit wechselnden Inhalten gefüllt wird. So wird sich meist ein einheitliches Gestaltungskonzept mit Kopf- und/oder Fußzeile, mit einer oder mehreren Spalten und einer Navigation auf allen Seiten wiederfinden. Dieses Grundgerüst der ganzen Webpräsenz sollte sich dann nicht per copy & paste auf jeder Einzelseite wiederholen, sondern vielmehr in Form einer Vorlage, eines Templates, vorliegen, um dann jeweils mit spezifischen Inhalten gefüllt zu werden. Auch ist es - gerade bei Webapplikationen - sinnvoll, die “Technik” von der “Darstellung” zu trennen, damit Änderungen am Design nicht zwingend Änderungen an der Programmierung erfordern und umgekehrt. (Und, natürlich, damit verschiedene Teams an der optischen Darstellung der Seiten und der dahinterstehenden Programmlogik arbeiten können).

Auf diese Art und Weise arbeiten bspw. Blogsysteme wie Wordpress (mit eigenen Template-Funktionen) oder Serendipity (wo das Template-System Smarty genutzt wird) und natürlich auch Content Management Systeme (CMS) oder static site generators.

Das Prinzip ist immer gleich: ein Grundgerüst und mögliche Inhalte werden getrennt definiert, wobei das Grundgerüst oft aus einer HTML-Datei besteht. In dieser (HTML-) Datei können Platzhalter (Variablen) durch passenden Text ersetzt und andere Dateien eingebunden werden, Codefragmente (in einer Programmiersprache wie Perl, PHP, Python oder Ruby und/oder in einer speziellen Template-Sprache) eingebaut und/oder sogar statt HTML andere Auszeichnungssprachen verwendet werden. Das kann “dynamisch” bei jedem Aufruf der Seite erfolgen, ggf. mit Caching, oder die Webseiten können einmal aus ihren Quelltexten generiert werden und dann “statisch” online gestellt - und nur bei Änderungen aktualisiert - werden.

Einbindung von Script-/Programmiersprachen in HTML-Dokumente

PHP ist an und für sich - und ganz ursprünglich - selbst eine Template Engine. In eine HTML-Datei werden PHP-Fragmente eingebunden und die Webseite auf diese Weise dynamisiert. In ähnlicher Weise funktionieren eRuby (das Ruby einbindet), Active Server Pages (ASP) oder Java Server Pages (JSP).

Die Einbindung kompletter Scriptsprachen in Webdokumente führt zwar einerseits zu einem großen Funktionsumfang, ist aber andererseits nicht immer bequem, weil oft komplex, und zudem auch nicht sicher - eben wegen des Funktionsumfangs: wer eine PHP-Datei auf einen Server hochladen kann, darf faktisch dort Programme ausführen.

Spezialisierte Template Engines

Systeme wie Smarty enthalten hingegen eine eigene, abgespeckte “Sprache”, die einerseits nicht unmittelbar die Ausführung beliebigen Codes erlaubt und - vor allem - andererseits speziell auf die Aufgabe, eine Vorlage mit individuellen Inhalten zu füllen, zugeschnitten ist.

Solche Template Engines können unter verschiedenen Sprachen ausgeführt werden; Smarty erfordert bspw. PHP. Ein anderes Beispiel, das unter einer Vielzahl von Sprachen ausgeführt werden kann, wäre mustache. Die dort gebotenen Möglichkeiten sind allerdings nicht ganz so vielseitig.

Template Engines und Markup Languages

Setzen die vorgenannten Beispiele in der Regel auf ein HTML-Dokument, also eine konventionelle Webseite, auf, und ergänzen das HTML mit zusätzlicher Funktionalität - Variablen, Funktionen, Datenbankanbindung usw. -, gibt es auch Template Engines, die eine eigene Auszeichnungssprache mitbringen und auf diese Art und Weise die Vorteile eines Templates mit einer vereinfachten Auszeichnungssprache wie Markdown oder Textile verbinden.

Eines dieser Systeme ist HAML. HAML-Templates bestehen nicht aus HTML, sondern einer vereinfachten Variante, die v.a. ohne schließende Tags auskommt und zudem die logische Struktur des Dokuments durch Einrückungen abbildet. Das hat - neben eingesparter Schreibarbeit - den charmanten Vorteil, dass das Problem “vergessener” schließender Tags der Vergangenheit angehört. Darüber hinaus bietet HAML zum einen die Möglichkeit des Einbindens von Ruby-Code (ersetzt insoweit also eRuby) und zum anderen den Einsatz von Filtern, so dass bspw. Markdown oder Textile in HAML-Templates eingebaut werden können. Letzteres ist schon deshalb wichtig, weil das Verfassen längerer Texte in HAML durch die Notwendigkeit, für jedes neue Tag einen neuen eingerückten Abschnitt zu beginnen, doch ziemlich umständlich ist.

Nach dieser komplizierten Erläuterung ein Beispiel für HAML in der Praxis. Der folgende kurze HTML-Schnipsel:

<section class="container">
  <h1>Ein neues Kapitel</h1>
  <div class="content">
    <p>
      Hier könnte jetzt ein längerer Text stehen,
      der sich über viele Zeilen erstreckt!
    </p>
  </div>
</section>

würde in HAML folgendermaßen aussehen:

%section.container
  %h1 Ein neues Kapitel
  .content
    %p
      Hier könnte jetzt ein längerer Text stehen,
      der sich über viele Zeilen erstreckt!

Sollte der “längere Text” weitere Tags enthalten, wird das in HAML allerdings eher umständlich:

<p>Hier könnte jetzt ein <strong>längerer</strong> Text stehen,
  der sich über <em>viele</em> Zeilen erstreckt!</p>

wird zu:

%p
  Hier könnte jetzt ein
  %strong längerer
  Text stehen,
  der sich über
  %em viele
  Zeilen erstreckt!

Daher kann man stattdessen - innerhalb von HAML - Markdown (oder auch Textile) verwenden und direkt auch (via eRuby) variable Elemente einbinden:

= render 'header'
%section.container
  %h1= chapter.title
  .content
    :markdown
      Hier könnte jetzt ein **längerer** Text stehen,
      der sich über *viele* Zeilen erstreckt!
= render 'footer'

Schick, nicht wahr?

Template Engines im Vergleich

Die Anzahl der verfügbaren Template Engines ist ähnlich unüberschaubar wie das bei CMS oder static site generators der Fall ist. Die englischsprachige Wikipedia bietet immerhin eine Vergleichstabelle für einen ersten Überblick an.

Dieser Beitrag gehört zur Reihe “Webdesign anno 2015”.