Übersicht CSS-Frameworks

[Jens-A. Koch]

Die Abstimmung "CSS-Framework(s) - ja, nein, welches?" gehört zum Thread/Post: http://forum.clansuite.com/index.php/topic,207.msg1053.html#msg1053

1. Ich möchte mich einfach nicht mit den IE-Bugs und den ganzen Cross-Browser Geschichten rumschlagen: bin pro FW!
2. Ich bin für YAML. Erstens ist das sehr gut dokumentiert, zweitens verfügt es über ne große Community, drittens könnten wir wohl auf freie YAML-Layout-Templates die für Wordpress, Joomla oder Drupal erstellt wurden zugreifen, viertens ist das von der Power soviel über das Ziel hinausgeschossen, dass Clantemplates damit locker zu machen sind! Fünftens: Man bedenke allein den Theme-Builder (ok, den hat man bei Y!Grids auch - er is ja von dort entlehnt)!

Meine alte Idee war: die Module mit reinen Daten-Templates, ohne/wenig html oder css auszuliefern: Anpassung wäre User Sache - "out-of-the-box" würde das nur im "Drahtgitter" laufen + gleichzeitig ein bereits angepasstes Theme "Standard" mitzuliefern. Xsign hat insoweit recht, dass es sofort "ootb" laufen muss. Mir ist nun klar, dass die Modul-Templates irgendwie gestylt sein müssen um sich (zumindest im Standard-Template) sofort verwenden zu lassen. Das läuft darauf hinaus, dass wir diese CSS Tags vereinheitlichen müssen. Wenn Theming darin besteht, die CSS Attributwerte zu ändern und zu ergänzen, dann kann man mit wenigen festen Zuweisungen arbeiten, dass wird bei Clansphere auch so gemacht (worauf xsign hingewiesen hat). YAML wäre nochmal etwas oben drauf, eben auch die Struktur für die Seite per Framework vorzugeben: ein professionelles CSS-Layout zu ermöglichen. Und sagen wir mal so: Vom starren und hochwertigen YAML-Turm, kann man immernoch runterklettern, um statische Tabellenlayouts zu verwenden.

[thunderm00n]

Gut, mit FW kenn ich mich nicht wirklich aus und bekannt ist mir von o.g. FW nur das Yaml. Sollte mit etwas einarbeitung aber schon klappen. Bin ja lernfähig

[xsign.dll]

Ok ich glaub ihr versteht CSS Frameworks nicht vollständig.
Bei fast allen CSS Frameworks geht es ausschließlich um sogenannte float Umgebungen. Also den Flusstext/Flussrichtung betreffende Container.
D.h. YAML lohnt sich nur, wenn wir <div> Templates hätten.
Wir haben dies bewusst vermieden, da wir von Anfang an wussten, dass es dort zu Komplikationen führen kann. Daher: <table>
Das hat sich durch alle unsere Templates gezogen, und ich werde dies mit Sicherheit nicht abschaffen.

