Was haltet ihr von YAML

[Andreas]

Hallo,

seid einiger Zeit Verwende ich YAML. Bis eigentlich ziemlich begeistert von diesem Framework. Allerdings scheinen da nicht alle meine Meinung zu teilen. Wäre super wenn ihr mir sagen könntet was ihr von YAML haltet...

...bitte nicht nur die die es sch. finden.

[ChrisB]

Hi,

seid einiger Zeit Verwende ich YAML. Bis eigentlich ziemlich begeistert von diesem Framework. Allerdings scheinen da nicht alle meine Meinung zu teilen. Wäre super wenn ihr mir sagen könntet was ihr von YAML haltet...

Generell halte ich von "Frameworks" eines - Abstand.

Die bekannten Frameworks, egal in welchem Bereich (PHP/JS/CSS) bieten i.d.R. jede Menge - und damit oft auch sehr viel mehr, als man eigentlich zur Loesung der jeweiligen Aufgabe wirklich braucht. Das ist halt ein generelles Problem eierlegender Wollmilchsaeue ...

Wenn man sich nur mal anschaut, wie viele Leute nur fuer einen einzigen kleinen JavaScript-Effekt JS-Libraries mit Downloadgroessen im mehrstelligen KB-Bereich einbinden ... fuer Sachen, die man mit etwas Ahnung sehr viel schlanker und besser auf die Aufgabe zugeschnitten haette umsetzen koennen.

Wenn man wirklich sehr viel von der Funktionalitaet, die ein Framework bietet, wiederholt brauchen kann - dann meinetwegen; aber fuer "Kleinkram" dann doch lieber Nein, Danke.

Und vor allem Anfaenger sollten m.E. erst mal eigenhaendig den Umgang mit der jeweiligen Technik erlernen, anstatt sich allen Denk- und Einarbeitungsaufwand von einem Framework abnehmen zu lassen - dadurch entstehen naemlich auch immer wieder Probleme, wenn grundlegendes Verstaendnis fehlt.

MfG ChrisB

[molily]

Generell halte ich von "Frameworks" eines - Abstand.

Wenn man nicht immer dasselbe Fundament von neuem entwickeln will, kommt man sehr schnell zu einem "Framework". Und weil es Leute gibt, die sich schon viele Gedanken über gute Architektur gemacht haben, kann es auch viel bringen, die Modelle und Pattern eines bestehenden Frameworks zu benutzen.

Wenn man sich nur mal anschaut, wie viele Leute nur fuer einen einzigen kleinen JavaScript-Effekt JS-Libraries mit Downloadgroessen im mehrstelligen KB-Bereich einbinden ... fuer Sachen, die man mit etwas Ahnung sehr viel schlanker und besser auf die Aufgabe zugeschnitten haette umsetzen koennen.

Modularisierung ist bei JS-Bibliotheken leider noch nicht voran gekommen. Aber gerade 08/15-Animationen will "man" nicht (und Anfänger schon gar nicht) low-lowel umsetzen. Schlanker macht mans, wenn Performance gebraucht wird und die Animationen komplex werden. Ansonsten nimmt man eine Standardlösung, die man in 5 Minuten aufgesetzt hat und die ausreichend performt.

Mathias

[suit]

Wenn man nicht immer dasselbe Fundament von neuem entwickeln will, kommt man sehr schnell zu einem "Framework". Und weil es Leute gibt, die sich schon viele Gedanken über gute Architektur gemacht haben, kann es auch viel bringen, die Modelle und Pattern eines bestehenden Frameworks zu benutzen.

wie ich schon gesagt habe: ich selbst nutze auch ein "framework" weil ich auch dinge sehr oft benötige und umsetze - aber yaml ist einfach etwas "zu viel des guten" für den standard-blah-blah

yahoos yui hingegen entspricht schon eher dem, was ich als einfaches framework bezeichnen würde - ich habs bisher nur 1x genutzt, nehme aber dann doch lieber mein eigenes bier :D

[RuD]

Seid gegrüßt!

Ich mag YAML nicht. Es schränkt zu sehr ein und enthält haufenweise "Müll", den man bestimmt nicht braucht.

Ich favaorisiere direkte Layouts auf meinen Anwendungsfall zugeschnitten, sehrt viel besser. Und auch so kann man Yet Another Multicolumn Layout schreiben.

[suit]

kopie von hier um die diskussion nicht zu zerpflücken

