YAML total Technikwürze 184

Technikwürze 184. Wir reden heute über YAML 4. Dazu begrüße ich, Dirk Jesse. Hallo Dirk.

Schönen guten Abend.

Den Matthias Mees.

Moin, moin.

Und Jens Grochtdreis.

Guten Tag.

Herzlich willkommen zu Technikwürze, eurem Design- und Webstandards-Podcast.

Ja, ich bin's auch mal wieder. David Maciejewski mein Name. War lange nicht auf Sendung, wird mal wieder Zeit. Aber bevor sie durchstarten, möchte ich mich noch mal bedanken bei unserem Sponsor Mittwald. Die bieten für euch ja, das wisst ihr, Webhosting, Managed Server und, Schulungen. Schulungen, da gibt's grade 'n Prospekt ganz fürs erste Quartal, was sie per Post versendet haben. Die machen so Schulungen zu TYPO3, Magento, HTML und CSS-Grundkurs und PHP in verschiedenen Städten.

Einfach auf mittwald.de gehen und ab dafür, würd ich sagen. Ab dafür auch für diese Sendung. Wir reden heute über YAML und das ist jetzt in der Version vier rausgekommen von Dirk Jesse. Und, Dirk, du sagst ganz kurz mal, was das ist.

Ja, mittlerweile oder beziehungsweise schon seit einiger Zeit nennt sich's ein CSS-Framework, also 'n Baukasten, für das Erstellen von mehr oder minder kompletts, komplexen Webseiten. Angefangen hat das Ganze in 2005, als ein recht schmales, einfaches Mehrspalten-Layout, was aber damals eben auch schon recht ungewöhnlich war, dass man damit quasi mehrere Varianten, immer mit demselben Markup erstellen konnte.

Ja, und das ist grade in Version vier, wie gesagt, erschienen und ist im Prinzip runderneuert von Dokumentation und Webseite und bringt jetzt das ganz offiziell alles mit, was man sich so als, Entwickler am halbwegs am Puls der Zeit, denk ich, wünscht.

Und es ist sehr schön geworden. Also du hast draufgeschrieben auf die Webseite flexibel, accessible und responsive. Also.

Ja. Flexibel ist es schon seit Version eins. Das war also eine der Sachen, die ich, die mich schon immer begeistert haben, und also die mir auch schon immer Spaß gemacht haben, flexible Layouts zu bauen. Ging ja dank CSS2 schon auch seit 'ner ganzen, ganzen Weile. Und ja, responsive Design ist halt in den letzten ein, anderthalb Jahren hochgekommen und es ist immer blöd, wenn man sagt, dass es geht und wenn man aber nicht wirklich zeigt, dass es geht.

Ne? Also man hat dann immer so 'n gefühltes Glaubwürdigkeitsproblem, zwischen dem, was man vor, was man da auf so eine Seite schreibt, was man alles können will und deswegen, ist dann auch die Seite mit Doku dann so aufgebaut, dass man wirklich jetzt sagt, YAML ist quasi alles, was irgendwie möglich ist, wird auch mal eingesetzt.

Genau, auf der Webseite sieht man das sehr schön. War denn das responsive Webdesign irgendwie, der Startschuss für dich, zu sagen: „Okay, ich muss da doch noch mal ran und mach jetzt 'ne Version vier. Weil im Vorgespräch sagten wir eigentlich, dass YAML 3, Mensch, das war doch eigentlich schon so gut. Bedarft es da noch eines Updates?

Um jetzt responsive Design und HTML5 und so was zu machen? Nein. Eigentlich ganz und gar nicht. Sondern die Sachen sind eigentlich schon seit 'nem Jahr oder anderthalb Jahren drin beziehungsweise auch was jetzt, bei HTML5. Wollen wir, ich, ich-- Willst du unterbrechen?

Nein. Ich, ich stocke genau grad 'n bisschen, weil wir haben den Jens verloren auf der Datenautobahn, aber vielleicht stößt er gleich noch mal zu uns. Aber lass dich nicht aufhalten.

Ja, das, also der Grund, das neu zu machen, waren zwei, im Prinzip zwei Sachen. Das eine ist, dass die ursprüngliche Seite, die es bis vor, bis Mitte letzter Woche gab, ihr Layout in 2007 im Sommer erhalten hat und irgendwo im Frühjahr, Winter 2007 entworfen. Das ist also schlappe vier Jahre alt, sieht auch so aus. Und, ich weiß nicht, wie's euch geht, also ich hat's, ja, satt gesehen. Ich wollt's einfach nicht mehr haben.

Ja, ich glaub, das ist so 'ne alte Web-, entwicklerkrankheit. Also alte Webseiten von uns können wir einfach nicht mehr wiedersehen.

Und das ist eben auch die ganzen Beispiele, das, also das, das sah halt alles aus wie 2007. Und das ist, sind, wenn man jetzt, hat sich halt doch ziemlich viel geändert. Wir haben jetzt CSS3 in einer Form, die auch wirklich nutzbar ist mittlerweile. Wir haben vernünftige Schriften, wir können damit arbeiten und das machen ja auch schon genügend Seiten. Umso mehr fällt das eben auf, wenn du mit so 'nem Projekt optisch hinterherhängst.

Und das Zweite ist, warum's so lange gedauert hat, war einfach, na, ich hab damals eben angefangen, alles in diese Doku zu schreiben, mehr oder weniger, was ich weiß. Das hat sie anwachsen lassen über die Jahre und hat dazu geführt, dass ich jetzt in der letzten Version, ich glaube, die deutsche Variante um die hundertfünfzig Seiten als PDF-Fassung dann hatte, also quasi 'n eigenes kleines Buch, das Ganze in zwei Sprachen und dann auch noch mal online alles oft in diese Webseite reingepackt.

Das ist A-

Nichts, was wirklich jeder lesen will und B, auch nichts, was ich noch weiter pflegen wollte.

Hast du die Dokumentation alleine gepflegt, die hundertfünfzig Seiten komplett? Ja, hört sich gut-

Also ich hatte zwischendurch immer wieder jemanden, der mir größere Brocken, wenn's denn größere Veränderungen gab, wenigstens übersetzt hat.

Ja, das ist ja schon irgendwie ätzende Arbeit.

Ja, aber also ohne wär's gar nicht gegangen, aber das war eben auch damals mein Wunsch zu sagen, eben nicht nur eine rein deutsche, sondern eben auch eine englische Dokumentation zu haben. Aber das ist ja dann, machst du dann trotzdem, wenn du sagst, du hast diese vier Varianten online zweisprachig und dann noch mal quasi in dieser PDF-Fassung zweisprachig.

Man ändert ja mehr an, in der Doku und ist darauf bedacht, dass die halbwegs konsistent ist, als dass man wirklich was am Framework selber macht.

Ja, ja.

Und das ist 'ne Situation, die, da hast du irgendwann auf eine größere Änderung keine Lust mehr, weil man weiß, was es für einen Rattenschwanz nach sich zieht.

Das ist, glaube ich, auch der Grund, warum so viele Open-Source-Projekte so schlecht dokumentiert sind. Du hast einfach keine Lust mehr, da noch, mehrsprachige Doku zu pflegen, die dann noch in so und so viel Ausgabeformate zu konvertieren und nebenbei eben auch noch ein Open-Source-Projekt zu pflegen. Das ist, kann ich auch jeden verstehen irgendwie.

Und dann war's eben auch so, sagen wir so die Zeit damals war ja so, als ich angefangen habe, da gab's ja nicht wirklich, viele Bücher und auch Lektüre im Netz, die so zusammengefasst, das dann die ganze Problematik aufgerollt haben, was alles, zu beachten ist, wenn man sich in diesen Layout-, -dschungel da wagen will mit den ganzen Browsern. Also hat man eben alles aufgeschrieben oder ich zumindest, nicht nur eben das Wie, sondern eben auch, warum wir das alles, warum ich das alles so mache.

Und das war das, das hat die Doku einfach riesig groß gemacht. Und ja, das braucht heute niemand mehr. Also wir haben genug Bücher, da steht das auch alles drin. Und dann bin ich der Meinung, da kann man da auch nachlesen. Und dann muss ich das nicht, quasi immer in, in so einer Doku für, für so 'n Projekt nicht den, den, den Urschleim oder, vom, von Funktionieren von HTML und CSS mehr aufschreiben.

Also Doku, im Englischen, das, das, da sollte der eine oder andere schon mächtig sein, das, das lesen zu können. Aber kommen wir noch mal, was mich so interessiert: Für wen, wer ist jetzt der Anwender? Wer ist die Zielgruppe von YAML? Sind's jetzt, keine Ahnung, der selbstständige Webentwickler, die Werbeagentur oder Content-Management-System-Benutzer, TYPO3-Benutzer? Ich weiß es nicht. Was steckt dahinter? Für wen ist das geeignet? Oder was bringt es mir in meiner Arbeit, YAML zu verwenden?

Von den Berufsgruppen und Bildern, die du gerade genannt hast, denke ich mal, sind mehr oder weniger alle vertreten. Also es sind sowohl von irgendwelchen kleinen Hobbybastlern, die sich's halt nehmen, weil sie sagen, sie kriegen damit eine eigenständige Seite hin, ohne selbst wirklich alles, verstehen zu müssen und bis ins Kleinste, hoch bis zu, großen Internetagenturen, die mit großen Content-Management-Systemen arbeiten. Ne?

Also es gibt, für YAML, Integrationen in Content-Management-Systeme von so kleinen Sachen, WordPress ist ja nicht klein, aber so teilweise hier CMS Simple, das ist so 'n Ding, das, das geht, läuft selbst ohne Datenbank, bis hin zu Open Text, ehemals Red Dot, die auch ein komplettes Basisprojekt auf YAML-Basis für ihre Kunden anbieten.

Aber diese CMS-Integration, die hast du auf der Seite auch aufgelistet. Das ist wirklich zahlreich. Die hast nicht du gemacht, sondern das haben quasi andere Entwickler gemacht, die YAML richtig gut fanden und wollten das in ihre Arbeitsumgebung quasi einbinden.

Ganz genau.

Wie sieht es da mit der Pflege so aus? Kommen die hinterher, das mal upzudaten oder...?

Sehr unterschiedlich. Also die meisten sind jetzt, hängen jetzt im Moment natürlich alle noch auf dem Dreierpfad. Die vier ist ja nun jetzt gerade erst ein paar Tage raus.

Es gibt auch einige, die würden, die, die, die Masse, denke ich, ist jetzt nicht gepflegt in dem Sinne, dass sie mit jeder kleinen Version geupdatet wurde, sondern eher mal so, wenn es jetzt 'n, 'n Template für WordPress oder, CMS Made Simple oder TYPO3 ist, dann gibt's auch ganz viele Tutorials, die einfach mal diesen grundsätzlichen Weg beschreiben, mit welcher Version du das von dem Framework dann dann einbindest. Das ist dann relativ, egal.

Wobei du ja, wenn ich das richtig erinnere, immer betont hast, dass es keinen Updatezwang gibt.

Na, das ja sowieso. Also das ist ja, du, ich meine, du, du, es ist ja keine Software mit Sicherheitslücken.

Ja klar.

Wo du sagst, sondern es ist maximal, 'ne Tool-Sammlung oder 'ne Sammlung von CSS-Schnipseln, die bestimmte Probleme lösen.

Natürlich könnte es sein, wenn du sagst, du hast auf deiner Webseite, die hast du gebaut, die ist live und die funktioniert in einem Browser nie, dann kann das Sinn machen zu sagen: „Okay, in der neuen YAML-Version ist dieses und jedes Problem gefixt." Das war sicherlich heute passiert es sehr viel, viel seltener als zu den Zeiten, wo der IE6 noch in, in Massen vertreten war. Da hat sich's gelohnt, drüber nachzudenken, so 'ne Version mal mitzuspielen.

Aber das war in der Zeit YAML eins, zwei bis zwei fünf irgendwo. Ab der drei war im Prinzip alles, was man für den IE in irgendeiner Form tun konnte, drin. Ne? Da hat sich eigentlich nichts mehr groß geändert. - Und dann sind Updates einfach, ja, also never change a running system.

Warum sollte ich mir jetzt, nur weil eine neue Version rausgekommen ist, jetzt alle bestehenden Seiten durchackern und, die, die Dateien da setzen, es, wenn es keine Probleme gibt, keine offensichtlichen, sondern das ist dann immer erst für das nächste Projekt, was man in Angriff nimmt.

Vor allen Dingen, wenn's funktioniert, warum sollte man's? Genau.

Ja, es ist-- genau. Die Browser unterstützen, das, die alten Sachen bis sonst wohin. Und da gibt's keinen Grund, da ständig, mit Updat, mit Updates drüber zu bügeln.

Und Jens, wir haben dich auch wieder in der Sendung, wie ich gerade feststelle. Jetzt ist er wohl nicht mehr dabei.

Er tippt.

Dann, denke ich, machen wir einfach mal weiter. Ich, hab hier 'n Stichwort in so 'nem Google-Docs-Dokument stehen: „YAML ist ein Baukasten, kein Fertiglayout." Ist das so, ja, von denjenigen, die das noch nicht eingesetzt haben, irgendwie so 'n, ich lass es mal böse darstellen und das ist ja hier nichts Anständiges, womit man arbeiten kann, so 'n Vorurteil?

Mhm. Also mit diesem, Fertiglayout, so hab ich's ja früher in den ganz frühen Versionen selber erklärt. Da war es eben auch das, ne. Das kam von diesem Mehrspalten-Variante, zwei oder drei Spalten und die Reihenfolge war relativ egal. Und dafür war, stand eben das Marker fest und so hatte ich's eben auch beschrieben. Und mit der Zeit, das war 2005, 2006, 7 kam dann aber eben schon diese und jene Baustelle dazu und, das Passwort Framework kam eben auch erst um die Zeit rum.

Und so wurde es immer mehr angereichert mit Bausteinen und Codeschnipseln und Navigationen und-- die man nehmen kann, die man aber auch genauso gut links liegen lassen darf, und hat sich quasi zu diesem Framework, über die Jahre entwickelt.