Allein die Historie von CSS zeigt, dass der Wegfall der Tables totaler Mist war:
1. Stufe: Anfang 2000
- Wegfall der <tables> prognostiziert - jeder wollte nur noch mit <div> arbeiten unter der Möchtegernpropaganda der "Barrierefreiheit".
2. Stufe: Anfang 2003
- vieles wurde auf <div> umgestellt, doch schnell wurden die Probleme der Browser zu einer Last - die ersten Frameworks entwickelten sich (dass bezieht sich alles NUR auf float Umgebungen. Normal positionierte <div>'s verursachen keinerlei Probleme und können sehr effektiv und browserkompatibel platziert werden!)
3. Stufe: Anfang 2005
- W3C hat aufgrund dessen in CSS2.1 die TABLE-Definitions mit eingeführt (was für ein kompletter Schwachsinn, wenn man bedenkt, dass man 5 Jahre zuvor genau davon wegkommen wollte).

Allein diese Historie zeigt mir, dass wir mit <tables> absolut richtig fahren, und auch Browserkompatible sind.


Und wie der gute Herr in dem Englischen Artikel schon beschrieben hat:
YAML erzeugt Overhead und ist komplett überflüssig, wenn man sich auf Konventionen bei der Namensgebung/Verwendung der CSS Klassen einigen kann. Und selbst mit YAML müssten wir uns darauf einigen, denn YAML ersetzt einem NICHT das stylen, sondern nur das positionieren von gefloateten <div>'s.



=> Nein

[Vyper]

Bin auch contra CSS-Frameworks. Schlicht aus dem Grund, weil man die vielen Möglichkeiten höchst selten braucht.
Nichtsdestotrotz bin ich pro CSS + <div>.
xsign's Argument, dass wir bei Clansuite mit Tabellen richtig fahren, ist schlichtweg falsch.
Es mag zwar sein, dass sich Tabellen rel. unkompliziert verhalten, wenn man darüber Layouts erstellt, jedoch ist es immer eine Qual - vorallem bei komplexeren Sachen - da noch den Überblick über womöglich verschachtelte Tabellen zu behalten -> Anpassung ist ein Grauß, ganz zu schweigen vom aufgeblähten Quelltext...

Und genau aus diesem Grund sind Tabellen nunmal nicht zum Layouten gedacht -> sie dienen nun mal einfach der Darstellung von Informationen - nicht mehr und nicht weniger.
Wenn ich doch einfach nur mehr (Frei-) Zeit hätte, dann könnte ich mich mal wieder bissl ums Accessible Template kümmern... 

[xsign.dll]

Naja so ist es ja auch bei uns gedacht - Tabellen sollen Informationen darstellen. Userlisten, Statistiken etc. - ich verwende auch gerne <div> container und bin sogar durch Mootools oftmals gezwungen diese Block Elemente zu verwenden, aber um Informationen itterativ darzustellen greif ich entweder zu <li> oder <tr>. Das gute sind dabei aber die festen Poistionen der tables - verutscht nicht und verzieht sich nicht. Jede Zeile ist gleich groß wie die darüberliegende. Und genau das ist ja das Hauptproblem, woraus CSS Frameworks entstanden sind - man bekommt diese Fixe Positionierung nicht immer hin.

Aber ich geb dir Recht. Mehr Quelltext ist es, und manch verschachtelte Tabelle versteh selbst ich nicht

Btw: Hier geht es auch nur um die Templates, welche sich im Modul Folder befinden. Dort sollten die TPLs so gestaltet werden, dass Sie Informationen solide und effektiv rüberbringen können. Solide im Sinne davon, dass man bei einem Theme Wechsel das jeweilige Modul mit seinen Templates trotzdem noch "schmackhaft" ansehen kann. Das ist meiner Meinung nach mit <div>'s nicht ganz so einfach wie mit <table>'s.

Was ich wirklich immer als Problem ansehe ist die Informationsdarstellung bei <div>'s bzw. deren Verwaltungsaufwand. Natürlich kann ich das so hier schreiben:

Code:

<div class="head">Userlist</div>
<div>User1</div><div style="float:left;clear:both;">Nickname</div>
<div>User234</div><div style="float:left;clear:both;">Nickname2</div>

Damit hab ich aber keine Spaltenstruktur (hier nochmal der Verweis auf das eigeführte table format von CSS 2.1). Es kann mir nicht garantiert werden, dass alle Zeilen gleich Breit bleiben, wenn sich z.B. das Fenster verkleinert (wäre mit JS aber machbar...). Dazu wäre eine fixe Breite notwendig, und dass sollte man vermeiden.

[Vyper]

Sry, wenn wir uns jetzt falsch verstehen, deinen Post lese ich jetzt in etwa so (zumindest den unteren Teil), als wenn wir uns zwingen wöllten, garkeine Tabellen zu benutzen - so meinte ich das in garkeinem Fall.
Dein Beispiel mit der Userlist finde ich da z. B. ganz gut - denn dort macht n'e Tabelle wirklich richtig Sinn - diese dann noch schön logisch auszeichnen (thead, tbody, tfoot, th, etc...) und alles sollte paletti sein.
Wo ich dann allerdings auf <div> setzen würde, wären dann z.B. im Frontend bei den News, da ne Tabelle herzlich wenig Sinn macht, wenn man sogesehen nur eine Spalte darzustellen hat.

[xsign.dll]

Ja und genau da ist eben das "problem". Wir müssen es in gewisser Hinsicht vereinheitlichen. Dazu Bedarf es im Wiki einer Auflistung von Classes, die wir verwenden sowie Namenskonventionen, an die wir uns halten.

Kommentare:

/**
* General Html Settings
*/

.......

/**
* Standard rows, columns & header definitions
*/

/**
* News module classes
* @todo    Rename classes to comply camelcase
*/

.....

Dann sollten wir darauf achten, dass wir die classes & id's in CamelCase schreiben, also nicht .td_header sondern .tdHeader

So und jetzt werde ich nochmal zusammentragen, was wir als "Standard" Klassen einführen müssen (bitte ergänzen):

Rows
.row1
.row2
.rowSmall1
.rowSmall2

Header
.header1
.header2
.headerSmall1
.headerSmall2

Buttons
.buttonGreen
.buttonRed
.buttonOrange
.buttonYellow
.buttonGrey

Error
.errorNormal
.errorCritical

Fonts
.fontSmall
.fontNormal
.fontHuge


Bitte vervollständigen, da ich dies dann ins Wiki schreiben möchte und vorallem die standard.css dementsprechend anpassen sowie alle TPLs damit bestücken möchte.

[xsign.dll]

Confirm
.confirmDelete
.confirmEdit

Forms
.inputText
.inputSelect
.inputSubmit
.inputError
.inputValid

(Hier bitte darauf achten, dass Checkboxen NICHT gestyled werden!)