Ich bin noch recht neu was Webseitengestaltung angeht. Aus deiner Aussage geht ja die pure Abneigung YAML gegenüber hervor. Ich finde das eigentlich garnicht schlecht. Hab mich eine Weile damit beschäftigt. Es ist super strukturiert und die ganzen Browserbugs werden auch bestens abgefangen. Änderungen fallen leicht naja DAS IST DOCH NICHT SO SCHLECHT.

die pure abneigung begründet sich vor allem darauf, dass yaml extrem viel "müll" in den code verfrachtet - etwa wie beim css zen garden

eine vielzahl der elemente ist nicht notwendig und der code ist ungemein aufgebläht

ein essentieller vorteil von css-basierenden layouts ist es, ein semantisch vernünftig strukturiertes dokument so hinzubekommen, dass es visuell durch pures css umgestaltbar ist

die logische reihenfolge beim lesen eines dokuments ist imho folgende:

• titel der seite
• wo bin ich?
• inhalt
• zusatzinformation, externe verweise
• metainformationen, tags usw
• menüfühung
• seitenende

wenn man das in ein tabellenlayout pfanzt, hat man das problem, dass die visuelle abfolge mit der logischen abfolge im konflikt steht - ein linerarisiertes tabellenlayout hat also zb so eine abfolge

• titel
• wo bin ich
• menü
• inhalt
• metainformationen
• zusatzinformationen
• seitenende

selbrige logische festzimmerei findet man auch bei grid-basierenden framewords wie etwa yaml - das einzige was yaml oder yui machen: unter dem deckmantel von tabellenlosem layout das schema von tabellen zu verstecken (zumindest mit den standardvorgaben)

es ist ein typisches grid mit kästchenbildung (und noch dazu mit viel mehr code als notwenidig)

wenn man yui mit yaml vergleicht: yui ist schlank und durchdacht, yaml ist hoffnungslos überladen - dennoch stimmt auch bei yui die logische abfolge mit meinem semantischen verständnis nicht überein

Machst du alles händisch?

nein, ich verwende in vielen fällen eine art html-framework wo viele codebestandteile vorgegeben sind und die abfolge "festgenagelt" ist - diese werden dann mit vorgefertigten bausteinen befüllt

das css selbst erstelle ich händisch - für dinge die man oft braucht, gibts natürlich fertige schnipsel, die dann auch wieder auf grids basieren - aber die seitenstruktur selbst wird immer von grundauf neu erstellt

natürlich ist es ansichtsache - aber wie bereits erwähnt: der vorteil von yaml gegenüber einem tabellenlayout wird mir nicht ganz klar ;)

[Cybaer]

Hi,

die logische reihenfolge beim lesen eines dokuments ist imho folgende:

Ist mir jetzt zum zweiten Mal aufgestoß^W aufgefallen. Worin begründet sich der scheinbar übermächtige Wunsch, die

• menüfühung

semantisch nach unten zu verbannen?

Davon abgesehen:

wenn man das in ein tabellenlayout pfanzt, hat man das problem, dass die visuelle abfolge mit der logischen abfolge im konflikt steht

Herrjeh, dann setzt das Menü halt auch hier nach unten, und positionier es dann mit CSS ... >:->

Gruß, Cybaer

[suit]

semantisch nach unten zu verbannen?

weil ich ohne zutun zuerst die inhalte haben möchte, die ich brauche

wenn ich auf einer detaulseite bin, brauch ich die navigation nicht - da ist der link "zum inhalt springen" (der imho da sein sollte) eine unnütze aktion, die es zu vermeiden gilt

spätestens auf der dritten seite die ich lese, geht mich das dann an

wenn du in der wikipedia schmökerst (und ich komme da wie jeder andere vom hundertsten ins tausendste) müsstest du bei jeder seite das menü überspringen, weil du es ja eh schon kennst - das ist lästig (besonders für menschen, die ohne css arbeiten oder screenreader nutzen)

Herrjeh, dann setzt das Menü halt auch hier nach unten, und positionier es dann mit CSS ... >:->

in einer tabelle?

<table>  
  <tr>  
    <td>kopf</td>  
  </tr>  
  <tr>  
    <td>inhalt</td>  
  </tr>  
  <tr>  
    <td>menü</td>  
  </tr>  
  <tr>  
    <td>fuss</td>  
  </tr>  
</table>

viel spass - führt das dann das tabellen-layout nicht ad-absurdum? :D

[Hopsel]

Hi suit!

viel spass - führt das dann das tabellen-layout nicht ad-absurdum? :D

Du regst dich gerade nicht wirklich über den Missbrauch von zu Layoutzwecken missbrauchten Tabellen auf, oder?! =)

MfG H☼psel

[suit]