Hast dieser Satz, mit dem Fertiglayout und dem Baukasten nicht auch 'n bisschen darauf gemünzt, dass es-- es gab, glaube ich, nicht wenig Leute, die haben, sozusagen dein Basislayout oder dein Basisdesign einfach übernommen. Und haben nicht viel damit gemacht und man soll ja eigentlich noch 'ne ganze Menge damit machen. Und, in der vier ist mir aufgefallen, die Demos sind auch 'n bisschen weniger ausgestaltet jetzt, ne. Ist das Absicht?

Es ist auf alle Fälle Absicht, dass ich die radikal von der Menge her zusammengestrichen habe. Weil eben genau das,, ich 'n bisschen vermeiden wollte. Also nicht mehr f-für, auch für jeden kleinsten, kleinen, für jede kleinste Änderung da jetzt noch ein extra Beispiel anzubieten.

Das ist zwar für den einen oder anderen ganz schön, wenn alles wirklich, wenn auch, wenn auch beispielsweise-- mich hat jemand gefragt, warum das, wo das Beispiel ist mit, dass das Layout immer auf volle Höhe beziehen kannst, ne. Also immer mindestens volle Browserhöhe. Diese hundert Prozent hohen Layouts, das sind fünf Zeilen CSS. Die kann man sich einfügen, wer sie braucht. Ich denke, aus meiner Sicht sind es sehr wenige.

Das ist 'n sehr spezieller Wunsch und in der Vergangenheit war's eben so, dass eher durch diese Masse an Beispielen, die Masse an Quelltexten, und CSS-Dateien, jedes einzelne Beispiel hatte seine eigenen Dateien. Das ist nicht übersichtlicher geworden. Und so wie's an vielen Stellen zwei, drei Leuten genutzt hat, gab's aber auch drei, vier Leute, die das eher genervt hat. Oder verwirrt hat, weil's am Anfang eben den Zugang auch entsprechend erschwert hat.

Und das Zweite bei den Beispielen, ja, sie sind jetzt komplett grau. Also ich hab bewusst sämtliche Farbe rausgeschmissen.

Das aber auch vor dem einen einfachen Hintergrund, dass ich eigentlich möchte, ich bin ja auch selber dabei, entsprechend da weiter zu programmieren, das Ganze für das Rapid Prototyping zu benutzen. Und da sollte tunlichst keine Farbe drin sein.

Ja, das ist diese, das ist diese Grey Box Methode, was, Santa Maria vor Jahren mal beschrieben hat, ne.

Genau, dass man einfach sagt, man kann damit bauen und das nicht-- das Erste, was du von deinem Kunden quasi hörst, ist nicht, dass ihm das Blau im Hintergrund nicht passt, sondern dass ihm, man sich auf die Inhalte konzentrieren kann, ne. Und das Schöne ist eben dann auch, dass es sehr viel einfacher ist, die Beis-- die, die, die einzelnen Bausteine jetzt, das Basislayout, das, das Screenlayout und die Navigation, die Formulare, dass man die recht schnell stimmig von der Optik zusammenbekommt.

Also jetzt auch von meiner Seite aus, dass ich wirklich etwas aus einem Guss liefern kann, was du miteinander kombinieren kannst und was von vornherein erst mal halbwegs anständig aussieht.

Ich denke, du, du lenkst den Fokus auch klar auf die Technik, die da, die dahinter steckt, dass man sich das wirklich anschaut und nicht denkt, ich hab hier 'ne fancy bunte Seite, die sieht einfach nur geil aus und ich möchte das Design jetzt kopieren und ach ja, da ist ja noch YAML dahinter, sondern wirklich: Hey, das sind Beispiele, wie du das nutzen kannst. Also ich find das genau richtig.

Na, wir hatten damals, guck mal, in der, in der Dreier-Version hattest du ja hier Navigation, auch hier diese shiny Buttons. Na, die hießen halt so, weil so 'n bisschen da,, 'n paar Hintergrundgrafiken da lagen und dann gab's noch hier so 'ne Rider, die Sliding-Doors-Navigation. Das sind aber schon ganz spezielle Navigationen, die entweder wie die Faust aufs Auge passen.

Das ist aber der Fall einer aus hundert und in den anderen neunundneunzig stimmt schon mal erstens die Farbe nicht und zweitens die Proportionen nicht und drittens noch alle anderen Sachen nicht, und du musst sie umbasteln. Oder sie passen eben in so 'n, in so 'nem Schnellschuss, dass du sagst Du baust mal schnell die, die eine Oberfläche zusammen, um irgendwie 'ne Idee durchzuspielen. Das funktioniert einfach nicht, weil sich automatisch schon von der Optik irgendwas beißt. Und das ist blöd.

Ist ja auch einfach eine Technik, ne. Wann hast du das letzte Mal Sliding Doors Ergo verwendet?

Ja, und wir, und wer hat das-

Braucht man auch nicht mehr.

Und wer hat das letzte Mal irgendwo eine Navi kopiert, und so reingebaut, jetzt von, von, als, als professioneller Entwickler, und ohne jegliche Veränderung übernommen. Also so ein Navigationsbaustein ist nun mal was, was man sehr individuell auf die eigene Seite anpasst, die man gerade baut.

Eigentlich schon, ja.

So, und dann gibt's da eigentlich keinen Sinn, da fünf Varianten, oder auch nur drei Varianten zu liefern, sondern dann gibt's eben nur eine. Und die in Graustufen und wenn die passt, kann man mit Farbe drauf werfen und sie benutzen.

Aber ich glaube, es gibt genug Codebeispiele, gerade in der, Dokumentation, in der englischen, woran man das lernen kann oder verstehen kann, wie es funktioniert oder einzelne Sachen. Ich glaub, da noch mal die einzelnen Navigationssteps aufzudröseln, macht wirklich wenig Sinn. Hast du denn Werte, wie sich das, jetzt beim Versionssprung verändert hat von der reinen Masse der Dateien her? Also irgendwie so ein Prozentwert. Ist es jetzt irgendwie so und so viel Code weniger oder so was?

.

Oder mehr?

Da müsste ich's-- Gute Frage. Es ist weniger geworden, aber wie viel muss ich selber gucken, wie groß das Download-Paket damals war. Das habe ich mir nicht aufgeschrieben.

Ich muss es mal selbst runterladen.

Ja. Also das jetzige ist zweihunderteinundsechzig Komma sechs Kilobyte.

Ja, das vorhergehende waren sechshundert..

Kann aber auch sein, die Doku war natürlich erheblich größer und die war, war die mit drin?

Nee, die Doku war da nicht drin. Dafür waren da aber, ein paar Photoshop-Dateien drin.

Aha.

Also da waren ja wirklich, von der Navi und auch so ein klassisches Ding. Ich hatte ja, direkt noch so ein Layout-Beispiel: Wie kriege ich um ein gesamtes Layout, also eigentlich diesen Wrapper, den man drum rum bastelt, ne, wie kriege ich den noch mit grafischen runden Ecken versorgt? Und zwar in einer Form, wo noch komplett ohne Box, ohne Border-Radius das Ganze funktioniert. Also wirklich schön mit grafischen ausgeschnittenen, PNG-Grafiken und...

Das finde ich so witzig im Moment. Wir haben so lange gewartet, bis wir endlich dieses verdammte Border-Radius benutzen können. Jetzt können wir's benutzen. Mittlerweile erzählen uns sogar schon namhafte Webentwickler, wir brauchen das nicht mehr prefix verwenden. Und jetzt, kommt da irgend so ein Russe und sagt: „Das ist ein absoluter Performance-Killer.“ Es ist, oh.

Das ist, ne, ging neulich rum, diese, da hat irgendein russischer Entwickler hat so einen, so einen, CSS-Performance-Test gemacht und hat tatsächlich festgestellt, Border-Radius ist der große Performance-Killer. Also wenn man's viel verwendet und, vermutlich nicht auf einer einfachen Web, Entschuldigung, auf einer einfachen Webseite, wo man ein Element mit roten Ecken macht, aber wenn man's in so einer Web-App viel benutzt, zieht es richtig an den Füßen. Das ist so witzig.

Betrifft aber auch die ganzen anderen Sachen. Also gerade hier so diese Box Shadows und, und, und, die Gradients. Also gerade mit den, was, Firefox vier, Firefox fünf, so bevor das losging mit der Hardwarebeschleunigung. Wenn man die wirklich auf kleinen Flächen hat, das alles funktioniert, also mal einen Button da zu gestalten, aber großflächig irgendwo dahinter zu legen, das hat schon ganz schön gefressen und ich bin der Meinung, das frisst immer noch recht ordentlich.

Aber man lässt es ja mittlerweile sehr gern geschehen, weil einfach, also zu diesen ganzen Grafiken, ich will da nicht wieder zurück, ne.

Also wer will denn dieses, dieses Zeug noch malen, wo du jetzt einfach ins Stylesheet gehen kannst, wenn dir was nicht passt und da den Alphawert noch ein Zehntel runtersetzt und die Farbe noch ein bisschen veränderst und dann zack, ein Reload und fertig.

Erschwert ja auch einfach diese ganzen Workflow-Vereinfachungen, an die wir uns gewöhnt haben, so im Browser gestalten und, mal eben irgendwie einen Web Inspector oder einen Firebug aufmachen und mal eben schnell eine Runde Fly CSS ändern. Und das sind ja alles Geschichten, wo du irre wirst, wenn du das alles erst in Photoshop nachbauen sollst. Das macht ja keiner mehr.

So, und was jetzt? Ja, Dateigrößen. Also meine Core-Dateien sind ein bisschen angewachsen. Liegt aber auch einfach daran, dass da ein bisschen was reingekommen ist, auch wirklich. Also ich hatte früher nur die, das, das reine Basis-Layout, also, die Grid-Komponente und die Spalten da drin. Und es ist jetzt, beispielsweise, es gibt kaum eine Webseite, die ich mir vorstellen kann, die ohne Formulare auskommt.

Demzufolge ist die Formularbaukasten da mit direkt mit reingewandert, dass man sagt, alles, was irgendwo Formularlogik ist, ist einfach da drin, dass ich da nicht noch eine extra Datei brauche. Und die Ganzuelle, die, die, die, das Visuelle der Formulare, also wirklich die, die, die reinen Präsentationsregeln, die sind ausgelagert in quasi so einen Formular-Theme.

Das macht auch Sinn. Also YAML ist quasi-- Der Core bei YAML ist das, wenn man YAML verwenden möchte, das, was man unbedingt braucht, damit es quasi funktioniert. Und alles andere ist in Modulen ausgelagert, die ich, sofern ich es dann brauche, einbinden kann. Das heißt, ich muss nicht die all deine Dateien, die du jetzt hast, mit all deinen Definitionen, die wirklich alles abdecken, wirklich benutzen oder alles mitschleppen, sondern das ist modular aufgebaut, ne?

Der Core sind irgendwo viereinhalb K. In der Base CSS benefiziert und noch mal, glaube ich, knapp an die zwei, -

Eins Komma eins

... als Strafsteuer für die alten IEs, also IE sechs und sieben, die dann noch per Conditional Command hinterhergeworfen werden. Alles andere ist zur freien Verwendung, wo man natürlich sinnvoll, sie zu nutzen, aber eben nicht zwingend notwendig.

Das, was in Core liegt, ist auch wenn ich's richtig verstehe, ich mach nicht viel mit YAML, aber das in Core ist das, was man auch normal nicht anfassen muss, oder?

Das sind die Sachen, die stellen quasi die Funktionalität zur Verfügung. Und, das war eins der Konzepte, die ich damals eben auch schon 2005 angefangen hab einzuführen, zu sagen, das wird eingebunden und wenn, dann wird über die CSS-Kaskade an anderer Stelle überschrieben, sodass man immer diesen Fallback hat und immer auf eine sauber funktionierende Lösung auch wieder zurück kann, die wiederverwendbar ist.

Deswegen, das sind die beiden Dateien aus dem Core, wo man sagt, wo ich eigentlich sage, Finger weg einbinden und alles andere danach bei sich selbst machen. Was ich auch als den eigentlichen Sinn eines Frameworks im Bereich CSS erachte, dass man nicht da nur einfach-- Also das unterscheidet das Ganze von so 'nem klassischen Fertig- oder Beispieltemplate, wo du einfach nur 'ne HTML- und 'ne CSS-Datei kriegst und wenn du die dir irgendwo zerschossen hast, dann war's das ja.

Ne, weil eben da Logik und Layout dann eben nicht voneinander getrennt waren.

Wenn ich's mir so angucke, kann man vielleicht sagen für Leute, die beispielsweise ARMS HTML5 Boilerplate kennen, ist, die Base CSS ist so ein bisschen normalized, ne. Es ist ein kleiner Reset drin und es sind so ein paar Basis-Styles drin und, Clear Fix und so was.

Ja, die Normalize ist, hab ich mir, jetzt auch die Tage vor Weihnachten entsprechend angeguckt. Im Prinzip das, was in der Normalize drin, CSS drinsteht in diesem Projekt, ist zu, ich würd sagen, fünfundneunzig, achtundneunzig Prozent auch irgendwo in YAML drin. Nur es ist an verschiedenen Stellen.

Also ein Teil davon ist wirklich in der Base drin, und zwar genau der Teil, wo ich sage, das sind echte Normalisierungsregeln von Elementen, die ich unter Umständen nachher nicht mehr anfasse oder nicht zwingend anfassen muss. Und ich denke, das sind so um die fünfzig Prozent und die anderen sind, ich glaube zu Großteilen, in entweder, in entweder in, im Typografie-Style Sheet und was Formulare betrifft, in dem Formular-Theme drin.

Weil eben die Normalize, glaube ich, auch noch so 'ne Sachen macht wie Überschriften, Größen festzulegen, wo ich sage, das ist was, also so klassisches Reset, ne. So was, das binde ich ganz vorn ein, bevor ich anfange. Dort brauche ich jetzt keine Überschriftenregeln, weil egal wie sie aussehen, lesbar sind sie erst mal das, was mir der Browser liefert. Also kann ich das dann auch, das sind ja, Überschriften sind ja Elemente, die fasse ich sowieso an.

Also muss ich die jetzt nicht extra noch mal, da noch mal die Schriftgröße einfach vorgeben in so 'nem extra Normalize-Style Sheet, sondern das kann ich dann hinten wirklich in der Typografie machen, genauso eben wie mit Formularelementen. Deswegen sind die Sachen ein bisschen aufgeschlüsselt.

Widerspricht auch diesem Geist, dass man sagt, Base CSS eigentlich am besten gar nicht anfassen.

