Luke Underwood schrieb mit einer interessanten Frage
Was sind die Best Practices für das Standard-Styling von `<table>`?
Ich denke, es gibt drei Möglichkeiten
- Standardstile haben
- Nicht
- Irgendwo dazwischen
Luke erläutert
Unser Büro ist gespalten. In unseren Basisschablonen werden derzeit keine Stile standardmäßig auf Tabellen angewendet. Sie benötigen eine Klasse, um sie gut aussehen zu lassen (mit Rahmen, Hintergrundfarben usw.). Wir verwenden diese Klasse hauptsächlich für Tabellen, die in Hauptinhaltsbereichen verwendet werden.
Wir Frontend-Entwickler haben entschieden, dass dies am besten ist, da wir so benutzerdefinierte Tabellen einfach gestalten können, ohne Standardstile überschreiben zu müssen. Dazu gehört auch das Überschreiben von Media Queries, die den Abstand auf kleineren Bildschirmen reduzieren, was lästig wäre. Wir denken auch, dass es wichtig wäre, einen Selektor für diese Inhaltstabellen zu haben, falls wir JavaScript-Lösungen wie responsive Tabellen-Plugins implementieren müssen.
Die Backend-Programmierer sind ständig frustriert darüber, dass sie nicht einfach „eine Tabelle auf eine Seite werfen“ können, ohne dass sie gut aussieht, und bestehen darauf, dass Standard-Tabellenstile der richtige Weg sind. Anscheinend kann es schwierig sein, jeder Tabelle eine einfache Klasse hinzuzufügen, und sie denken, wir sollten uns darum kümmern, zusätzlichen CSS-Code zu schreiben, um dies zu umgehen.
Zusammenfassend
Vorteile von Standardstilen
- Sie können einfach „eine Tabelle“ in den HTML-Code einfügen und sie gut aussehen lassen
Vorteile der Anforderung einer Klasse
- Sie können mehrere Tabellenstile haben, ohne gegen die Standardwerte kämpfen zu müssen
- Sie benötigen möglicherweise den Selektor, um diese bestimmten Tabellen zu finden
Ich würde ein paar weitere Überlegungen hinzufügen.
Was ist der Kontext?
Eine ist, über den Kontext nachzudenken. Werden diese Tabellen als Inhalt gespeichert und angezeigt? Wie in Artikeln, Dokumentationen usw. Ich bleibe gerne so klassenfrei wie möglich im Inhalt. Ich finde, Klassen halten nicht so lange wie Inhalte. Eines Tages ist Ihr `.striped-table { }` vielleicht kein Ding mehr und Tabellen kehren zu einem stilosen Zustand zurück, der unbeabsichtigt ist. Standardstile würden Sie davor bewahren.
Vielleicht werden Ihre Inhalte in Markdown gespeichert, was ich für langlebige Inhalte sehr empfehle. Markdown bietet Ihnen nicht einmal eine großartige Möglichkeit, einer Tabelle eine Klasse zuzuweisen, also ist das eine Überlegung.
Ist Scoping eine Möglichkeit?
Eine weitere Überlegung ist das Scoping. Vielleicht können Sie *global* Standardstile vermeiden, aber Stile, die offensichtlich innerhalb von Inhaltsbereichen liegen, haben diese.
/* Scoped styles to articles */
article,
.this-is-content-or-whatever {
table {
}
th, td {
}
}
Ähnlich wie bei Opt-in-Typografie.
Sind leichte Standardstile eine Möglichkeit?
Zusätzlich zu den typischen Benutzeragenten-Stylesheets tragen diese erheblich dazu bei, dass eine Tabelle präsentabel aussieht
table {
border-collapse: collapse;
}
tr {
border-bottom: 1px solid #ccc;
}
th, td {
text-align: left;
padding: 4px;
}
Das ist nicht viel, womit man im Falle benutzerdefinierter Tabellenklassen kämpfen müsste.
Was machen andere Seiten?
Luke hat recherchiert! Danke Luke.
| Website | Standard-Tabellenstile? |
|---|---|
| Mozilla | Nein |
| MDN | Nein |
| CSS Tricks | Ja |
| Wikipedia | Nein |
| Nein | |
| eEbay | Nein |
| Smashing Magazine | Nein |
| Awwwards | Nein |
| Nein | |
| jQuery | Ja |
| Modernizr | Nein |
| GitHub | Nein |
| W3C | Nein |
| CodePen | Nein |
| InvisionApp | Nein |
| Apple | Nein |
| Yahoo | Nein |
| Amazon | Nein |
| PayPal | Nein |
| NetFlix | Nein |
| DropBox | Nein |
| StackOverflow | Nein |
| CNN | Nein |
| Microsoft | Nein |
| Gumtree | Nein |
| Nein | |
| News.com.au | Nein |
| Bureau of Meteorology | Nein |
| ABC | Nein |
| RealEstate.com.au | Nein |
| Tumblr | Nein |
| IMDB | Nein |
| Seek | Nein |
| Commonwealth Bank | Nein |
| ANZ | Ja |
| The Verge | Nein |
| BBC | Nein |
| SA Gov | Nein |
| MailChimp | Nein |
| Adobe | Ja |
| Telstra | Nein |
| Target | Ja |
| JB Hi-fi | Nein |
Es scheint beliebt zu sein, keine Standard-Tabellenstile zu verwenden.
Was ist mit Resets?
Der beliebteste Reset tut es
table, caption, tbody, tfoot, thead, tr, th, td {
margin: 0;
padding: 0;
border: 0;
font-size: 100%;
font: inherit;
vertical-align: baseline;
}
table {
border-collapse: collapse;
border-spacing: 0;
}
Das erscheint mir ein wenig übertrieben.
Normalize rührt sie nicht an, was viel aussagt. Das bedeutet, dass es keine wesentlichen Unterschiede (oder gar keine?) gibt, wie Standardtabellen browserübergreifend gerendert werden, also gibt es nicht viel zu befürchten.
Was ist mit den großen Frameworks?
- Bootstrap berührt die Standardstile für Tabellen kaum, bietet aber `.table`, `.table-striped` und eine Handvoll anderer, zu denen Sie sich anmelden können.
- Foundation stylt Standardtabellen von Anfang an.
50/50 Spaltung.
Gedanken
Persönlich neige ich dazu, Standardstile für Tabellen zu haben, zumindest in Bereichen, die auf Inhalte beschränkt sind. Ich verwende Tabellen nur für tabellarische Daten und benötige nicht viele Variationen, wie diese tabellarischen Daten präsentiert werden. Selbst wenn ich das täte, wäre es keine besonders schwierige Aufgabe, einige Variationsklassen zu erstellen.
Bei jedem Projekt wird es einen Punkt geben, an dem Sie eine Tabelle verwenden müssen, ohne oder mit minimalem Styling. Es ist viel schwieriger, diese Stile rückgängig zu machen, als eine Klasse hinzuzufügen – das habe ich auf die harte Tour gelernt, wir verwenden jetzt .presentation-table und presentation-table–zebra :)
Persönlich denke ich, dass das Überschreiben von Browser-berechneten Stilen und das Aufbauen von Stilen mit kontextbezogenen Klassen die sicherere Option für Tabellen in großen Webanwendungen ist. Es ist ziemlich selten, dass ein bestimmter Tabellenstil für alle Tabellen ausreicht.
Die Lösung ist ziemlich selbsterklärend, sobald man darüber nachdenkt.
Außerdem, falls jemand wirklich wirklich auf diesen Standardstilen aufbauen möchte
Na gut, wir werden extra-rücksichtsvoll sein, aber wenn Ihre App leere `class`-Attribute ausgibt, sollten Sie professionelle Hilfe suchen. :p
Dies ist definitiv der flexibelste Ansatz, und ich war bereit, ihn vorzuschlagen, aber Sie waren schneller als ich! Ich mag auch die Idee einer „Default Plus“-Klassenoption.
Ich habe Ihren Vorschlag hier geliebt… Ich mag die Idee, einen Standardstil zu haben, würde ihn aber später nur ungern überschreiben. Daher ist die Verwendung dieses Ansatzes definitiv etwas, das ich in Betracht ziehen kann… danke
Was ist, wenn Sie eine Tabelle wollen, die nicht ähnlich genug zu Ihrem `.default_style` ist, um sie zu rechtfertigen, aber Sie wollen sie stylen – das beinhaltet unweigerlich das Hinzufügen einer Klasse, die dann den Standardstil anwendet, den Sie dann rückgängig machen müssen (gleiches Problem wie die Anwendung von Standard) oder eine weitere Ausnahme zur Regel hinzufügen.
9 von 10 Mal rächt sich Cleverness in CSS. KISS.
@Brendan Ich bin mir nicht sicher, was Sie meinen. Könnten Sie ein Beispiel mit Code posten?
Ich denke, es ist besser, eine Opt-out-Klasse zu verwenden, anstatt Standardstile nur auf Tabellen ohne *irgendeine* Klasse anzuwenden. Das bedeutet, diese Klasse nur zu Tabellen hinzuzufügen, die keine normale Formatierung benötigen. Es bedeutet auch, dass Sie nie Stile schreiben müssen, die die Standardstile aufheben, Sie fügen die Undefault-Klasse hinzu.
Wenn Sie die Standardstile minimalistisch halten, sollte diese Klasse eine seltene Ausnahme sein.
Standard-Tabellenklasse (.table). Ich weiß, dass es technisch kein Standard ist, aber es ist trivial hinzuzufügen oder für benutzerdefinierte Stile wegzulassen. Es ist auch weniger aufdringlich als ein harter CSS-Reset, der mir langsam lästig wird.
Ich bin ganz für die Scoping-Option. Wir setzen Stile global zurück und stylen dann die meisten Präsentationselemente (Tabellen, ULs, OLs usw.) basierend auf Inhaltsbereichen, über die ein Kunde die Kontrolle hat. Zum Beispiel fügen wir für jeden Bereich, in den ein Kunde Inhalte über ein WYSIWYG-Feld einfügen kann, entweder eine Klasse oder ein Datenattribut hinzu und stylen darauf aufbauend.
Die Verwendung eines Datenattributs hilft, die Spezifität etwas zu reduzieren, sodass es später leichter zu überschreiben ist, falls erforderlich.
Unser WYSIWYG-Editor ermöglicht die Einfügung von Tabellen, entfernt aber alle Klassen, die wir nicht wollen – daher sind Standard-Tabellenklassen unerlässlich.
Ich denke, Sie sollten in der Lage sein, jedes Element überall auf einer Website ohne Klassen zu verwenden, und es sollte zum Rest der Website passen. Das schließt alle Typografie und jedes HTML-Element ein, das vom CMS aus zugänglich ist.
Ich würde definitiv eine `reset`-Regel verwenden und dann eine spezifische `class` für die Tabellen selbst. Viele Male musste ich unterschiedliche Tabellenstile innerhalb derselben Website/Web-App verwenden, und das Überschreiben von Standardstilen ist nichts Praktisches.
Warum nicht den :not-Selektor verwenden und Standardstile für alle Tabellen festlegen, die nicht die Klasse table enthalten, zum Beispiel.
Wir haben Standard-Tabellenstile.
Da wir eine staatliche Behörde sind, haben wir eine riesige Website mit vielen Datentabellen. Konsistenz (und Zugänglichkeit) ist uns sehr wichtig, daher wollen wir keine Menge benutzerdefinierter Tabellen. Und wir möchten leicht erkennbare Tabellen identifizieren können, die nicht richtig codiert wurden.
Das Schlimmste ist, wenn man versucht, einen Drittanbieter-Service zu branden. Es haut mich um, wie viele dieser Dienste Tabellen für das Layout verwenden – und das schlecht. Für einige ist jede Kopfzeile eine Tabelle.
Wie wäre es mit einem Hybridansatz? Verwenden Sie eine Klasse für Tabellenstile und mischen Sie sie dann für editorbasierte Inhaltsbereiche ein
Das ist keine direkte Lösung für das Problem, aber das ist mir beim Lesen des Problems wirklich aufgefallen
Warum das Backend aus der Markup-Gleichung entfernen? Dazu gibt es eine Vielzahl von Template-Engines oder Frameworks für eine Vielzahl von Sprachen, die Ihnen helfen können, Präsentation/Markup von den Daten zu trennen. So können Sie und die Backend-Entwickler sich auf das konzentrieren, was Sie am besten können.
Ich habe keine Ahnung, wie Ihr Tech-Stack aussieht, um zu wissen, ob dies für Sie eine Möglichkeit ist. Aber wenn ich Sie wäre, würde ich nach einigen Daten-APIs suchen :)
Viel Erfolg, Luke!
Vielen Dank für das Teilen dieser Informationen. Ich habe über dasselbe Problem nachgedacht, das sich auf normalize.css und sanitize.css bezieht. Auch die aktuelle (zum Zeitpunkt der Erstellung) stabile Version von normalize.css setzt Tabellen zurück, aber dies war ein meinungsbildender Reset (und Browser behandeln die Standard-Tabellenstile konsistent), weshalb er entfernt wurde und in der 4x-Version so sein wird.
Ich verwende in über 90 % meiner Projekte Standardstile für meine Tabellen. Kunden und generell Leute, die die Seite nutzen und Inhalte eingeben, wissen oft nicht, wie sie Dinge richtig machen. Das also für sie zu tun, ist das Hauptproblem hier. Und nicht nur das, sondern ich verwende oft jQuery, um die Tabellen-Responsivität zu zähmen, denn wenn ein Benutzer z.B. eine 12-Spalten-Tabelle erstellt, wird es sehr unübersichtlich :-)
Ich verwende normalize und dann verschiedene Klassen (z.B. `.Table–thin`, `.Table–wide` usw.) für verschiedene Tabellenstile. Diese Gewohnheit stammt aus einem früheren Projekt, bei dem wir viele verschiedene Tabellenstile mit separaten Anforderungen hatten. Das Vermeiden eines gestylten Standards ermöglichte eine einfachere Verwaltung der separaten Stile, weniger Überschreibungen, weniger Verwirrung rundherum.
Ich bin dafür, das Root-Tabellen-CSS sauber zu halten. Wo es angebracht ist, versuche ich, die Verbreitung von untergeordneten CSS-Klassen zu vermeiden, die Kenntnis ihrer übergeordneten Elemente erfordern.
Nicht nur das Überstylen des Root-Tabellenelements macht es schwierig zu überschreiben (wie erwähnt), sondern es macht auch das *Ändern* des Stylings dieses Root-Tabellenelements zu einem späteren Zeitpunkt schwieriger, was meiner Meinung nach ein noch größeres Problem darstellt. Wenn Sie zum Beispiel irgendwann abwechselnde Zeilenfarben zu Ihrem Standard-Tabellen-Styling hinzufügen möchten. Jetzt müssen Sie nicht nur eine Klasse aktualisieren, sondern auch die Website durchgehen und sicherstellen, dass das Hinzufügen von `&:nth-row(2) { … }` keine der Überschreibungen kaputt gemacht hat. Bei bestimmten größeren und verteilteren Projekten wird dies zu einer Belastung, insbesondere wenn ein Entwickler neu im Projekt ist und insbesondere wenn das CSS auf mehreren Codebasen wiederverwendet wird.