Als Alternative zur Apptisierung des mobilen Internets wird immer wieder die Webapp genannt. Ebenso oft wird betont, dass native Apps den Webapps in UI und Features überlegen sind. Die Browser holen jedoch langsam auf, z.B. mit der Möglichkeit Geodaten zu lesen, oder auch Zugriff auf eine im Smartphone integrierte Kamera zu erhalten. Und dann ist das noch das Feature der offlinefähigkeit. Im folgenden will ich einige Techniken dazu kurz anreissen, zum einen um (mir) einen Überblick zu verschaffen, zum anderen um feststellen zu können, wie weit wir denn technologisch heute sind, in Sachen offline. Zum über den Onlinezustand hinaus gehenden Speichern von Daten stehen im wesentlichen drei Techniken zur Verfügung.

DOM Storage

Als DOM Storage bezeichnet man einen kleinen, leicht zugänglichen Speicherbereich, auf den vom Browser über eine sehr einfaches Interface zugegriffen werden kann: es werden jeweils Key-Value-Paare gespeichert. Das DOM Storage kommt in zwei Ausführungen: als Localstorage ist der Speicher persistent, als Sessionstorage hält er nur bis zum Sessionende.

DOM Storage besticht vor allem durch die Einfachheit mit der man ihn nutzen kann und ist zudem weit verbreitet. Deswegen wird er wohl vielerorts als das Schweizer Messer der Offlineapplikationen angespriesen; ja, das wäre ja zu schön… die Wahrheit ist: DOM Storage is considered harmful, vor allem wegen seiner grausigen Performance. Zudem ist die Menge an Speicher, die man damit zur Verfügung bekommt ziemlich klein. Unter iOS stehen wohl nicht mehr als 5 MB zur Verfügung, da kann man eh’ keine großen Sprünge machen, auch wenn Androiden und Desktopbrowser mehr Speicher zu lassen.

Application Cache

Die Mutter der Offlinefunktionalitäten dürfte der Application Cache sein. Hier steuert man unter Zuhilfenahme einer Manifest-Datei, welche Dateien der Browser für die eigene Webapp in den Application Cache legt. Der Clou dabei ist, dass im Offlinezustand diese gecachten Dateien völlig transparent zur Verfügung stehen. Ohne die Meldung »Ey Alter, geh’ mal online« werden Bilder aus dem Cache geladen und Scripts interpretiert. So sollte es jedenfalls sein. Hier zeigt sich der Browser called Browser (aka. Android-Webkit) aus Android 3.2 etwas unwillig und beschwert sich per Popup, das man ja nun offline sei, nur um danach alles wie gewünscht zu verarbeiten.

Für den Application Cache gibt es auch etwas Javascript-Interface mit dem man bspw. den Cache leeren kann. Auch gut geeignet zum Debuggen, denn wegen der oben erwähnten Transparenz, sind Fehler manchmal etwas schwierig zu finden. Hilfreich: hier kann man seine Manifest-Datei validieren lassen. Wermutstropfen Nummer eins: auch der AppCache wird durch das störrische iOS auf einer Untergrenze von 5 MB festgenagelt.

Browserdatenbanken

Wer bis hier mit den vorgeschlagenen Möglichkeiten zurecht kommt, oder mit anderen Worten: wer nicht mehr als 5 MB offline zu speichern hat, der hat Glück gehabt, denn er ist nicht auf die DB-Funktionalitäten der modernen Browser angewiesen. Diese stellen zwar wesentlich mehr Speicherplatz zur Verfügung, selbst im mobile Safari kann man, nachdem der Nutzer zugestimmt hat, bis zu 50 MB Daten in Datenbanken speichern und offline wieder abrufen. Trotzdem steht man derzeit vor einem Schlachtfeld.

Auf der einen Seite steht WebSQL, dass zwar in vielen Browsern zur Verfügung steht (Chrome, Opera, Safari, Android Browser…), aber vom W3C letztendlich verschmäht wurde, weil alle Browserhersteller das gleiche Backend nutzten. Stattdessen arbeitet man nun an IndexedDB. Das wäre sicherlich eine genauso gute Lösung, ist aber zumindest zum heutigen Zeitpunkt nicht gerade verbreitet: Firefox kommt seit Version 4 damit, Chrome (ab 12) kann beides, IE 10 wird es haben hat es, eines Tages. Der neue Chrome für Android kommt ebenfalls mit IndexedDB. Momentaner Stand hier ist allerdings, dass sich die Implementierungen doch noch sehr stark unterscheiden, zwischen den Browsern, aber vor allem auch von einer Browserversion zur nächsten, die ja heutzutage praktisch wöchentlich kommen…

