[sahnemuh]

@css3hero hast Du denn tatsächlich verstanden worum es in bacons Ausführungen geht?
Was er schreibt hat nichts mit "modern" oder "Steinzeit" zu tun, sondern mit Standards, die schlechter implementiert wurden als sie hätten sein können, weil es zu viele DAUs gibt, die weiter ihr Frontpage HTML bauen wollen.

[dercem]

[Karlarsch]

Es fehlt hier definitiv die Möglichkeit Beiträge zu "liken".

Ich würde sogar soweit gehen, dass Ganze nicht nur "pragmatisch" sondern "professionell" zu nennen. Denn genau das ist das Wissen, welches man benötigt um ein Werkzeug richtig bedienen zu können.
HTML5 ist quasi das Pendant zu PHP; es ermöglicht einem mit wenig Hintergrundwissen gradezu unmögliche Codekonstrukte zu erstellen um etwas zu erreichen was ungefähr so aussieht und funktioniert wie man es sich vorgestellt ... zumindest irgendwo. Um aber genau das zu realisieren was gefordert ist und auch überall funktioniert braucht es eine Menge Hintergrundwissen und Disziplin.
XHTML2 hätte diese Disziplin von sich aus gefordert und es damit im Endeffekt Webentwicklern leichter gemacht. Die strengen Regeln wären vorgegeben gewesen und hätten nicht von jedem quasi beliebig ausgelegt werden können.

Gruß
Karl

[ChrisKam]

Den Ausführungen von bacon über die Probleme der HTML/CSS Matsche, denen man sich als Webentwickler heutzutage konfrontiert sieht, habe ich nichts hinzuzufügen.

Vielleicht können wir im Anschluss noch über Lösungen bzw. Hilfsmittel sprechen?

Ich fange mal an: Was mich an CSS/HTML massiv stört ist der fehlende Umgang mit Fehlern. Wenn ich in Programmiersprache XY einen Syntaxfehler reinbaue, kompiliert der Murks nicht oder ich erhalte spätestens bei der Ausführung eine (meist aussagekräftige) Fehlermeldung. Das fehlt bei HTML oder CSS, schlimmer noch: Browser A bügelt meinen Fehler evtl. sogar so aus, dass ich ihn überhaupt nicht mehr sehen kann, während Browser B mir ein zerschossenes Layout präsentiert. Erfahrene Entwickler konnten dem lange nur mit Disziplin und Erfahrung begegnen, für neue Leute stellt dieser Zustand aber eine erhebliches Problem dar.

Zum Glück kann man diesem Problem seit einiger Zeit mit Precompilern für CSS/HTML gut begegnen (SASS, LESS, HAML, Jade etc.) -> if it doesn't build, it's broken.

Precompiler-Frameworks wie Compass können darüberhinaus auch bei der Vereinheitlichung von Code helfen und ersparen uns einige Cross-Browser-Kompatibilität Debugging-Sessions. Bei der Wartbarkeit sehe ich hier übrigens keine Probleme, im Gegenteil: Wenn in einigen Jahren z.B. auf Vendor-Prefix X verzichtet werden kann oder Hack Y nun performanter zur Verfügung steht, lass ich mein CSS einfach neu kompilieren und das war's.

[bacon]

... um das alles unter einen einheitlichen Hut zu bringen, benutz´ ich Assetic: https://github.com/kriswallsmith/assetic
Schöner geht´s eigentlich kaum. In Rails heißt das glaub ich Assets Pipeline oder so. Damit kannste mehrere Prä- und Postprozessoren hinternanderschalten, bspw. ein sass/compass vor ´nem yui-compressor etc.

[ChrisKam]

Danke, sieht schick aus

[bacon]

Jep, gerade noch ergänzt: Ganz praktisch dabei, dass das Ding einen Wachhund mitbringt, der bei Änderung automatisch "kompiliert", ähnlich wie Grails das macht (oder Java JIT)

Gibt (natürlich) auch ein vollkonfigurierbares Symfony-Bundle dafür

[ChrisKam]

Das kann Scout auch, was ich zurzeit benutze; für Mac OS gibt es bessere Lösungen http://mhs.github.com/scout-app/

JS- und CSS-Kompression war damit afair auch möglich. Ist im Prinzip nur eine gebundelte und auf Win portierte Ruby-SASS Umgebung. Nur sind die Konfigurationsmöglichkeiten damit sehr stark einschränkt, was auch weil daran liegt, dass ich kein Python spreche. Werde mir Assetic wirklich mal genauer anschauen...