Du regst dich gerade nicht wirklich über den Missbrauch von zu Layoutzwecken missbrauchten Tabellen auf, oder?! =)

nie nicht :)

[Cybaer]

Hi,

semantisch nach unten zu verbannen?
weil ich ohne zutun zuerst die inhalte haben möchte, die ich brauche

Und dich will schnell zu einer anderen Seite, wenn mir der Inhalt doch nicht zusagt - und dann ganz bestimmt nicht naxh unten scrollen müssen.

So what?

wenn du in der wikipedia schmökerst (und ich komme da wie jeder andere vom hundertsten ins tausendste) müsstest du bei jeder seite das menü überspringen,

Liest Du Wikipedia als HTML-Quelltext? Was nützt es mir denn, wenn das Seitenmenü "Artikel Diskussion Seite bearbeiten Versionen/Autoren" im Quelltext hinten steht, aber doch immer auf jeder Seite als erstes erscheint, weil das Layout es nunmal vorsieht - noch über dem fetten Spenden-Banner?

Und die Wikipedia-Navigation selbst steht im Quelltext noch vor dem Inhalt.

weil du es ja eh schon kennst - das ist lästig (besonders für menschen, die ohne css arbeiten oder screenreader nutzen)

Also ich findes es praktischer, nicht den ganzen Text durchscrollen zu müssen, um ans Menü zu kommen (in der stillen Hoffnung, daß wenigstens am Ende ein Menü sein wird ;->).

Nun ja, ich bin nicht blind, nutze keinen Screenreader und hoffe jetzt einfach mal, daß sich ein Blinder analog nicht den ganzen Text anhören muß, um zum Menü zu kommen ... ;->

Herrjeh, dann setzt das Menü halt auch hier nach unten, und positionier es dann mit CSS ... >:->
in einer tabelle?

Ist doch egal:

<table>  
  <tr>  
    <td><img src="kopf.png" height="50" alt="Kopf"></td>  
  </tr>  
  <tr>  
    <td><!-- Platzhalter für Menü --></td>  
  </tr>  
  <tr>  
    <td>inhalt</td>  
  </tr>  
  <tr>  
    <td><div style="position:absolute; top:50px; left:20px;">menü</div></td>  
  </tr>  
  <tr>  
    <td>fuss</td>  
  </tr>  
</table>

führt das dann das tabellen-layout nicht ad-absurdum? :D

Ist wohl die Frage, wofür man Tabellenlayout einsetzt. Ich z.B. setze TL als Fallback ein, um auf weniger modernen Browsern/ohne CSS dennoch meine Layoutvorstellungen darzustellen (andere bevorzugen dann ja den HTML-1-Look - Ansichtssache).

Das bedeutet aber doch nicht, daß man das Layout im Falle des Vorhandenseins von CSS und i.d.R. auch JS nicht anders macht. Im Detail, oder komplett neu strukturiert ...

Gruß, Cybaer

[suit]

Und dich will schnell zu einer anderen Seite, wenn mir der Inhalt doch nicht zusagt - und dann ganz bestimmt nicht naxh unten scrollen müssen.

wenn du noch nicht beim inhalt bist, musst du zuerst das menü überspringen, schaun ob dir der inhalt zusagt oder nicht, dann wieder nach oben udn weg

So what?

2x extra klicken ;)

Liest Du Wikipedia als HTML-Quelltext?

siehe unten

Was nützt es mir denn, wenn das Seitenmenü "Artikel Diskussion Seite bearbeiten Versionen/Autoren" im Quelltext hinten steht, aber doch immer auf jeder Seite als erstes erscheint, weil das Layout es nunmal vorsieht - noch über dem fetten Spenden-Banner?

siehe unten

und das mit dem banner für die werbung ist ein eigenes thema ;) der soll so weit oben wie möglich sein, weil er ja zuerst gesehen werden soll :D

Und die Wikipedia-Navigation selbst steht im Quelltext noch vor dem Inhalt.

nicht wirklich, der inhalt kommt zuerst

Nun ja, ich bin nicht blind, nutze keinen Screenreader und hoffe jetzt einfach mal, daß sich ein Blinder analog nicht den ganzen Text anhören muß, um zum Menü zu kommen ... ;->

dafür gibts einen link zum überspringen - aber die wahrscheinlichkeit, dass ich mir den inhalt durchlese ist größer als die, dass ich auf jeder "angeklickten" seite am menü interessiert bin ;)

Ist wohl die Frage, wofür man Tabellenlayout einsetzt. Ich z.B. setze TL als Fallback ein, um auf weniger modernen Browsern/ohne CSS dennoch meine Layoutvorstellungen darzustellen (andere bevorzugen dann ja den HTML-1-Look - Ansichtssache).