Da muss man sich dann natürlich fragen, ab wann sich der Aufwand lohnt, denn um eine Browser-Offline-Datenbank-Anwendung zu schreiben, braucht man schon ein paar ausgewachsene Abstraktionsstufen, um die Daten in allen Browsern ordentlich wegzuschreiben und auch wieder zu finden…

Ein Fazit

Es ist nicht alles Gold, was sich HTML5 nennt. Beim Storage geht es jedenfalls, vor allem bei den Datenbanken noch sehr holprig zu. Somit liegt die Grenze für Offlinedatenspeicherung doch sehr sehr sehr niedrig. Definiert wird diese Untergrenze regelmäßig von den iOS-Geräten, man könnte Apple verdächtigen, den Webapp-Entwicklern Steine in den Weg legen zu wollen, um seine liebgewonnene App-Welt zu schützen, aber andererseits, man will ja auch keine Verschwörungstheorien verbreiten. ;)

Via @datenkind.

→

Testseite (Fenster fröhlich groß und klein ziehen).

<!DOCTYPE html>
<html>
	<head>
		<title>H1 Test</title>
		<style type="text/css">
		body {
			min-height: 500px;
		}
			@media screen and (min-width: 680px) and (max-width: 1024px) {
				h1::before {
					content: url('img/freude_680.jpg');
					display: block;
				}
			}
			@media screen and (min-width: 1024px) {
				h1::before {
					content: url('img/freude.jpg');
					display: block;
				}
			}

		</style>
	</head>
	<body>
		<h1>Meine tolle H1</h1>
		<p>Lebowski ipsum vee vant zat money, Lebowski. Dolor sit amet, consectetur adipiscing elit praesent ac magna justo. I did not watch my buddies die face down in the mud so that this fucking strumpet. Pellentesque ac lectus quis elit blandit fringilla a ut turpis. Praesent felis ligula, malesuada suscipit malesuada non, ultrices non urna. It's a complicated case, Maude. Lotta ins. Lotta outs. And a lotta strands to keep in my head, man.</p>

<p>I got information—new shit has come to light and—shit, man! She kidnapped herself! Sed orci ipsum, placerat id condimentum. Rutrum, rhoncus ac lorem aliquam placerat. You got the wrong guy. I'm the Dude, man. My dirty undies. Laundry, Dude. The whites. Posuere neque, at dignissim magna ullamcorper. In aliquam sagittis massa ac tortor. I've had a rough night, and I hate the fucking Eagles, man.</p>
	</body>
</html>

Getestet gerade nur in Chrome. Kommt von hier.

Ein Prototyp (altgr. protos ,der Erste‘ und typos ,Urbild, Vorbild‘) stellt in der Technik ein für die jeweiligen Zwecke funktionsfähiges, oft aber auch vereinfachtes Versuchsmodell eines geplanten Produktes oder Bauteils dar. Es kann dabei nur rein äußerlich oder auch technisch dem Endprodukt entsprechen.

de.wikipedia.org

Wenn der Prototyp das Licht der Welt erblickt, dann hat es “Klick” gemacht, dann ist das Team aufgestanden vom Konzepttisch und hinüber gegangen an die Werkbank. Und wenn schon nach kurzer Zeit erste Ergebnisse zu sehen sind—Sachen die sich bewegen, auf die man klicken kann—dann weiss man, dass es nun losgeht, das jetzt etwas gebaut wird, an dem man bald Freude haben wird. Der erste Schritt ist getan. Fehlen nur noch 99%.

Some rights reserved by Masked Malayan

Ich hatte jüngst großen Spaß mit dem mobilen Proxy der Telekomiker und—würde es nicht immer eine besonders störungsanfällige Nutzerschar treffen—ich würde glatt darüber lachen. Denkt man allerdings die Gutsherrenartigkeit mit der alle Mobilprovider mit unseren Websites im mobilen Netz umgehen konsequent zu Ende, wird einem leider Angst und Bange.

