Habe nie ganz verstanden, warum gerade grids so viel besser als Tabellen sein sollen. Überall tauchen nun im Quellcode css classen auf, die nicht den Inhalt oder dessen Bedeutung entsprechen, sondern eine reine Layoutfunktion haben.
Das hatte mich auch verwirrt, als ich eine Seite mit einem Gridsystem (Bootstrap) erstellen sollte. Mit LESS ( siehe http://lesscss.org/ ) kann man aber Inhalt und Design wieder trennen. Erst das Ausgelieferte CSS für das Endprodukt wird compiliert, und sieht dann weider unübersichtlich aus. Beim Entwickeln kann man mit Sprechenden css Klassen arbeiten und diesen dann erst Designelemente zuordnen. Man kann da nämlich auch css Klassen innerhalb von Klassen benutzen.(genannt Mixin) LESS bietet auch die Möglichkeit Variablen oder Funktionen zu nutzen.
Ich kann Less oder SASS oder sonnst eine Erweiterung zu CSS nur empfehlen.
content
@black = #FFFFFFFF;
.info{ font-weight: normal; font-style: normal; }
.infobox{ .info color: @black; }
Auch wenn es sich wie billige Werbung anhört. Ich kann Less oder SASS oder sonnst eine Erweiterung zu CSS nur empfehlen.
Sie haben Wörter oder Phrasen verwendet, die die Vermutung nahe legen, dass es sich bei Ihrer Meldung um eine automatische Werbeaussage (Spam) handeln könnte. Wir möchten Sie deshalb bitten zu Validierungszwecken das unten stehende Kontrollwort einzugeben.
Ja, Less / Sass sind sehr nützlich, können aber schnell zu unschönen CSS Code führen, welcher auch den Browser leicht ausbremsen kann. Muss man alles mit Augenmaß einsetzen.
Als Entwickler muss man ja sich ja gerade nicht mehr mit dem Kompilat herumschlagen, nur der Sourcecode ist wichtig zum Entwickeln. Was habe ich da für einen Nachteil, wenn das CSS unleserlich wird, wenn ich mit LESS wunderschönen Dateien habe?
An den Speedverlust durch unoptimiertes CSS hatte ich noch gar nicht gedacht. Ist das wirklich ein Problem? Gibt es Seiten ,welche wegen mülligem CSS ausgebremst werden?
Das javascript eine Seite Verlangsamen kann kenne ich ja aber mit dis CSS war bei mir noch nie ein Problemfaktor.
"An den Speedverlust durch unoptimiertes CSS hatte ich noch gar nicht gedacht. Ist das wirklich ein Problem? Gibt es Seiten ,welche wegen mülligem CSS ausgebremst werden?"
Bei meinen Entwicklungen sind mir durchaus Nachteile mit großen CSS Dateien begegnet. Zum einen bezüglich der Ladezeit - auch komprimiert sind sie teils recht groß bei komplexen Seiten - zum anderen durch verlangsamtes Seitenrendering, vor allem wenn die Seite selbst viele Elemente enthält.
Es muss einem immer klar sein: Auch ein Browser kann nicht zauber. Weniger ist immer besser
Aber natürlich sprechen wir da von wirklich großen Seiten, bei alles unter ein paar tausend HTML-Elementen und CSS Dateien von wenigen KB gibts keine Probleme.
Generell ist das auch nichts, was sich mit SASS/LESS nicht auch lösen lässt, man muss nur aufpassen. Beide blasen die CSS Datei gerne mal gehörig auf, deutlich über dem, was man händisch machen würde fürs gleiche Ziel. Das kann durchaus die Seite langsamer machen. Aber das ist wie gesagt erst ab einer gewissen Größe ein Problem, und ein Aufsplitten kann da helfen. Aber man muss eben auch daran denken, SASS/LESS sind auch keine Zauberlösungen :) (Wobei aufsplitten wieder andere Probleme bringt)
Ist technisch betrachtet noch eine Trennung Da man aber all diese Design Elemente in den Inhaltsteil ( html ) reinschreibt, hat man trotzdem wieder eine vermischung aus Inhalt und Design.
Mit LESS kann mann dann wieder so trennen, dass man auch merkt, dass Inhalt und Design getrennt sind.
Ich muss dann im CSS alle Eigenschaften von allen Klassen von Hand kopieren. Habe ich mehrerer Button Klassen oder Mehrere Klassen, .Red verwenden, kenne ich keine Möglichkeit Redundanter Code zu verhindern. Das ganze wird also unübersichtlicher Fehleranfälliger schwerer zu warten oder zu erweitern...
Bedenke dabei, dass die Klasse .Red auch irgendwas verrücktes mit einem Verlauf und Browserweichen beinhalten könnte und nicht nur color: red; setzen muss.
Das angesprochen Bootstrap nutzt ähnlich Klassennamen Sie heissen da class="btn btn-primary btn-large"
siehe http://getbootstrap.com/2.3.2/
AFAIK wurde Twitter damit erstellt. Zusammen mit LESS taugt Bootstrap durchaus was.
Ich muss dann im CSS alle Eigenschaften von allen Klassen von Hand kopieren. Habe ich mehrerer Button Klassen oder Mehrere Klassen, .Red verwenden, kenne ich keine Möglichkeit Redundanter Code zu verhindern.
Das lese ich oft, ist aber totaler Quatsch. Selektoren sind keine IDs, du darfst sie so oft verwenden wie du möchtest und genau so kannst du dir auch doppelten Code sparen und die Regeln sinnvoll zusammenfassen. Dafür braucht es kein Sass oder Less, im Gegenteil, der von Sass und Less generierte Code ist oft unnötig redundant. (Klassen nach dem Aussehen zu benennen ist übrigens ganz schlechter Stil, ändert sich das Aussehen ist der Name falsch und irreführend.)
Ich habe grundsätzlich nichts gegen CSS-Frameworks (auch wenn ich sie nicht nutze, ich halte den Code lieber schlank) und auch CSS-Präprozessoren find ich durchaus interessant, leider kennen viele nicht einmal die Möglichkeiten von CSS selbst und begeben sich viel zu blauäugig in Abhängigkeiten die sie weder brauchen noch wirklich ausnutzen.
1) Darstellung der Seite: Mit Tabellen baut man ein statisches Layout. So kann man zwar einfach "sauber" ausrichten, aber es funktioniert nur solange der User sich an deine Vorgaben hält ("optimiert für IE6 @ 1024x768). Sobald man Browser welchselt, auf verschiedenen Geräten darstellen will, andere Schriften installiert sind, man "Strg +/-" verwendet, ... sind diese Layouts kaputt/hässlich/unpraktisch. Sofern es der Entwickler richtig macht skaliert ein CSS Design dynamisch über ein breites Spektrum an Browsern und Bildschrimen. Durch die Angabe verschiedener CSS Files kann man das Layout gänzlich verändern.
In Zeiten von Smartphones und Tablets ist das wichtiger denn je.
2) Inhalt und Bedeutung werden sehr wohl getrennt. Die CSS Klassen sind nur Attribute an einem Inhaltlich strukturiertem Dokument. Für den Menschen der sich den Sourcecode aus der Ferne ansieht mag das auch nicht sauber aussehen. Doch spätestens wenn man versucht Informationen automatisiert zu parsen merkt man wie große die Unterschiede sind. Mit einem CSS Design bekommt man flache, stabile Strukturen. Table Designs sind i.d.R tiefe Verschachtelung inhaltlich unnötiger Tags, welche sich mit jeder kleinen Design Änderung wieder verändern.
Beides setzt natürlich vorraus dass der Entwickler weiß was er tut. CSS ist auch nur ein Werkzeug, welches man auf die schlimmsten Arten missbrauchen kann.
Sofern es der Entwickler richtig macht ... .. Beides setzt natürlich vorraus dass der Entwickler weiß was er tut.
Ich finde es mittlerweile normal das Schrift über Schrift/Grafik liegt und Teile von Webseiten aussehen wie hingeschmiert. Scheinen nicht so viele mit zurechtzukommen.
Tatsächlich passen sich viele alte Tablet-Designs den Auflösungen weit besser an, die zumeist festen Breiten (wie auch hier) sind eher ein fader Kompromiss, keine echte Lösung. Echte Lösungen entwickeln sich erst mit aktuellen CSS Versionen und in Verbindung mit JS, vorher gab es viele Nachteile und Probleme mit dynamischen Anpassugnen auch in CSS, weswegen fast alel Webseiten weste Pixelbreiten nutzen. Das war und ist nicht modern, CSS hin oder her!
Nur mal ein Hinweis: Pro-Linux nutzt Tabellen... ;) Und, ist das jetzt so schlimm? geht die Welt davon unter? Ich kenne tausende ohne Tabellen, die keinen deut flexibler sind. Gerade Seiten mit Spaltenlayouts sind selten wirklich flexibel. Es gibt Lösungen die es können, viele aber nicht.
Zur Trennung von Inhalt und Bedeutung: Dies ist hier wie gesagt nicht der Fall. Ob ich nun oder schreibe macht kaum einen Unterschied. Solange das div nur dafür da ist, dieses eine Tag zu tragen, und nur für das Layout existiert, ist es beides nicht sauber. Die hier vorgestellte Lösung macht nichts besser, sie macht es nur anders. Sie ist auch nicht sauberer zu parsen, noch immer finden sich völlig nutzlose Tags im Design.
Hier geht es wohlgemerkt nicht um die Frage: CSS ja oder nein, mir geht es um Lösungen wie die vorgestellte.
Es gibt viele tolle Lösungen mit CSS und ganz ohne Tabellen, aber diese hier ist keine solche. Den sie hat leider eben genau die unnötigen Tags, die man eigentlich vermeiden will.
Von asdfghjkl am Di, 17. September 2013 um 13:57 #
Das ist viel, viel, viel, besser! Der wichtigste Vorteil: Linearität: Die Inhalte können in der semantisch korrekten Reihenfolge im Dokument stehen, völlig unabhängig vom Layout (wichtig z.B. für Barrierefreiheit oder Responsive Layout für Mobilgeräte). Mit Tabellen ist das nicht machbar.
"In der »Sturm und Drang«-Zeit des Webs wurden mehrspaltige Layouts gerne mit Tabellen realisiert – was heute zurecht als verpönt gilt."
Ja, ich habe auch schon lange damit aufgehört, mehrspaltige Layouts etc. mit Tabellen zu realisieren, weil es ebenso lange schon einhellige Meinung ist, dass man so etwas nicht macht. Begriffen habe ich es aber bis jetzt noch nicht. Auch Seiten, die ich früher mit Tabellen gemacht habe, laufen heute noch perfekt. Ein paar Firmen haben die - wenn ich mich nicht irre - fast schon 10 Jahre drin. Die Seiten werden nur inhaltlich gepflegt: Minimalaufwand. Sie laden sehr schnell und sie nützen den ganzen Bildschirm aus. Weshalb sind Tabellen schlecht, wenn alle damit zufrieden sind?
Von divdividv am Do, 12. September 2013 um 17:56 #
Leute die Screenreader benutzen sind scheinbar nicht zufrieden damit. Wenn man das Web automatisch auswerten möchte, ist man dankbar, wenn Design und Inhalt getrennt werden. Ausserdem ist man dann dankbar, wenn Dinge Sematisch korrekt beschrieben werden.
PS: man kann auch mit divs Seiten machen, welche den gesamten Bildschirm nützen und sehr schnell laden.
Ja, ich verwende ja auch DIVs für eine bildschirmfüllende Darstellung und wenn man sauberen einfachen Code schreibt, sind die zumindest genau so schnell wie Tabellen-Seiten. So gravierend finde ich den Unterschied aber nicht.
Am schlimmsten sind eigentlich nur die Seiten, die mit CMS erzeugt wurden. Die sind von handgeschriebenen sauberen Tabellen- oder DIV-Seite meilenweit entfernt.
CSS und Tabellen sind kein Widerspruch. Es geht eher um die Verwendung von DIVs oder Tabellen FÜR DEN SELBEN ZWECK. Tabellen werden ja nicht kritisiert, wenn sie für tabellarische Inhalte verwendet werden.
... und noch etwas: Ich werde mehr und mehr zum Purist. Ich möchte es überspitzt und vielleicht etwas provokativ ausdrücken: Die schönsten Seiten brauchen nicht mehr, als dieses Prinzip:
Tabellen dienen dazu Inhalte in einer bestimmten organisierten Form wieder zu geben. Richtig gemacht haben damit auch schreenreader damit keine Probleme.
Beim Design wird aber nicht nur eine Tabelle verwendet. Oft kamen mehrere ineinander Verschachtelte Tabellen zum Einsatz. Weder für einen screenreader, noch für einen Roboter ist erkennbar wo was der eigentliche Inhalt ist. Die Navigation innerhalb solcher Konstrukte ist mittels screenreadern umständlich.
Tabellen sind ein starres Design, der Inhalt der Seite muss entsprechend dargestellt werden. Das ist vorallem bei Browsern auf kleineren Displays schwierig.
divs lassen sich dynamisch positionieren. Zur Not bricht der Browser das Design und kann die divs umorganisieren. Der Inhalt bleibt weiterhin nutzbar. Durch bewusste Bezeichnung der divs können Inhalt und Navigation eindeutig getrennt werden, was der Barrierefreiheit und auch den Robotern von Suchmaschinen dient.
Früher konnten die Seiten mittels div auch einiges code einsparen. Mittlerweile dank javascript-frameworks und fetter css aber kein argument mehr.
CSS und javascript bieten in zwischen eine Vielzahl an funktionalität, die man mit Tabellen kaum umsetzen kann.
Wenn Tabellen für Inhalte verwendet werden, deren sinnvollste Darstellungsmöglichkeit die Tabellenform ist, sind Tabellen völlig in Ordnung. Für alles andere gibt es semantisch bessere Methoden.
Lass dir mal eine Designtabelle von einem Screenreader vorlesen …
Der Html Beispiel ist nicht gerade vorbildlich. H2 aber kein H1 Titel ist sonderbar und nicht barrierefrei. Ich habe mir einige css Dateien angeschaut und war auch entsetzt, Form Elemente sind in der reset*.css nicht enthalten. Die Zeichengröße ist zu gering usw. Die Idee die im Modell steckt ist zwar gut. die Ausführung aber ungenügend.
Das sehe ich auch so, das HTML ist nicht optimal, vor allem sowas macht man nicht:
<div class="clear"></div>
Dafür gibt es Easy-Clearing ganz ohne den HTML-Code mit sinnlosen leeren Elementen zu verschmutzen.
Die CSS-Dateien überzeugen mich auch nicht, besonders schlecht ist die Angabe der Schriftgröße in Pixeln, da sollte man unbedingt zu em oder % greifen. Überhaupt wüsste ich nicht warum man alles in Pixeln festzimmern muss, auch für Spaltenbreiten bietet sich eher Prozent an.
Die Pixelitis ist einer weit verbreitete Krankheit, davon wird auch in WCAG abgeraten. EM, EX und % sind vorzuziehen, dies kann aber zu kleine Probleme führen, die aber in der Regel leicht lösbar sind. Für meinen Teil sind Pixelangaben verpönt.
Zumindest in der Vorgängerversion konnte ich das auf 16 Spalten anpassen. Das "responsive Webdesign" ist ein sehr grosser vorteil von Bootstrap gegebnüber 960.gs Die Smartphones werden nämlich nicht weniger.
Auch die Benutzung von Less bietet enorme Vorteile.
Falls man .js einsetzen mag, bietet Bootstrap auch da noch weitere Möglichkeiten. Wenn man nicht nur eine minimalistische Website für den PC herstellen möchte, gibt es imho interessantere Lösungen als 960.gs
Na toll -- Layout mit Tabellen ist also "zurecht verpönt" (obwohl man viele Layouts mit Tabellen sehr viel sauberer hinbekommt als mit den sonst notwendigen CSS-Hacks), "pixelgenaues Layout", das z.B. die Schriftgrößeneinstellung des Browsers ignoriert aber anscheinend nicht.
Klar, in vielen Fällen sind CSS eindeutig besser geeignet als Tabellen; in anderen Fällen -- insbesondere bei robusten mehrspaltigen Layouts -- ist es aber genau andersrum. Die diversen "mehrspaltigen CSS"-Hacks, die im Internet kursieren, sollte man meiden, da sie meist nur so halb oder nur mit bestimmten Browsern funktionieren. Und ich habe noch nichts gesehen, was Tabellen hier das Wasser reichen könnte.
Ebenso würde ich empfehlen, Layouts und Systeme, die versuchen, pixelgenau zu sein (wie das angegebene), zu meiden. Es ist durchaus sinnvoll, dass man im Browser eine Standardschriftgröße einstellen kann -- diese wird aber vom 960-Grid-System komplett ignoriert. Verstellt man sie doch -- oder verwendet man einen Browser, der den Webseitenzoom anders implementiert, geht die Seite gnadenlos kaputt. Überlappende Texte, nicht-sichtbare Texte, kaputte Navigationsleisten usw. sind die Folge...
Und viel Spaß beim Betrachten einer 960-Grid-System-Seite mit einem 800x480 Display oder noch kleinerer Auflösung...
Na toll -- Layout mit Tabellen ist also "zurecht verpönt" (obwohl man viele Layouts mit Tabellen sehr viel sauberer hinbekommt als mit den sonst notwendigen CSS-Hacks), "pixelgenaues Layout", das z.B. die Schriftgrößeneinstellung des Browsers ignoriert aber anscheinend nicht.
Ganz genau, sie sind zu Recht verpönt, da die Verwendung zu Layoutzwecken nicht semantisch ist. Nur weil es Leute gibt die leider Pixel für Schriftgrößen verwenden, rechtfertigt das den eigenen Murks noch lange nicht.
Klar, in vielen Fällen sind CSS eindeutig besser geeignet als Tabellen; in anderen Fällen -- insbesondere bei robusten mehrspaltigen Layouts -- ist es aber genau andersrum
In allen Fällen (außer es handelt sich tatsächlich um tabellarische Daten) ist CSS besser geeignet, denn es wurde genau für den Zweck geschaffen, das Aussehen zu bestimmen.
Die diversen "mehrspaltigen CSS"-Hacks, die im Internet kursieren, sollte man meiden, da sie meist nur so halb oder nur mit bestimmten Browsern funktionieren. Und ich habe noch nichts gesehen, was Tabellen hier das Wasser reichen könnte.
Man braucht überhaupt keine Hacks um Elemente nebeneinander zu positionieren und CSS kann in der Hinsicht nicht nur Tabellen das Wasser reichen, sondern ist weitaus besser für den Zweck geeignet.
Layout-Tabellen sind nicht nur schlecht pflegbar, sie skalieren auch nicht. Lass mal deine Tabelle auf einem mobilen Gerät umbrechen, da nicht genug Platz für beide Zellen nebeneinander ist. Du wirst dich das gleiche CSS schreiben sehen welches du ohne Tabellen benötigt hättest und noch etwas mehr. Als kleiner Bonus ist auch noch dein HTML-Code länger und unübersichtlicher.
(div style="column-count: 3;")Hier der dreispaltige Text(/div)
Alle gängigen Browser unterstützen das (ältere Versionen mit CSS3-validem Vendor-Prefix.)
wegen Forum: () = jeweils spitze Klammern
Habe nie ganz verstanden, warum gerade grids so viel besser als Tabellen sein sollen. Überall tauchen nun im Quellcode css classen auf, die nicht den Inhalt oder dessen Bedeutung entsprechen, sondern eine reine Layoutfunktion haben.
Das ist nicht wirklich viel besser...
Das hatte mich auch verwirrt, als ich eine Seite mit einem Gridsystem (Bootstrap) erstellen sollte.
Mit LESS ( siehe http://lesscss.org/ ) kann man aber Inhalt und Design wieder trennen. Erst das Ausgelieferte CSS für das Endprodukt wird compiliert, und sieht dann weider unübersichtlich aus.
Beim Entwickeln kann man mit Sprechenden css Klassen arbeiten und diesen dann erst Designelemente zuordnen. Man kann da nämlich auch css Klassen innerhalb von Klassen benutzen.(genannt Mixin) LESS bietet auch die Möglichkeit Variablen oder Funktionen zu nutzen.
Ich kann Less oder SASS oder sonnst eine Erweiterung zu CSS nur empfehlen.
content
@black = #FFFFFFFF;
.info{
font-weight: normal;
font-style: normal;
}
.infobox{
.info
color: @black;
}
Auch wenn es sich wie billige Werbung anhört. Ich kann Less oder SASS oder sonnst eine Erweiterung zu CSS nur empfehlen.
Sie haben Wörter oder Phrasen verwendet, die die Vermutung nahe legen, dass es sich bei Ihrer Meldung um eine automatische Werbeaussage (Spam) handeln könnte. Wir möchten Sie deshalb bitten zu Validierungszwecken das unten stehende Kontrollwort einzugeben.
Ja, Less / Sass sind sehr nützlich, können aber schnell zu unschönen CSS Code führen, welcher auch den Browser leicht ausbremsen kann.
Muss man alles mit Augenmaß einsetzen.
Als Entwickler muss man ja sich ja gerade nicht mehr mit dem Kompilat herumschlagen, nur der Sourcecode ist wichtig zum Entwickeln.
Was habe ich da für einen Nachteil, wenn das CSS unleserlich wird, wenn ich mit LESS wunderschönen Dateien habe?
An den Speedverlust durch unoptimiertes CSS hatte ich noch gar nicht gedacht. Ist das wirklich ein Problem? Gibt es Seiten ,welche wegen mülligem CSS ausgebremst werden?
Das javascript eine Seite Verlangsamen kann kenne ich ja aber mit dis CSS war bei mir noch nie ein Problemfaktor.
"An den Speedverlust durch unoptimiertes CSS hatte ich noch gar nicht gedacht. Ist das wirklich ein Problem? Gibt es Seiten ,welche wegen mülligem CSS ausgebremst werden?"
Bei meinen Entwicklungen sind mir durchaus Nachteile mit großen CSS Dateien begegnet. Zum einen bezüglich der Ladezeit - auch komprimiert sind sie teils recht groß bei komplexen Seiten - zum anderen durch verlangsamtes Seitenrendering, vor allem wenn die Seite selbst viele Elemente enthält.
Es muss einem immer klar sein: Auch ein Browser kann nicht zauber. Weniger ist immer besser
Aber natürlich sprechen wir da von wirklich großen Seiten, bei alles unter ein paar tausend HTML-Elementen und CSS Dateien von wenigen KB gibts keine Probleme.
Generell ist das auch nichts, was sich mit SASS/LESS nicht auch lösen lässt, man muss nur aufpassen. Beide blasen die CSS Datei gerne mal gehörig auf, deutlich über dem, was man händisch machen würde fürs gleiche Ziel.
Das kann durchaus die Seite langsamer machen. Aber das ist wie gesagt erst ab einer gewissen Größe ein Problem, und ein Aufsplitten kann da helfen. Aber man muss eben auch daran denken, SASS/LESS sind auch keine Zauberlösungen :)
(Wobei aufsplitten wieder andere Probleme bringt)
Als Entwickler muss man ja sich ja gerade nicht mehr mit dem Kompilat herumschlagen, nur der Sourcecode ist wichtig zum Entwickeln.
Na ja, sobald man dann debuggen muss, warum eine spezielle CSS-Regel nicht greift, arbeitet man doch wieder mit dem Kompilat.
Es gibt Webframeworks, welche diese Trennung ad absurdum führen.
html:
(div class="button big-button red blink popupOnClick")Inhalt(/div)
css:
.button{...}
.big-button{...}
.red{...}
.blink{...}
.popupOnClick{...}
Ist technisch betrachtet noch eine Trennung Da man aber all diese Design Elemente in den Inhaltsteil ( html ) reinschreibt, hat man trotzdem wieder eine vermischung aus Inhalt und Design.
Mit LESS kann mann dann wieder so trennen, dass man auch merkt, dass Inhalt und Design getrennt sind.
html:
(div class="alertButton") Inhalt (/div)
LESS:
alertButton{
.button
.big-button
.red
.blink
.popupOnClick
}
Der Button wird nur noch sematisch beschrieben, das aussehen wird im Designteil geregelt.
Was hält dich davon ab, das Ding direkt im CSS alertButton zu nennen?
Wenn du ein Framework haben solltest, welches so schlechte Klassennamen nutzt, schmeiß es raus, es taugt nichts.
Ich muss dann im CSS alle Eigenschaften von allen Klassen von Hand kopieren. Habe ich mehrerer Button Klassen oder Mehrere Klassen, .Red verwenden, kenne ich keine Möglichkeit Redundanter Code zu verhindern. Das ganze wird also unübersichtlicher Fehleranfälliger schwerer zu warten oder zu erweitern...
Bedenke dabei, dass die Klasse .Red auch irgendwas verrücktes mit einem Verlauf und Browserweichen beinhalten könnte und nicht nur color: red; setzen muss.
Das angesprochen Bootstrap nutzt ähnlich Klassennamen
Sie heissen da class="btn btn-primary btn-large"
siehe http://getbootstrap.com/2.3.2/
AFAIK wurde Twitter damit erstellt. Zusammen mit LESS taugt Bootstrap durchaus was.
Ich habe grundsätzlich nichts gegen CSS-Frameworks (auch wenn ich sie nicht nutze, ich halte den Code lieber schlank) und auch CSS-Präprozessoren find ich durchaus interessant, leider kennen viele nicht einmal die Möglichkeiten von CSS selbst und begeben sich viel zu blauäugig in Abhängigkeiten die sie weder brauchen noch wirklich ausnutzen.
Zwei wesentliche Gründe:
1) Darstellung der Seite: Mit Tabellen baut man ein statisches Layout. So kann man zwar einfach "sauber" ausrichten, aber es funktioniert nur solange der User sich an deine Vorgaben hält ("optimiert für IE6 @ 1024x768). Sobald man Browser welchselt, auf verschiedenen Geräten darstellen will, andere Schriften installiert sind, man "Strg +/-" verwendet, ... sind diese Layouts kaputt/hässlich/unpraktisch.
Sofern es der Entwickler richtig macht skaliert ein CSS Design dynamisch über ein breites Spektrum an Browsern und Bildschrimen. Durch die Angabe verschiedener CSS Files kann man das Layout gänzlich verändern.
In Zeiten von Smartphones und Tablets ist das wichtiger denn je.
2) Inhalt und Bedeutung werden sehr wohl getrennt. Die CSS Klassen sind nur Attribute an einem Inhaltlich strukturiertem Dokument. Für den Menschen der sich den Sourcecode aus der Ferne ansieht mag das auch nicht sauber aussehen. Doch spätestens wenn man versucht Informationen automatisiert zu parsen merkt man wie große die Unterschiede sind.
Mit einem CSS Design bekommt man flache, stabile Strukturen. Table Designs sind i.d.R tiefe Verschachtelung inhaltlich unnötiger Tags, welche sich mit jeder kleinen Design Änderung wieder verändern.
Beides setzt natürlich vorraus dass der Entwickler weiß was er tut. CSS ist auch nur ein Werkzeug, welches man auf die schlimmsten Arten missbrauchen kann.
Ich finde es mittlerweile normal das Schrift über Schrift/Grafik liegt und Teile von Webseiten aussehen wie hingeschmiert. Scheinen nicht so viele mit zurechtzukommen.
Tatsächlich passen sich viele alte Tablet-Designs den Auflösungen weit besser an, die zumeist festen Breiten (wie auch hier) sind eher ein fader Kompromiss, keine echte Lösung.
Echte Lösungen entwickeln sich erst mit aktuellen CSS Versionen und in Verbindung mit JS, vorher gab es viele Nachteile und Probleme mit dynamischen Anpassugnen auch in CSS, weswegen fast alel Webseiten weste Pixelbreiten nutzen. Das war und ist nicht modern, CSS hin oder her!
Nur mal ein Hinweis: Pro-Linux nutzt Tabellen... ;)
Und, ist das jetzt so schlimm? geht die Welt davon unter? Ich kenne tausende ohne Tabellen, die keinen deut flexibler sind.
Gerade Seiten mit Spaltenlayouts sind selten wirklich flexibel. Es gibt Lösungen die es können, viele aber nicht.
Zur Trennung von Inhalt und Bedeutung: Dies ist hier wie gesagt nicht der Fall.
Ob ich nun oder schreibe macht kaum einen Unterschied. Solange das div nur dafür da ist, dieses eine Tag zu tragen, und nur für das Layout existiert, ist es beides nicht sauber.
Die hier vorgestellte Lösung macht nichts besser, sie macht es nur anders. Sie ist auch nicht sauberer zu parsen, noch immer finden sich völlig nutzlose Tags im Design.
Hier geht es wohlgemerkt nicht um die Frage: CSS ja oder nein, mir geht es um Lösungen wie die vorgestellte.
Es gibt viele tolle Lösungen mit CSS und ganz ohne Tabellen, aber diese hier ist keine solche.
Den sie hat leider eben genau die unnötigen Tags, die man eigentlich vermeiden will.
Das ist viel, viel, viel, besser! Der wichtigste Vorteil:
Linearität: Die Inhalte können in der semantisch korrekten Reihenfolge im Dokument stehen, völlig unabhängig vom Layout (wichtig z.B. für Barrierefreiheit oder Responsive Layout für Mobilgeräte). Mit Tabellen ist das nicht machbar.
"In der »Sturm und Drang«-Zeit des Webs wurden mehrspaltige Layouts gerne mit Tabellen realisiert – was heute zurecht als verpönt gilt."
Ja, ich habe auch schon lange damit aufgehört, mehrspaltige Layouts etc. mit Tabellen zu realisieren, weil es ebenso lange schon einhellige Meinung ist, dass man so etwas nicht macht. Begriffen habe ich es aber bis jetzt noch nicht. Auch Seiten, die ich früher mit Tabellen gemacht habe, laufen heute noch perfekt. Ein paar Firmen haben die - wenn ich mich nicht irre - fast schon 10 Jahre drin. Die Seiten werden nur inhaltlich gepflegt: Minimalaufwand. Sie laden sehr schnell und sie nützen den ganzen Bildschirm aus. Weshalb sind Tabellen schlecht, wenn alle damit zufrieden sind?
Leute die Screenreader benutzen sind scheinbar nicht zufrieden damit.
Wenn man das Web automatisch auswerten möchte, ist man dankbar, wenn Design und Inhalt getrennt werden.
Ausserdem ist man dann dankbar, wenn Dinge Sematisch korrekt beschrieben werden.
PS: man kann auch mit divs Seiten machen, welche den gesamten Bildschirm nützen und sehr schnell laden.
Ja, ich verwende ja auch DIVs für eine bildschirmfüllende Darstellung und wenn man sauberen einfachen Code schreibt, sind die zumindest genau so schnell wie Tabellen-Seiten. So gravierend finde ich den Unterschied aber nicht.
Am schlimmsten sind eigentlich nur die Seiten, die mit CMS erzeugt wurden. Die sind von handgeschriebenen sauberen Tabellen- oder DIV-Seite meilenweit entfernt.
Kommt aufs CMS an. Mit Silverstripe gibt es genau so guten Code.
Willst du auf sowas verzichten: BILD ?
Schlecht gemachte Tabelle ...
Das geht aber auch mit DIVs ...
Sowas sehe ich mehrmals täglich, scheint aber nur mir so zu gehen...
Och, wenn ich da an die ganzen Probleme denke, die viele mit CSS haben
CSS und Tabellen sind kein Widerspruch. Es geht eher um die Verwendung von DIVs oder Tabellen FÜR DEN SELBEN ZWECK. Tabellen werden ja nicht kritisiert, wenn sie für tabellarische Inhalte verwendet werden.
... und noch etwas: Ich werde mehr und mehr zum Purist. Ich möchte es überspitzt und vielleicht etwas provokativ ausdrücken: Die schönsten Seiten brauchen nicht mehr, als dieses Prinzip:
Mehr braucht man nicht
Sorry, ich glaube ich lasse es heute ...
Dir sind ein paar Tags abhanden gekommen, oder?
Ja - sorry ...
Tabellen dienen dazu Inhalte in einer bestimmten organisierten Form wieder zu geben. Richtig gemacht haben damit auch schreenreader damit keine Probleme.
Beim Design wird aber nicht nur eine Tabelle verwendet. Oft kamen mehrere ineinander Verschachtelte Tabellen zum Einsatz. Weder für einen screenreader, noch für einen Roboter ist erkennbar wo was der eigentliche Inhalt ist. Die Navigation innerhalb solcher Konstrukte ist mittels screenreadern umständlich.
Tabellen sind ein starres Design, der Inhalt der Seite muss entsprechend dargestellt werden. Das ist vorallem bei Browsern auf kleineren Displays schwierig.
divs lassen sich dynamisch positionieren. Zur Not bricht der Browser das Design und kann die divs umorganisieren. Der Inhalt bleibt weiterhin nutzbar. Durch bewusste Bezeichnung der divs können Inhalt und Navigation eindeutig getrennt werden, was der Barrierefreiheit und auch den Robotern von Suchmaschinen dient.
Früher konnten die Seiten mittels div auch einiges code einsparen. Mittlerweile dank javascript-frameworks und fetter css aber kein argument mehr.
CSS und javascript bieten in zwischen eine Vielzahl an funktionalität, die man mit Tabellen kaum umsetzen kann.
Lass dir mal eine Designtabelle von einem Screenreader vorlesen …
Der Html Beispiel ist nicht gerade vorbildlich. H2 aber kein H1 Titel ist sonderbar und nicht barrierefrei.
Ich habe mir einige css Dateien angeschaut und war auch entsetzt, Form Elemente sind in der reset*.css nicht enthalten. Die Zeichengröße ist zu gering usw.
Die Idee die im Modell steckt ist zwar gut. die Ausführung aber ungenügend.
Das sehe ich auch so, das HTML ist nicht optimal, vor allem sowas macht man nicht:
Dafür gibt es Easy-Clearing ganz ohne den HTML-Code mit sinnlosen leeren Elementen zu verschmutzen.Die CSS-Dateien überzeugen mich auch nicht, besonders schlecht ist die Angabe der Schriftgröße in Pixeln, da sollte man unbedingt zu em oder % greifen. Überhaupt wüsste ich nicht warum man alles in Pixeln festzimmern muss, auch für Spaltenbreiten bietet sich eher Prozent an.
Die Pixelitis ist einer weit verbreitete Krankheit, davon wird auch in WCAG abgeraten. EM, EX und % sind vorzuziehen, dies kann aber zu kleine Probleme führen, die aber in der Regel leicht lösbar sind. Für meinen Teil sind Pixelangaben verpönt.
Zumindest in der Vorgängerversion konnte ich das auf 16 Spalten anpassen. Das "responsive Webdesign" ist ein sehr grosser vorteil von Bootstrap gegebnüber 960.gs
Die Smartphones werden nämlich nicht weniger.
Auch die Benutzung von Less bietet enorme Vorteile.
Falls man .js einsetzen mag, bietet Bootstrap auch da noch weitere Möglichkeiten.
Wenn man nicht nur eine minimalistische Website für den PC herstellen möchte, gibt es imho interessantere Lösungen als 960.gs
Hallo,
von Twitter Bootstrap habt ihr auch noch nichts gehört, oder?!
Das ist bestimmt 10 mal besser als das Ding hier und wesentlich weiter verbreitet. Kann also auch für die berufliche Karriere das zu können.
Gruß
Bootstrap ist doch im Artikel als Alternative erwähnt...
Na toll -- Layout mit Tabellen ist also "zurecht verpönt" (obwohl man viele Layouts mit Tabellen sehr viel sauberer hinbekommt als mit den sonst notwendigen CSS-Hacks), "pixelgenaues Layout", das z.B. die Schriftgrößeneinstellung des Browsers ignoriert aber anscheinend nicht.
Klar, in vielen Fällen sind CSS eindeutig besser geeignet als Tabellen; in anderen Fällen -- insbesondere bei robusten mehrspaltigen Layouts -- ist es aber genau andersrum. Die diversen "mehrspaltigen CSS"-Hacks, die im Internet kursieren, sollte man meiden, da sie meist nur so halb oder nur mit bestimmten Browsern funktionieren. Und ich habe noch nichts gesehen, was Tabellen hier das Wasser reichen könnte.
Ebenso würde ich empfehlen, Layouts und Systeme, die versuchen, pixelgenau zu sein (wie das angegebene), zu meiden. Es ist durchaus sinnvoll, dass man im Browser eine Standardschriftgröße einstellen kann -- diese wird aber vom 960-Grid-System komplett ignoriert. Verstellt man sie doch -- oder verwendet man einen Browser, der den Webseitenzoom anders implementiert, geht die Seite gnadenlos kaputt. Überlappende Texte, nicht-sichtbare Texte, kaputte Navigationsleisten usw. sind die Folge...
Und viel Spaß beim Betrachten einer 960-Grid-System-Seite mit einem 800x480 Display oder noch kleinerer Auflösung...
Layout-Tabellen sind nicht nur schlecht pflegbar, sie skalieren auch nicht. Lass mal deine Tabelle auf einem mobilen Gerät umbrechen, da nicht genug Platz für beide Zellen nebeneinander ist. Du wirst dich das gleiche CSS schreiben sehen welches du ohne Tabellen benötigt hättest und noch etwas mehr. Als kleiner Bonus ist auch noch dein HTML-Code länger und unübersichtlicher.