es gibt leute, die bevorzugen benutzerstylesheets - es muss nicht "html-1-look" sein - mein default-stylesheet ist durchaus ansprechend und lesbar, ich schalte bei bestimmten seiten gerne das css aus - besonders bei der wikipedia, weil ich einfach den restlichen "müll" nicht brauche

[Cybaer]

Hi,

wenn du noch nicht beim inhalt bist, musst du zuerst das menü überspringen, schaun ob dir der inhalt zusagt oder nicht, dann wieder nach oben udn weg

Ich weiß ja nicht, was Du für Menüs und Browsergrößen verwendest, aber ich verwende eigentlich so kleine Menüs, daß man noch auf 'nem Netbook der 1. Generation was vom Inhalt sieht. ;)

Aber ...

Und die Wikipedia-Navigation selbst steht im Quelltext noch vor dem Inhalt.
nicht wirklich, der inhalt kommt zuerst

... stimmt, da hatte ich mich verguckt.

Und bei so endlos langen Menüs wie bei Wikipedia, ergibt die Platzierung am Ende des Quelltextes auch einen Sinn. Aber i.A. dürften die Menüs wohl nicht soooo lang sein, oder? =:-)

dafür gibts einen link zum überspringen - aber die wahrscheinlichkeit, dass ich mir den inhalt durchlese ist größer als die, dass ich auf jeder "angeklickten" seite am menü interessiert bin ;)

Ja, OK - zumal bei solchen Monstermenüs wie bei Wikipedia. Aber wie gesagt: Das ist ja nun nicht gerade üblich ...

es gibt leute, die bevorzugen benutzerstylesheets - es muss nicht "html-1-look" sein

Also wenn ein TL dahingehend ausgelegt ist, daß das TL mittels CSS "überstimmt" wird, dann kann man auch mit Benutzerstylesheets ankommen. OK, ist natürlich die Frage, inwieweit der Autor meint, vom TL in diesem Fall überhaupt abweichen zu müssen (und die Elementen entsprechend auszeichnet).

Ansonsten: Du erdreistest dich, an fremder Leute Werke deine schnöde Hand anzulegen? Schäm dich! ;->

bestimmten seiten gerne das css aus - besonders bei der wikipedia, weil ich einfach den restlichen "müll" nicht brauche

Aha. Ich wechsel dafür einfach auf die Druckansicht. Die ist meistens frei von "Müll" ... :)

Gruß, Cybaer

[suit]

Ich weiß ja nicht, was Du für Menüs und Browsergrößen verwendest, aber ich verwende eigentlich so kleine Menüs, daß man noch auf 'nem Netbook der 1. Generation was vom Inhalt sieht. ;)

wenn das menü aus 4 punkte besteht (wie bei einem blog) oder ähnlichs, dann lass ichs mir einreden :D

Aber i.A. dürften die Menüs wohl nicht soooo lang sein, oder? =:-)
Das ist ja nun nicht gerade üblich ...

die seiten die ich so in den fingern haben sind üblicherweise welche von mittelständigen und großen wirtschaftsunternehmen - die haben ab und an produktpaletten mit sehr vielen punkten, darum erachte ich das als durchaus sinnvoll

Ansonsten: Du erdreistest dich, an fremder Leute Werke deine schnöde Hand anzulegen? Schäm dich! ;->

ja, und das sogar sehr oft - besonders auf webseiten auf denen ich öfter unterwegs bin lege ich gerne mal hand an - zb bei den orf-seiten die spaltenbreite, die wird beinhart geändert ;) nur werbung unterdrücken tu ich nicht, das finde ich unfair - die seitenbetreiber leben idr davon

Aha. Ich wechsel dafür einfach auf die Druckansicht. Die ist meistens frei von "Müll" ... :)

sowas ähnliches tu ich ja auch :D

[molily]

die pure abneigung begründet sich vor allem darauf, dass yaml extrem viel "müll" in den code verfrachtet - etwa wie beim css zen garden

Was meinst du mit Müll?

Der Code des CSS Zen Gardens erfüllt halt seinen Zweck.

eine vielzahl der elemente ist nicht notwendig und der code ist ungemein aufgebläht

Jeena Paradies und ich hatten vor vielen Jahren eine lange Diskussion mit dem YAML-Autor Dirk Jesse darüber. Die Wrapper-Elemente sind notwendig, um die vom Framework beworbene Flexibilität zu bieten. Uber das einmal gewählte Layout hinaus soll eine radikale Umgestaltung möglich sein, ohne HTML- und CSS-Grundgerüst anfassen zu müssen. Das betrifft vor allem die logische Reihenfolge, die unabhängig vom einen oder anderen mit YAML möglichen Layout sein soll.