Erste Erfahrungen damit, das im mobilen Internet der Sourcecode einer Website beim Nutzer nicht so ankommt, wie man ihn am Server losgeschickt hat, hatten wir kurz nach dem Launch unserer iPad-Website. Eins der zahlreichen Scripte auf der Seite nutze einen <meta>-Eintrag im Head der Seite, um zu erfahren, in welchem Ressort es sich gerade befand. Informationen, die man zwischen Datenbasis und Frontend sicherlich auch bspw. mit Hilfe einer Klasse am <body>-Element übertragen hätte können. Aber unsere Templatehasen haben uns einst einen dicken <head> mit massig Informationen über die Seiten unserer Anwendung gegeben, warum sollte man die nicht nutzen und auslesen? Weil im mobilen Netz (zum Zwecke der Geschwindigkeitserhöhung) von den diversen mobile proxy alle <meta/> herausgefiltert werden, zum Beispiel.

Ok, das kann man ja noch verstehen, steht ja auch nichts drin, was so ein Handy, iPhone oder auch iPad im 3G-Betrieb brauchen könnte. Der zuckt der Entwickler kurz mit den Schultern und programmiert drum herum. Ein wenig komplizierter wurde es, als wir feststellten, dass im mobilen Netz nicht nur Daten aus dem <head> entfernt werden, es werden auch welche hinzugefügt. Dort verlinkte Javascripte bspw. werden komprimiert und direkt in den <head> ausgegeben. Das ist ja nett. Ich nehme mal an, ein derart aufbereitete Seite wird dann so gecached, spart ja auch reichlich Verbindungen. Technisch alles durchaus verständlich.

Und wenn man sich denn darauf verlassen könnte. Aber bspw. die Telekomiker verbessern ihre Systeme natürlich auch und da dieses Treiben nur wenig oder gar nicht dokumentiert ist, gibt es natürlich auch keine Releasetermine, keine Vorwarnung. Dass man wieder in die 3G-Falle gelaufen ist, merkt man genau dann, wenn der erste Nutzer sich meldet.

Dazu ein kurzer murphyesker, aber logischer Merksatz: Fehler am Livesystem werden immer zuerst von einem Nutzer entdeckt, niemals vom Entwickler.

Vor kurzem hatte also mein Lieblingsprovider wieder an seinem Proxy herumgespielt und folgendes Verhalten hinzugefügt: ähnlich wie die Javascripte wurden nun auch CSS statt wie vorgesehen verlinkt zu werden, direkt in den <head> geechoet, schick auf eine Zeile komprimiert. Das sollte weiter nicht stören, es sei denn man nutzt eine Technik zum Austauschen von verlinkten Styles zur Ladezeit. Dieser Hack um Stylesheets bei Bedarf zu dis- und/oder enablen funktioniert dann so gar nicht mehr.

Und wenn diese Technik dann für die Seite wichtig ist, dann kann man schon mal ins Schwitzen kommen. Die Lösung war in diesem Fall recht einfach: schreibt man statt <link rel="stylesheet" href="../styles.css"/> genauer <link rel="stylesheet" href="../styles.css" media="screen"/>, zeigt sich der Proxy derzeit gütig und lässt die Styles in Ruhe. Mal davon abgesehen, dass sich das leider morgen ändern kann, kann man nun auch keine @media innerhalb des CSS mehr machen.

Im Grunde ist das ja auch alles nicht so schlimm, so lange der Mobilprovider sich nicht auch noch am Inhalt der Seite zu schaffen macht. Es zeigt aber, dass eine iPad-HTML-Anwendung sehr viel defensiver gebaut werden müsste, als ich es bisher getan habe. Vielmehr muss man berücksichtigen, dass ein Tablet eben auch ein mobiles Device sein kann und dann eben den gleichen Restriktionen unterliegt, wie das schnöde Handy in meiner Tasche. Hier klafft imho noch eine mobile-Web-Smartphone-und-Tablet-Lücke, die sich auch darin zeigt, wie drastisch niedrig die Datenmengen von den Providern beschränkt werden (statt die Infrastruktur auszubauen oder die Technik zu verbessern). An Seiten, die eine Tonne wiegen und zwei Minuten Ladezeit bei UMTS auf die Ur bringen, hat der Nutzer in zweierlei Hinsicht wenig Freude.

One Web ist gar nicht so einfach.

Über die Jahre hat sich in meiner Toolbox ganz schön was angesammelt.
Foto: Some rights reserved by See-ming Lee 李思明 SML

