Gegen Ende letzten Jahres gab es einen lustigen kleinen Trend, bei dem Unternehmen ihre Herangehensweise an CSS veröffentlichten. Die beteiligten Tools, die Methodiken, das Denken und die Daten und Zahlen dahinter. Mark Otto hat ihn, soweit ich das beurteilen kann, ins Rollen gebracht. Ich wollte einfach nur eine Liste davon hier posten, da dies perfektes Futter für CSS-Tricks ist. Ich habe es am Ende in eine Tabelle mit ein paar leicht vergleichbaren Daten gepackt, nur zum Spaß.
Unternehmen:
Github
Preprocessor:
SCSS
Prefixing:
Benutzerdefinierte @mixins
# Quelldateien
100+
# Selektoren
7,000
Stil-Durchsetzung:
SCSS-lint, styleguide
Notizen:
2 fertige Stylesheets, wegen der IE-Selektorengrenze
Unternehmen:
Buffer
Preprocessor:
LESS
Prefixing:
Autoprefixer
# Quelldateien
93
# Selektoren
5328
Stil-Durchsetzung:
LESS lint
Notizen:
2 fertige Stylesheets
Unternehmen:
CodePen
Preprocessor:
SCSS
Prefixing:
Autoprefixer
# Quelldateien
171
# Selektoren
1186
Stil-Durchsetzung:
.editorconfig
Notizen:
Asset pipeline
Unternehmen:
Ghost
Preprocessor:
SCSS (libsass)
Prefixing:
Autoprefixer
# Quelldateien
36
# Selektoren
1609
Stil-Durchsetzung:
Allgemeine Richtlinien
Notizen:
Open Source
Unternehmen:
Groupon
Preprocessor:
Sass (Syntax unklar)
Prefixing:
Compass
# Quelldateien
?
# Selektoren
?
Stil-Durchsetzung:
SMACSS
Notizen:
Toolstrap
Unternehmen:
Lonely Planet
Preprocessor:
Sass
Prefixing:
Autoprefixer
# Quelldateien
150+
# Selektoren
1527
Stil-Durchsetzung:
Rizzo, kein Linting
Notizen:
BEM / OOCSS, Normalize.css, SVG-Icons
Unternehmen:
Medium
Preprocessor:
LESS
Prefixing:
Benutzerdefinierte @mixins
# Quelldateien
50-100
# Selektoren
?
Stil-Durchsetzung:
Richtlinien
Notizen:
Kein Verschachteln, benutzerdefinierte Methodik für Benennung
Unternehmen:
Trello
Preprocessor:
LESS
Prefixing:
Benutzerdefinierte @mixins
# Quelldateien
44
# Selektoren
2,426
Stil-Durchsetzung:
Preprocessor
Notizen:
1 fertiges Stylesheet, Namespacing
Ein weiteres sehr gängiges Thema: Klassenpräfixe .js- zum Trennen von JavaScript- und Styling-Hooks.
Außerdem habe ich versucht, diese Tabelle responsiv zu machen...
Ich wollte, dass sie
- Bei genügend Platz wie eine normale Tabelle aussieht.
- Auf kleinen Bildschirmen zu Blöcken zusammenklappt.
- Auch ohne jegliches CSS funktioniert (E-Mails, RSS)
Hier sind die Ergebnisse