Ja, das ist genau.

Deswegen packt man da ja keine Styles rein, von denen man weiß, da geht sowieso jeder bei. Das ist ja sinnvoll und, gut, über den, den Meyer Reset haben wir auch schon mal in einem anderen Podcast gesprochen, dass der manchmal eher hinderlich ist. Insofern.

Nee, aber auch bei Normalize. Es ist mir, da sind, es sind einfach ein paar Sachen, Regeln, da wird man ran müssen. Oder also man definiert sie eh, da steht ein paar Sachen auch drin, die man wirklich regelmäßig anfasst. Und es ist mir einfach zu viel, um's wirklich so frühzeitig einzubinden, um zu sagen, das überschreibst du dann wirklich noch mal alles, weil dann hast du wirklich entsprechend Redundanz drin.

So an dieser Stelle muss ich den, Jens Grochtdreis, der ja nicht allzu sehr in der Sendung vertreten war, außer beim Hallo. Er hat heute Schwierigkeiten mit seinem Internet oder mit Skype, ganz genau ist es nicht bekannt, aber er war, hat er heute schon Schwierigkeiten beim Surfen. Deswegen kann er leider nicht mehr in die Sendung kommen, was sehr schade ist, weil, Jens auch 'n, wirklich 'n sehr aktiver User von YAML ist und da hätte er sicherlich einiges beitragen können.

Aber ich denk, das kriegen wir auch so geschaukelt.

Jo.

Klassisches, Gegenargument, war was, was viele, die YAML eben nicht kennen oder sich das angeschaut haben, was ich immer so höre und jetzt auch lese, das hat zu viel Overhead, da ist doch viel zu viel definiert und, da muss doch alles berücksichtigt sein und, so ganz, kann ich das nicht nachvollziehen, weil grade durch den modularen Aufbau bin ich ja wie gesagt nicht verpflichtet, alles benutzen zu müssen, oder? Also es steht ja jedem frei, das zu benutzen, was er möchte von YAML.

In dem Sinne ja, ein bisschen Overhead ist immer drin, ne. Also du hast, wenn du 'ne reine Spaltenlayout pr-mit-malst, dann brauchst du die Code-Definition natürlich nicht. Die in YAML, vielleicht wissen sie, vielleicht nehmen sie fünfhundert Byte ein, in der Base. Oder du, du hast den Formularbaukasten, der drei grundlegend verschiedene Layoutvariationen schon mal anbietet, ja, wie du Labels und Formularelemente zueinander positionieren kannst.

Das sind natürlich Sachen, die man Rausstreichen kann. Wenn, wenn man jetzt sagt, diese vier Kilobyte Basisversion, die sind mir zu viel, da kommt man sicherlich auf, wenn man's individuell, individuell auf das entsprechende Layout anpasst, vielleicht auf drei oder auf dreieinhalb runter. Wenn ich aber weiß, dass ein halbwegs, komplexes Layout locker mal fünfzig, siebzig Kilobyte an CSS mitliefert, fragt sich's, ob sich's lohnt.

Ich denke, der Ansatz, -

Also das rauszustreichen, weil im, im Zweifelsfall musst du's ja eh wieder schreiben.

Ja, das ist ein gutes Argument. Ich denke, der Ansatz ist von YAML sowieso ein ganz anderer. Also es geht bei YAML natürlich darum, dass du nicht immer wieder alles selbst neu schreiben musst mit CSS und HTML.

Und auch nicht, dass du dir deine Vorlagen irgendwo wegspeicherst und da fehlt dann vielleicht eine und du musst sie dir wieder raussuchen, sondern ich denk jetzt grade an 'ne klassische Werbeagentur, wo die Webentwickler da sitzen und keine Ahnung, in der Woche fünf, sechs, sieben Projekte hochschrauben müssen, wenn's kleine sind und die machen vielleicht mal ein längeres. Aber um auf den Punkt zu kommen, sie wollen schnell starten.

Das heißt, wenn ich mich einmal in die YAML-Struktur eingearbeitet habe, das heißt, ich verstehe, wie es funktioniert und ich weiß vielleicht, wie die CSS-Klassen heißen, die ich da benutzen muss, dann kann ich sehr, sehr schnell mit diesem Basisset die Webseite aufbauen.

Und sagen wir mal, wenn, wenn die auch 'n paar Kilobyte mehr hat als 'ne Variante, die ich selber machen würde, bin ich A: sehr, sehr viel schneller mit der Webseite fertig, was sich, auszahlt bei der Budgetierung des Projektes.

Und, andererseits, wenn der Kunde jetzt sagen würde: „Mensch du, ich hätte das ganz, die, die Labels im Formular", weil du sie gerade genannt hast, "jetzt doch mal links", dann stellst du nur eine CSS-Klasse um quasi, um's mal zu übertreiben und dann, dann ist es das schon. Und du musst keine weitere Arbeit in das CSS reinstecken. Das heißt, grade für, ich sag mal, Leute, die wirklich sehr, sehr viel Projekte wegschaffen müssen, ist das doch von Vorteil.

Ja, nee, es ist immer 'n Totschlagargument, weil du sagen kannst, da ist zu viel drinne. Und, also dieser klassische, wo, Auswurf Bloated Code, ne, den kannst du natürlich immer, und den kannst du eigentlich fast jedem Projekt um die Ohren hauen, nicht bloß jedem Framework. Aber es ist an der Stelle auch immer die Frage, wo sind die achtzig Prozent an Performance, die man sich leicht holt und wo sind die zwanzig Prozent, wo liegen die, an die man sehr viel schwerer rankommt?

Und in der Regel kannst du aus 'nem Bild beispielsweise schon, sehr viel schneller und sehr viel mehr rausquetschen, an Bytes, die du einsparen kannst, als dass du jetzt an, dass es sich lohnt, an der Stelle, bei deinem CSS-Framework deiner Wahl jetzt anfangen, da teilweiser, den Code rauszustreichen, nur um 'n bisschen was, 'n paar Bytes zu sparen. Also das geht wirklich an anderer Stelle schneller.

Also ich glaub auch grade mit der Dokumentation, ich, ich, ich scroll da unglaublich gerne dann rum in der, in der Dokumentation von YAML, der neuen. Die ist ja so aufgebaut auf eine Seite, ich scroll runter und die Navigation, passt sich grade dem Bereich an, in dem ich mich grade bewege. Verleitet mich grade dazu, ich kopier mir eben mal das CSS oder HTML raus und probiere mal ein bisschen was rum. Also ich glaube, der Spielfaktor war bei dir auch gegeben.

Sagtest du im, im Vorbereitungsgespräch, YAML zu entwickeln, es hat dir echt Bock gemacht, ne?

Na, so ist es auch gedacht. Also ein, ein, einer der Gründe, warum YAML eben jetzt so lange gebraucht hat, ist diese Version vier offiziell gibt. Das hat er jetzt, ich würd mal sagen, anderthalb Jahre bis fast zwei Jahre, spuckt's bei mir im Kopf rum. Lag daran, dass ich wusste, dass die alte Doku ich so nicht mehr will und ich aber nicht wusste, wie die neue jemals aussehen solle.

Im Sommer war ich irgend auf dem Trip, oder auch kurz davor, so 'ne Art API-Dokumentation zu bauen, wie sie jQuery hat, und vor allen Dingen wie sie jQuery und jQuery UI hat. Also dass du wirklich diese einzelnen, APIs dort aufgeschlüsselt kriegst und mit kleinen Beispielen, die da so im, im iFrame laufen, diese verschiedenen Varianten, dass man die zeigt, wie sie funktionieren. Aber das war eben auch entsprechend aufwendig und hab ich dann irgendwo nicht gemacht.

Und, ja, dann bin ich eben irgendwann bei Bootstrap mal wieder vorbei und das Projekt ist von einer Weile hatte ich's mir mal angesehen, dann aber wieder vergessen und jetzt mal wieder durchgeblättert und dort hat mir eben diese Art und Weise, diese Doku, genau dieser Einseiter, alles drauf, alles einfach zu erreichen, sehr gut gefallen. Und ja, was soll's, dann macht's man halt.

Also 'n Konzept, was funktioniert, das, daran, davon sollte man sich ja schon mal inspirieren lassen und das zu übernehmen. Und dann war das relativ schnell gebaut und ab dem Moment hat's eben auch wirklich Spaß gemacht, weil dann klar war, dass ich nur noch beschreibe, wie alles funktioniert und nicht mehr, warum es so und so läuft, hat dafür gesorgt, dass jeder einzelne Baustein, der zu erklären war, sich auch relativ kurz hält.

Und wenn man natürlich mit dem eigenen Framework dann gleich so 'ne schöne schicke neue Seite aufbauen kann, dann macht's eben auch entsprechend Spaß. Und jetzt, mit den Codebausteinen, dass man die beispielsweise eben wirklich rauskopieren kann, das erleichtert natürlich auch die Arbeit für jeden Einzelnen. Ne, also jetzt nicht nur für mich.

Mir hat Spaß gemacht, das zu bauen, aber so Leute wie Jens, die das natürlich auch täglich einsetzen, für die ist es ja auch nervig gewesen, auch wenn sie's kennen, wenn sie nachschlagen müssen, sich da durch mehrere Seiten zu klicken und im Zweifel zu lesen, wie's geht, aber dann doch den Code selber zu schreiben. Und hier sind jetzt an vielen Stellen wirklich die- In der Regel benötigten Codeschnipsel, die liegen einfach da und ich kann sie mir rauskopieren.

Jens, dich haben wir wieder dabei.

Ja, offensichtlich hat mich, mein Provider grade mal wieder reingelassen.

Fragt sich, wie lange, aber nutzen wir die Zeit.

Ja, genau.

Du bist ja, du bist ja natürlich, richtig intensiver YAML-Benutzer schon seit langer Zeit und hast dich wahrscheinlich jetzt auch auf die neue Version viel gefreut.

Ja, vor allen Dingen hab ich mich drauf gefreut, dass sie dann endlich mal veröffentlicht wird, weil ich ja nu schon, bisschen länger, mit Dirk dahingehend in Kontakt bin und, ich, hab-- hatte ihn ja auch mal, angeregt, die, diese Grids, anders zu implementieren. Ich glaub, das war im Wesentlichen meinen, meinen Anstoß, dass er die Grids umgeschrieben hat. Ich schätze mal, dann hat er den ganzen Rest auch noch gleich mitgemacht.

Also das, mit der, mit den Namespaces, das, spukte ihm wegen WordPress schon die ganze Zeit im Kopf herum. Das war 'ne gute Sache und, als er dann die Grids umgeschrieben hatte, da war die Sache auf einmal, richtig, richtig klasse. Da-- ich hatte da so mein, mein, Schlüsselerlebnis in dem Fall, in dem ich mal dann selber meine eigene, mein eigenes Grid geschrieben hab.

Das wird ja auch immer gerne übersehen, dass man dieses, dieses YAML einfach nur als Basis für, für seine Entwicklung nehmen kann. Ich weiß nicht, ob ihr das schon hattet.

Das haben wir kurz, angesprochen, ja.

Ja, ich, ich versuch das immer so zu vermitteln, dass das 'n Werkzeugkasten ist und vor allen Dingen ein Werkzeugkasten, mit dem man sich neue Werkzeuge auch bauen kann. Und, das geht bei diesen Grids halt super. Und das ging vorher nur mit Schmerzen.

Da hat man unglaublich lange Zeilen Code geschrieben, nur um, neue Grid-, Breiten zu, zu erzeugen, um dann später festzustellen, das war bei mir der Fall, dass man dann komplett vergessen hatte, das Ganze für den IE auch noch mal nachzuziehen, sodass das in den richtigen Browsern gut aussah und in wie IE voll-vollkommene Grütze war. Das wollten wir ja auch nicht. Und, und jetzt ist es, nur noch so, dass du, wenn du neu, ein neues Grid erschaffen möchtest, dass du nur noch die Breiten definierst.

Egal wie. Also in Pixel, EM oder in Prozent, wie du möchtest. Und das ist schon mal richtig klasse. Das, das ist dann für die Praxis einfach, super. Und diese, diese neue Doku, die ist dahingehend natürlich klasse, weil man, auch wenn man das regelmäßig nutzt, immer wieder mal schnell nachschlagen kann: Wie war das jetzt noch mal genau geschrieben? Es sei denn, man macht sich dazu – dafür plädiere ich ja immer – man macht sich dann einfach seinen Editor zu Nutzen.

Ich weiß ja nicht, welche Editoren ihr alle nutzt, aber du, David, nutzt ja, glaub ich, so 'n, so 'n, so 'ne Abart von, von-

Ich wusste, dass so was kommt.

So 'ne Eclipse-Abart, oder? Du-

Nein, nein. Hat mit Eclipse nix zu tun. Das-- ich nutze NetBeans derzeit.

Ach so, okay. Ich dachte, du hattest doch früher mal Zend Framework. Das ist doch so...

Ja, ja, das hab ich getestet. Ich hab-- war, war ja so 'n alter Zend-, User damals und die haben das irgendwann auf Eclipse umgestellt und dann mocht ich's nicht mehr. Und dann hab ich so CSS- und HTML-Editoren wie keine Ahnung, wie sie alle hießen, aufm Mac grade probiert. Aber um das ab-

Da kann man ja auch Snippets abspeichern, ne. Das, das kann man dann in, in vielen Editoren machen. Das ist bei, bei Dreamweaver ist das super gelöst. Das ist in vielen Editoren klasse gelöst und ich hab das jetzt bei, bei TextMate dann für mich gemacht und dann, brauchst du einfach nur noch so 'n, so 'n Kürzel eingeben, Tab drücken.

Ja, genau.

Und schon steht dieser, der ganze Kram für, für die Grids, in deinem, Quellcode drin und das ist schon saupraktisch.

Ach, du meinst Snippets. Ich red sie die ganze Zeit: „Was meint der Mann?" Du meinst Snippets.

Ja, ja.

Also heißt das-

Was hab ich denn gesagt?

Nö, du, gar nichts. Mir war nicht so ganz klar, was du genau meintest, aber in, ins Sublime Text für die Akten, den verwende ich, heißt es Snippets. Also Code-Schnipsel halt.

Ich glaub, den muss ich mir jetzt demnächst auch noch mal noch einmal ein zweites Mal angucken, wie es das-

Ich hab auch zwei gebraucht. Im, im ersten Anlauf fand ich den auch doof.

Ja, na gut, so ging's mir bei TextMate auch. Als ich den das erste Mal installiert hab, da hab ich gedacht, die wollen mich verarschen und, so nach 'ner Woche hab ich dann festgestellt, dass das doch 'n gutes Tool ist.

Ich glaub, wir brauchen noch mal 'ne Sendung zum-

Da hat man, da hat man, da hat man Toolleisten, weißt du? Und, und das ist halt bei Tech, die, die haben da nur Torfeld. Na egal.

Wir machen noch mal 'ne Sendung zum richtigen Editor, den man benutzen sollte. Für welche, ja, für welche, für welchen Einsatzzweck. Genau.

Nein, es gibt nicht die richtigen Editoren. Das ist der, der Editor, der dir am besten gefällt. Und da, wie dein Haargeschmack, oder Geschmack für dein Lieblingsbier kann sich das alle zwei Jahre ändern.

Definitiv.

Weiß nicht, wie viel Editoren ich durchgemacht hab. Ich glaub, fünfzehn oder so.

Ach ja.

Also der einzig gute Grund für eine, welche ist der beste Editor Technikwürz ist, glaub ich, wenn du den längeren Record brechen willst, weil da kannst du tagelang drüber diskutieren.

Ja, und du siehst nachher auf alle Fälle zweihundert Kommentare.

Ja, als Erstes kommen die Wim-Leute, ne. Die Wim-Leute sind die schnellsten. Wim ist das Allerbeste. Dann kommen die Emacs-Leute, dann ganz verhalten die TextMate-Leute und dann kommen die ersten mit so Aptana, NetBeans, Eclipse und das, das nimmt kein Ende.

Man kann auch wunderschön über, über Betriebssysteme,, philosophieren und, dem anderen dazu raten, wenn er 'n vernünftigen Editor haben möchte, dann soll er doch bitte auf Betriebssysteme XY wechseln. Das ist dann auch immer sehr beliebt, ja. Aber ich glaub, darüber wollten wir heute gar nicht reden.

Ich wollte grad die Überleitung machen. Diese Editoren machen ja diesen ganzen heißen Scheiß wie HTML5 und, CSS und so 'n ganzen Kram, das ganze Gedönse dieses modernen Zeugs. Wie sieht's denn da mit YAML-Unter-Unterstützung von diesem Zeugs aus? Dirk.

Also mei-mei-meines Erachtens hat das eine mit dem anderen ja gar nix zu tun. Ich, ich hab mich, ich hab mich jetzt, sehr amüsiert, als ich glaube beim Dirk

In, in irgendein, in den Kommentaren zu einer der, der Ver-, der Veröffentlichung von Dirk, also entweder in seinem Blog oder, bei Google+, in einem der Kommentare dann gelesen habe, dass, dass YAML doch endlich, für ihn z--, nutzbar wäre, weil er, weil man da jetzt mit HTML5 umgehen könne.

Ja, und das, das hat mich dann wieder an eine der allerersten Fragen, die, mal an mich herangetragen wurden bei YAML 1 oder 2, erinnert, als dann gefragt wurde, ob, ob denn YAML sich mit jQuery vertragen würde. Und ich mein, das eine hat mit dem anderen nichts zu tun. Ist doch vollkommen egal. Bei, bei YAML werden nur Klassen genutzt und ob ich die an HTML 3.2 dran kn-- dreinknalle, HTML4, 5 oder XHTML 1.1, ist doch wurscht.

Ja, zumal mit jQuery ist ja schon der Witz, dieses, - -dieses großartige Tab-Skript von Dirk Ginader ist ja jQuery-Basis. Was Dirk, glaub ich, auch mit Blick auf YAML entwickelt oder zumindest optimiert hat. Oder du hast Dirk, glaub ich, mitentwickelt an dem Accessible Tabs, was im Übrigen das tollste Tab-Skript überhaupt ist.

Definitiv, ja. Ja.

Ich hab Dirk den Floh ins Ohr gesetzt, dass ich so 'n Tab-Skript haben will. Das war zu 'ner Zeit, wo ich mit jQuery, ich es zwar vom Sehen her gemocht, aber selber noch nicht konnte. Und Dirk war damals so freundlich und hat genau nach meinen Wünschen eben das, so programmiert, weil er es eben auch die Idee entsprechend w-- cool fand.

Und, es ist wirklich, im Moment das einzigste und wahrste und genialste Tab-Skript, was ich kenne, weil's eben wirklich erst mal-- Ich kann ganz normalen Code schreiben und, wenn der ohne JavaScript dargestellt wird, steht da nicht so 'ne dämliche Liste, mit der ich nichts anfangen kann, sondern da steht normale Überschriften, da steht normal gegliederter Text und in dem Moment, wo ich das Tabs anschalte, schnipp ich mit den Fingern und das sieht anständig aus.

Ich nutz es auch in der Tat schon sehr, sehr lange, ja.

Und es ist barrierefrei bis weiß der Himmel wohin. Dirk hat, glaub ich, mit einem, Kollegen von Yahoo da ganz viel Arbeit reingesteckt-

Mhm, genau.

-dass das auch mit Uralt-Screenreadern läuft.

Ja. Ich hab's auch mal, ich hab's auch mal in 'nem Projekt oder für ein, für 'n, für 'n Klick-Dummy für ein Projekt so aufge-, um-umgebastelt oder nicht umgebastelt, sondern so genutzt, dass man's als, als Bilder-Slideshow nehmen kann. Und das ist richtig klasse. Also das ist ganz einfach.

Du musst einfach anstatt des, des Textinhaltes, in jeden Bereich nur 'n Bild reinknallen und dann hast du im Prinzip mit 'n bisschen CSS deinen Bilder-Slider und musst nicht einen von den zweihundert Milliarden jQuery-Bilder-Slider nehmen, die alle drei Wochen rauskommen.

Ja, da kannst du aber auch einfach das alte Schlachtross Cycle nehmen. Das ist einfach. Also wenn's 'n bisschen mehr Slideshow mit automatisch und so sein soll, ich, ich, ich lande immer wieder bei Cycle. Das ist auch schon steinalt, aber funktioniert und tut, was es soll.

Du bist so'n Traditionalist.

Da ja.

Ja, was HTML5 betrifft, ja mein Gott, Jens hast du schon gesagt, das sind halt Elemente, welche-- Ich kenn kein Framework im Moment, was irgendwelche Eigenschaften an irgendein Element bindet. Also-

Und so-

Eben, also ist Quark. Also die binden das alles an irgendwelche Klassen oder IDs und damit kann ich's auch mit jedem beliebigen, HTML, ob's jetzt nun 3, 4 oder 5 ist, verwenden. Was bei HTML5 halt ist bei den einzelnen Reset-Bausteinen, die man sich so gerne irgendwo hinlegt, dass so bestimmte Elemente wie Header, Footer, und noch so drei, vier andere per Definition oder, oder per, per, per W3C-Standard, Inline-Elemente sind und man sie doch liebend gern als Block-Elemente benutzt.

Demzufolge ist in der Regel das noch erforderlich, dass man denen als, als allererstes mal Display Block zuwirft. Und das ist seit YAML 3.3 schon drin.

Nee, das hat nichts mit Standard zu tun, Dirk, sondern damit, das hab ich auch mal gelernt, dass wenn ein, wenn ein neu, ein unbekannter Tag auf einen Browser trifft, auf einen, also auf einen Browser. Ja, also was nicht, ne, also Browser.

Ja, ja, wir haben das schon verstanden.

Auf einen Browser trifft, dann ist das für den 'n Inline-Element. Für die Internet Explorer ist das ein unbekanntes Ele-Element und der macht dann irgend 'n Bockmist daraus. Und deswegen gibt's für den Internet Explorer, dann diese JavaScript-Lösung und die dann unbekannten Elemente sind für den dann trotzdem, dann kommt er auf 'nem richtigen Browser raus, halt unbekannt und dementsprechend Inline-Elemente.

Was auch, was auch 'n gewissen, praktischen Nutzen eigentlich hat, weil so 'n Inline-Element erst mal nichts zerstört. Und deswegen muss man dem per CSS dann sagen: „Nee, nee, du, du Header, du bist 'n Block-Element.“ Darauf kommt das hinaus. Und die, die Browser, die's richtig implementiert haben, denen sagst du halt, den bestätigst du nur, nur noch einmal, dass das tatsächlich 'n Block-Element ist.

Was das nicht wehtut, ja.

Nee, das tut nicht wirklich weh. Und da-dafür, dafür gibt's diesen Res, diesen Schnipsel im Reset-Baustein, den hast du ja auch drin und den hast du schon seit YAML 3.3, glaub ich, drin oder YAML 3.2, also auch schon seit 'nem Jahr etwa.

Ja, also ab dem Moment, wo man irgendwo der Meinung sein könnte, man könnte es praktisch gebrauchen und auch einsetzen, ne. Also, diesem Hype da hinterherrennen, und da alles gleich sofort zu machen, was irgendwo in zwei Jahren vielleicht mal spruchreif wird, das bringt's dann irgendwie auch nicht.

Nee.

Was mich 'n bisschen gewundert hat, also nicht, dass ich's jetzt unbedingt fordern würde, aber du hast den, du hast den klassischen HTML5-Shim drin, der wirklich nur die neuen Elemente anmeldet. Es-- Hat das Gründe, dass du nicht beispielsweise jetzt, weil ich's sehr mag, dass du nicht gleich komplett Modernizer mit reingeschmissen hast?

Ja, weil mir Modernizer 'n bisschen viel ist, so ohne Weiteres.

Es ist zwar auch, wenn man sich's über den Konfigurator bei Modernizer zusammenbaut, man kann's relativ klein machen, aber, 'ne abgespeckte Version jetzt mitzuliefern, die ich dann nachher sowieso nicht benutzen kann, weil mir die Hälfte fehlt, bringt's nicht aus meiner Sechte, Sicht. Deswegen, wenn, dann hätte ich eh nur die große implementieren müssen.

Und jetzt nur, ich wollt ja wirklich, es geht ja wirklich nur erst mal um die blanke Demonstration oder nicht, nicht Demonstration, sondern das blanke Nutzbarmachen dieser neuen Elemente und dafür reicht das HTML5-Shim. Und das Zweite ist, dass ich ja, mit besten Grüßen an Alexander Farkas, der guten Hoffnung bin, dass sich auch dieses HTML5-Shim in nächster Zeit noch mal ändert, im internen Aufbau.

Also das ist einfach das, wo im Moment die meiste Entwicklungszeit reingesteckt wird, um das stabil lauffähig zu machen. Das hat immer noch 'n paar Macken. Das ging damals, vor 'nem halben Jahr oder 'nem Jahr hatte ich da mit dem Alexander mal drüber gesprochen, etwas intensiver.

Da war der Zustand so, dass du beispielsweise im HTML, im IE, in den älteren IEs, die das gebraucht haben, die haben das zwar angezeigt, aber du konntest diesen Krempel dann nicht mehr ausdrucken, weil der im, im, im Print-Layout im Prinzip alles zerschossen hat.

Ah, der nimmt im, im Print-Layout nimmt er den, den HTML-File-Shim nicht mit, oder wie?

Nee, der hat dann im Print-Layout schreibt er das ganze CSS um, um, um diese Elemente auch im Druck nutzbar zu machen und hat dann aber damals in der ersten Version haben sie das irgendwie über zusätzlich rangepappte Klassen gelöst. Klassen macht's dann irgendwo mal klingeling, mit Spezifität. Das heißt, das haut ja dein normales CSS unter Umständen komplett durcheinander.

Wenn du Elementen eine Klasse zusätzlich dazu gibst, die sie vorher nicht hatten und demzufolge ist eben auch ganz viel beim, beim Druck quasi kaputtgegangen und es hat sich auch, glaube ich, totgerechnet, im IE. Und mittlerweile funktioniert's recht gut. Die Version, die jetzt da ist, aber auch noch nicht hundertprozentig stabil beim Drucken. Also am Bildschirm ist alles okay.

Und deswegen habe ich auch, noch zwei Alternativen in der Doku mit verlinkt, weil da ist eben aktuell wirklich noch, das Ding wird weiterentwickelt regelmäßig. Und Modernizer übernimmt ja auch immer nur, quasi den aktuellen Ist-Stand, der grad live ist und deswegen war's, dann kann man auch gleich das, das, das Basisprojekt dessen einbinden.

Ist das, was du drin hast, jetzt die Version, die diesen Inner Shift dabei hat? Also es gibt ja irgendwie 'n Problem in, ich weiß nicht, war das auch nur IE oder auch noch andere ältere Browser, wo's, praktisch schwierig wird, wenn man die neuen Elemente so Ajax-mäßig über JavaScript einfügt. Und da gibt's auch irgendwie 'n Fix für.

Das ist das Inner Shift, wenn ich's mich richtig erinnere. Warte mal, ich geh mal, jetzt muss ich selber gucken.

Ja, das ist es.

Das kommt von Alexander Farkas. Und das soll wohl, wenn's, wenn's nach ihm geht, auf alle Fälle und wenn er die anderen beiden überz, auch überzeugen kann, soll wohl in die nächste Version da reinkommen. Und in jQuery ist es in der eins sieben ja schon drin.

Oh, das wusste ich gar nicht.

Also das war das Problem bei jQuery generell, oder, oder bei, sagen wir mal so, das ist das Problem bei allen, JavaScript-Frameworks bis vor jQuery eins sieben gewesen, dass du zwar mit, diesem HTML5-Shim da statische Elemente, die also schon im, im normalen Quelltext drin waren, benutzen konntest, aber eben nichts injizieren danach.

Mhm. Genau.

Und das ging oder geht schon die ganze, 'ne ganze Weile früher, über die Web-Shims-Link vom, von Alexander Farkas. Der hat da so 'ne ganze Menge Polyfills da auch geschrieben. Da hat er 'n paar jQuery-Methoden extra dafür zur Verfügung gestellt, dass du eben auch, dann wirklich zur Laufzeit Elemente reinschieben kannst. Und dieser Teil ist in jQuery eins sieben auch direkt in jQuery reingewandert.

Das ist generell 'n großartiges Projekt vom Alexander, diese Web-Shims-Library. Das ist großartig. Das und, für allen möglichen Kram, den bestimmte Browser noch nicht können, gibt's da 'n Polyfill und das ist toll dokumentiert und das ist klasse.

Ja. Und dieses IAPP ist auch von ihm. Das ist 'ne dritte Variante, das zu machen und die ist nach seiner Aussage mit Abstand die robusteste, braucht aber, glaub ich, was war das hier, so 'ne HTC oder so was? Ja, braucht 'ne HTC.

Das kann sein, ja.

Und da bin ich einfach, da hatte ich mit ihm auch drüber gesprochen, ob man die vielleicht direkt in Jaml vier jetzt hier anbieten, aber, das war 'n bisschen knifflig von der Konfiguration, weil das teilweise auch, glaube ich, über 'n Server gesteuert werden muss, noch 'n bisschen. Also ich glaube, du musst, kannst über die Apache-Konfiguration irgendwie so was machen.

Das war jedenfalls genau, hier kommt noch so 'ne, so 'ne, so 'ne Apache-Regel mit dazu und damit geht's ja los, dass du nicht jeden, nicht jeder hat das Know-how und traut sich an eine HT Access ran, der im Frontend 'n bisschen was macht und deswegen habe ich dann davon wieder Abstand genommen, das direkt da reinzubohren, sondern hab's einfach nur verlinkt.

Gibt vermutlich auch-

Die funktioniert auch.

Sag du.

Entschuldigung.

Nein, mach du.

Die soll auch komplett, fehlerfrei beim Drucken sein.

Okay, gibt vermutlich auch immer noch Zielgruppen, die auf Web Spaces rumturnen, die einfach keine, keinen Zugriff auf die HT Access haben.

Das kommt noch dazu. Genau.

Ne, also auch 'n Grund. Und deswegen haben wir dann, wir hatten eben drüber gesprochen, was wir jetzt nehmen und das Einfachste war jetzt auch für mich, also das Sicherste eben, auch jetzt nicht irgend'n Projekt quasi selber mit in Zip zu packen, weil sich eben auch bei dem HTML5-Shim in den nächsten Wochen wieder was verändern kann, beziehungsweise es hätte jetzt auch schon im Januar passieren können, sondern dann eben echt, per Deeplink das Ding quer von Google einzubinden.

Gut, dann haben wir hier, HTML5 Boilerplate und YAML, Freund oder Feind?

Also von meiner Seite aus Freund.

Jo.

Ich find, hatte das HTML Boilerplate, etwas unglaublich Nützliches, um 'n Projekt zu starten, um 'ne saubere Arbeitsbasis zu haben. Über die Style Sheets mit dem Normalize hat man ja vorhin schon gesprochen. Also die würd ich an der Stelle einfach sagen, das CSS halt austauschen mit dem, was von YAML kommt und dann ist es gut. Was das Boilerplate für mich ausmacht, sind in erster Linie diese wunderbare, htaccess-Konfiguration.

Und dieses gigantische Build-Skript, was ich zwar selber noch nicht in seiner ganzen Logik durchdrungen habe.

Das versteht, glaub ich, niemand komplett. Das ist sehr komplex.

Ja. Also anwenden ist das eine, also anwenden kann ich's selber nicht, aber ich hab's, ich genieße es, dort drin zu stöbern, wenn ich meine eigenen Build-Skript schreibe, um mir dort die Sachen rauszuziehen, die ich brauche. Weil da so ziemlich jeder Fall da drin ist, den man brauchen könnte.

Ja, da passiert auch wahnsinnig viel. Also wir haben, das läuft ja im Moment mit so einem komischen Java-basierten, Apache, irgendwas, dieses Ant. Und da ringen die schon seit Monaten mit rum und wollen es gerne portieren. Und jetzt hat es sich so verselbstständigt, dass es irgendwie, ich glaub, drei verschiedene Ansätze gibt, das zu portieren. Einmal auf dieses, Rake, was zu, Ruby, glaub ich, gehört. Und dann gibt's, aber kam gleich der Nächste und sagte: „Nee, Ra-rake ist schon alter Kram.

Jetzt, nehmen wir Tor", oder wie das heißt. Das kenn ich überhaupt nicht, aber scheint auch aus der Ruby-Ecke zu kommen und, da passiert theoretisch viel, aber das Build-Skript an sich ist oberpraktisch.

Also ich wäre auch dafür, dass sie's jetzt bitte nicht sofort wieder ändern, weil ich hab mich grade erst im letzten halben Jahr an An-ant und Ru, Rhino und diesen ganzen Gedöns, was man da dazu braucht, gewöhnt. Also das ist-

Das Argument ist, glaub ich, das Ant wird gefüttert mit, mit XML-Syntax und das mögen die irgendwie nicht so richtig. Hab nicht ganz verstanden, warum nicht, aber es ist schon auch 'n sehr umfangreiches Teil des Build-Skript, wenn man da mal reinguckt, weil's halt auch viele Dinge, bedenkt oder berücksichtigt oder zur Verfügung stellt, die man so als Durchschnitts-Web-Heini, glaub ich, gar nicht benutzt. So diese Pro-production builds und, development builds.

Also normal haust du ja dein End-Build rein und schiebst das, was dabei rauskommt, auf den Server und gut.

Genau. Also mei-meine beiden Build-Skripts, die ich jetzt hier für YAML vier verwende, das eine für die minifizierten Datei-Versionen und das andere dann für die Website. Bei der Website wird eben CSS und JavaScript jeweils in eine Datei gepackt und dann minifiziert ausgeliefert. Das sind jeweils zwei Build-Skript, die passen ausgedruckt auf 'ne A4-Seite. Also die sind sehr viel harmloser.

Und da ist eigentlich diese XML-Syntax, da gewöhnt man sich relativ schnell dran und sie liest sich auch halbwegs anständig.

Ja, zumal du sie ja normal auch gar nicht unbedingt lesen musst. Du kannst ja einerseits über die Konfigurationsdateien 'n paar Sachen steuern, also kannst sagen, hier diese Sachen, wenn du beispielsweise Sass verwendest, dann kannst du den Ordner mit den Quelldateien vom Build-Skript ausnehmen, dass er den nicht mit rüberschiebt. Und solche Sachen kannst du auch eigentlich schon relativ gut einstellen, ohne im, im Build-Skript selber rumzufummeln.

Und da-dahinter macht das Ding ja eigentlich nur das, was Dirk schon sagte, also die Style Sheets kombinieren und minifizieren und dann optimiert er noch mal die Bilder mit zwei verschiedenen, einmal für, für PNG und einmal für JPEG und, entfernt unnütze Kommentare, auf Wunsch dann eben bis zum Abwinken, dass da überhaupt nichts mehr drinsteht und selbst das HTML minifiziert wird, was ich immer 'n bisschen unglücklich finde, weil da ist der Quellcode halt nicht mehr schön lesbar.

Aber das ist es ja im Grunde schon. Hast du vor, so ein Build-Skript für YAML zu bauen und, mit öffentlich zu machen? Oder ist das was, was du nur für dich machst?

Also ich hab's jetzt erst mal nur für mich, weil wie gesagt, ich hab's-- im Moment ist es komplett abgespeckt auf das absolut Notwendige. Also grade bei, bei YAML selbst geht's ja bloß um die Minifizierung von drei Dateien. Ich könnt, wenn mir, wenn man mich fragen würde, oder mich bitten würde, das mit auszuliefern, dann hätt ich, glaub ich, kein Problem. Da müsste man's eben noch mal 'n bisschen sauber machen, und dann kann man's mit ausliefern.

Es ist einfach in dem Moment, wo es jemand benutzen will, muss er sich eben eh damit auseinandersetzen, dass man sagt: „Okay, wie krieg ich jetzt Java zum Laufen? Wie krieg ich, Ant zum Laufen?", unter Mac ist das eigentlich kein Problem. Da braucht man, glaub ich, bloß noch Rhino und, und, dann YY-Kompressor, den benutz ich im Moment. Unter Windows musst du dir das Ant selber noch installieren und ich hatt zumindest 'n paar Schwierigkeiten, dann, Rhino zum Laufen zu kriegen.

Also hier die, die Rhino ist für die Leute, die es nicht kennen, ist 'ne JavaScript-Imple-implementation auf Java drauf. Ja. Damit dann eben auch... War doch richtig so, ne?

Du hast, glaub ich, ein lokal laufendes JavaScript, was, 'tschuldigung, in Java implementiert ist, damit du irgendwie, weil du bist ja in dem Moment, wo das Build-Skript läuft, nicht im Browser. Also hast du auch keine JavaScript-Engine. Dafür ist, glaub ich, Rhino da.

Irgendwie so. Es ist, da wird's mir auch langsam zu hoch, aber es gibt ja verschiedene Tücken. Es gab auch phasenweise 'ne, musstest du fürs Boilerplate Build Script eine bestimmte Endversion haben und die war dann auf bestimmten Linux-Systemen nicht vorhanden und solche Schwierigkeiten. Und dann reichte das aber auch, das Build Script ein bisschen umzubauen und dann ging's auch wieder mit der älteren Version.

Ja, also prinzipiell hätte ich kein Problem, das beizulegen, weil es ist dann der Lernaufwand, um's zu benutzen, ist dann relativ klein. Nur ist es eben im Moment so, dass für YAML selber, hab ich's ja. Da ist es so konfiguriert, dass es diese minifizierten Varianten er-erzeugt. Es wäre dann eher sinnvoll, eins zu bauen, was dann eben auch sofort die Nutzer-Style-Sheets mit einbezieht.

Ne, das eben würde ich sagen, kannst, du kannst dein eigenes Projekt bauen, hast dein, dein, dein CSS und dein JavaScript und kannst das einfach nur in eine Konfiguration einz-eintragen und sagen-

Drei Knöpfchen und ab dafür, ja.

Und lässt's einmal durchrauschen und lädst aufm Server, genau. Das könnte man mal machen. Ja. Aber ich hab's-- momentan benutz ich's eben nur für mich.

Jetzt hat uns der Jens gerade verlassen. Ich wollte nämlich umschwenken jetzt mal zu Grids und, Spalten. Layouts und Grids. Ist ja, ja, Gestaltungsmerkmal. Wie baue ich eine Webseite auf? Was benutze ich da? Nehme ich da Spalten oder Grids, Columns? Was nutze ich? YAML kann beides, ne?

YAML kann beides und ja.

Es ist ja auch letztlich dasselbe.

Also, also.

Entschuldigung, aber Spaltenlayout ist irgendwie auch 'n Grid. Na ja.

So, wenn man's-

Nö, nö. Nicht wirklich.

Also ich könnt's, manchmal drück ich's etwas zynisch aus und sag so, im deutschen Sprachraum nehmen wir Spalten, der Rest der Welt layoutet mit Grids mittlerweile..

Es ist die Frage, wie du's definierst, meine ich. Also letzteres ist 'n Grid, ist 'n Gestaltungsraster.

Eben.

Das sind Spalten und zwischen den Spalten gibt es Ab-Abstände und eventuell haben die Spalten noch einen Innenabstand. Und im Grunde kannst du auch sagen, ein, ein Zweispalter ist auch 'n zweispaltiges Grid irgendwo.

Ja. Also uh, das ist jetzt aber ganz weit an den Haaren herbeigezogen.

Nö, wieso?

Nö, es passt schon, aber es ist-

Ja, ja.

Bei YAML ist es-

Eigentlich nicht, weil, weil das, beim, beim, Spaltenlayout hast du einen grundsätzlichen wichtigen Unterschied gegenüber, den, den Grid-Layouts. Du kannst, die, die linke Spalte schnell nach rechts schieben und umgekehrt.

Das kannst du im Grid-Layouts auch. Das ist doch 'ne, 'ne technische Sache. Also du hast einmal diese Push-Pull-Classes, die du in den klassischen von, von 1960 GS abgelegenen Dingern hast. Dass, dass es typischerweise anders funktioniert, ist mir auch klar. Normalerweise, wenn du 'n Grid-Layout hast und zwölf Spalter, da sind alles float left, das ist klar. Aber das, das, das ist ja die, der technische Überleger für ein Grid.

Aber das, was unten drunter ist, meine ich, ist dasselbe, dass du halt ein, ein in Spalten angeordnetes Raster hast.

Jein. Also bei den, bei dem, bei den normalen Grid-Layouts hast du wirklich 'ne, 'nen, 'ne Verbindung zu 'nem Raster, das im Hintergrund liegt. Klar, du wirst ja auch als eine Art Gestaltungsraster für, für die Spalten machen, aber dass diese, diese ge-direkte Ve-Verbindung zwischen Gestaltungsraster und, Umsetzung in CSS, die hast du eigentlich nur bei den, bei diesen typischen Grid-Layouts. Und deswegen sind sie für mich ähnlich flexibel wie ein Tabellenlayout.

Aber, sie sind durchaus praktisch.

Es ist 'ne Geschmackssache. Es gibt beides. Es gibt in YAML beides.

Ja klar.

Ne.

Ist auch praktisch.

Also die, die Spalten sind in dem Sinne oder waren früher flexibler, dass man mehr oder weniger alles draufschmeißen konnte in allen Einheiten. Die Grids definieren sich im Prinzip so, dass du sagst, du hast 'ne regelmäßige Aufteilung, also auch regelmäßige, Breiten, ne. Du hast jetzt nicht die linke Spalte in, in, in, in, in, in zwanzig EM und die mittlere ist irgendwie flexibel und die rechte ist mit dreißig Prozent festgelegt, sondern es ist eben alles gleich.

Das ist halt immer die Frage, was du erreichen willst. Und, so die, der Vorteil, mit dem früher CSS so verkauft wurde, dass du, wie ich's eben gesagt habe, aus der linken Spalte 'ne rechte machen kannst und umgekehrt, ist ja auch nur 'ne rein theoretische Größe. Wann habt ihr das das letzte Mal gemacht?

Ja, vor allen Dingen konntest du das gerade früher ja meistens nicht, weil dir irgendein Browser in die Quere spuckte.

Oh nö, das konntest du, das kannst du, glaube ich, bis zum IE fünf runter. So, so dramatisch ist das nicht. Das geht schon. Da gibt's ja die unterschiedlichsten Varianten. Also das ist nicht das, Thema, von, von links nach rechts und von rechts nach links zu kommen. Aber wann machst du denn das? Wann, wann kommt jemals ein Kunde zu dir und sagt: „Ich hätte mal gern 'n Redesign", und das, beschränkt sich darauf, dass, dass sie bitte die Navigation von links nach rechts schieben.

Ja, nee, nie. Kunde sagt immer, Logo muss größer.

Ja klar, muss größer und animiert sein und, und da brauchen wir diese dollen Transitions und das Ganze in 3D.

Und Flash.

Und Musik muss das haben.

Und ob das aufm iPad läuft.

Und aufm iPhone.

Was bei den, was bei den Grids im Prinzip, die gehen ja zurück, irgendwo die, die, im englischen Sprachraum sind die Grids in Anführungsstrichen erfunden worden, irgendwann so, weiß nicht, 2006, 7. In dem Bereich ging das los mit Blueprint damals.

Die sind ja immer so implementiert: feste Breite plus diesen Spaltenabstand zwischeneinander, ne, als Padding oder Margin noch mit eingerechnet und dass das so ein Container ist.

Und- Das führt ja zu dieser recht unsinnigen Situation, dass gerade damals bei Blueprint es schon so war, dass auch nur bei diesem einen Blueprint-Beispiel, was es damals gab oder was es auch jetzt noch gibt, diese, diese, diese eine Demoseite, wo die da so 'n Layout aufgebaut haben, ihre eigenen Definitionen für ihr Grid schon wieder umschreiben müssen, weil sie eben in einer irgend so einer Spalte da noch ein Pixel Border mit dazu haben wollten, ne.

Wo, wenn ich, wenn ich da das zugehörige Padding dieses Elements nicht reduziere, diese Floats genau das machen, was sie tun, wenn man sie, wenn man ihnen 'nen Schubs gibt, ne. Sie-- Das bricht alles um. Und das ist im Prinzip die einzige oder, oder der entscheidende Unterschied bei dem, so wie ich es bei Jamel gemacht hab, zu sagen, davon lassen wir die Finger. Breiten kommen in den eigenen Container, alles andere, solange wir mit CSS zwei arbeiten, kommt woanders hin.

Und ich bin halt von vornherein auf Prozentwerte gegangen und da ist man 2006, 2007 noch ein bisschen ausgelacht worden, wo man gesagt hat, flexible Layouts sind irgendwo sinnvoll und im letzten Jahr kam's irgendwo wie 'n Bumerang zurück.

Das ist das eigentlich Spannende an, an Dirks Grid-Ansatz, find ich, in Jamel, dass das tatsächlich weggeht von diesem Ding, was man seit 1960 GS kennt. Dass eine, eine Box in einem Grid hatte immer eine bestimmte Breite, egal ob nun in Pixel oder in Prozent. Und sie hatte Außenabstände auch in Pixel oder Prozent. Und das ist eben das, was dir bei Grids als Erstes um die Ohren fliegt.

Und da gibt's diesen Ansatz zu sagen: Okay, die Breite machen wir für die Grid-Box und dann ist in der Grid-Box eine Box, die erzeugt dann praktisch den, wie sagt man, das Gutter, also die Abstände zwischen den Boxen. Da gibt's ja auch diesen, diesen Ansatz von dem, von diesem Finnen Joni Korpi, der dieses Golden Grid System gebaut hat, was ja auch in jedem älteren Browser auseinanderfliegt, weil es, Box Sizing verwendet. Aber das wird irgendwann das sein, wie wir das bauen.

Es sei denn, vorher kommt da irgendein CSS-Grid-Modul und sagt: „Nee, macht mal so, geht einfacher.“ Aber diese Geschicht-

Flexbox könnte irgendwann dann vielleicht doch noch mal kommen, aber das-

Man weiß es nicht, aber bis dahin-

Ist ja erst mal wieder, ist ja erst mal wieder ausgehebelt mit diesem neuen, ne...

Ja. Das Lustige ist ja, dass, das Lustige ist ja, dass du dadurch hast du in deinen Grid-Beispielen relativ gerade Zahlen. Also jetzt außer bei der Drittelung sind das alles Werte ohne Nachkommastellen und plötzlich rundet das. Weil ansonsten hast du bei flexiblen Grids immer Ärger mit, mit Rundungsfehlern. Dann-

Das funktioniert eigentlich. Also du, du, du kannst die Browser eigentlich bis auf den Opera, mit drei, vier Nachkommastellen füttern. Auch bei so krummen Zahlen. Und dann kriegen die das in der Regel auch gebacken, auch halbwegs pixelgenau das hinzubekommen. Aber das sind eben genau diese Sachen. Das, das Problem ist eben wirklich, dass, du mit Floats arbeitest und denen ist es eben nicht egal, ob ein Pixel zu wenig ist okay, aber ein Pixel zu viel ist halt die Katastrophe.

Ja. Das ist dann immer dieser Effekt. Man macht 'n Border drum und rumms, rutscht das 'ne Spalte nach unten.

Und wenn, wenn du eben die ganzen Sachen, Paddings, Border dort aus dieser Rechnung rausnimmst und sagst, du hast jetzt erst mal nur noch die Breiten, dann, so ist es eben bei mir aufgebaut, dann reicht es wirklich dann einem Container und bei mir ist es eben dann die rechte Seite in der Regel oder es ist an diesen, an diese Klasse, die den, den letzten in der Zeile beschreibt, dann reicht's dort, so 'n kleines Spielchen zu treiben, dort dem ein negatives Margin auf der linken Seite mitzugeben, um zu sagen, in dem Moment, wo sich der Browser irgendwo mal vertut und, in den Nachbarkontainern eins drauf addiert, was er nicht soll, dann hab ich dort, 'ne Pufferzone, dass ich da was überlappen kann, ne.

Das passiert, ja, immer wieder mal. In der Regel sind das so wirklich so ein, zwei Pixel, um die das da mal gehen kann. Und wenn man da so 'nen kleinen Margin vorne setzt, auf einmal wird das Ding stabil.

Und das ist es eben. Und das ist die Situation, die, das ist so geschrieben 2006, als mich der Jens damals mal gesagt hat: „Mach mal.“, und das funktioniert. Das funktioniert bis runter zum IE fünf und seit, da musste man seitdem nie wieder was ersetzen oder neu schreiben oder umschreiben oder anfassen.

Was mich bisher immer gewundert hat, ist, dass das nie irgendein anderer übernommen hat, diese Technik, sondern dass ich eben genau dieses Modell, wie es 960 und, und, und Blueprint und so was aufgesetzt haben, dass das eigentlich bis heute Bestand hat. Also überall dort, wo du flexible Grids siehst, siehst du genau dasselbe Spielchen, ne. Neun Prozent Spaltenbreite plus ein Prozent Rand und dann wird aufaddiert.

Vielleicht sind das, ich glaube immer, dass negative Margins und so was, das sind Sachen, da haben, da gehen manche Leute nicht gerne ran. Keine Ahnung, aber du vermeidest halt auch diesen Ziehharmonika-Effekt, ne, dass du, das hast, wenn, wenn das Grid größer wird, werden natürlich auch die Abstände größer und das passiert bei dir halt nicht, wenn du dann das, Padding der inneren Box zum Beispiel auch in Pixeln definierst. Dann hast du da 'ne gewisse Konsistenz.

Ich find's auch angenehmer so, dass eben wirklich, also gerade bei flexiblen so Sachen, ich kann eben was zusammenschieben, aber mein Weißraum schiebt sich eben nicht im gleichen Maße zusammen, sondern der hält ein Mindestmaß.

Ja, zumal du theoretisch rein rechnerisch, wenn du das Grid immer kleiner machst, ja auch irgendwann die Abstände, also die, das Gutter, ich komme immer noch nicht auf den deutschen Begriff dafür, aber das wird ja auch immer kleiner. Und dann wird das ganze Ding immer unleserlicher, gerade wenn du wie, in Dirks Doku oder in den Beispielen, da ist ja auch relativ viel Text. Das ist ja nicht, dass da irgendwie drei Bilder nebeneinander sind in 'nem Grid, sondern es ist ja immer Text drin.

Das wird ja irgendwann unleserlich, wenn da einfach kein Weißraum mehr vorhanden ist.

Ja. Und man kann eigentlich jetzt erst mal nur hoffen, also wie, was du vorhin, was du vorhin gesagt hast mit den neuen Layout-Varianten, also sei es jetzt Flexbox oder sei es dann irgendwann andere Geschichten, das übernehmen in dem Moment, wo wir wenigstens schon mal das Box Sizing dann irgendwann verwenden können.

Fällt erst mal, fällt erst mal diese Notwendigkeit, diese Schachtelung vorzunehmen und zu sagen, du musst jetzt wirklich Breitendefinitionen und Rand, sonstige Randabstände wirklich elementweise voneinander trennen. Aber vorher wird das eben nicht passieren und das demzufolge, wenn man da ebenso wie wir jetzt gehofft haben, dass der IE sechs jetzt bei einem Prozent ist, werden wir da wahrscheinlich warten müssen, bis der IE acht...

Ist der Achter oder der Sieben, der das-- Ich glaub, der Achter kann's auch noch nie.

Ich, ich will's grad nachgucken. Ich glaube, der Achter kann es, nee, der Achter kann es definitiv noch nicht, weil wie gesagt, Uni Corby's Grid-System benutzt das auch und der weiß extra, der hat extra 'n Artikel irgendwie, wie man IE sechs bis acht ignoriert. Also Box Sizing gibt's erst im Neuner, aaaber es gibt ein Polyfill. Müsste ich jetzt googeln. Ist glaube ich von-

Aber das ist Wahnsinn. Also gerade, es, es, hier von, von Christian Schaefer gibt's 'n Polyfill.

Ja, genau.

Für auch Box Sizing. Der arbeitet mit 'ner HTC. Und das ist ja schön, aber das ist, führt eben auch dazu, gerade flexible Breiten. Das ist eben jedes Mal, wenn du das Browserfenster irgendwie auf und zu oder die Größe machst, rattert das Ding ja dann zwangsweise jeden Container durch.

Und wenn ich das richtig sehe bei Christian im, im GitHub, das ist auch nur für sechs und sieben scheinbar. Also nicht für, ja, definitiv nicht für 'n Achter.

Dann kann's auch sein, dass der Achter das schon kann. Ich weiß es, ich hab's im Moment nicht genau-

Ich hab grade mal nachgeschaut. Ich bin wieder da.

Ja, der Jens.

Das Internet hat mich wieder reingelassen. Ich hab mal grade nachgeschaut. Es gibt doch jetzt seit heute diese hübsche neue Seite, HTML5 please. Und, da kannst du nach Box Sizing gucken und da wird dir auch 'n Polyfill angezeigt oder dann die Unterstützung. Und bei We, bei When Can I Use gibt's den Hinweis, dass der IE ab Version acht das Ganze unterstützt. Das, war, war das nicht eigentlich, das alte Box-Modell? Das Ka-, das falsche vom IE?

Das war das falsche.

Das, das-

Aber das Problem, das Problem ist bei diesem Polyfill-

Das Offizielle.

Das Problem bei diesem Polyfill ist an der Stelle, also der, nicht der Polyfill, das ist das Problem, sondern dass es wirklich, dass man den an einer Stelle braucht, wo ich sage, wenn ich irgendwo das Browserfenster ver-vergrößer oder verkleinere, weiß ich ja, was nicht zu selten vorkommt, sagen wir's mal so, ich dann aber den Browser vor 'ne Situation setze, dass du wirklich mit diesen langsamen JavaScript-Engines, die die Dinger noch haben, dann auch noch jedes Element durchrattern musst.

Also das wäre ein, das würde wahrscheinlich wahnsinnig auf die Performance gehen, wenn das Ding nicht sogar einfriert. Und das ist einfach was, da, da will ich nicht ran. Also da lasse ich einfach die Finger davon und mach für diese alten Browser dann lieber 'n fixes Fallback.

Ist aber 'ne schöne Überleitung, wenn wir jetzt überleiten wollten zum nächsten Punkt im Skript, weil da steht am Ende auch: Wie supportet man IE sechs bis acht? Und das ist dann responsive Design, was du auch eingebaut hast oder- -unterstützt oder wie möchtest du's formulieren?

Ää, unterstützt, eingebaut? Nein. We-weiß nicht, wie man's, wie man's sonst beschreiben sollte, weil, ja, ja, die, die, die, die Beispiel-Layouts, die haben das drin, aber es ist eben, ich versteh's als nichts fest Vorgegebenes.

Also es ist eben nicht so, dass ich sage oder wie die Masse der responsive Frameworks, die es da draußen gibt, funktioniert, dass sie eben sagen: „Okay, bis siebenhundertsechzig Pixel, das sind die Desktop-Auflösungen und alles, was drunter ist, schreiben wir mal den Mobilgeräten zu und, weil wir responsive sein wollen, dann linearisieren wir alle unsere U, unsere Gestaltungsraster und dann sind die weg.

Ich kann mir gut vorstellen und, dass es auch auf 'nem dreihundertzwanzig mal vierhundertachtzig gro, Pixel großen Bildschirm durchaus sinnvoll sein kann, 'n paar Thumbnails von Bildern nebeneinander darzustellen und auch mal was noch ein- oder zwei- oder dreispaltig noch zu bauen. Also dieses zwanghafte alles abschalten und ohne Wiederkehr halte ich für 'n Fehlgriff.

Das beste Beispiel ist ja, wenn du, was weiß ich, zweiunddreißig Pixel Icons hast. Klar, die kann ich auch auf 'n dreihundertzwanzig-Pixel-Bildschirm noch nebeneinander anordnen. Warum nicht?

Genau. Und deswegen hab ich, beim Bau der Seite im Prinzip dann jetzt, 'ne Variante gewählt, dass ich gesagt hab, ich schlage ein System vor, in dem man, über zusätzlich an 'nen, an 'n Grid oder an 'n Spaltenmodul gehangene Klasse dieses einzelne Grid linearisieren kann. Und dem für diese Klasse gibt's halt,, 'n Media Query, was die Eigenschaften definiert, wann das Ding getriggert wird.

Und so hat man eben die Möglichkeit, die Klasse einfach in seinem HTML zu verteilen und die funktioniert dann eben genau an dieser Stelle und macht diesen Umbruch. Und wenn man mehrere Stufen haben will, dann kann man eben aufeinander gestaffelt, diese Klasse mehrfach in verschiedenen Media, Queries definieren und hat dann eben so 'ne Möglichkeit, dass ich 'n Layout stufenweise, und zwar nach selbst festgelegten Stufen linearisieren lassen kann.

Aber ich, die Frage: Wie supportet man IE sechs bis acht? Die hattest du ja auch vor zwei Tagen in Google+ gestellt, ne. Deswegen, das fand ich eben extrem interessant, weil ich, ich bin ja genau denselben Weg gegangen. Ne. Nur du bist, du hast diesen, Mobile-First-Ansatz genommen.

Ich hab das, ja, ja. Das Problem ist halt, wenn du mit Mobile First anfängst, kommst du relativ schnell auf den Trichter, dass du ja 'n Problem kriegst mit IE sechs bis acht, weil die halt keine Media Queries, nativ zumindest unterstützen. Und dann ist halt die Frage: Wie kriegt man das hin?

Weil bei Mobile First fängst du halt von unten an und arbeitest dich nach oben und setzt dabei immer wieder auf einer Mindestbreite basierend Media Queries ein und scheiterst dann eben dabei, dass es in der Mitte, wo man eigentlich den IE sechs bis acht bedienen müsste, nicht greift. Es sei denn halt, du setzt, 'n Media-Query-Polyfill ein.

Ja, oder du machst, in Conditional Comments deine, deinen, dein eigenes, Layout rein.

Ja, IE Style Sheets, das, find ich jetzt nicht mehr so. Also, das find ich 'n bisschen aufwendig. Es gibt ja durchaus so, so JavaScript-Krücken, wobei die, hm, ne, Respond.js gibt es und dieses CSS Media Queries JS, was fürchterlich schlecht dokumentiert ist, aber komischerweise funktioniert. Und Respond.js hat aber anscheinend ziemliche Performance-, -einschränkungen. Das heißt-

Das haben die auch aus Modernizer grad wieder rausgeschmissen, ne? War das deswegen, oder?

Ja, das ist ganz interessant, weil es, in der vorgebauten Version von Modernizer, die im HTML5 Boilerplate 2.0 drin ist, da ist es noch drin. Und, wenn du dann hingehst, was das HTML5 Boilerplate empfiehlt und was auch absolut Sinn macht und machst dir so einen, Custom Build von Modernizer, wo du nur das reinpackst von Modernizer, was du wirklich brauchst, dann stellst du fest, dass der, dieser Builder, den sie auf der Webseite haben, der bedenkt Modernizer gar nicht mehr. Das heißt, du baust-

Respond.js.

Respond.js, genau, danke. Das heißt, du baust im übelsten Fall baust du 'ne Seite, verlässt dich darauf, dass Respond.js da ist, weil's ja in der gebundelten Version enthalten ist. Dann machst du das Ding fertig für 'n, für 'n Live-Server, baust dir so einen, Custom Build und das Ding fliegt dir um die, um die Ohren, weil Respond.js nicht mehr drin ist. Das muss man erst mal merken.

Und ich hab's dann nachgeguckt und es steht tatsächlich im, im Issue Tracker vom Boilerplate steht's drin, dass es, oder von Modernizer steht's drin, dass sie es rausgenommen haben, weil es, irgendeinen da nicht näher definierten Performance-Hit mit sich bringt. Davon war wohl selbst der Scott Jehl, der's, entwickelt hat, 'n bisschen überrascht. Und das ist jetzt 'n bisschen drollig.

Also, ich-

Aber ist das, das Problem tritt doch eigentlich dann nur auf, wenn du, den, diesen Mobile-First-Ansatz wählst, oder?

Ja. Ja, ja klar.

Wenn ich, wenn ich andersrum gehe, dann tritt das Problem eher, eher nicht auf. Und, dann stellt sich für mich sowieso die Frage, warum ich, für, für diese Browser-Imitate, 'ne, 'ne andere Version überhaupt, in, in Betracht ziehen sollte.

Wenn ich das Ganze jetzt, so sehe, dass ich unterschiedliche Versionen für unterschiedliche Medientypen oder Gerätetypen, nur zur Verfügung stelle, dann, also und jetzt nicht so, so krass mache wie Smashing Magazine bei dem, Redesign, wo, wo sie, glaube ich, so gute, 'n gutes Dutzend, unterschiedliche-

Bisschen, bisschen zu viel gewollt, ja.

Ja, ja, das war, war heftig. Hab ich damals, hab ich damals Vitaly auch schon gefragt, ob sie da irgend 'ne, 'ne Wette laufen hatten. Jedenfalls wenn du das nicht so machst, sondern dir einfach nur denkst: Ich optimier das jetzt das Ganze mal so, dass das auch auf Smartphones vernünftig aussieht und auf Tablet-PCs vernünftig aussieht. Du hast ja da zumindest das Glück, dass da nur Browser existieren und keine Internet Explorer.

Ja. Also, das ist auch für mich der Grund gewesen, wo ich sage, in dem Moment, wo du diesen Mobile-First-Ansatz nicht nimmst, stellt sich eben für mich so was wie Respond.js und CSS drei Media Queries, diese an, etwas ältere Variante, deren Daseinsberechtigung ist dann für mich weg. Weil ich's eben nicht brauche. Weil ich sage: Auf Mobilgeräten gibt's diese alten Browser nicht, und auf Desktops kann ich froh sein und glücklich sein.

Und auch sollte es an der Stelle auch der Nutzer, wenn das Layout noch funktioniert. Aber ihm muss ich jetzt nicht diesen Effekt geben, der ihm ja, außer dass es, dass er's sieht, ihm nicht viel bringt, dass ich das Layout bis sonst wohin zusammenschieben kann. Und also ich bin dann eben auch so vorgegangen.

Dann würde ich so sagen: Okay, die Browser, die jetzt wenigstens noch, also IE sieben mit minimaler und maximaler bereiten können, die ver-, und aber mit Media Queries nicht klarkommen, die fallen dann eben auf normales flexibles Layout zurück und bei denen ist halt bei siebenhundertsechzig Pixel oder so oder neunhundertsechzig ist halt Feierabend. Dann ist, das ist die Untergrenze.

Weiter lässt sich nicht zusammenzuschieben und der IE sechs kriegt jetzt halt von mir 'n fixes Layout ausgeliefert. Ne, weil, weil ich eben auch das, was ich bis YAML drei drei eben noch gemacht hab, diese JavaScript Expression damit, zu mit auszuliefern und zu dokumentieren, wie man sie denn generiert, was ja auch ganz furchtbar lesbarer Code ist, einfach sage: Das ist es nicht mehr wert für diese alten Browser.

Die sind wirklich an der Stelle sicherer und besser bedient, wenn man ihnen ein anständiges Fallback auf ein fixes Layout gibt.

Mhm. Aber-

Zumal es-

Ich würd, ich würd trotzdem noch mal gerne betonen, dass das nichts damit zu tun hat, ob ich jetzt nun YAML nutze oder nicht.

Nee, das ist richtig.

Also das, das war ja auch deine Aus-- oder der, der Ausgangspunkt, der Frage oder der, der Diskussion, ob, Dirk das quasi mitliefert. Es gibt ja so, es gibt ja so Frameworks, bei denen, diese, dieser Responsive-Charakter mit eingebaut ist. Und, da kann man ja auch schon, die Frage stellen, ob das überhaupt sinnvoll ist, denn, du wirst nachher ja dann dazu gezwungen, ganz bestimmte, na, Breakpoints mitzunehmen, weil sie dir die vorgeben. Ob du das nun für gut hältst oder nicht.

Und, es ist aber, ich, eigentlich geht diese Technik doch ein bisschen über ein normales Framework hinaus. Jedenfalls sehe ich das so. Weil das, du, du wendest da ja das, das Framework dann wieder, bisschen erweitert an. Und, Dirk hatte dann offensichtlich für sich entschieden, dass er da keine, keine Sachen mitliefert, die, die, die fest eingebaut sind, wo dann nachher sicherlich die Antworten kommen: „Oh, ich hätt aber gerne folgende Breakpoints.", und, genauso wie bei den Grids, ne.

Er hätte jetzt auch ganz viele unterschiedliche Grids nachbauen können.

Nee, das Albe bei diesen festen Breakpoints ist ja, dass sie-- Wa-was machen sie jetzt? Im Moment, gibt's grad, iPads und 'n paar Android-Tablets mit 'ner tausendvierundzwanzig Auflösung. Also ist irgendwo im Moment siebenhundertachtundsechzig und tausendvierundzwanzig irgendwie 'ne magische Grenze.

Richtig. In drei Jahren gibt's die nicht mehr.

In drei Jahren. Was ist denn in drei Monaten, wenn das iPad wirklich mit der doppelten Auflösung kommt?

Dann haben wir 'n Problem, ja. Das Tolle ist ja vor allen Dingen, es gibt diese, von Andy Clark, glaub ich, diese Vorlage für, für, -

Dreihundertzwanzig ab.

Ja, und das-- Nee, die nicht, sondern 'ne andere, irgendwie Hardboiled Media Queries oder so muss das heißen.

Ja, ja.

Das Ding ist, dass die ansetzen und sagen, also die fragen praktisch die Breite und die Höhe des Gerätes ab. Der, der Effekt daran ist, dass du feststellst, dass das zum Beispiel seine Vorgaben, die funktionieren auf iPhones, die funktionieren vermutlich auf iPads, aber sie funktionieren nicht auf Android-Telefonen.

Na ja, für ihn existiert halt kein Android.

Das kann ich aber, also abgesehen davon, dass ich selber Android-Nutzer bin, kann ich das nicht von 'nem Profi so nicht ernst nehmen. Du kannst keine Breakpoints vorgeben. Du musst immer gucken: Wie funktioniert mein Design? Funktioniert das bis dahin?

Es macht keinen großen Sinn. Deswegen find ich's zum Beispiel gut, dass Dirk so was, als Beispiel liefert. Man kann daran die Technik, die Anwendung der Technik lernen und man kann sich dann sein eigenes Bild, machen. Das ist halt 'n bisschen aufwendiger, als einfach nur zu sagen: „Ich nehme mir jetzt Framework XY, werfe das auf meinen Code und dann funktioniert das." Sondern du musst halt selber denken. Und-

Also das Einzige, was, was ich noch verstanden hätte, das haben wir aber auch vorab schon mal besprochen, wäre, wenn Dirk jetzt gesagt hätte: „Ich pack noch hier diese, diesen kleinen Trick für die Navigation rein." Navigation ist ja immer schwierig auf kleinen Bildschirmen oder auf, in linearisierten Layouts. Und da gibt's dann diese, diese Lösung von Chris Coyier, aber da hattest du vorher schon gesagt, da bist du einfach nicht zu gekommen, oder?

Nee, ich hab ja, sowieso für die Navigation oben, JavaScript geschrieben, um die so schön sticky zu machen und dass die mitläuft. Das Einzige, was mir jetzt noch fehlt, was ich noch selber schreiben wollte: Ich wollte sie noch dahingehend erweitern, dass sie genau das macht, dass sie eben auf, kleinen Bildschirmen ist es im Moment so, dass ich, also auf, auf 'nem Telefon wird sie quasi nicht sticky, damit sie nämlich nicht, in-

Den halben Bildschirm dicht macht.

In voller epischer Breite dann in drei Zeilen umbricht, und damit nichts mehr sichtbar ist, sondern dass wirklich oben hängt. Man wählt einmal und springt dahin, wo man hinwill. Und ich wollt's eben noch einbauen, dass sie dann eben wirklich, aber eben nicht so wie dort in diesem Beispiel, wa, was du jetzt hier verlinkt hast. Dort musst du ja quasi das, die, die Menüpunkte doppelt wieder mal anlegen.

Ja, also der nimmt praktisch die, der holt sich die Menüpunkte per JavaScript und schmeißt die in 'ne, in 'ne Select-Box.

Na, das sieht aber so aus, als ob du die Select-Box quasi im Code schon mit anlegen musst. Der macht sie nur sichtbar. Ich wollt's eben dann wirklich so schreiben, dass ich die Select-Box dynamisch generiere.

Coyier legt, glaub ich, die Select-Box an und schiebt dann über JavaScript die, -

Ah, okay.

Die einzelnen drei.

Er hat oben so 'n Beispiel gemacht, dass man beides macht und später sagt er: „Nee, nee, also das bilden wir doch mit jQuery dann nach", oder was, wie auch immer er das macht da.

Also so 'n Schnipsel wollte ich mir noch mal schreiben und in dem Moment, wo er fertig ist, könnte man ihn, könnte ich ihn eigentlich auch, der, der, der normalen horizontalen Navigation mit dazulegen, dass man ihn einfach benutzen kann.

Aber wie gesagt, ich mein, YAML ist, ja, ist 'n Modul. Kannst du modulartig einsetzen als Baukasten und dementsprechend kannst du dir ja selber noch deine Sachen hinzufügen, halt wie du willst.

Ja, es ist ja auch grade wie gesagt mit jQuery. Es ist ja auch nicht so schwer.

Nicht wirklich, ne. Ja. Ja, wie sieht denn das mit Updates in Zukunft aus? Wird es da so kleine Updates geben, grade wenn du gesagt hast, dazu kamst du nicht und du machst noch was und, da müsste man nur 'n Mo-Modul austauschen. Wie geht's denn bei YAML weiter?

. Für mich ist jetzt, sind's eigentlich nur noch kleine Sachen, die ich im Moment vorhabe, noch mit dazu zu fügen. Ich hab hier grad schon stehen Sass, Less und Stylus. Darüber wollten wir noch mal sprechen. Das ist ja auch im letzten Jahr massiv hochgekommen, diese ganzen Preprozessoren.

Gibt eigentlich kaum noch irgendwie Frameworks, die nicht gleich auch noch eine Sass- und eine Less-Version zumindest mit dabei haben.

Ja, und ich hab mich-- Also eine ganze Weile habe ich mich dagegen komplett gesträubt, weil das schon für den Nicht-Hardcore-Entwickler, Frontend-Entwickler, 'ne Umstellung ist. So wie eben nicht jeder ein Build-Skript bedienen kann, hat eben auch nicht jeder einfach mal so 'n Less oder Sass Compiler bei sich installiert und lauffähig. Das schränkt aus meiner Sicht schon ein bisschen die Nutzerbasis ein.

Und dann ist natürlich auch immer die Frage, wenn ich sage, ich hab 'n Framework Kern, da steht das drin, was ich immer brauche. Ja, weiß, wo zum Teufel, warum soll ich's modularisieren? Mittlerweile bin ich aber so 'n bisschen auf zumindest schon mal auf dem Standpunkt, dass ich auf alle Fälle Vorteile sehe, beispielsweise bei der Typografie. Da hat's dann doch relativ viel Mühe gemacht, diese ganzen Elemente da auf diesen vertical rhythm zu, zu trimmen.

Und das ist definitiv 'ne Situ-- 'ne Sache, wo es eigentlich sehr schön wäre, wenn man oben da drei Variablen hat für Schriftgröße, Abstand und, noch, noch kleine andere Dinge, und das sich einfach durchrechnen lassen kann.

Wie ist denn das? Das hatte, glaube ich, auch schon jemand neulich gefragt, das, ganze YAML-Ding, ob du das auf GitHub stellen würdest und dann Mitarbeit aus der Community praktisch annehmen würdest. Ich könnte verstehen, wenn du sagst: „Uh, da hab ich 'n bisschen Bauchweh mit“, aber hast du so was vor?

Ja und nein. Also Bauchweh in dem Sinne hatte ich vor ganz langer Zeit. Ist ja auch einer der Gründe, warum das Projekt ursprünglich eben nicht als in, in einer so freien Lizenz erschienen ist, weil ich eben wirklich, auch damals selber gesagt hab, da will ich die Hand draufhalten, was damit passiert.

Was GitHub betrifft, ist es 'ne sehr schöne Sache, die ich mittlerweile selber sehr genieße, dass du wirklich Projekte einfach verfolgen kannst, forken kannst und damit immer einfach nur per Knopfdruck updaten kannst. Und das würde ich mir für YAML auch wünschen. Deswegen, ich überlege es auch. Entweder wird's, im Moment pflege ich's mit 'nem SVN, aber auch mit so 'ner Uralt-Installation im Web mit so 'nem SVN und Track, die, mit der ich nicht glücklich bin.

Also entweder wird's über kurz oder lang irgend so 'n Web-SVN-Ansatz geben oder ich schieb das ganze Projekt zu Git, zu GitHub. Da es jetzt nicht, keine klassische Open-Source-Lizenz ist, ist es einfach nur für mich so, dass ich dann halt, dass es halt was kostet für seinen Privataccount dann, aber das ist eigentlich nicht, nicht der Rede wert.

Das Schöne, was ich eben finde, ist, dass du das Projekt wirklich dort oben haben kannst und eben nicht ständig auf der Webseite vorbeikommen musst, um zu gucken, ob ich ein neues Bild generiert hab-... was man runterlädt, sondern einfach, beim, Mac ich unter Tower einfach draufgehen kann auf das Projekt und ich sehe, ob's ein Update gibt und einfach nur sage: „Okay, dann zieh mir mal die aktuellen Dateien.“

Spannend wär vielleicht auch dann könnte das jemand, der jetzt irgendwie sagt: „Mensch, ich bin Sass-Experte oder Less-Experte oder Stylus. Könnte es forken, ne? Und du könntest-

Das Zweite ist eben, dass es 'n, 'n klassischen oder dass es einen Weg gibt, der auch bekannt und akzeptiert ist, wie man Bugs, Bug-Meldungen liefert, wie man, Ergänzungsvorschläge an mich herantragen kann. Das läuft ja im Moment jetzt auch oder seit vielen Jahren per E-Mail. Liegt aber auch da dran, dass ich eigentlich, auf 'ne mehr oder weniger Handvoll von wirklich treuen, Vertrauten zurückgreifen kann.

So Leute wie Jens und, Thomas Caspars, Ansgar Heyn, die mich seit Jahren immer wieder unterstützen, wenn's beispielsweise Sachen um Barrierefreiheit geht. Mit Jens hab ich, über die ganzen Jahre immer wieder die YAML-Struktur selber durchgesprochen und durchdiskutiert, bis wir 'ne Form hatten, die uns beiden halbwegs gepasst hat, wo ich sage, ich hab mein Feedback.

Ich glaub, es immer noch nicht.

Ne?

Also ich habe über die Jahre immer das Feedback von, von, aktiven Entwicklern gehabt, aber es war eben, es war jetzt nicht die Masse an Leuten, die da reagiert haben, aber es sind Leute, die seit Anfang an mehr oder weniger das Projekt kennen, auch selber nutzen, zu denen ich auch ein großes Vertrauen habe, dass, die Richtung, in die es geht, in die ich, einerseits, wenn ich irgendwo hinrenne, dass ich auch ein recht, gutes Feedback bekomme, ob ich damit richtig liege oder ob ich gegen eine Wand renne.

Genauso gut, dass eben auch die entsprechenden Vorschläge, die kommen, schon recht gut geeicht sind in die Richtung, in die das Projekt eigentlich seit Jahren marschiert. Ne? Und das ist 'ne angenehme Situation. Wie ob sich das jetzt erweitert und ob da jetzt viele Leute drauf anspringen, weil's eben nicht, unter GPL steht, wenn ich's jetzt bei GitHub poste, das würde ich offenlassen und mich drüber freuen, wenn da Feedback kommt.

Mir würde es das Leben erleichtern, weil ich eben wieder einen Schritt weniger hab, dass ich quasi ständig da, Zips von Hand bauen muss, wenn ich irgendwo, 'n, da 'n Typo wegmache, ne. Sondern ich kann mein Projekt eigentlich über, über Git, ich könnt es dann kontinuierlich pflegen. Wenn's 'ne größere Änderung gibt, dann wird meine neue Versionsnummer dokumentiert. Ansonsten kann eben jeder sich zu jeder Zeit den aktuellen Stand einfach ziehen.

Was ich generell für, für so 'ne Projekte auch, damit man sie besser in seinen eigenen Workflow integrieren kann, mittlerweile als sehr sinnvoll erachte. Also das denke mal, wird im nächsten Viertel, halben Jahr werd ich das denke ich mal angehen.

Spannende Aussichten auf jeden Fall.

Jetzt sag mal, ist einer von euch dreien eigentlich überhaupt so Nutzer von Sass oder Less oder so 'n ähnlichen Preprozessor?

Ich benutze Sass in erster Linie, weil ich für, also haben wir vorher auch schon drüber gesprochen, der technische Unterschied ist ja minimal, da tun die sich nicht viel funktional. Ich benutze halt Sass, weil das in meinem Workflow, in meinem System besser zu integrieren war. Die anderen beiden laufen auf Node JS und das krieg ich hier nicht so richtig, da bin ich irgendwie zu doof zu.

Ja, nee, das, das ist ja auch, reine Geschmackssache, glaube ich. Was ich so an Syntax, Unterschieden zwischen Less und Sass gesehen habe, ist das ja-

Minimal.

Nur ich, ich hab mich jetzt die ganze Zeit, ich, ich hab so viele Artikel darüber gelesen. Ich hab auch schon einmal drei Minuten, damit rumgespielt mit Sass so in etwa und hab mich dann aber jedes Mal, wenn ich, die Beispiele gelesen habe, gefragt, was ich damit überhaupt soll, wenn, wenn ich doch 'n Framework nutze.

Da finde ich immer wieder sehr, sehr erheiternd die Beispiele, wo dann, wo dann jemand den, den Clearfix-Hack an, an irgendein Element dran tackert oder an irgendeine Klasse dran tackert.

Ja, das ist, das-

Dann hast du das, dann hast du das vielleicht fünf oder zehnmal in deinem, in deinem CSS drin, anstatt dass man einfach die Clearfix-Klasse dann ins HTML reinschreibt.

Das ist so 'n Punkt, da hat dann jemand, ohne dass es jetzt zu weit führen soll, aber da hat dann jemand Sass nicht, nicht verstanden.

Ja, also ich für mich ist Sass eigentlich nur noch in der, eigentlich nur noch in, in, in der, in Nutzbarkeit übrig, um Farben zu verwalten.

Nee, es ist, es gibt-

Das kann man glaube ich auch anders machen.

Es gibt schon nette Dinge, die auch, für YAML vielleicht interessant wären, dass man eben zum Beispiel die ganzen Module, die Dirk da drin hat, die, wo Dirk schon sagte, die benutzt wahrscheinlich nicht jeder. Beispielsweise, fällt mir jetzt spontan nichts ein, aber früher hatte Dirk ja diese vorgegebenen Navigationsbeispiele mit, Shiny, Shiny Buttons und Sliding Doors. Und das sind ja Sachen, wo du sagst, die benutzt nicht jeder und die muss dann im Prinzip jeder rein- oder rauskopieren.

Die kannst du halt mit Sass, du hättest sie dann in deinen Sass-Dateien, aber sie werden in das CSS, was Sass dann erzeugt, nur eingebunden, wenn du sie auch wirklich benutzt. Das ist ganz praktisch.

Da würde ich mir auch Snippets bauen.

Das kannst du. Die Frage ist, ob Snippets, das ist ja wieder 'ne Frage des Werkzeugs. Klar, das ist, das ist für jemand, der sagt-

Ich bin permanent panisch auf der Suche da-dabei, wie, wie ich mir meine, mein, meine Arbeit erleichtern und verbessern kann, weißt du? Ich hab jetzt letztens, wieder so 'n, so 'ne, Sache gethemed, 'n Theme gemacht oder also Themes angeboten, und, musste dabei feststellen, dass so die, die Art, wie ich die letzten Jahre die Seiten aufgebaut habe, dafür einfach unpraktisch ist.

Das hat dann nichts mehr mit YAML oder mit, so was zu tun, sondern eher wie, wie benennt man Klassen, wie benennt man IDs oder hauptsächlich Klassen. Und da, da hilft mir auch Sass nicht unbedingt weiter. Wenn ich nachher fünfzehn Klassen habe, die alle das Gleiche tun, dann ist das egal, ob ich's mit Sass mache oder ohne, ohne Sass mache, ist das unpraktisch. Ich hab so den Eindruck, dass, dass Sass mich eher dabei unterstützen würde, aus den fünfzehn Klassen dreißig zu machen.

Und deswegen fand ich das gra, hat mich das bislang noch nicht so richtig, angesprochen, aber vielleicht muss ich's einfach mal testen.

Ich habe wie fast jeder, glaube ich, der jemals irgendeinen Preprozessor probiert hat, ich hab zwei oder drei Anläufe gebraucht. Das ist was, was einem nicht sofort anspringt. Was ich, empfehle, das ist nicht direkt Sass, sondern das ist Compass, was 'ne Erweiterung für Sass ist, die auch in weiten Teilen man nicht braucht. Da gibt's tolle Sachen, zum Beispiel mit, CSS Sprites.

Gibt's 'ne hervorragende, hervorragendes Beispiel in den Videos zur letztjährigen Frontiers-Konferenz von, oh Gott, ich kann mir ihren Namen immer nicht merken, Divya-

Manian.

Divya Manian. Die demonstriert da eben, wie du mit, mit Compass CSS Sprites generierst. Und das ist so unglaublich simpel. Es funktioniert ohne ein Grafikprogramm. Das ist 'n guter Punkt, um Leute z-zu locken und zu sagen: „Guck dir das mal an, das ist toll."

Okay, dann-

Es ist halt, es ist halt nichts, was sich irgendwie einem an einem Nachmittag unbedingt erschließt und man braucht auch manchmal zwei Anläufe und man sollte sich unbedingt auch Less angucken und Stylish angucken, weil wie gesagt, funktional unterscheiden die sich kaum.

Aber du hast ja eben gerade schon den Grund genannt, warum Dirk, das Ganze noch nicht, drauf portiert hat und warum das es wahrscheinlich auch niemals eine nur reine Preprozessoren-Version geben wird, weil das einfach nicht massentauglich ist.

Das weiß ich nicht, ob das so ist. Es ist sicherlich nichts für den, für den Feuerwehrverein, der seine mit Joomla betriebene Webseite auf YAML aufbauen möchte. Das soll jetzt nicht um Gottes willen, ne, alle Feuerwehrvereine der Welt gerne, aber-

Wer die Zeit hat, sich damit zu befassen, kann ich nur sagen: Macht das. Es spart echt 'ne Menge Zeit und Arbeit.

Ja, den Link dazu, auch zu den Sprite Generators, schreiben wir da noch rein. Jetzt, was schreibt der Dirk uns jetzt?

Dirk hat zerhackten Empfang.

Ich denke, ich denke, dann, sind wir auch am Ende der Sendung angelangt. YAML, das Ganze findet sich natürlich auf yaml.de. Auch die Links zu den Sachen, die wir besprochen haben, packen wir auf Technikwürze.de. Da hätten wir ganz gerne noch eure Kommentare, ob ihr YAML schon nutzt, ob ihr euch freut jetzt wie gesagt auf die neue Version vier. Gerne dürft ihr das auch kommentieren. Und in diesem Sinne sag ich auf jeden Fall, erst mal danke natürlich an unseren Sponsor Mittwald noch mal.

Wer Webhosting, Managed Server oder Schulungen zu TYPO3, Magento, HTML, CSS und PHP braucht, guckt mal bitte auf mittwald.de oder auf die Blogs von Dirk Jesse. Vielen Dank, dass du dabei warst.

Vielen Dank an euch. Hat richtig Spaß gemacht.

Find ich auch. Matthias Mehls, das erste Mal in der Technikwürze.

Ja, danke für die Einladung. Viel Spaß war's.

Sehr gerne. Angenehme Stimme. Und Jens Grochtdreis. Ja, schönen Dank, dass ich mal wieder nur ein paar Minuten dabei sein durfte. Vielen Dank an meinen Sponsor 1&1 für die schlechte Verbindung. Damit hätten wir auch alle Sponsoren abgedeckt. Ich bedanke mich natürlich auch bei euch Zuschauern. Hinterlasst uns gerne Kommentare. Ansonsten hören wir uns demnächst wieder, wenn es wieder heißt, da gibt's eine neue Technikwürze. Bis dahin, ciao, ciao.

Mehr Qualität im Webdesign durch Webstandards. Tipps und Tricks zur Umsetzung findet ihr bei den Webkrauts auf Webkrauts.de. Für ein besseres Web. Weitere Informationen und die Links zur Sendung auf Technikwürze.de