Schon vor ewig hatte der gute Frank Bueltge einen Artikel über seine WordPress Entwickler Toolbox gepostet und seitdem habe ich einen ähnlichen Artikel in die Pipe gelegt, der nun endlich fertig ist. Die Frage, womit ich dieses Blog entwickle lässt sich von der Frage, womit ich auch professionell arbeite, nicht trennen. Dieses Blog (und die anderen zuvor) ist ja immer die Spielwiese für das, was ich auf Arbeit mache und umgekehrt, setze ich im Arbeitsleben Gelerntes hier gerne ein und um. Von daher kann ich nur meinen globalen Werkzeugkasten präsentieren, für das, was ich so mache… Digitalkreativer und Internethandwerker.

Betriebsystem(e)

Ganz grundsätzlich arbeite ich seit Jahren fast nur noch mit Apple-Rechnern, namentlich zur Zeit einem MacBook Pro (2.66 GHz Intel Core 2 Duo, 4GB RAM). Zu Hause steht noch ein kleiner Mac mini. Vor kurzem wurde allerdings zusätzlich ein Samsung Netbook angeschafft, dessen mitgeliefertes Windows 7 Stalker geplättet und durch das aktuelle Netbook-Ubuntu ersetzt. Mein Arbeitgeber stellt mir zusätzlich ein iPhone und zum Testen auch regelmäßig ein iPad. Entwickelt wird bei mir aber eigentlich ausschließlich auf dem MacBook Pro.

Editor/IDE

Ich weiss gar nicht wirklich, ob es derzeit ein sinnvolles IDE für HTML und CSS auf dem Mac gibt. Ich habe in den Jahren viel ausprobiert, Aptana, NetBeans, Espresso, Coda, am Ende des Tages bin ich immer wieder zu meinem heißgeliebten Textmate zurückgekehrt. Textmate ist eben ausdrücklich keine IDE, sondern ein Texteditor, der praktisch alles kann.

Ja, das ist richtig, ich mache alles mit dem Texteditor, bis hin zu kleineren jQuery-Projekten. Unterstützt wird dies durch viele viele Textmate-Bundles, die beispielsweise JS Lint integrieren, für ordentliche Formatierung sorgen, gegen den W3C Validator checken, SVN (oder Git oder Mercurial) bedienen und so weiter und so fort. Hinzu kommen Templates und eine prima Projektverwaltung.

Serverkontakt

Obwohl ich gerne bis zur letzten Sekunde lokal entwickle (Server zur Verfügung gestellt von MAMP), kommt man natürlich ohne Serverkontakt nicht aus. Wenn ich dabei auf das vorsintflutliche und leider noch viel zu verbreitete FTP angewiesen bin, dann nutze ich dazu @work Transmit und sonst gerne Cyberduck. Viel lieber mag ich allerdings entfernte Dateisysteme mounten, mit MacFusion und MacFUSE. Ich kann aber auch eine Shell bedienen und direkt auf dem Server mit vi. Ich habe auch schon mal mit macvim gespielt, für vi-Abhängige am Mac jedenfalls das Richtige. Meine terminal.app erreiche ich übrigens mit dem coolen Visor, aber das ist natürlich nur Spielerei.

Grafik, Konzept

Da ich mir privat kein Photoshop leisten will und kann, und im Beruf nicht zu denen gehöre, die standardmäßig damit ausgestattet sind, habe ich mir vor einiger Zeit schon Acorn zugelegt. Das macht zumindest alles, was man im Blogalltag so braucht und öffnet sogar PSDs (was auch im Büro manchmal hilfreich ist). Zum Webdesign eignet es sich aber weniger. Hin und wieder spiele ich mit GIMP, aber mal ehrlich… naja.

Zur graphischen Analyse von Webseiten (und damit ich mir die Standardpixelwerte von zeit.de nicht merken muss), habe ich mir xScope gekauft. Dieses wirklich grandiose Tool misst alles am Bildschirm aus, zeigt Farbwerte, macht globale Hilfslinien, Grids und und und…

Im Beruf brauche ich noch zusätzlich Helfer für die Visualisierung von Seiten, Abläufen, etc., bspw. bei der Konzeption. Standardmäßig nutzen wir Omni Graffle, was ich auch sehr mag. Trotzdem habe ich mich schon an Balsamiq versucht, da ich Mockups, die aussehen wie Mockups für pädagogisch sinnvoll halte. Zumal wir dann sehr schnell zu HTML-Prototypen übergehen, da muss man Grenzen ziehen. In Omni Graffle nutze ich deswegen das Web Sketch Interface Stencil.

