Teen pornhub porn videos watched. xnxx webcam porn video online stream tv.

BlogPimp

Tipps, Empfehlungen und News aus dem Web.

 

Weblog
Empfehlungen

Impressum
wer steckt dahinter

 

Blog:
Der direkte Vergleich: YAML / GridEasy

02.06.08 – 09:23 Uhr

Mein letzter Beitrag Die Schlacht um den richtigen Weg hat ja einigen Wirbel hier und in anderen /Blogs verursacht. Die Diskussion war gezeichnet von persönlichen Meinungen, Fakten waren eher weniger vertreten. Um das Ganze besser beurteilen zu können, möchte ich hier einen konkreten Praxisfall präsentieren.

Ich habe eine Projektvorlage von YAML.de geladen und so ähnlich wie möglich mit GridEasy nachgebaut. Das Ergebnis sind zwei Webseiten, die fast identisch aussehen, deren Funktion sich aber in einigen wesentlichen Punkten unterscheidet. Die mit YAML gebaute Webseite könnt Ihr Euch hier ansehen, die mit GridEasy gebaute hier.

Auf den ersten Blick sehen sich die Seiten zum Verwechseln ähnlich, auf den zweiten Blick gibt es aber wesentliche Unterschiede. Hier zum Vergleich erst einmal ein paar nackte Zahlen:

|_.  |_. GridEasy|_. YAML|
|Größe des Frameworks|13 Dateien|38 Dateien|
|Umfang des Frameworks|11.400 Bytes|240.027 Bytes|
|Ganze Webseite Ordner|2 Ordner|20 Ordner|
|Ganze Webseite Dateien|17 Dateien|57 Dateien|
|Ganze Webseite Bytes|22.981 Bytes|507.041 Bytes|
|Anzahl geladener Dateien|5 Dateien|8 Dateien|
|Größe der geladenen Dateien|9.059 Bytes|23.631 Bytes|
|Anzahl der DIV-Container|8 DIVs|15 DIVs|

Ich habe zwecks besserer Vergleichbarkeit in den Original-Projekt-Dateien von YAML die ausführlichen Kommentare gelöscht. Da sich viele dieser Kommentare auf Seitenelemente bezogen, die bei GridEasy gar nicht benötigt werden, ist der Vergleich so meines Erachtens fairer.

Wie gesagt, die Webseiten sind, unabhängig von benutzten Framework, optisch nahezu identisch, die minimalen Unterschiede fallen nur auf, wenn man beide Seiten nebeneinander betrachtet.

Kommen wir zum dem, was die beiden Seiten tatsächlich unterscheidet und der YAML-Lösung angeblich den entscheidenden Vorsprung geben soll. Die Lösung mit GridEasy ist ein sogenanntes statisches Seiten-Layout. Das heißt, dass die Gesamtbreite der Seite ebenso wie die Breite der Spalten fest definiert sind. Wenn ich im Browser die Schriftart vergrößere, so verändert sich die Spaltenbreite nicht. Die Lösung mit YAML ist ein sogenanntes flexibles Seiten-Layout. Das heißt, dass sich sowohl die Breite der gesamten Seite, als auch die Spaltenbreite an die Schriftgröße und das Browserfenster anpassen.

Theoretisch ist das flexible Layout natürlich eine gute Idee. Betrachtet man die YAML-Webseite im Firefox 2, dann stimmt das auch so, wie es YAML verspricht. Wenn man die Schrift vergrößert (z. Bsp. durch drücken Strg +), dann verbreitern sich alle Seitenelemente bis zu einer voreingestellten Maximalbreite oder bis das Browserfenster gefüllt ist. Dann wird nur noch die Schrift größer, die Spalten und die gesamte Seite wachsen nicht mehr.

Leider gilt das aber nur für den Firefox der Generation 2. Im aktuellen Internet-Explorer 7.0, im aktuellen Opera-Browser 9.27 und auch im Firefox 3, der in Kürze die Version 2 ablösen wird, funktioniert das leider gar nicht so wie versprochen. In allen diesen Browsern verbreitern sich die Spaltenbreiten und die Gesamtbreite der Webseite nahezu grenzenlos, was bei einer Browserfensterbreite von 1024 Pixeln schon bei einer Schriftvergrößerung von 30% bis 50% zur horizontalen Scrollleisten führt. Das heißt, um die Seite zu lesen muss man nicht nur vertikal, sondern auch noch horizontal scrollen (siehe Screenshots unten).

Die YAML-Seite im Internet Explorer 7.0, Zoom auf 150%.

Die YAML-Seite im Opera 9.27, Zoom auf 150%.

Die YAML-Seite im Firefox 3.0 RC1, Zoom auf 150%.

Und nicht nur, dass die Seiten “überlaufen”, auch die Verbreiterung der Spalten ist, wie man in den Screenshots sehr schön sehen kann, in jedem Browser anders und keinesfalls analog zur Schriftgröße. Wer Mathematik bisher für eine exakte Wissenschaft hielt, wird durch die Browserhersteller eines Besseren belehrt.

Fassen wir zusammen: Die viel gepriesenen Vorteile des flexiblen Layouts sind bei Licht und am realen Beispiel betrachtet gar nicht existent. Anpassung an das Browser-Fenster? Fehlanzeige. Die Zeilenlänge bleibt beim Zoomen gleich? Auch nur ein Traum. Betrachtet man das ganze auf einem wirklich kleinen Bildschirm, zum Beispiel einem Handy, dann wird es noch schlimmer. Da ist dann nicht mal mehr eine einzelne Spalte in kompletter Breite sichtbar, es sei den der Provider zoomt die Seite vor der Ãœbertragung an das Handy selbstständig herunter (was einige Provider für Internet über Handy tun) oder aber das Handy hat einen intelligenten Browser eingebaut, der das erledigt. In den beiden Fällen brauche ich dann aber auch kein flexibles Layout, weil ja nicht das Layout die Darstellungsgröße steuert.

Was bleibt? Dass YAML eigentlich eine sehr gute Idee verfolgt. Aber leider, ohne Rückendeckung durch die Browserhersteller. Und damit wird die gute Idee leider weitestgehend wertlos. Die Vorteile sind akademisch, das heißt, sie sind nur in der Theorie vorhanden, im realen Leben mit einem realen Browser betrachtet leider meistens nicht.

Dafür muss ich dann aber 8 statt 5 Dateien vom Server laden, um die gleiche Darstellung der Webseite zu erzielen, mit 23.631 Bytes Umfang statt 9.059 Bytes. Und ich muss im (X)HTML 15 DIVs bemühen, die Seite zusammen zu halten statt derer 8. Nah danke. Das sieht für mich nicht nach der Zukunft des Webdesigns aus. Und Dirks Titel “Flexible Layouts vs. Fixe Layouts – 5:0″ erlaube ich mir auch mal anzuzweifeln.

geschrieben von BlogPimp | gespeichert unter Blog |

2 Trackbacks

  1. [...] geschafft. Siehe: Technikwürze 110 – Buntes am Sonntag, ebenfalls beschäftigt sich Der direkte Vergleich: YAML / GridEasy auch mit diesem Thema, wenn auch nur [...]

  2. [...] Der direkte Vergleich: YAML / GridEasy von Lothar Baier [...]