ein essentieller vorteil von css-basierenden layouts ist es, ein semantisch vernünftig strukturiertes dokument so hinzubekommen, dass es visuell durch pures css umgestaltbar ist

Und dem wiederspricht YAML? Warum?

selbrige logische festzimmerei findet man auch bei grid-basierenden framewords wie etwa yaml

Ich glaube, da hast du etwas grundsätzlich missverstanden, jedenfalls war das Gegenteil der Fall, als ich das letzte Mal mit YAML gearbeitet habe. Und YAML ist auch kein (konzeptionell) Grid-basiertes Framework. Lies dir doch mal die vielen Artikel dazu in Dirk Jesses Weblog an.

Mathias

[suit]

Was meinst du mit Müll?

eben all diese überflüssigen elemente welche die sache flexibler machen - aber das sagst du weiter unten ja bereits

Der Code des CSS Zen Gardens erfüllt halt seinen Zweck.

ja, das steht da auch klar dort, dass da viel zeug unnötig ist ;) das war in keinster weise ein angriff

aber im praktischen betrieb ist das einfach alles viel zu viel

Und dem wiederspricht YAML? Warum?

ich sehe yaml als komplettpaket welches html UND css liefert - das html mag flexibel gestaltbar sein, aber nachdem yaml als framework geliefert wird, hab ich da eben dinge dabei die ich so nicht einbauen würde weil einfach viel zu viel drinnen ist - dinge die viele sonderlösungen und umstände vorsehen, die eher selten anzutreffen sind - sollte sowas wirklich mal nötig sein, kann man notfalls das html ändern (auch wenns eher uncool ist)

aber mit einer template-engine ist das nicht das problem

Ich glaube, da hast du etwas grundsätzlich missverstanden, jedenfalls war das Gegenteil der Fall, als ich das letzte Mal mit YAML gearbeitet habe. Und YAML ist auch kein (konzeptionell) Grid-basiertes Framework.

mir ist klar, dass das bei yaml flexibel ist und nicht wie bei konventionellen grids vorgegeben ist - nur der ganze payload der dabei ist, für meinen geschmack "etwas zu viel" - wie schon irgendwo in diesem thread erwähnt: wer einen tooltip mit javascript machen möchte, muss sich nicht gleich mootools oder prototype (oder wie die alle heissen) anschaffen

KISS halt

[molily]

wer einen tooltip mit javascript machen möchte, muss sich nicht gleich mootools oder prototype (oder wie die alle heissen) anschaffen

Wer einen Tooltip machen will, braucht:

• Ansprechen von Elementen anhand von einfachen Selektoren (mindestens Klassen oder Nachfahrenselektoren)
• Event-Handler registrieren
• Zugriff auf Event-Target und Mausposition relativ zum Dokument
• DOM-Methoden zum Einbauen des Tooltip-Elements
• Evtl. Timeout-basiertes Ein- und Ausblenden bzw. Animationen zum Ein- und Ausfaden

Und das ganze bitte Cross-Browser.

Eigentlich Standardsachen, die man in jedem DOM Scripting braucht. Sorry, aber das kann man nicht ohne ein (Minimal-)Framework umsetzen, es sei denn, man scheißt auf Abstraktion, wiederholt den ganzen Quark in jedem Script von neuem und macht die ganzen Cross-Browser-Sachen zu Fuß. Der Code, der herauskommt, ist alles andere als toll.

Man kann sich natürlich 15 zusammenhanglose Helferfunktionen zusammensuchen, die die obigen Aufgaben erfüllen, und mühsam aufeinander abstimmen. Dann bin ich auch schon bei 10 KB, um erstmal schmerzlos und aufgeräumt mein Tooltip programmieren zu können...

Frameworks zu verwenden spart einfach Zeit, macht Code lesbar, weil er ständige Wiederholung vermeidet und Funktionalität zentral auslagert. Und da sie meist ausgereifte und empfehlenswerte Design-Pattern vorgeben, kommt etwas besseres raus als bei zusammenhanglosen Helferfunktionen.

Mathias

[Andreas]

hmmm ich denke ihr habt mich davon überzeugt, dass es am besten ist alles komplett selbst zu machen.

Könnt ihr mir ein gutes Buch empfehlen, dass sich mit der Erstellung von CSS-Layouts beschäftigt. Schön wäre ein deutsches Buch.

[suit]