Firefox ist immer noch die Nummer 1.

Browser, Virtualisierung

Ich entwickle nach wie vor im Firefox. Ich habe mit Chrome geliebäugelt, aber es geht doch nichts über Firefox mit Firebug. Dazu habe ich noch ein paar Addons am Start: natürlich die Web Developer Extension, den User Agent Switcher, den Fangs Screenreader und die Selenium IDE und die passenden Selenium IDE Buttons. Natürlich habe ich trotzdem zusätzlich jede Menge Browser auf dem Rechner installiert, zum Testen eben.

Dafür betreibe ich auch gezwungenermaßen Virtualisierung und zwar mit VirtualBox, wo diverse Auswüchse der Windows-Ära zu Hause sind und diverse Browserversionen von IE verfügbar machen.

Und sonst so?

Puh, das war ja eine lange Liste. Aber alle diese Programme und Tools brauche ich für meinen gelungenen Arbeitsalltag. Und es werden immer mehr. Seitdem ich zum Beispiel viel mit dem iPad zu tun habe, nutze ich immer öfter Simplenote zusammen mit Notational Velocity und gerne auch in Kombination mit Dropbox, mit dessen Hilfe ich Dateien zwischen meinen verschiedenen Rechnern share. Und man will ja auch kommunizieren, obwohl sich immer alle beschweren, dass ich viel zu selten mein Adium am Start habe. Und Gmail und Tweetie und Skype…

→

→

→

Hatte schon die Idee (in Webkit bereits testweise implmentiert) von Konstanten in CSS die Welt in Aufregung versetzt, dürfte man CleverCSS – the pythonic way of webdesign als die endgültige Gotteslästerung betrachten. Um es kurz zu machen zitiere ich flugs:

CleverCSS is a small markup language for CSS inspired by Python that can be used to build a style sheet in a clean and structured way. In many ways it’s cleaner and more powerful than CSS2 is.

sandbox.pocoo.org

Hmmm… pythonic, das könnte meinem Wunsch nach Formatierung und Sauberkeit doch entgegenkommen. Und CleverCSS kann einige witzige Sachen, ausser einfach CSS wieder raus zu printen. Bspw. gibt es einen grouping operator, der Attribute zu Gruppen zusammenfasst. So:

#main p
  font->
    family: Verdana, sans-serif
    size: 1.1em
    style: italic

Ausgegeben würde hierfür:

#main p {
    font-family: Verdana, sans-serif;
    font-size: 1.1em;
    font-style: italic;
}

Mal bitte, das ist ja lustig. Und dann wirds spannend, CleverCSS beherrscht natürlich Konstanten, um z.B. Farbwerte einmalig festzulegen und editierbar zu machen. Ich weiß schon, nichts, was man nicht auch mit suchen & ersetzen erschlagen kann… nur, CleverCSS kann damit auch ein wenig rechnen:

background-position: $foo + 2 + 3 $foo - 2

Das täte background-position: 15 8; ergeben. Mit CleverCSS kann man beinahe richtig rechen, sogar mit Farben (#fff - #ccc => #333333). Und als wär das nicht schon genug: es gibt auch noch einen ganzen Satz Methoden, wie Number.abs(), String.length(delimiter), Color.brighten(amount) oder String.split(). Klingt doch spannend.

Allen Features zum Trotze muss man natürlich die Frage nach dem Sinn stellen. Ehrlich gesagt: weiss ich noch nicht. Fällt mir aber sicherlich noch ein. Zusammenhänge könnten Frameworks, Templatesysteme, …, ja was?

Prädikat: unbedingt mal runterladen und ausprobieren.

Andreas Dölling ist laut Autorenangbae Webentwickler, kann es aber nicht lassen, seine Nase immer wieder in Bereiche zu stecken, die ihn eigentlich gar nichts angehen, und seine Meinung dazu kundzutun. Schon passiert würde ich mal sagen, obwohl ich dachte, dass CSS einen Webentwickler sehr wohl etwas angeht.

Zunächst einmal ist es natürlich eine super Sache, seine CSS-Klassen gut und semantisch zu benennen, es werden auch wirklich schöne und einleuchtende Besipiele genannt, die Herr Dölling einem alten Hasen abgescahut hat bzw. zu denen ihn das Qualitätsmanagement einer professionellen Firma gezwungen hat. Scheinbar aus Rachen gegen die Affront jedoch hat sich Herr Dölling noch einige Reste eigenen CSS-Stils bewahrt und die haben es in sich. Mein Vorschlag dazu: auf gar keinen Fall nachmachen!

Anordnung von CSS-Eigenschaften

Es wird empfohlen, Eigenschaften in der Reihenfolge der Wichtigkeit zu notieren, wobei in fünf Wichtigkeitsgruppen eingeteilt wird (Verhalten, Position und Dimension, Abstände und Rahme, Schriftgröße und Zeilenhöhe, Hintergrund und übrige Eigenschaften). Dämliche Idee numero uno: erstens halte ich die Wichtigeit von CSS-Eigenschaften für höchst diskutabel, das kommt halt immer auf den Fall an, in Wahrheit ist dies ein willkürliche Festlegung. Wogegen man eigentlich gar nichts einwenden kann, denn wenn es keine logische Reihenfolge gibt ist koordninierte Willkür der einzige Weg. Nur sind diese Gruppen schwer vemittelbar: man muss lernen, was zu welcher Gruppe gehört, lernen in welcher Reihenfolge die Gruppen anzuordnen sind und innerhalb der Gruppen, gibt es gar keine definierte Reihenfolge. Stellen sie sich einmal vor, sie sind Qualitätsmanager und sollen nun dieses Regelwerk an diverse Webentwickler und -dekorateure kommunizieren. Schönen Dank. Ich sag’s mal in CSS-Inquisitions-Sprache: wird sich nicht durchsetzen. Zu kompliziert, zu schwierig umzusetzen.

Der Gegenvorschlag bleibt bestehen: CSS-Eigenschaften immer in aplhabetischer Reihenfolge notieren. Das ist einfach, versteht jeder, ist eine nachprüfbare, also durchsetzbare Regel und super umsetzbar. Und führt auch auf lange Sicht zu lesbaren Stylesheets.

Einrückung und Umbrüche

Endgültig die Haare zu Berge stehen einem dann, wenn man die Idee zum quer schreiben liest. Herr Dölling, lassen sie sich an dieser Stelle einmal folgendes sagen: wer quer schreibt, ist noch lange kein Querdenker, eher schon ein Quertreiber. Mal davon abgesehen, dass die letzte Übersichtlichkeit, die Herrn Döllings drolliger Dialekt noch bietet, einzig und allein durchs Synthaxhighlighting zustande kommt, ist dies ein CSS-Code der sagt: »Fass mich nicht an! Mein Autor ist so von sich selbst überzeugt, dass er nicht glaubt, dass jemand anderes ausser er selbst Änderungen vornehmen möchte.« Danke schön.

Sowas darf man sicherlich auf den Server stellen, es spart eine Menge Platz und sicherlich das eine oder andere Byte an Gewicht. Aber während der Entwicklungszeit ist so eine Schreibweise einfach nur eins: kontraproduktiv. Man stelle sich nur vor, man soll jetzt hier eine CSS-Regel hinzufügen, womöglich nach der vorgenannten Fehllehre, sozusagen irgendwo in der 400 Zeichen langen Zeile. Wir wünschen fröhliches horizontal scrollen. Das ist wirklich eine dumme Idee. Auf gar keinen Fall nachmachen.

Hoffe, das war jetzt inquisitorisch genug, war ja auch so gewünscht. Da kann einem aber auch der Geduldsfaden reissen. Schon passiert: hier habe ich eine Videoaufnahme davon:

http://www.youtube.com/watch?v=gldlyTjXk9A

Nachtrag: ich habe heute morgen in meiner grenzenlosen Weisheit Dämlichkeit diesen Artikel aus Versehen gelöscht und musste z.T. von Hand restoren, dabei sind die Pingbacks flöten gegangen. Sorry.

→

→

I’ve often seen features cut from a product launch in favor of generating “better” documentation.

David Verba in Sketching in Code: the Magic of Prototyping.

Manchmal denke ich, hier, diesseits des großen Teiches, machen wir Webentwicklung irgendwie noch mit Hammer und Meißel. So ein bißchen, als wären wir Steinzeitmenschen, die eben zusehen dürfen, wie der Stamm nebenan das Feuer kultiviert, das Rad erfindet etc., aber unser Stammesältester unterbindet den neumodischen Kram.

»It’s not everything that bad…« ©BBC

Kommentare

Mehrzeilige Kommentare, mit Einrückung et al. sind zu platzieren:

• am Beginn jeder Datei
  • mit Angabe wozu und an welcher Stelle das Stylesheet benötigt wird, kurze Inhaltsangabe o.ä.
  • Abhängigkeiten
• vor jedem Themenabschnitt

Codebespiel: mehrzeiliger Kommentar

/**
 * Hello World
 * Dies ist ein mehrzeiliger Kommentar
 */

In allen anderen Fällen ist der Zeilenkommentar zu nutzen

Codebespiel: einzeiliger Kommentar

/* Dies ist ein einzeiliger Kommentar */

Leerzeilen

Einzelne Regeln sind durch 1 Leerzeile voneinander zu trennen. Es sollten niemal mehr als 2 Leerzeilen aufeinander folgen.

Codebespiel: Leerzeilen

.note { border: 1px solid #000; }

.black_note {
    background: #ff00ff;
    color: #000;
}

Anm.: Bitte den Code immer so leserlich wie möglich gestalten. Optimierung des CSS auf Größe wird in späteren Buildprozessen umgesetzt und ist vom Layout unabhängig.

Kurzschrift-Eigenschaften

Wo immer möglich und sinnvoll sollen die Deklarationen in Kurzschreibweise zusammengefasst werden.

Codebespiel: Kurzschreibweisen 1

.small {
    background: transparent url(img/border-bottom.gif) repeat-x bottom;
    border: 1px solid #000;
}

Trotzdem bitte flexibel bleiben und davon abweichen, wenn es sinnvoll ist:

Codebespiel: Kurzschreibweisen 2

a:link {
    background: transparent url(img/sprite.gif) no-repeat 0 0;
}

a:hover {
    background-position: 0 -16px;
}

Best practice

Bitte jede Deklaration immer mit einem Semikolon abschließen.

Namen

• alle Namen in Kleinbuchstaben
• zusammengesetzte Namen mit _ (underscore) verbinden
• eher aber kurze Namen suchen, höchstens 1 Zusammensetzung
• Update: Klassennamen verraten nicht das Aussehen eines Elementes. (via) D.h. Klassen heissen nicht “.grey-border” oder ähnliches.

Reservierte IDs: folgende IDs sind in der Regel für das HTML-Gerüst vergeben und sollen außerhalb dessen nicht benutzt werden:

• #wrapper
• #container
• #header
• #content
• #sidebar
• #footer

To be continued.

Begriffsklärung

Codebespiel: Begrifflichkeiten

h2 { color: #000; }

• Diese Codezeile ist eine CSS-Regel (rule)
• h2 ist (hier) ein Selektor (selector)
• color: #000; ist die Deklaration (declaration)
• color ist eine Eigenschaft (property)
• #000 ist ein Wert (value)

Nachzulesen beim W3C.

Schreibweisen

• Alle IDs und Klassennamen klein schreiben
• Alle Selektoren klein schreiben
• Alle Deklarationen klein schreiben
• Alle Werte klein schreiben

Codebespiel: Schreibweisen

h2, #container, .formbox { color: #efe; }

Leerzeichen (Space)

• Zwischen Deklaration und Wert (nach dem Doppelpunkt)
• nach Kommata
• bei einzeligen Selektoren nach { und vor }
• nach /* und vor */

Einrückung

• Selektor auf eigener Zeile, dahinter {-Klammer
• Deklarationen (1 pro Zeile) eingerückt um vier Leerzeichen
• }-Klammer am Ende wieder ausgerückt

Codebespiel: Einrückung 1

.note {
    border: 1px solid #000;
    color: #ff0000;
    margin-bottom: 10px;
}

Ausnahme: Selektor mit nur 1 Deklaration wird einzeilig geschrieben

Codebespiel: Einrückung 2

.note { border: 1px solid #000; }

Regeln, die sich auf Kindelemente beziehen, werden an der Mutter-Regel ausgerichtet.

Codebespiel: Einrückung 3

.note {
    border: 1px solid #000;
}
    .note p {
        padding: 4px 2px;
    }

To be continued. Update: Teil 2 ist fertig.

Selten so gelacht.

• why are we doing this?
• what problem are we solving?
• is this actually useful?
• are we adding value?
• will this change behavior?
• is there an easier way?
• what’s the opportunity cost?
• is it really worth it?

Jason Fried von 37signal, via hier sozusagen. Auch mal als Antwort hierzu zu verstehen.