Markup mit HAML
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="/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.)
Trackbacks
Keine Trackbacks
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt