Mangels Themen zockten sich Hans, Schepp und Peter durch vier Runden CSS-Glücksrad. Nachdem sie dort keine großen Erfolge feiern konnten, verlasen sie die Links und ließen es gut sein.
HTML5-Glücksrad
- [00:00:50] CSS Conditionals
- Eine Spezifikation aus der Abteilung CSS-Fundament, zu deren Unterpunkt @media-Syntax uns nicht viel einfiel. Schepp erklärte das only-Keyword in Media Queries und am Ende schweiften wir in Richtung Cargo-Cult-Techniken in CSS und JS ab.
- [00:07:27] CSS Marquee
- Marquee in CSS? Gibt es weder auf Caniuse noch in MDN noch, wie wir feststellen mussten, in irgendeinem Browser. Über mögliche Use Cases dachten wir trotzdem ein wenig nach.
- [00:13:59] CSS Transforms
- CSS-Transforms kann man über bequeme Funktionen, aber auch über Transformationsmatrizen festlegen. Wir stellten fest, dass wir diese Möglichkeit bisher eher selten nutzen, was daran liegt, dass wir eher selten CSS-Transformationen durch Code errechnen lassen (dann dafür wären sie gut geeignet). Ein weiteres interessantes Detail ist, dass das CSS OM beim Abfragen von Transformationen immer mit Matrizen antwortet. Schließlich schweifen wir in Richtung skew-Transforms ab (die Schepp mal für Schatteneffekte brauchte) und reden über die Auswirkungen von Transforms auf den Stacking Context (die es auch bei opacity geben soll).
- [00:27:00] CSS Selectors Level 4
- Nachdem Peter ein wenig über :empty in Selectors Level 3 (kaputt) und :blank in Selectors Level 4 (nicht kaputt) gerantet hatte, versuchten wir ohne großen Erfolg das Wesen der Grid-Structural Selectors zu erraten. Mehr Erfolg haben wir bei den Themen Parent Selector, :last-child und den technischen (Performance-)Probleme dahinter. Zum Schluss erklärte Peter nochmal kurz, warum es kein CSS4 gibt und wir stellten erfreut fest, dass die Kombinatoren
+
und~
selbst im IE7 funktionieren.
[00:41:40] Keine Schaunotizen
- Popping Out of Hidden Overflow
- Beschreibt einen interessanten Edge Case bei der Arbeit mit Overflows in CSS.
- Custom CSS preprocessing
- Wie man sein eigenes kleines CSS-Tool baut.
- codefest.herzogtumcleve.de
- Ein aus rheinischer Solidarität gespeister Tipp von Schepp.
- Lesser-Known JavaScript Debugging Techniques
- Besonders interessant: die DebugUtils.
- Stylestats
- Produziert interessante Statistiken zu Stylesheets.
Kommentare
Franky #
Geschrieben am 26.03.2014 um 18:32
von wegen :blank und :empty und dem ganzen „mimimi, das is jetzt ewig im browser“-rant: wär halt echt mal zeit dass CSS elemente explizit als deprecated erklärt und dann auch die browsern und IDEs diese attribute wie deprecated-funktionen z.b. warnungen produzieren und durchstreichen und was auch immer.
Peter #
Geschrieben am 26.03.2014 um 18:48
Also ich glaube nicht dass das groß helfen würde. An
:empty
sind ja nun die Webentwickler am wenigsten Schuld.Franky #
Geschrieben am 27.03.2014 um 08:32
Das hat ja keiner behauptet, aber es würde dem „hm, was soll ich verwenden“ vorbeugen, wenns in der IDE bereits angestrichen wird als deprecated. Ich bin ja auch nicht „schuld“ wenn z.B. in Java oder .Net Library-Funktionen (oder ganze Klassen) deprecated werden, aber es hilft mir dass ich die Dinger nicht mehr verwende wenn ich etwas neues schreibe.
Deprecated bedeutet ja nicht dass es nicht mehr geht, sondern soll nur den Entwickler hinweisen dass er gerade etwas verwendet was wegen diversen Gründen eigentlich nicht so toll ist. Und ne Warnung im browser-devtool-log tut ja echt niemandem weh außer dem Entwickler der eben dort reinschaut um zu erfahren was man denn alles subideal und/oder falsch macht.
Mal ne komplett andere Frage: könntet ihr vielleicht einmal eine Folge machen wie ihr euer Testing betreibt? Also vor Allem Automatisierung und Regression Testing und so? Wurde nämlich vor einiger Zeit aus meiner angenehmen Services-Welt gerissen und darf mich jetzt als Tester mit einer AngularJS App beschäftigen (noch dazu mobil … oh the joy *vomit*)
Peter #
Geschrieben am 29.03.2014 um 09:56
Naja, aber am Ende wirst du dann einfach des Nutzens der falschen IDE schuldig sein :) Weil selbst wenn man es hinbekommen würde, 50% der für Webentwicklung verwendeten IDEs und Editoren dieses Feature einzubauen (wobei ich nicht weiß, wie man das durchsetzen sollte) und dieses Feature dann auch einheitlich zu halten, kann man ja immer noch eine IDE ohne dieses Feature nutzen. Also ich glaube nicht dass man diese Schlacht gewinnen könnte.
Das mit dem Testing habe ich als Themenvorschlag ins Trello geschrieben.
Marius #
Geschrieben am 30.03.2014 um 18:16
Ich finde diese Diskussion ohnehin etwas seltsam, bzw. die Unterscheidung der beiden Fälle gar nicht so unsinnig.
Es werden halt zwei Stati abgefragt. Zum einen ein wirklich leeres Element und zum anderen ein Element ohne Inhalt. Und beide Fälle per CSS individuell ansprechen zu können kann doch recht praktisch sein.
Peter #
Geschrieben am 30.03.2014 um 18:19
Nenne mir einen Use Case für
:empty
, für den:blank
nicht taugt.Marius #
Geschrieben am 31.03.2014 um 13:28
Nehmen wir an, du hast einen Container mit dickem, schwarzem Border.
Darin sind X Elemente mit definierter Ausdehnung und jeweils einem Backgrund(-Image).
Wenn der Container leer ist, will man natürlich keinen Border haben.
Im Fall von :blank würde der Border nicht angezeigt
Im Fall von :empty würde der Border solange angezeigt, bis kein inneres Element mehr vorhanden ist.
Peter #
Geschrieben am 31.03.2014 um 17:24
Genau! Deshalb ist
:empty nutzloser Ranz und nur
:blank
wirklich brauchbar :)Marius #
Geschrieben am 31.03.2014 um 17:44
ehm.. nee. ;)
Ich könnte mir Fälle vorstellen, in denen man eben eine Verschachtelung von [Container] + [Kind-Elementen ohne Inhalt aber mit Background(-Image)] hat, man aber den Container so lange mit einem Border, einer festen Höhe, etc. versehen möchte, bis es kein Kind-Element mehr gibt. In diesem Fall würde :blank ja nicht greifen, da von Anfang an kein Textinhalt vorhanden war.
Peter #
Geschrieben am 31.03.2014 um 17:59
Elemente zu Designzwecken?
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.