Könnt ihr mir ein gutes Buch empfehlen, dass sich mit der Erstellung von CSS-Layouts beschäftigt. Schön wäre ein deutsches Buch.

das wobei dir yaml usw hilft, ist ein ein paar zeilen abgehandelt:
http://www.css4you.de/wslayout1/index.html

für das innen drin (also das zeug, dass dir yaml nicht abnimmt) würde ich diesen artikel empfehlen

für jedes "modul" (suche, navigation, seitenkopf) usw gibts ein paar empfehlenswerte artikel - das ganze sinnvoll in ein buch zusammengetragen hat aber meines wissens noch keiner ;)

[Andreas]

das wobei dir yaml usw hilft, ist ein ein paar zeilen abgehandelt:
http://www.css4you.de/wslayout1/index.html

für das innen drin (also das zeug, dass dir yaml nicht abnimmt) würde ich diesen artikel empfehlen

Zwei fragen dazu:

1.)
Über den ersten Link finde ich ja u.a. ein paar CSS-Layout-Vorlagen. Berücksichtigen die denn auch die ganzen Browserbugs?

2.)
Gibt es auch einen deutschen Artikel für das "innen drin" den du mir empfehlen kannst? Mein Englisch ist nicht das beste.

[suit]

Über den ersten Link finde ich ja u.a. ein paar CSS-Layout-Vorlagen. Berücksichtigen die denn auch die ganzen Browserbugs?

nein - aber die meisten browserbugs werden dir nicht bei der struktur der seite begegnen sondern beim formatieren des inhalts (meine erfahrung) dabei würde dir yaml auch nicht helfen

aber auch yaml verhindert prinzipiell nicht alle bugs, nur viele - die meisten wirklich komplizierten bugs treten unter extrem absurden konstruktionen um

die gewöhnlichen bugs hat man schnell im griff (double float margin left, 3-pixel-bug usw)

2.)
Gibt es auch einen deutschen Artikel für das "innen drin" den du mir empfehlen kannst? Mein Englisch ist nicht das beste.

irgendwo gibts eine seite, die ala-artikel übersetzt ;)

[luti]

nein - aber die meisten browserbugs werden dir nicht bei der struktur der seite begegnen sondern beim formatieren des inhalts (meine erfahrung) dabei würde dir yaml auch nicht helfen

Naja, auch da gibt es ja schon Hilfestellungen ...

die gewöhnlichen bugs hat man schnell im griff (double float margin left, 3-pixel-bug usw)

Die gibt es aber zahlreich ... und ich habe zumindest keine Lust, mich damit mehr als irgend nötig beschäftigen zu müssen ;)
Grüße,
luti

[ChrisB]

Hi,

die gewöhnlichen bugs hat man schnell im griff (double float margin left, 3-pixel-bug usw)

Die gibt es aber zahlreich ... und ich habe zumindest keine Lust, mich damit mehr als irgend nötig beschäftigen zu müssen

Dann beschaeftige dich mit ihnen dann, wenn sie auftreten.

Kontrolle in den aktuellen Versionen aller relevanten Browser ist sowieso ein Muss, und dabei merkt man dann ja, wenn wo was schief laeuft.

MfG ChrisB

[molily]

hmmm ich denke ihr habt mich davon überzeugt, dass es am besten ist alles komplett selbst zu machen.

Das ist es sicher nicht, schließlich steckt darin sehr viel Know-How und Praxiswissen, über das man als Anfänger erstmal nicht verfügt. Es ist aber sinnvoll, zu verstehen, wie Frameworks wie YAML arbeiten. Dazu hat YAML z.B. eine ganz gute Dokumentation: http://www.yaml.de/de/dokumentation/grundlagen/allgemeines.html

Siehe auch:
http://de.selfhtml.org/css/layouts/einfuehrung.htm
http://aktuell.de.selfhtml.org/weblog/css-spaltenlayout

Mathias

[luti]

Hallo,

seid einiger Zeit Verwende ich YAML. Bis eigentlich ziemlich begeistert von diesem Framework. Allerdings scheinen da nicht alle meine Meinung zu teilen. Wäre super wenn ihr mir sagen könntet was ihr von YAML haltet...

Wenn DU begeistert bist, scheint mir das für DICH doch das wichtigste Kriterium zu sein ;)

Jedenfalls bin auch ich restlos begeistert von YAML! Best ever! Mit YAML als Grundlage lässt sich in geringer Zeit ein solides Layout erstellen, das funktioniert. Und das ganz ohne sich den Kopf über IE Version xyz zerbrechen zu müssen, der mal wieder nicht macht, was man ihm sagt. Das hat mir wirklich schon einiges an Arbeit erspart. Auf keinen Fall möchte ich zurück in die Zeit, wo ich noch alles von Hand gestrickt habe ...