23 Kommentare

  1. schrieb am 02.06.08 um 09:57 Uhr: | Permalink

    Sehr gute Ausführung! (gebookmarkt unter argumentationshilfen)

    bin neulich nach dem Erstellen eines flexiblen Layouts zur gleichen Meinung gekommen.

    Wenn die Browserhersteller für die Zoombarkeit von Seiten sorgen muss man sich als Webdesigner nicht wirklich gedanken um flexible layouts machen.

  2. schrieb am 02.06.08 um 10:10 Uhr: | Permalink

    Hallo Lothar,

    ich nehme für mich in Anspruch, nicht nur eine Meinung zu haben, sondern diese auch durchdacht zu haben und mit Fakten belegen zu können. Schade, daß Du mir das nicht zutraust. Dein Artikel belegt aber auch leider nichts Gegenteiliges.

    Ich habe nun schon in vielen Kommentaren und in einem Artike versucht, Dir meinen Standpunkt zu erklären. Mir geht es nicht um ein flexibles Layout. Dirk vielleicht, mir nicht. Aber versuch doch mal bitte, nur mit Änderungen am CSS, col1 und col3 zu vertauschen und zusätzlich die Breiten zu verändern. Bei YAML geht das schnell und simpel. Grid-Frameworks können das “by Design” nicht. DAS ist mein Punkt, der in Deinem Artikel leider nicht angesprochen wird.

    Und bitte korrigiere Deinen interessanten Vergleich mit korrekten Daten. Nutze als erstes die für den Produktionsalltag vorgesehenen Dateien. Sie sind zusammengefaßt und hne Kommentare und dadurch leichter. Wer dies nicht tut hat wahrsceinlich die Anleitung nicht (vollständig) gelesen.

    Zudem vergleiche dann noch fixes (nicht statisches!) Layout mit fixem Layout. Dafür kannst Du bei YAML bswp. die ganzen inneren DIV löschen, denn die sind nur ein Angebot. Du verschweigst leider, daß YAML so konstruiert ist, daß Dir immer mehr angeboten wird, als Du benötigst.

    Der Vergleich ist interessant, aber leider nicht korrekt. Und ich warte auf die Möglichkeit, mit GridEasy schnell die Spalten zu vertauschen und zu modifizieren. Nur mit CSS!!!! Und bitte eine freie Einteilung der Spaltenbreite, denn YAML interessiert sich nicht für ein festglegetes Raster. Jedes Raster ist möglich. DAS ist der Praxistest, den ICH erwarte.

  3. schrieb am 02.06.08 um 10:41 Uhr: | Permalink

    Hallo, Jens.

    Ich habe mir die Freiheit genommen, den Praxistest zu machen, den ich für den richtigen halte. Nämlich YAML-Out-of-the-Box gegen GridEasy-Out-of-the-Box. Und halt nicht nach Deiner Idee von der Zukunft des Web, sondern nach den Regeln, die von den Browsern heute vorgegeben sind. Das nämlich ist die Praxis.

    Daran ändert auch nichts, dass mir YAML immer mehr anbietet, als ich brauche. Da ich dieses Mehr nicht brauche, habe ich keinen Vorteil davon. Aber Nachteile, was die Anzahl der zu ladenden Dateien und die Menge der zu übertragenden Bytes angeht. Das ist die Praxis.

    Worin liegt denn der Vorteil eines Frameworks, wenn ich erst stundenlang aus 38 Dateien alles das herauslöschen muss, was ich für das gegenwärtige Projekt nicht brauche? Da kann ich die 100 Zeilen CSS, die ich für die Positionierung brauche auch gleich selbst schreiben und brauche gar kein Framework zu bemühen.

    Und der Vergleich ist, so wie ich ihn gemacht habe und auch so wie ich ihn beschrieben habe, völlig korrekt. Ich habe ihn nämlich so durchgeführt, wie man üblicherweise so ein Framework einsetzen würde, nicht nach dem, was theoretisch möglich ist.

    Der einzige Vorteil von YAML, der nach meiner Betrachtung bleibt, ist tatsächlich die Möglichkeit, die Reihenfolge der Spalten nachträglich auszutauschen, ohne das HTML ändern zu müssen. Das geht bei GridEasy tatsächlich nicht.

    Aber mal ganz ehrlich, so von Praktiker zu Praktiker: Wie oft hast Du bei einer Webseite, nach dem sie einmal online war, noch die Reihenfolge der Spalten getauscht? Auch hier reden wir nur von Theorie, aber nicht von Praxis. Ich jedenfalls habe das in den 14 Jahren, in denen ich nun Webseiten baue, noch kein einziges Mal tun müssen.

    P.S.: Wenn Du einen anderen Praxistest erwartest, wirst Du ihn schon selbst machen müssen. Ich freue mich schon auf den passenden Beitrag.

  4. schrieb am 02.06.08 um 11:06 Uhr: | Permalink

    Hallo Lothar,

    ist es denn nicht die Idee eines Frameworks, Dir möglichst umfassend Problemlösungen anzubieten? Wie soll es das allgeimeintauglich tun, wenn es Dír nicht mehr anbeitet, als Du brauchst? Von jQuery benötige ich auch nicht alles. Im Gegensatz zu YAML kann ich aber aus jQuery nichts rausstreichen. Und Dein Praxistest ist halt falsch, wenn du YAML ohne nachzudenken out-of-the-box nutzt. Deine störrische Antwort läßt mich eher vermuten, daß Du auf alle Fälle ein negatives Ergebnis (bzw. für Dich positives) haben möchtest. Ich hoffe, dieser Eindruck täuscht.
    Dein Verlgeich ist falsch/verfälschend. Du müßtest es besser wissen, Du hast früher YAML genutzt. Es gibt bewußt eine umfangreiche Version, in der alle Kommentare sind und eine komprimierte.

    Klar positioniert man seltener etwas um, höchstens in einem Klickdummy. Da spielen Frameworks auch ihre Stärken aus, denn ich kann mit dem gleichen Code zwei unterschiedliche Layouts präsentieren.

    Aber Deine ausweichende Antwort zeigt mir, daß nun endlich nach dem x-ten Kommentar mein Thema in Deinem Kopf verstanden wurde. Daß Du dies erstmal als irrelevant zur Seite schiebst ist Dein Problem, nicht meines.

  5. schrieb am 02.06.08 um 11:42 Uhr: | Permalink

    Hallo Lothar,

    vielen Dank für diesen Vergleich beider Systeme und Deiner Kritik an YAML, welche ich hier gern kommentiere.

    Zu den nackten Zahlen: Die ersten vier Zeilen der Tabelle haben mit den beiden Layoutumsetzungen gar nichts zu tun. Sie bestätigen lediglich, was die jeweiligen Projektseiten bereits erahnen lassen. YAML hat einen ungleich größeren Funktionsumfang als GridEasy und behinhaltet im normalen Download-Paket bereits zahlreiche Anwendungsbeispiele, daher die größere Anzahl an Dateien, Odnern und Bytes. Zu den angegebenen Dateigrößen will ich nichts sagen, sie sind einfach nicht nachvollziehbar, zumal Du Notwendiges mit Optionalem und Beispielhaftem willkührlich vermengst und zudem noch unkommentiert dem Leser präsentierst.

    Kommen wir zur HTML-Umsetzung: Du machst Dir zwar Gedanken für eine möglichst schlanke Umsetzung des Layouts mit GridEasy, wendest diese Gedanken auf die YAML-Umsetzung aber nicht an, um später mit ein paar weniger DIVs glänzen zu können. Im Detail: Die Container #page, #main, #topnav und #nav könnten bei identischem CSS auch bei der YAML-Variante eingespart werden. Berücksichtigt man diese etwas einseitige Optimierung (Denk an das TOP-DOWN-Prinzip von YAML: Wegnehmen, was nicht benötigt wird!), sieht der Container-Vergleich schon anders aus. Einsparpotential sehe ich bei einem fixen Layout bei den #colx_conten-Containern, die Du in deiner Fassung auch entfernt hast, bei YAML sind sie noch enthalten.

    Ein objektiver Vergleich basiert immer auf identischen Rahmenbedingungen. Du erstellst dafür aber nicht etwa mit beiden Systemen ein identisches fixes und ein flexibles Layout. Nein, GridEasy bleibt fix (geht ja auch nicht anders) und YAML bleibt flexibel (fix wäre problemlos möglich). Du vergleichst lieber Äpfel mit Birnen. Ich bin Dir daher wegen der mangelnden Optimierung auch gar nicht böse, denn somit bleiben die Vorteile von YAML erhalten – die Flexibilität und Robustheit in allen Dingen.

    Kommen wir zum nächsten Punkt, die sagenhafte Auflösung von 1024 Pixeln. Wie ein Artikel bei SelfHTML aus dem Jahre 2006 zeigt, hatten schon damals 67% der Anwender höhere Auflösungen. Auf YAML.de ist dieser Wert laut Statistik mittlerweile auf 16% gefallen. Die ganze Diskussion um flexible Layouts dreht sich aber um nicht um extem niedrige Auflösungen sondern um das genaue Gegenteil. Doch auf diesen Umstand gehst Du gar nicht ein. Darf ich fragen warum? Und gleich noch eine Frage: Wie schlägt sich denn GridEasy unter diesen Bedingungen? Hast Du dafür auch ein paar Screenshots mit hässlichen horzizontalen Scrollbalken parat? Für einen objektiven Vergleich wäre diese sehr interessant, doch diese Ergebnisse verschweigst Du lieber, obwohl wegen fehlender Grafiken im Layout das Ergebnis vermutlich noch recht brauchbar wäre – jedoch gewiss nicht besser als bei YAML – unter diesen Bedingungen.

    Kommen wir zum Kern deiner Argumentation: Dein Zoom-Test bei 150%, auf dessen Grundlage Du flexibles Layouts für die Praxis generell in Frage stellst, geht nämlich sowohl im Firefox 2 und 3, als auch im Opera 9.x bereits bei JEDER größeren Auflösung, angefangen bei 1152×864, ohne horizontale Scrollbalken auf. Damit löst sich dein wichtigstes Argument quasi in Wohlgefallen auf, denn während das YAML-Layout dank intelligentem Zoom in Opera und Firefox 2 und 3 bei jeder größeren Auflösung perfekt skaliert, kann GridEasy in all diesen Fällen nicht punkten.

    Nun zur Flexibilität der Framework-Konzepte selbst. Du wirst nicht müde, das Thema Praxis vorzuschieben. Du behauptest auch immer wieder, als Entwickler die Layoutvorlagn des Kunden schnell und pixelgenau umsetzen zu müssen. Wie erklärst Du dann deinem Kunden, dass Du nur Layouts mit einem konstanten Rasterabstand von 10 Pixeln umsetzen kannst? In diesem Beispiel hast Du das große Glück, dass die YAML-Vorlage ebenfalls runde Pixelwerte verwendet. Doch während man bei YAML mit einer Zeile CSS diesen Abstand und jede Spaltenbreite auf einen x-beliebigen Wert (in px|em|% …) setzen kann – ohne, dass dem Layout etwas passiert, bricht GridEasy – wie ALLE Grid-Frameworks ebenfalls – wie ein Kartenhaus in sich zusammen. Oder zwingst Du den Kunden und Grafikern etwa DEINE Vorstellungen für das Raster auf?

    Das gesamte feste Grid ist damit für diesen einen Anwendungsfall relevant. Jens hat die Problematik bereits erläutert. Mit Flexibilität hat das in meinen Augen sehr wenig zu tun, denn es reduziert in erheblichem Maß die Freiheit des Grafikers – auch bei fixen Layouts. Individuelle Anpassungsmöglichkeiten im Raster sind schlichtweg nicht möglich oder enden in einem weitern Framework, welches dann wieder unter einem neuen Namen veröffentlicht wird und dann auf Deiner Vorarbeit basiert.

    Und noch ein Hinweis zu Deinem Kommentar zum Tauschen der Spalten. Wer soetwas nachträglich erledigen muss, hat bei der Layouterstellung nicht nachgedacht. Fakt ist, dass die suchmaschinenorientieren Layoutvarianten bei YAML extrem beliebt sind. Nicht zuletzt bei der Umsetzung fixer Layouts. Aber das braucht ja in der Realität wirklich keiner, wenn man Dir Glauben schenken darf. Schade, dass Du immer wieder so ausweichend argumentierst.

    Ich war bei Deiner Ankündigung des Vergleiches wirklich gespannt auf das Ergebnis, schließlich habe ich selbst einen solchen Vergleich zu Blueprint vor einigen Wochen in meinem Weblog veröffentlicht. Leider handtierst Du hier jedoch weder mit korrekten Zahlen, noch mit realen Randbedingungen (siehe 1024 Pixel). Du vermischt Notwendiges mit Optionalem, optimierst den Code einseitig, verschweigst die Ergebnisse Zoom-Problematik deiner Lösung vollständig.

    Du darft, was Flexibilität im Framework- und Layout-Design betrifft, gern anderer Meinung sein. Ãœberzeugt von den Vorteilen Deines Grids oder eines anderen Grid-Frameworks hat mich dieser Beitrag aufgrund der zahlreichen inhaltlichen Schwächen nicht. Und einen echten, praxisnaher Vergleich kann man das einfach nicht nennen.

    Sorry, dass es so lang geworden ist.

    Viele Grüße
    Dirk Jesse

  6. schrieb am 02.06.08 um 11:46 Uhr: | Permalink

    Korrektur zur Auflösungs-Statistik:

    2006 – > 67% größer 1024×768
    2008 (YAML-Website) -> 84% größer 1024×768

    Der YAML-Wert für 2008 ist sicher nicht repräsentativ fürs Web, zeigt aber deutlich die Entwicklung und diese ist repräsentativ belegt.

    Ich hatte oben die Prozentwerte etwas missverständlich angegeben.

    Gruß
    Dirk

  7. schrieb am 02.06.08 um 13:05 Uhr: | Permalink

    @ Jens >

    Du must endlich mal anfangen, andere Meinung genau so ernst zu nehmen, wie Deine eigene. Ich hab Dein Thema nicht erst jetzt verstanden, sondern gleich, nachdem ich Deinen Beitrag gelesen habe. Aber ich habe von Anfang an eine andere Meinung dazu. Und die vertrete ich auch von Anfang an.

    Nämlich das die Aspekte, die für Dich wichtig sind, im meiner Berufspraxis wenn überhaupt nur eine marginale Rolle spielen, aber andere Aspekte, die Du außen vor lässt, in meiner Praxis ganz wichtig sind.

    Und mir unfaires Testen vorzuwerfen, zeigt mir im besten Fall, dass Du den Beitrag oben nicht ganz gelesen hast. Diese Dateien mit der YAML-Lösung stammen nicht von mir, sondern vom Schöpfer von YAML, und zwar komplett. Dirk hat das genau so auf der YAML-Website publiziert. Ich war sogar noch so fair, das ich aus allen Projekt-Dateien (nicht jedoch aus dem YAML-Code) die Kommentare gelöscht habe vor dem Vergleich, damit das Ergebnis fair (und für YAML besser) ausfällt.

    Was an den puren Fakten unfair ist, kann ich nicht erkennen. Aber vielleicht haben wir zwei auch zum Thema Fairness unterschiedliche Meinungen.

  8. schrieb am 02.06.08 um 13:25 Uhr: | Permalink

    Diese Dateien mit der YAML-Lösung stammen nicht von mir, sondern vom Schöpfer von YAML, und zwar komplett. Dirk hat das genau so auf der YAML-Website publiziert.

    Worauf stützt sich Deine Behauptung, diese Grundlagenbeispiele stellen bereits dan optimierten Anwendungsfall dar? Die Beispiellayouts auf YAML.de sind bewusst in keiner Weise optimiert, weder im HTML, noch im CSS. Sie dienen lediglich zur Erläuterung der prinzipiellen Funktionsweise des Frameworks.

    Und wenn es für Deine Arbeit wirklich ein Randaspekt ist, warum gönnst Du Dir und deinen Lesern nicht wenigstens bei diesem Vergleich die notwendige Objektivität. Die entsprechenden Kritikpunkte habe ich oben bereits angeführt. Ich würde mich freuen, wenn Du darauf noch erklärend eingehen könntest.

    Gruß
    Dirk

  9. schrieb am 02.06.08 um 13:49 Uhr: | Permalink

    @ Dirk >

    Du musst erst mal meinen Beitrag lesen, dann meckern. Sonst ist das Ganze ein wenig peinlich.

    Die Zahlen in meiner Tabelle sind relevant und nachvollziehbar, weil ich ein komplettes Fallbeispiel von der YAML-Website verwendet habe. Und ich habe alle Readme-Dateien, Kommentare und anderes gelöscht. Was im Test verwendet wurde, hat weder Dokumentations-Dateien noch irgendwelche anderen Anwendungsbeispiele enthalten. Dies ist für jedermann nachvollziehbar, da ich beide Versionen online gestellt habe und jeder sich das Projektpaket selber herunterladen kann (Link oben im Beitrag).

    Zur HTML-Umsetzung schreibst Du, ich hätte meine Lösung gezielt schlank umgesetzt. Und bei der YAML-Version alles drin gelassen. Stimmt. Aber nur so konnte ich aufzeigen, mit welchem Overhead man sich die Vorteile von YAML erkauft. Die dann keine sind, weil die Browser damit leider anders umgehen, als Dir lieb ist.

    Und Du schreibst, ein objektiver Vergleich beruhe immer auf den gleichen Rahmenbedingungen. Eben. Der Vergleich ist YAML-Out-of-the-Box gegen GridEasy-Out-of-the-Box. Und nicht GridEasy als Out-of-the-Box-Paket gegen YAML nach stundenlangem Entfernen aller nicht benötigten Code-Bestandteile.

    Was die Browser-Auflösungen angeht, so freut es mich für Dich, das die YAML-Fans so große Bildschirme haben, aber das wahre Leben bildet auch das nicht ab. Nach den aktuellen Zahlen von Webhits.de (Stand 2.6.08, also heute) sind in Deutschland 46,1% aller Internetbenutzer mit Auflösungen von 800*600 bezw. 1024*768 unterwegs, das ist fast die Hälfte der Internetnutzer.

    Denen hilft es nicht wenn YAML jenseits von 1152 Pixeln Bildschirmbreite so zoomt, wie Du es vorgesehen hast. Die haben nämlich schlichtweg nicht soviel Bildschirmbreite. Und auch viele, die eine höhere Bildschirmauflösung haben, haben keinen größeren Viewport, also nutzbare Browserfläche. Weil sie in Ihrem Browser eine Sidebar mit den Bookmarks eingerichtet haben zum Beispiel. Daher war für den Test die Grundannahme einer nutzbaren Bildschirmbreite von 1024 Pixeln wohl durchaus angeraten.

    Und natürlich hast Du recht, dass bei der GridEasy-Variante auch horizontale Scrollleisten entstehen. Aber GridEasy behauptet von sich ja auch nicht, sich flexibel an das Browserfenster anzupassen. Im Gegensatz zu YAML.

    Obendrein solltest Du mal wieder selber mit aktuellen Browser-Versionen testen. Es ist nämlich schlichtweg falsch, das im Firefox 2 und 3 und im Opera am 1152 Pixeln keine horizontalen Scrollbalken auftreten, das stimmt so nur für den Firefox 2. Ich habe gerade selbst noch einmal mit dem YAML-Projekt getestet, sowohl im Firefox 3 RC1 als auch im Opera 9.27 treten bei entsprechendem Zoom horizontale Scrollbalken auf.

    Und natürlich zwinge ich meinen Kunden oder dem Grafiker keine Spaltenbreiten oder -Abstände auf. Aber so, wie man bei YAML mit wenigen Zeilen CSS beliebige Abstände und Breiten erzielen kann, so kann ich das natürlich auch mit GridEasy. Ich hab es gerade ausprobiert. Ich habe gerade ein 21er Raster gebaut mit 7 Pixeln Spaltenzwischenräumen. Hat genau 4,5 Minuten gedauert. Und natürlich geht das auch mit EM oder % oder sogar mit PT oder CM. Aber das ist ja gar nicht die Absicht hinter GridEasy. GridEasy ist mit der Absicht mit fixen Abmessungen programmiert worden. Weil ich es eben so brauche in der Praxis und nicht flexibel.

    Und natürlich ist der Vergleich echt und praxisnah, denn ich habe das getestet, was in meiner Praxis täglich vorkommt. Und nicht das, was Du gerne gesehen hättest. Nix mit teil-optimiert oder so. Beide Paket aus der Box genommen und eingebunden. Was sonst nennst Du praxisnah?

    Und zu guter letzt nur noch eins: Ich habe gar nicht die Absicht, Dich von irgendwas zu überzeugen. Ich habe auch nicht die Absicht, GridEasy als den optimalen Webbaukasten darzustellen. Es ist einfach etwas, was mir das Arbeiten erleichtert und das ich der Öffentlichkeit geschenkt habe, weil ich dachte, es nützt vielleicht auch anderen.

  10. schrieb am 02.06.08 um 13:57 Uhr: | Permalink

    Nochmals an Dirk:

    Zu Deinem letzen Kommentar: Wie kommst Du darauf, ich würde annehmen oder gar behaupten, das Dein Grundlagenbeispiel optimiert wäre. Ganz im Gegenteil. Ich schreibe oben sogar das ich der Fairness halber selbst die Kommentare aus allen Projektdateien gelöscht habe, um faire Zahlen zu erzielen. Aber es kann doch nicht die Aufgabe des Anwenders sein, sämtlichen überflüssigen Code aus den Dateien zu löschen. Das ist doch dann kein Framework (sprich einbinden und benutzen) sondern eine Schnipsel-Sammlung (Oder gehst Du auch bei z. Bsp. JavaScript-Frameworks her und löschst vor jeder Benutzung den gesamten Code, den Du für dieses Projekt nicht benötigst?). Das ist definitiv praxis- und weltfremd. Das macht wahrscheinlich keiner.

  11. schrieb am 02.06.08 um 15:52 Uhr: | Permalink

    “Du musst erst mal meinen Beitrag lesen, dann meckern. Sonst ist das Ganze ein wenig peinlich.”

    Du must endlich mal anfangen, andere Meinung genau so ernst zu nehmen, wie Deine eigene.”

    Geht es wirklich nicht ohne einen respektlosen Einführungsatz bei Dir? Ich lese Deine Beiträge sorgfältig und kommentiere sie mit Bedacht, Jens sicherlich ebenso.

    “Und Du schreibst, ein objektiver Vergleich beruhe immer auf den gleichen Rahmenbedingungen. Eben. Der Vergleich ist YAML-Out-of-the-Box gegen GridEasy-Out-of-the-Box. Und nicht GridEasy als Out-of-the-Box-Paket gegen YAML nach stundenlangem Entfernen aller nicht benötigten Code-Bestandteile.”

    Du willst zwei Systeme mit unterschiedlichen Layoutansätzen unter praxisnahen Bedingungen vergleichen. Dann setze beide Systeme auch so ein, wie es die Dokumentation empfielt. Ein Framework, welches “out of the box” robuste, flexible Layouts liefert, bietet für den technisch einfacheren fixen Anwendungsfall eben auch Optimierungspotential.

    “Zur HTML-Umsetzung schreibst Du, ich hätte meine Lösung gezielt schlank umgesetzt. Und bei der YAML-Version alles drin gelassen. Stimmt. Aber nur so konnte ich aufzeigen, mit welchem Overhead man sich die Vorteile von YAML erkauft.”

    In wissenschaftlichen Kreisen nennt man eine solche wissentliche Ungleichbehandlung in einem Vergleich eine Manipulation der Ergebnisse. Entweder Du optimierst beide, oder lässt es bleiben – auch bei beiden. Zumindest im Zweiten Fall hättest Du dennoch den DIV-Vergleich gewonnen, jedoch auf faire Weise. Denn Du darfst mir glauben, man braucht – wenn man YAML optimimal nutzt – für ein fixes Layout keinen einzigen Container mehr. Und wenn Du den Vorteil deiner Lösung “nur” durch die Ungleichbehandlung im direkten Vergleich beweisen konntest, dann ist es objektiv kein stichhaltiges Argument.

    Du hättest stattdessen sehr wohl glaubhaft mit dem Anpassungsaufwand punkten können, mit “stundenlangem Entfernen von nicht-benötigtem Code” entgleitest Du allerdings nur in Polemik ab. Ein paar Minuten reichen für die Anpassung, wenn man das System verstanden hat. Und auch diese Minuten sind schnell hereingeholt, wenn man sich die Grundlage mit dem YAML-Builder zusammenbaut.

    “Nach den aktuellen Zahlen von Webhits.de (Stand 2.6.08, also heute) sind in Deutschland 46,1% aller Internetbenutzer mit Auflösungen von 800*600 bezw. 1024*768 unterwegs, das ist fast die Hälfte der Internetnutzer.”

    Webhits wird Dir sicher auch sagen können, wie es vor einem Jahr aussah und Du wirst Dir vorstellen können, wie es in einem Jahr um diese Prozentsätze bestellt sein wird. Und auch nach diesen Zahlen hat heute bereits jeder zweite eine höhere Auflösung. Wo ist der Widerspruch zu meiner Aussage? Auf meinen Seiten ist es nunmal schon jetzt noch extremer um die Bandbreite der Auflösungen bestellt. Meinst Du nicht auch, das könnte auch auf anderen Seiten so sein oder so kommen?

    “Ich habe gerade ein 21er Raster gebaut mit 7 Pixeln Spaltenzwischenräumen. Hat genau 4,5 Minuten gedauert. Und natürlich geht das auch mit EM oder % oder sogar mit PT oder CM.”

    Schön, dass Dir das so leicht fällt. Dann beantworte mir bitte jetzt die Frage, warum ich – oder jemand anderes – GridEasy und nicht Blueprint nehmen soll, denn mit dem Blueprint-CSS-Generator kann das jeder Anwender – auch in 5 Minuten, nicht nur der Autor des Frameworks selbst? Es muss ein vollkommen neues Raster her, jede einzelne Breite jeder Klasse ändert sich. Genau daran entzündet sich doch die Kritik an den Blueprint-Clones, denn allein in der Wahl des vorgegebenen Rasters unterscheiden sich diese maßgeblich. Was macht GridEasy also so unverwechselbar besser als Blueprint der 960.gs, wie Du es in der Doku so ausdrücklich betonst? Das ist einer der Fragen, die Jens in seinem Beitrag aufwirft und die wir in der Technikwürze-Sendung diskutiert haben.

    “Aber es kann doch nicht die Aufgabe des Anwenders sein, sämtlichen überflüssigen Code aus den Dateien zu löschen. Das ist doch dann kein Framework (sprich einbinden und benutzen) sondern eine Schnipsel-Sammlung (Oder gehst Du auch bei z. Bsp. JavaScript-Frameworks her und löschst vor jeder Benutzung den gesamten Code, den Du für dieses Projekt nicht benötigst?).”

    Ja, bei YAML fällt diese Aufgabe dem Anwender zu – und das aus gutem Grund. Denn der Anwender startet mit dem großen Vorteil eines funktionsfähigen, barrierearmen Basislayouts. Nicht benötigte Elemente kann der Anwender optional ausblenden oder ganz entfernen. In der Regel spart diese Herangehensweise gegenüber dem Start bei Null sehr viel Zeit. Einsteigern erleichtert dieser Weg erheblich ersten Schritte und sie haben dennoch von Beginn an alle Gestaltungsfreiheiten, ohne Profis in Ihrer Arbeit einzuschränken oder zu behindern. Voraussetzung für die Anwendung ist allerdings, dass man sich mit dem System zuvor beschäftigt und nicht “out of the box” das Wunder eines minimalen Markups bei umfassender Gestaltungsfreiheit erwartet.

    Es mag nicht Deinem Stil entsprechen – für das CSS-Framework YAML ist es aus meiner Sicht und basierend auf fast 3 Jahren Entwicklungserfahrung der optimale Weg für den Anwender. Denn die “zusätzlichen” Container sind alles andere als nutzloser Ballast. Sie sind der Schlüssel zu robusten und extrem vielseitigen Layoutvariationen, wie es zahllose Anwender bestätigen. Erfahrene Anwender wie Du und ich, können den Quellcode im Bedarfsfall optimieren. Hältst Du das für nachteilig?

    GridEasy enthält “out of the box” keinerlei vorgegebene Quelltextstruktur, keine Ordner-Struktur, keine semantischen ID-Bezeichner, keine Skip-Navigation, keinerlei Navigationselemente, kein Print-Stylesheet usw. Meinst Du, mit GridEasy gäbe es für den Anwender nichts mehr zu tun und all diese Dinge erstellen sich von selbst? In der Regel dauert das sorgfältige Erstellen all dieser Dinge deutlich länger als das Löschen desselben, wenn man es nicht benötigt – erst Recht für unerfahrene Anwender. Ich halte den Weg von YAML daher in der Tat für einen sehr guten Weg.

    Viele Grüße
    Dirk

  12. schrieb am 02.06.08 um 16:47 Uhr: | Permalink

    @ Dirk >

    Und Du wirfst mir Polemik vor? Dann lies Doch bitte noch einmal Deine gesammelten Kommentare von heute.

    Und noch einmal: Wer lesen kann, ist echt im Vorteil. Ich habe nie behauptet, mein GridEasy wäre unverwechselbar besser als BlueprintCSS oder 960gs. Ich weis nicht, wo Du das gelesen hast, aber bestimmt nicht in meiner Doku. Allerdings habe ich geschrieben, dass GridEasy gegenüber z. Bsp. 960gs einen gravierenden Vorteil hat, nämlich 10 verschiedene Rasterweiten und nicht nur 2 wie bei 960gs. Und das ist nichts als purer Fakt.

    Und ja, Du hast natürlich recht, GridEasy enthält eine Menge weniger als zum Beispiel YAML. Und das mit gutem Grund. Es ist kein HTML-Grundkurs. Deshalb sind keine Seitengerüste dabei. Und keine anderen HTML-Komponenten wie Navigation, Skip-Links und ähnliches. Es ist, was es vorgibt zu sein: Ein CSS-Grid-Layout-System, nicht mehr und nicht weniger. Und alles, was es dazu braucht, ist auch dabei. Ich verstehe nicht, was daran falsch sein soll.

    Und was Du für den optimalen Weg für den Anwender hältst, das hängt ja wohl in erster Linie vom Anwender ab. Und ich hatte wohl bei der Entwicklung von GridEasy einen anderen Typ Anwender im Auge als Du. Also nochmal: Was ist daran falsch?

    Du willst alles an Deinen Maßstäben und Einsichten messen. Jeder, der eine andere Meinung hat als Du muss sich von Dir sagen lassen, dass das was er tut falsch ist. Ich habe eine andere Arbeitsweise als Du, ich verdiene im Gegensatz zu Dir mit dem was ich tue meinen Lebensunterhalt und ich habe bei meinen Veröffentlichungen Leute im Auge, die ähnlich wie ich aufgestellt sind. Ich will weder meine Kunden, noch meine Kollegen erziehen. Ich habe lediglich ein Angebot zum Download gemacht von etwas, was sich für mich als Nützlich erwiesen hat. Du musst es nicht nutzen, Du musst es nicht einmal nützlich finden. Aber Du solltest aufhören, es schlecht zu machen, nur weil es Dir nicht gefällt.

    Und zur Erinnerung hier nochmal, obwohl ich auch das schon öfter geschrieben habe: Ich finde YAML nach wie vor gut und nützlich. Und wenn ich mal wieder ein flexibles Layout erstellen muss, dann werde ich vermutlich auch wieder YAML einsetzen. Aber für die meisten meiner Aufgaben ist es mit Kanonen auf Spatzen geschossen. Und deshalb nützt mir im Alltag GridEasy meist mehr. Und auch da kann ich nichts Falsches dran entdecken.

  13. schrieb am 02.06.08 um 16:52 Uhr: | Permalink

    Kinder, ihr habt doch alle Schaufeln. Und die schaufeln Sand. Jetzt hört auf euch zu zanken wer eine schönere Schaufel hat.

  14. schrieb am 03.06.08 um 15:06 Uhr: | Permalink

    Ich schätze mal, dass dieser Missstand mit YAML im Firefox 3 später noch behoben wird. Wäre ja auch zu komisch, wenn es in der Vorgängerversion funktioniert, und beim Nachfolger nicht mehr. Bisher ist ja erst ein Release Candidate am start, mal schauen, was weitere Versionen bringen…

    Daniel

  15. makcie
    schrieb am 06.06.08 um 07:45 Uhr: | Permalink

    Der Kommentar von Daniel Rollos zeigt, dass der „Direkte Vergleich: YAML/GRIDEASY“ zu Verunsicherungen und sogar zu Fehleinschätzungen führt.

    Lothar Baier zeigt beim Vergleich der beiden Webseiten zum Schluß nur drei Bildschirmfotos für das Yaml-Beispiel, um zu beweisen, dass durch den Einbau des Seitenzooms in den Browsern die flexiblen Yaml-Layouts nicht mehr so funktionieren, wie vorgesehen und dass YAML keine Rückendeckung durch die Browserhersteller erhält.

    Führt man den Vergleich der beiden Webseiten exakter durch, kann man Folgendes feststellen:

    1. Die Browser zoomen unterschiedlich, am schlechtesten funktioniert der Zoom im IE 7, den kann man zur Zeit wirklich vergessen.

    2. Der horizontale Scrollbalken erscheint beim GridEasy-Beispiel (mit fixem Layout) eher als beim Yaml-Beispiel (flexibles Layout) – nur beim IE 7 erscheint der Scrollbalken ab Zoom 125% bei beiden Webseiten.

    3. Je breiter das Browserfenster (bzw. der Viewport) ist, desto später erscheinen die Scrollbalken.

    4. Der User kann den Scrollbalken abstellen: Im Opera mit ‚An Seite anpassen’, im Firefox 3 RC1 (bzw. RC2) mit ‚Nur Text zoomen’ – im IE 7 lässt sich der Scrollbalken nicht abstellen.
    Im Opera rutscht dann beim fixen Layout die rechte Randspalte unter die mittlere Spalte, beim flexiblen Layout bleiben die drei Spalten nebeneinander stehen.
    Im Firefox bleiben die drei Spalten sowohl beim fixen GridEasy-Layout als auch beim flexiblen YAML-Layout nebeneinander stehen.

    Fazit:
    Im Opera 9.x und im Firefox 3.0 RC1 funktionieren die flexiblen Yaml-Beispiele weiterhin so wie vorgesehen. Das Ãœberlaufen der Seiten und das Erscheinen eines horizontalen Scrollbalkens kann gestoppt werden. Der Einbau eines Seitenzooms in den Browsern macht flexible Layouts nicht überflüssig.

  16. schrieb am 06.06.08 um 09:54 Uhr: | Permalink

    @ makcie >

    Ich habe auch gar nicht behauptet, flexible Layouts wären gänzlich überflüssig. Aber sie sind auch nicht so nützlich, wie Dirk es in seinem Beitrag “Fexibel gegen Fix – 5:0″ dargestellt hat.

    Es ist wie es immer ist: es kommt drauf an. Bei manchen Projekten geht flexibel problemlos und ist dann auch meistens nützlich, sofern je ein vernünftiger Wert für minwidth und maxwidth angegeben wird. Bei anderen Projekten ist flexibel nicht oder nur unter der Prämisse gezoomter Fotos machbar, da ist dann fix durchaus sinnvoll. Ich wehre mich ja gar nicht gegen flexibel, ich sage nur, dass es nicht in jedem Fall geht oder sinnvoll ist.

    Ein Büro-Nachbar von mir ist stark sehbehindert. Um überhaupt noch am Computer arbeiten zu können, hat er die Bildschirmauflösung seines Rechners auf 640X480 Pixel einstellen lassen (Mit 19″-LCD). So kann er sowohl das Betriebssystem bedienen als auch die meisten Internetseiten noch lesen. Aber er hat auch bei den meisten flexiblen Layouts horizontale Scrollbalken, weil minwidth im Normalfall auf mindestens 760 Pixel eingestellt ist. Und oft genug noch höher. Und wenn er die voreingestellte Schriftgröße zoomen möchte, um sich das Lesen zu erleichtern, dann ist manchmal sogar die Zeilenlänge der Haupt-Inhaltsspalte so lang, dass sie nicht mehr auf den Bildschirm passt. Und der surft auch mit dem IE 7, nicht weil er es nicht besser weis, sondern weil er sich nach einem ausführlichen Test verschiedener Browser gezielt dafür entschieden hat, weil er damit am Besten klar kommt.

  17. makcie
    schrieb am 12.06.08 um 17:45 Uhr: | Permalink

    Hallo Lothar,

    Deinen Kommentar habe ich aufmerksam gelesen

    Du schreibst:
    “Ich habe auch gar nicht behauptet, flexible Layouts wären gänzlich überflüssig….”
    Na ja, Du hast das schon mal so formuliert:
    “Fluid und Liquid haben für meinen Geschmack zu viele Nachteile und zu wenige Vorteile. Und da inzwischen fast alle Browser (inkl. Firefox 3.0) ein Ganz-Seiten-Zoom beherrschen, finde ich diese Methoden auch überflüssig.”
    http://grideasy.blogpimp.de/das-blogpimp-grideasy-css-framework-ist-da.html#comment-3
    Diese Formulierung war mit der Auslöser für die Diskussion „Fixe Layouts vs. flexible Layouts“.

    Um den Nachteil flexibler Layouts zu demonstrieren, verweist Du auf die Situation Deines stark sehbehinderten Büronachbars: bei einer Bildschirmauflösung von 640×480 erscheinen bei den meisten flexiblen Layouts horizontale Scrollbalken, die ihm das Lesen erschweren. Und wenn bei einem fixen Layout die Seitenbreite mit 960px festgelegt ist? Erscheinen da keine horizontalen Scrollbalken?
    Bei einem flexiblen YAML-Layout ist es problemlos möglich, min-width auf 600px zu reduzieren. Damit wäre wohl bei Deinem Büronachbar das Problem mit dem Scrollbalken gelöst. Aber auch alle Webseitenbetrachter mit größeren Bildschirmen wären nach wie vor gut bedient. Wird in Deiner GridEasy-Webseite die Seitenbreite von 960px auf 600px reduziert, wäre Dein Büronachbar gut bedient, aber auf größeren Bildschirmen würde die Webseite etwas mickrig aussehen. In diesem Fall also 1:0 für flexible Layouts.
    Webseitenersteller, egal, ob sie fixe oder flexible Layouts erstellen, werden im Jahr 2008 wohl kaum ihre Webseiten für 640x480px ‚optimieren’. Dein Büronachbar muss wohl oder übel sich selbst behelfen. Entweder mit einem Benutzer-Stylesheet oder indem er in extremen Fällen CSS abschaltet.

    Bekanntlich haben sowohl fixe als auch flexible Layouts Vor- und Nachteile.
    D a s flexible Layout gibt es nicht, flexible Layouts existieren in verschiedenen Varianten, die wiederum ihre speziellen Vorzüge und Nachteile haben – die beste Variante, die ich kenne, sind die flexiblen YAML-Layouts.
    Ein Webseitenentwickler muss die Vor- und Nachteile kennen, um sich grundsätzlich für fix oder flexibel bzw. projektbezogen mal so oder so zu entscheiden.
    Ein sachlich geführter Meinungsaustausch über fixe und flexible Layouts ist durchaus anregend und kann neue Denkanstöße vermitteln. Aber eine „Schlacht um den richtigen Weg“, die zu verfestigten Fronten führt, nutzt keinem. Ich plädiere für friedliche Koexistenz!

    Inzwischen habe ich auch noch mal über das „Fazit“ in meinem Kommentar nachgedacht und möchte meine Schlussfolgerungen wie folgt ändern bzw. ergänzen.

    Ein Vergleich der beiden Webseiten (GridEasy und YAML) zeigt:

    Ein intelligenter Seitenzoom (Opera, FF 3) macht flexible Seiten nicht unbrauchbar, flexibel gestaltete Seitenlayouts werden nicht zerstört. Die Browserhersteller Opera und FF unterstützen also nach wie vor Webseiten mit flexiblem Layout.

    Man muss allerdings auch akzeptieren: Fixe Layouts werden durch den Seitenzoom „aufgewertet“ – durch das Zoomen wachsen sie im Opera, im FF 3 und im IE 7
    w i e ein flexibles Layout auch in die Breite. Das ist bei herkömmlicher Textvergrößerung nicht der Fall.
    Insofern ist die Frage, ob der Seitenzoom flexible Layouts überflüssig macht, durchaus berechtigt.

    Diese Frage kann heute noch niemand endgültig beantworten. Heute und morgen und übermorgen sind flexible Layouts meines Erachtens unverzichtbar. Wenn endlich der IE 6 verschwunden ist (und auch der IE 7) und wenn alle wichtigen Browser einen intelligenten Seitenzoom implementiert haben, dann muss noch einmal ernsthaft darüber nachgedacht werden. Web Development ist und bleibt spannend.

  18. schrieb am 12.06.08 um 19:01 Uhr: | Permalink

    @ makcie >

    Hier scheint wirklich jeder nur das zu lesen, was er lesen möchte, der Rest wird einfach ignoriert. ;-)

    Ich habe nicht nur das geschrieben, was Du zitierst, sondern ich habe auch geschrieben, dass ich selber YAML schon mehrfach mit Erfolg eingesetzt habe und dass ich flexible Layouts durchaus nützlich finde, wenn die Aufgabenstellung und der Kunde dies erlauben.

    Ich habe nur versucht aufzuzeigen, dass der direkte Vergleich zwischen YAML und GridEasy etwas anderes offenbart, als Dirk in seinem Beitrag “Flexible Layouts vs. feste Layouts – 5:0″ geschrieben hat. Der Vergleich der tatsächlichen Sites zeigt, dass diese Aussage so einfach nicht zutrifft und das Ergebnis keineswegs so eindeutig ausfällt, wie uns Dirk glauben machen will.

    Außerdem wollte ich deutlich machen, dass zwischen der philosophischen Betrachtung und dem Alltag im Webdesign Welten liegen und die Philosophie sehr schön, aber nicht immer alltagstauglich ist.

    Quintessenz: Ich bin nicht gegen flexible Layouts, aber ich bin ganz eindeutig gegen Dogmatiker, die uns glauben machen wollen, es gäbe nur eine richtige Lösung. Das Leben hat mich gelehrt, das es erstens *immer* mehr als eine Lösung gibt und zweitens richtig und falsch keine absoluten Wahrheiten, sondern immer das Ergebnis subjektiver Betrachtungen sind.

  19. makcie
    schrieb am 14.06.08 um 22:52 Uhr: | Permalink

    @blogpimp
    Zitat:
    ‘Hier scheint wirklich jeder nur das zu lesen, was er lesen möchte, der Rest wird einfach ignoriert. ‘

    Ich habe alles aufmerksam gelesen, habe allerdings den ‘Rest’ nicht lobend hervorgehoben.
    Das will ich gerne nachholen.

    Du bevorzugst fixe Layouts, hast aber auch schon YAML mehrfach mit Erfolg eingesetzt und findest flexible Layouts durchaus nützlich, wenn die Aufgabenstellung und der Kunde dies erlauben. Das klingt doch gut.

    Dirk Jesse favorisiert flexible Layouts, bietet in seinem CSS-Framework aber auch ein Beispiel für ein fixes Layout an, das gern genutzt wird. (Sicher kann man ein fixes Layout auch ohne YAML erstellen und mit weniger Overhead, darüber wurde bereits ausgiebig diskutiert.)

    Zitat:
    ‘Das Leben hat mich gelehrt, das es erstens immer mehr als eine Lösung gibt und zweitens richtig und falsch keine absoluten Wahrheiten, sondern immer das Ergebnis subjektiver Betrachtungen sind.’

    Das ist richtig. Wenn ich erinnern darf, ich hatte nicht von richtigen und falschen Lösungen gesprochen, sowohl fixe als auch flexible Layouts haben Vor- und Nachteile, die man kennen muss, um sich grundsätzlich oder aber von Fall zu Fall für die eine oder andere Variante zu entscheiden.

    Also wie ich schon schrieb: Friedliche Koexistenz! Das Web hat Platz für alle.

    Einen schönen Sonntag wünscht makcie

  20. Günter
    schrieb am 10.02.09 um 02:46 Uhr: | Permalink

    Was soll eigentlicher dieser Krieg???
    Mein Kommentar dazu: YAML ist ganz einfach genial!
    Ach so, jedem das seine und es erinnert mich ein wenig an den Basic Pascal Krieg. BlogPimp sollte sich vielleicht einmal wirklich mit YAML etwas intensiver beschäftigen, bevor er hier seine Meinung zu YAML der YAML-Gemeinde aufzuzwingen versucht. Grüsse aus Basel

  21. schrieb am 13.04.09 um 12:30 Uhr: | Permalink

    Ein hallo an die Gemeinde.

    Ich habe auch etwas zu sagen, diese Seite ist gut und die Herrn von yaml sollten sich mal darüber im klaren werden was sie wollen. Etwas für Web Entwickler und das Web und für auch deutsche user. Nun ja seit okt. mache ich wieder seiten für mich, und habe halt mit dem ie Probleme, habe dann mit css auch einiges korrigieren können, auf der suche im web bin ich vor Ca. 1woche auf yaml gestoßen, habe mir die Anleitung durchgelesen und es auf meinen server gespielt. Die dateien kann ich aufrufen aber der YAML Builder erscheint nicht, sich ein Fehler von mir! Ich wollte infos aus dem netz über yaml haben webkrauts, yaml und http://forum.yaml.de.
    Bei dem letztgenannten Forum hat man angst fragen zu stellen und den eindruck das die fragen und antworten von einem Roboter kommen, oder das nur gefaekte fragen sind, mein eindruck.Ich kenne halt viele andere foren. Na ich bin noch nicht so fit in css das ich alles beherrsche, Jens Grochtdreis dessen Vortrag ich bei Galileo über yaml gesehen habe, hat mich so begeistert das mal auszuprobieren und dann zu erwerben. Mit dem ausprobieren ist es bis jetzt noch nichts geworden…. grins. Diese Seite zu lesen und GridEasy mal trotz festem layout zu probieren spricht einfach für sich, eine woche Yaml nichts erreicht! 15min auf dieser Seite 30min nachdenken und bei yaml nachschlagen …hmmm, 1min zu GridEasy 5 min Download und Installation 15min die erste seite fertig. Das ist irgendwie erschütternd und man fragt sich ob man total verblödet ist, oder die Anleitung von yaml. Der Zwiespalt der hier herrscht zwischen der Entwicklung von yaml und Webstandards und dem lieben Geld ist doch recht groß so das mir das als außen stehender innerhalb einer Woche aufgefallen ist. Das Projekt als solches erachte ich eigentlich als wichtig und würde wenn ich auf ein deutsches Forum komme auch gerne eine deutsche Seite sehen und nicht ein Englisches Layout mit deutschen Inhalten. Aber das hat hier nichts zu suchen. Ich kann für mich nur sagen das ich auch gerne mit yaml arbeiten möchte falls es mal läuft und ich die Anleitung verstehe. Ich halte den Bericht hier für sehr neutral und man kann sich ein urteil bilden, und yaml wird hier nicht verunglimpft. An yaml selbst kann ich nur die Worte richten sie sollen sich mal entscheiden was sie wollen web oder geldverdienen und dann nicht unter einem Deckmäntelchen, eine klare Linie was rechte usw. gui angeht. Alles andere ist Fuck!
    Ich würde mich auch gerne meinem Vorschreiber Günter anschliessen ( Yaml ist einfach genial) aber da kann ich noch nicht so richtig mitreden. Eine Woche Yaml und alle infos dazu später im netz, dagegen keine 20 min bei GridEasy, da ist der erste versuch wesentlich Erfolgreicher was Doku und Funktion angehen.
    und ich bin ein Neuling und lerne.
    Grüß aus dem schönen Adenau Jürgen
    Na ich habe vielleicht keine Ahnung, aber davon eine Menge!

  22. schrieb am 04.10.09 um 02:46 Uhr: | Permalink

    ЕÑ?ли бы можно было вÑ?Ñ‘ так объÑ?Ñ?нить, то люди бы не пиÑ?али об Ñ?том так открыто, хотÑ? кто знает.

  23. schrieb am 24.05.11 um 14:32 Uhr: | Permalink

    Interessanter Vergleich, wollten vielleicht etwas mit Grideasy für unser Projekt machen. Nachdem ich mir den Vergleich jetzt allerdings durchgelesen hab, bin ich nicht so sicher, ob das wirklich so gut geeignet ist…

Einen Kommentar schreiben:

Ihre Email wird niemals veröffentlicht oder weitergegeben.

 

Design: BlogPimp · Lizenz: Alle Rechte vorbehalten blogoscoop