Der Ursprung des Konzepts war, mit "normalen" HTML-Elementen (section, div, p, span) zu beginnen und sie zu zwingen, sich wie eine Tabelle zu verhalten. Ich habe die Dinge etwas anders benannt, aber man könnte einfach Hilfsklassen verwenden.
.table { display: table }
.tr { display: table-row }
.thead { display: table-header-group }
.tbody { display: table-row-group }
.tfoot { display: table-footer-group }
.col { display: table-column }
.colgroup { display: table-column-group }
.td, .th { display: table-cell }
.caption { display: table-caption }
Dann, bei einer bestimmten Media Query, zwingt man sie zurück in ihren normalen Zustand.
@media (max-width: 700px) {
.table { display: block }
.tr { display: block }
.thead { display: block }
.tbody { display: block }
.tfoot { display: block }
.col { display: none }
.colgroup { display: none }
.td, .th { display: inline-block }
.caption { display: block }
}
Aber das alles ergibt nur wirklich seltsam aussehende Sätze, also habe ich eine Menge <br>-Tags gemischt, um sie nach Bedarf zu beabstanden, die per CSS ausgeblendet werden. Ich habe auch ein <span> verwendet, um jede Zelle zu betiteln, ebenfalls per CSS ausgeblendet, sodass man, wenn kein CSS vorhanden ist, diesen Titel für jeden Datenpunkt sieht.
Das ist redundant und unordentlich. Verschlimmert wird es durch die Notwendigkeit, es in WordPress einzubinden, wo das Auto-p-Verhalten zusätzliche Absätze hinzufügt, auf die man achten muss. Ich habe das Ganze in einem Pen gemacht, dann hier das HTML komprimiert.
Für jeden Fall, in dem ich responsive Tabellen verwenden musste, habe ich sie normalerweise mit ganz anderen Elementen erstellt. Das ist ein wirklich schöner Ansatz, den du verfolgt hast. Du solltest das vielleicht als Beitrag zum Styling responsiver Tabellen isolieren.
Ja, ich habe genau dasselbe gemacht. Zwei Elemente auf einer Seite zu platzieren und sie nach Bedarf ein- und auszublenden ist für mich kein Showstopper.
Ich kann mir nicht viele Situationen vorstellen, in denen das der Fall wäre... denn wenn du eine Tabelle anzeigst, die so groß ist, dass sie das Rendern der Seite beeinträchtigt, solltest du vielleicht überdenken, wie du deine Daten lädst. Vielleicht gibt es mehr Nachteile bei diesem Ansatz, als ich erkenne, aber ich habe noch keine Beschwerden von Benutzern darüber gehört.
Ich habe mir gerade den Quelltext der Seite angesehen und festgestellt, dass dies auch nicht mit Tabellenelementen gemacht wurde.
Ich bin neugierig zu erfahren, warum du "normale" Elemente (section, div, p, span) verwendet und sie bei einem bestimmten Breakpoint wie eine Tabelle verhalten lassen hast? Da es sich um tabellarische Daten handelt, wäre ein Tabellenelement nicht sinnvoller? Du kannst dieselbe Media Query verwenden, um die thead-, tbody-, th-, td-, tr-Elemente für kleinere Bildschirme als Block festzulegen.
Mir ist bewusst, dass das das gleiche Ergebnis ist, aber
<span class="th">erscheint mir ein wenig verrückt. :)Ich muss dem zustimmen... Ich denke, die Verwendung des entsprechenden semantischen Elements wäre in diesem Fall der bessere Ansatz... und dann CSS oder JSS zu verwenden, um das Layout des Inhalts für kleinere Geräte zu ändern...
Ich bevorzuge generell auch den Ansatz "Table first". Aber siehe den dritten Punkt. Es muss auch ohne CSS funktionieren. Eine Tabelle funktioniert immer noch, aber es gibt eine 100%ige Chance, dass sie das Format der E-Mail, die aus diesem Blogbeitrag gesendet wird, verfälscht. Und wer weiß, was durch die RSS-Reader der Leute kommt. Dies war nur eine Herausforderung an mich selbst, mit HTML zu beginnen, das in diesen Situationen völlig resilient ist, aber dennoch das gewünschte Format für den Standard-Desktop-Benutzer auf meiner eigenen Website hat.
+1 für einen Artikel über das Styling responsiver Tabellen (falls es noch keinen gibt). Das ist etwas, mit dem ich mich in letzter Zeit viel beschäftigt habe, indem ich versucht habe, viele Daten in einem responsiven Layout zu kommunizieren, und das Ergebnis war nicht unähnlich dem, was du dort hast. Außer dass ich eine tatsächliche
<table>verwendet habe, denn schließlich sind es tabellarische Daten, die als Tabelle angezeigt werden.Chris, die "Tabelle" sah in Feedlys Darstellung des Feeds etwas unsinnig aus.
Schade. Screenshot?
Chris, hier ist ein Screenshot [tinypic] des Feedly-Tabellen-Renderings.
Genau das habe ich mir erhofft! Gut beabstandet, lesbar, bricht das Layout nicht.
Feedly auf dem Desktop auch.
Relevanter Screenshot: http://i.imgur.com/4O1tCEQ.png
Ich habe diese Beiträge so sehr genossen, dass ich sie in einem GitHub-Repo gesammelt habe. Sieht so aus, als hätte ich den Ghost-Beitrag verpasst. Ich denke, es gibt ein paar auf meiner Liste, die du auch verpasst hast. Prost...
Danke @chriscoyier für diesen Kommentar, warum du native Blöcke/Inline-Block-Elemente verwendet hast.
Ich wollte gerade sagen, dass ich lieber
<
table> in diesem Fall verwende.
Schließlich bin ich deiner Meinung bezüglich E-Mails. Ich habe nicht einmal an RSS gedacht...
Das ist hier der Mobile-First-Ansatz.
Das zusätzliche CSS ist nur auf großen Bildschirmen nützlich, was gut ist, weil wir die Website-Größe bei Netzwerken mit geringer Bandbreite nicht überladen wollen.
Ich empfehle dir auch diese CSS-Umfrage, die @LeaVerou auf Twitter geteilt hat: https://twitter.com/LeaVerou/status/555859362670202880
Ein bisschen ein Mashup eines Beitrags, aber wirklich gute Informationen über die verschiedenen CSS-Ansätze.
Das ist vielleicht eine dumme Frage, aber was meinst du, wenn du sagst "finale Stylesheets"? Googeln dieses Begriffs hat nichts Relevantes ergeben.
Das bedeutet, dass sie am Ende, nach all der Vorverarbeitung, ein oder zwei finale CSS-Dateien erhalten. Github teilt ihre in zwei Dateien auf, wegen der Selektorengrenze von IE.
Und das ist es auch schon, da die meisten von ihnen Less oder Sass verwenden, teilen sie ihre Stile in verschiedene relevante Dateien auf, um etwas Struktur hinzuzufügen.
Danke Rodrigo – das ergibt Sinn. Ich denke, ich habe diesen Ausdruck überanalysiert.
Hallo Chris! Schöne Liste dort und eine gut aussehende Tabelle. Ich gebe mein Bestes, um heutzutage alle Tabellen zu vermeiden, sie sind so ein Pain.
Und übrigens, ich habe auch über CSS-Strukturen geschrieben (für Noodles) :)
Ich verstehe die Verwendung von
<br>in der responsiven Tabelle nicht. Könntest du das näher erläutern?Br-Tags werden für manuelle Zeilenumbrüche zwischen Wörtern verwendet.
Buzzfeed hat auch einen Artikel gemacht: http://www.buzzfeed.com/erakor/i-am-all-about-that-sass#.yqq2Dxwne (
Wirklich schönes Experiment mit den HTML-Tabellen! Ich wollte schon immer ein Tabellensystem, das dynamisch ist und sich leicht an kleine Bildschirme anpassen und gelesen werden kann, und das ist es, wonach ich gesucht habe! Mein Problem ist, dass meine Website derzeit ein veraltetes System für die Gestaltung von Inhalten für alle Bildschirmgrößen verwendet. Ich habe @media only screen für die Gestaltung von Inhalten für kleinere Bildschirme verwendet, obwohl ich dies für Basisstile verwenden sollte, die nichts mit der Breite usw. zu tun haben, und Media Queries für die Änderung von Layout und Größe verwenden sollte. Dein CSS hat mir meinen Fehler verstehen lassen, also danke, Chris.
Hallo! Warum ist es bei einigen Unternehmen unmöglich, Selektoren zu zählen?
Freundlicher manueller Trackback: http://meiert.com/en/blog/20150122/deterioration-of-practices/.
Die No-CSS-Anforderung ist ein Nachteil, es gibt so schöne Möglichkeiten mit
:afterundattr(), die den Bedarf an vielen solchen Dingen reduzieren könnten.Für reines HTML würde ich es vielleicht in etwas Semantischeres umwandeln wie
pro Zelle, und dann alle dt's in der Tabellenanzeige ausblenden (außer natürlich der obersten Zeile). Das könnte helfen, die Brüche und zusätzlichen Klassen loszuwerden, denke ich, und würde auch ohne CSS gut formatiert werden.
Bei meinen Tabellen stieß ich auf einige Reihenfolgeprobleme (z.B. wenn die linkeste Spalte nicht zuerst in responsiver Darstellung erscheinen soll). Und ich weiß immer noch nicht, ob ein Element (Zeile) in einer solchen Liste als
<article>oder<section>oder<div>gekennzeichnet werden sollte.Btw, interessante Aggregation von CSS-Workflows.