Die Kritiken verstehe ich nicht wirklich. Ich binde doch immer nur die 4-5 angepassten Dateien ein, die ich auch tatsächlich benötige. Das finde ich nicht sonderlich aufgebläht.

Und seit wann ich YAML Grid-basiert? Verstehe ich auch nicht. Ich mache mit YAML keine Grid-Layouts.

Das gute an dem Konzept ist doch gerade, dass ich keine Schablone (fertiges Layout) habe, dass ich hier und da anpasse. Ich nutze das Framework lediglich als Basis, die mir die DIVs generiert und hilft, mit Browser-Inkompabilitäten umzugehen. Das spätere Aussehen der Seiten hat dann nichts mehr mit YAML zu tun.

So long,
luti

[suit]

Und seit wann ich YAML Grid-basiert? Verstehe ich auch nicht. Ich mache mit YAML keine Grid-Layouts.

ist das jetzt ein scherz? yaml ist das was klassischerweise als grid bezeichnet wird ;)

http://www.yaml.de/de/home/news/details/article/46/yaml-305-v.html?cHash=4902fb229e&no_cache=1&sword_list[0]=grid

Das gute an dem Konzept ist doch gerade, dass ich keine Schablone (fertiges Layout) habe, dass ich hier und da anpasse.

genau dafür ist yaml da - es erlaubt dir die struktur der seite zu bilden - das innen drinnen musst du selbst machen und genau dafür ist ein FRAMEwork, grid (wie auch immer man es nennen will) da

Ich nutze das Framework lediglich als Basis, die mir die DIVs generiert und hilft, mit Browser-Inkompabilitäten umzugehen. Das spätere Aussehen der Seiten hat dann nichts mehr mit YAML zu tun.

das ist mir klar und genau diese "basis" versaut die logische abfolge deines dokuments ;)

[luti]

Hallo,

ist das jetzt ein scherz? yaml ist das was klassischerweise als grid bezeichnet wird ;)

http://www.yaml.de/de/home/news/details/article/46/yaml-305-v.html?cHash=4902fb229e&no_cache=1&sword_list[0]=grid

Genau den Artikel hatte ich mir auch noch mal angeschaut, als ich mein Posting verfasst habe ... Man _kann_ eben auch Grid-basierte Layout erstellen. Genauso gut kann man aber auch Spalten-basierte Layouts erstellen ...

genau dafür ist yaml da - es erlaubt dir die struktur der seite zu bilden - das innen drinnen musst du selbst machen und genau dafür ist ein FRAMEwork, grid (wie auch immer man es nennen will) da

Bin ganz Deiner Meinung. Wollte diesen Punkt nur klar stellen ;) Nicht, dass der falsche Eindruck entstünde, es ginge hier um Layout-Vorlagen ...

das ist mir klar und genau diese "basis" versaut die logische abfolge deines dokuments ;)

Hm? Du kannst die Reihenfolge der Spalten doch selber festlegen?! Bei YAML wird doch _gerade_ auf Benutzerfreundlichkeit wert gelegt, bzw. hatte ich diesen Eindruck. (siehe auch Barrierefreiheit & Webstandards

Grüße,
luti

[suit]

Hm? Du kannst die Reihenfolge der Spalten doch selber festlegen?! Bei YAML wird doch _gerade_ auf Benutzerfreundlichkeit wert gelegt, bzw. hatte ich diesen Eindruck.

die reihenfolge der spalten reicht nicht - das menü sollte imho hinter dem eigentlich nutzinhalt sein

was machst du bei einem klassischen layout mit navigation oben und mehrspaltiger inhalt unten? ;)

[luti]

Hallo,

die reihenfolge der spalten reicht nicht - das menü sollte imho hinter dem eigentlich nutzinhalt sein

was machst du bei einem klassischen layout mit navigation oben und mehrspaltiger inhalt unten? ;)

Wie wäre es mit Skip-Links?

Auf der Seite wird argumentiert, dass ein Benutzer auch gerade nicht am Inhalt, sondern am Menü interessiert sein könnte - was mir irgendwie einleuchtet ...

Ansonsten scheint es aber auch da schon Lösungen, z.B. für Typo, zu geben: Barrierefreie Menüs mit TYPO3.

Grüße,
luti

[suit]

Wie wäre es mit Skip-Links?

