Clansuite Community Forum


 
Willkommen Gast. Bitte einloggen oder registrieren.
Haben Sie Ihre Aktivierungs E-Mail übersehen?

Einloggen mit Benutzername, Passwort und Sitzungslänge
 
Umfrage
Frage: CSS-Framework(s) - ja, nein, welches?
ja - 2 (33.3%)
nein - 2 (33.3%)
YAML - 2 (33.3%)
Blueprint - 0 (0%)
Yahoo Grids - 0 (0%)
Grideasy - 0 (0%)
Elements - 0 (0%)
Tripoli - 0 (0%)
960 Grid System - 0 (0%)
WMStyle - 0 (0%)
Clansuite-CSS-Framwork - 0 (0%)
Stimmen insgesamt: 4

Seiten: [1]   Nach unten
  Drucken  
Autor Thema: Übersicht CSS-Frameworks  (Gelesen 2052 mal)
0 Mitglieder und 1 Gast betrachten dieses Thema.
Jens-A. Koch
Maintainer
*
Offline Offline

Beiträge: 574

One-Man Team


« am: August 29, 2008, 05:46:45 »

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.


Gespeichert

Keine Supportanfragen per PN oder Mail. Fragen bitte nur im Forum stellen (Wie man Fragen richtig stellt).
thunderm00n
Designer
*****
Offline Offline

Beiträge: 107


« Antworten #1 am: August 29, 2008, 07:13:01 »

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 Zwinkernd
Gespeichert

greetz Thunderm00n

Ein Rechtschreibfehler (auch Fehlschreibung genannt) bezeichnet eine Schreibweise eines Wortes oder Satzzeichens, die laut der allgemein üblichen Orthographie falsch ist.
Meine Rechtschreibfehler unterliegen der General Public License und dürfen frei verwendet werden.
xsign.dll
Guide
***
Offline Offline

Beiträge: 155


« Antworten #2 am: August 29, 2008, 09:03:36 »

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
Gespeichert

Vyper
Neuling
*
Offline Offline

Beiträge: 13


« Antworten #3 am: August 30, 2008, 12:22:56 »

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...  Traurig
Gespeichert
xsign.dll
Guide
***
Offline Offline

Beiträge: 155


« Antworten #4 am: August 30, 2008, 01:03:29 »

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 Zwinkernd

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.
Gespeichert

Vyper
Neuling
*
Offline Offline

Beiträge: 13


« Antworten #5 am: August 30, 2008, 10:23:23 »

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. Smiley
Gespeichert
xsign.dll
Guide
***
Offline Offline

Beiträge: 155


« Antworten #6 am: August 30, 2008, 07:24:30 »

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:

Zitat
/**
* 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.
Gespeichert

xsign.dll
Guide
***
Offline Offline

Beiträge: 155


« Antworten #7 am: September 11, 2008, 01:44:44 »

Confirm
.confirmDelete
.confirmEdit

Forms
.inputText
.inputSelect
.inputSubmit
.inputError
.inputValid

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

Gespeichert

Seiten: [1]   Nach oben
  Drucken  
 
Gehe zu:  


Powered by SMF 1.1.16 | SMF © 2006-2009, Simple Machines

Google visited last this page Mai 10, 2012, 01:15:08