Hier möchte ich nochmal sagen, wieso ich nicht der Meinung bin, dass man JavaScript dazu verwenden sollte, nur um Elemente zu erzeugen, die ausschließlich fürs Design zuständig sind.

JavaScript dient dazu, das DOM so zu manipulieren, dass die Website interaktiv genutzt werden kann. Das heißt Inhalte zu generieren oder nachzuladen.

Wenn man mit Hilfe von JavaScript einen „künstlichen Mantel“ erzeugt, der dafür sorgt, dass die Seite anders aussieht, entspricht das nach meiner Meinung nicht den Zweck.

Sowas halte ich unter anderem für einen schlechten Stil, weil ob man das Element nachträglich hinzufügt oder direkt im Markup einbindet, macht keinen Unterschied im endgültigen Quellcode.

Ich verstehe nicht, was du meinst. Wie gesagt, das ist eine Form der DOM-Manipulation: Ein Dokument nehmen und es anpassen. Das ist Javascripts Job, dafür ist es da. Wofür man solche Änderungen macht ist doch unerheblich. Es ist gängige Praxis JS zu nutzen, um z.B. das Design bestimmter Standard-HTML-Elemente umzubauen. Einfaches Beispiel: http://jqueryui.com/demos/button/ Du kannst es gern als falsch oder unsauber ansehen, aber es widerspricht doch nicht dem Zweck von JS.

Ein Element mit JS in ein Dokument einzufügen ist eine zentrale Operation, die i.d.R. direkt in C implementiert ist und nicht viel mehr Aufwand kostet als wäre das Element direkt im HTML. Der Code dafür passt in eine Zeile. Wo siehst du hier also Probleme bei der Ladezeit? Wir leben in Zeiten von jQuery Mobile und vergleichbaren Vertretern, in so einer Umgebung kann man das wirklich vernachlässigen.

Mit der Arbeitsteilung: Typischerweise ist es ja der Anwendungsentwickler, der das HTML schreibt (ggf. auch ein Redakteur, je nach Sichtweise). Das CSS kommt üblicherweise von einem Designer. HTML-Schreiber und Designer (im Sinne von grafischer Gestalter) können gerne zwei verschiedene Personen sein (darum geht es ja bei der Trennung von Inhalt und Design). Ich als Entwickler muss aber das Gebiet des Designers respektieren und eben nicht sagen, dass dieser Button groß zu sein hat. Ich kann sagen, dass ein Button ein Formular bestätigt, der andere abbricht. Ob jetzt aber einer davon größer oder andersfarbig oder was weiß ich zu sein hat, liegt ganz beim Designer.

Du schreibst deinem Blog, Klassen können Hinweise für Entwickler enthalten. Tatsächlich bescheibst du aber auch Hinweise für Designer (button-BIG). Und hier liegt das Problem: Du mischt Inhalt und Design und ich denke dass es allgemein anerkannt ist, dass das als schlechte Praxis gilt.

Wie gesagt, du hast ja recht, man kann reinschreiben was man will und das wird heute ja auch gern so gemacht. Ich finde das nur sehr unsauber.

Ja, JavaScript hat die Aufgabe der DOM-Manipulation, allerdings nicht zu dem Zweck, ein bestimmtes Verhalten des Design herbeizuführen. Außerdem kann man die Ladezeit aus meiner Sicht nicht einfach vernachlässigen.

Den Satz mit dem Designer verstehe ich nicht ganz – kannst Du ihn nochmal anders formulieren?

Ich verstehe deine Argumentation nicht ganz. Sicher ist es nicht „schlimm“ wenn in einem Element eine Klasse clearfix steht, aber es ist eben schlechter Stil. Im Markup kein Design – ganz einfach. HTML und CSS können von zwei völlig verschiedenen Personen entwickelt werden und dein Designer wird dir schon was anderes erzählen, wenn du ihm da irgendwelche Sachen aufzwingst.

Und was meinen JS-Ansatz betrifft: Doch, DOM-Manipulation ist genau die Aufgabe von Javascript. Und Ladezeiten kann man für sowas vernachlässigen. Aber wie gesagt: Das ist ohnehin eine Notlösung, am besten sollte man ohne auskommen.

also ich bin auch dafür, dass Entwickler penibel sauberes HTML beziehungsweise XHTML schreiben sollten. Das Beispiel von TYPO3 ist schon ziemlich heftig für eine einfache Überschrift. Schlimm finde ich außerdem die Klassen-Namen. Aus denen lässt sich nur schwer erkennen, was sie bedeuten. Was sich hinter csc verbirgt, weiß ich als Nicht-TYPO3-Entwickler nicht.

IDs und Klassen können semantisch sein. Mikroformate benutzen ja die Klassen, um den Inhalt des Elements semantisch zu kennzeichnen. Allerdings dienen Klassen in erster Linie dazu, Schnittstellen für CSS und JavaScript zu bieten. Klassen-Namen sollten Entwickler sinnvoll über die Aufgabe eines Elements informieren. Beispiel:
<article class="post"></article>
Entwickler, die sich noch nicht so sehr damit befasst haben, erkennen sofort, worum es sich handelt. Und wenn man diese Klassen-Namen kontinuierlich anwendet, dann ist der Code automatisch semantisch. Es ist auch nicht schlimm, wenn man mal ein Element mit der Klasse .clearfix verzieht. Also die Klassen-Namen können ruhig vom Inhalt unabhängig sein. Dadurch wird es nicht „unsemantisch“.

Und wenn man einen Container um mehrere Elemente schließt, halte ich das auch nicht für schlimm, wenn es notwendig ist, wenn man beispielsweise einen grauen Hintergrund haben will und der zentrierte Inhalt einen weißen über die komplette Monitorbreite bekommen soll. Von dem Vorschlag, dieses Problem mit JavaScript zu lösen, halte ich nichts, denn das ist nicht die Aufgabe von JavaScript. Das erhöht die Ladezeit eventuell.