das ist eine peinliche ausrede, mehr nicht - wie oft bist du am menü einer seite interessiert? gewöhnlicherweise nach dem lesen des inhalts, wenn du zum nächsten punkt weiter willst

nicht bei jedem seitenaufruf

Auf der Seite wird argumentiert, dass ein Benutzer auch gerade nicht am Inhalt, sondern am Menü interessiert sein könnte - was mir irgendwie einleuchtet ...

klar, ich bin bei jeder seite die ich lese am menü interessiert, wenn ich das aufmerksam gelesen habe (etwa zum 10. mal) dann komme ich zum inhalt

Ansonsten scheint es aber auch da schon Lösungen, z.B. für Typo, zu geben: Barrierefreie Menüs mit TYPO3.

das ist keine lösung sondern eine katastrophe

kein klares beispiel dafür, dass jemand der nicht viel ahnung von typo3 oder typoscript hat[1], versucht irgendwelche tipps zu geben und dann einfach mal ein php-script rausrotzt - tolle lösung :D wenn man ein cms verwendet und für jeden käse ein script braucht, ist das schon traurig - besonders dann, wenn das cms das schon kann

zudem hat dies nichts mit der reihenfolge des codes zu tun ;) es erzeugt lediglich ein menü als unsortierte liste mit zusätzlichem "blah" welches ich selbst als eher hinderlich als barrierefrei erachte - eine navigation zu nummerieren ist etwas ungünstig für screenreaderbenutzer, wenns schon sein muss, dann bitte standardkonform als ordered list (das ist aber jetzt themenverfehlung, dazu hab ich mich schon mal an anderer stelle geäussert)

[1] sagte ich eigentlich schon, dass es extrem viele leute gibt, die keine ahnung von typo3 haben und dann teils "fahrlässige" dinge empfehlen - mit 10 zeilen typoscript wovon eigentlich nur eine notwendig wäre?

[ChrisB]

Hi,

Die Kritiken verstehe ich nicht wirklich. Ich binde doch immer nur die 4-5 angepassten Dateien ein, die ich auch tatsächlich benötige. Das finde ich nicht sonderlich aufgebläht.

Redest du jetzt von 4-5 einzelnen CSS-Ressourcen, also 4-5 HTTP-Requests, fuer das *Grundlayout* *einer* Seite?

MfG ChrisB

[molily]

Redest du jetzt von 4-5 einzelnen CSS-Ressourcen, also 4-5 HTTP-Requests, fuer das *Grundlayout* *einer* Seite?

Die Aufteilung von CSS in Dateien dient der Übersicht des Entwicklers, der Modularisierbarkeit usw. Der HTTP-Client, der meine Style-Regeln auf ein Dokument anwenden soll, interessiert sich natürlich nicht für meine interne Aufteilung - es sei denn, die Modularisierung dient letztlich auch den Ladezeiten. Aber deshalb schreibe ich noch längst nicht allen Code in eine CSS-Datei - kann ihn aber durchaus in einer HTTP-Ressource ausliefern, indem ich ihn mit cssmin oder YUI Compressor zusammenfasse und komprimiere.

Mathias

[Joachim]

Hi,

Wäre super wenn ihr mir sagen könntet was ihr von YAML haltet...

ich habe einen grösseren Webauftritt mit yaml umgesetzt, zugegebenermassen nicht freiwillig.

Fazit: grundsätzlich bietet ein Framework wie yaml vor allem dem eine Hilfe, der keine Lust oder Erfahrung hat, sich mit den jeweiligen Browserbefindlichkeiten auseinanderzusetzen. Vorraussetzung ist aber die Einarbeitung in die Idee von yaml, insbesondere wenn man die Beispiel-Strukturen nicht komplett übernehmen möchte. Dann jedoch leistet yaml gute Dienste, vor allem bei mehrspaltigen Layouts.

Ich persönlich arbeite dennoch lieber ohne Framework. Zum einen habe ich genug Erfahrung, um mit den Standard-bugs klarzukommen, zum anderen hatte ich zuweilen Probleme beim Entwickeln, die sich auf die globalen Vorgaben des Frameworks zurückführen liessen. Ausserdem ist es natürlich reichlich viel Code...

Auf alle Fälle empfiehlt sich durchaus ein Blick in den Code, denn einiges ist recht intelligent gelöst.

Gruesse, Joachim

[suit]

Auf alle Fälle empfiehlt sich durchaus ein Blick in den Code, denn einiges ist recht intelligent gelöst.

wie bereits erwähnt würde ich da eher einen blick in yui riskieren, das ist ÄUSSERST intelligent gelöst (wenn man das mit yaml vergleicht)