nicht angemeldet
Hallo, Axel,
Ich habe noch nicht mit Dreamweaver MX gearbeitet (60 MB Trial Version...? Nee, mein Rechner ist sowieso zu langsam), aber gegenüber WYSIWYG-Editoren habe ich das grundsätzliche Vorurteil, dass sie dem Mensch das Denken nicht abnehmen können.
Den Anspruch hat die Software auch nicht. Sie dient als Unterstützung beim Designprozess.
Ein Grafikprogramm wie Photoshop tut dies genauso. Der entscheidende Unterschied ist, dass der WYSIWYG den Hypertextcode erzeugt, somit kann nicht davon gesprochen werden, dass der Editor ein reines Designwerkzeug ist, da er auch die Hypertextumsetzung bewerkstelligt.
Ich glaube beispielsweise nicht einmal, dass sich zentrale Formate derart flexibel definieren lassen, wie wenn man CSS per Hand schreibt.
Was spricht dagegen?
Gegen was? Die Formate per Hand zu schreiben? Nichts, ich kenne es, wie gesagt, jedoch aus DTP-Programmen, dass man über die GUI Formate definieren kann und diese dann zuweisen kann, indem man den Absatz markiert und als diesem Format zugehörig deklarariert.
Die CSS-Unterstützung von MX ist durchaus als gut zu bezeichnen - ein wenig Übung im Umgang (wie immer erforderlich) vorausgesetzt.
Ja, daraufhin zielte meine implizite Frage ab.
Mir ist nicht bewusst, ob man einem WYSIWYG einfache CSS-Selektoren beibringen kann, wie beispielsweise »färbe alle Links in der Navigation mit der Farbe X, alle Links im Fließtext mit Farbe Y«.
Naja...Nu komm... Du definierst eine Klasse für die Navigation im Kopf und eine für den Fließtext - dann wendest Du die Klassen entsprechend an - wo ist da nun das große Problem?
Ich wollte nicht behaupten, dass dies ein Problem ist, nur wissen, ob das Programm dabei assistiert.
Wie sieht es mit semantischem Markup aus, lassen sich explizit Elemente wie abbr, cite, q, blockquote, address, dfn usw. einfügen, lassen sich Überschriften trotz hX komplett zentral umformatieren?
Was spricht dagegen? Selbstverständlich kannst Du jedes Dir genehme Tag einfügen. Texte lassen sich Deinen Wünschen entsprechend auszeichnen. Daran ist nicht das Geringste aufwendig.
Daraus schließe ich, dass es im Endeffekt doch per Hand im Code eingetippt werden muss, oder wie habe ich das zu verstehen?
Im Gegensatz zu einem Menschen kann ein an der Ausgabe orientierter Editor keine Dokumentstruktur verstehen, das ist mit Sicherheit das größte Manko.
Nenne mir einen Grund, warum ein Editor die Dokumentstruktur verstehen muss.
Um globale Formatierungen überhaupt erst zu ermöglichen? Die Seite kann nur so flexibel gewartet und ausgebaut werden, wie die dahinterliegenden, ausgelagerten Styles und beispielsweise Codebausteine (Makros o.ä.) es zulassen.
Die Ausgabe selbst ist in der Regel nur eine mögliche Interpretation des Codes, welcher viel mehr Informationen enthält, als die Ausgabe hergibt (beispielsweise wird man im handmade code Listen für eine Navigation verwenden und vielleicht mit padding-left:0 und list-style-type:none verstecken, sodass die Liste nicht sichtbar, aber vorhanden ist).
Auch das lässt sich mit einem solchen Editor machen - zur Not geh´st Du in die Quellcodeansicht und nimmst die Änderung Deinen Wünschen entsprechend vor.
Die Praxis ist das leider nicht... Sicherlich kann der Autor es »zur Not« per Hand machen, die Software sieht es aber nicht grundsätzlich vor, schließe ich daraus. Was natürlich, wie du sagst, kein Manko der Software sein muss, welche dem Autor die Arbeit nur erleichtern, aber nicht abnehmen kann.
Ich nehme einmal an, dass jegliches Layout mit verschachtelten Tabellen gelöst wird...
Nicht zwingend. Du kannst beispielsweise auch Layer nehmen.
Vielleicht irre ich mich, aber ich habe schon viele Seiten gesehen, die offensichtlich mit dieser Funktion erstellt wurden. Auf der Seite fliegen dann hunderte absolut positionierte div-Elemente mit Inline-Styles herum - das Wahre ist das auch nicht.
Sicherlich wäre ein solcher Editor für die Entwicklung eines Layouts interessant, in welchem man die Textformatierungen direkt editiert, ohne CSS-Code zu schreiben, somit wäre der WYSIWYG eher ein Setzkasten, etwas flexibler als ein Grafikprogramm, ein Reißbrett für das Layout.
Zu nichts anderem dient ein WYSIWYG-Editor. Er dient dazu ein Layout möglichst schnell umzusetzen.
...was meiner Meinung nach etwas anderes ist, als ein Layout zu entwerfen und zusammenzusetzen. Siehe oben, der Editor generiert den Code.
Einer Nacharbeit per Hand zur Optimierung steht eigentlich u.U. nur Zeit und Kostendruck entgegen - es hindert Dich niemand daran.
Dass der Editor nur ein Hilfsmittel ist, verstehen scheinbar viele WYSIWYG-Benutzer nicht, denn in den Quellcode schauen sie wahrscheinlich selten bis gar nicht. Der Auftraggeber bekommt dann eine dementsprechende Seite geliefert. Tatsächlich liegt die Verantwortung nicht unbedingt beim WYSIWYG-Benutzer.
Generell betrachtet ist es womöglich eine Frage der künstlichen Intelligenz - das Programm ist im Gegensatz zum Benutzer völlig ineffizent, wenn es darum geht, ein vorher zurechtgebautes Layout als Code abzubilden, mehr als mit Formatierungen um sich werfen wird kein Programm im Stande sein, da die Abstraktionsebene des Codes fehlt.
Ein Layout wird durch Formatierungen definiert
Ein Hypertextdokument aber nicht. Eine Software, welche aus einer Bildschirmgrafik heraus Hypertext produziert, wird nichts als auf die visuelle Darstellung gemünzten Code ausgeben können, sofern der Autor nicht von Hand dem Dokument Struktur gibt. »Hypertext« ist das im klassischen Sinne keinesfalls, in der Regel eher (kaputter) Code, welcher zu nichts anderem fähig ist, als pixelgenaues Bildschirmlayout zu produzieren. Hypertext wird nur als Medium missbraucht, siehe Tabellenlayout.
Wenn Du einen ästhetischen Anspruch an den Quellcode hast, ist das Dein privates Vergnügen
Das ist zweifellos falsch, denn der aufgeräumte Code, welcher die Struktur des Hypertextdokuments und nicht das Layout definiert, sorgt dafür, dass die Seite interoperabel und skalierbar ist.
es ändert nichts am Output.
Das Kriterium, dass eine Seite auf allen System gleich aussieht, war noch nie entscheidend für guten Hypertext.
Visuelle Gestaltung alleine erhält die Struktur durch sich selbst, nicht durch einen zugrunde liegenden Code.
Damit negierst Du Deine vorangegangen Aussagen
Nein, wieso?
Der Output eines WYSIWYG ist eine pervertierte Art Hypertext, welche nichts anderes zum Ziel hat, durch vermurksten Code eine bestimmte Präsentation zum Ziel zu haben. Die Hypertextsprache wird in diesem Fall nur verwendet, um damit eine bestimmte Gestaltung zu erreichen.
Wenn hingegen ein vom Ausgabemedium abstrahierter Hypertext verwendet wird und mit CSS formatiert wird, impliziert der Code selbst keine spezielle Präsentation, er ist unabhängig davon. Die Hypertextsprache wird in diesem Fall des Hypertexts willen verwendet.
Ich werde mir Dreamweaver beizeiten anschauen, bin mir aber nicht sicher, ob dieses Programm meinen Anforderungen genügt und die Parodoxie WYSIWYG-HTML-Editor zu durchbrechen vermag.
Es geht hier um WYSIWYG auf der Visualisierungsebene - ich glaube, Du hast hier das Prinzip nicht verstanden.
WYSIWYG-Editoren produzieren HTML *über* die visuelle Ausgabe. Ich wollte darstellen, dass dies paradox ist, da es wie gesagt umgekehrt sein sollte. Ein WYSIWYG visualisiert nicht den Code, er schließt von einer grafischen Anzeige auf den Code, was aber nicht möglich ist, da es im Hypertext nicht um die Präsentation geht (siehe den Unterschied zwischen b und strong). Ein WYSIWYG wird nicht von der Formatierung zurück auf den Code schließen können, ohne dass die Semantik des Hypertextdokuments verloren geht.
Die Arbeitsweise eines WYSIWYG ist genau die entgegengesetzte Richtung wie sie ein Verfasser von Hypertextautor wählen würde, dieser würde *erst* die Dokumentstruktur festlegen (Hypertext) und denkt *dann* darüber nach, wie er sie visualisieren kann (CSS). Damit beziehe ich mich natürlich nur auf den Umsetzungsprozess, während des Designprozesses gibt es diese Trennung natürlich nur bedingt, dennoch beinhaltet jede Komposition auch eine gewisse Semantik in den Beziehungen und Wechselwirkungen der Elemente.
Ein von der Präsentation unabhängiger Hypertext würde <h1> etc. enthalten, ein WYSIWYG weiß aber nicht, dass der Benutzer die Schrift größer formatiert hat, weil es sich um eine Überschrift handelt - er könnte allenfalls <font size="3"> oder <div style="font-size:120%;"> ausgeben - dies meinte ich mit der dem WYSIWYG fehlenden Abstraktionsebene. Solange ein WYSIWYG dem Autor kein Interface bietet, um Layoutbereiche mit Bedeutung anstatt nur mit Formatierungen zu belegen, wird der WYSIWYG-Code sich nicht in diese Richtung verbessern können.
Zudem hast Du - Deinen Äußerungen entnehme ich das - derartige, moderne Editoren bisher nur gerüchteweise wahrgenommen
Ja, aus diesem Grund bestand mein Posting aus Fragen und Mutmaßungen, auf welche ich mir eine Antwort erhoffte.
Du hast offensichtlich nicht die geringste Erfahrung damit
Das ist korrekt.
sogesehen bist Du auf Grund Deiner Erfahrung nicht in der Lage qualifiziert über Sinn und Unsinn derartiger Editoren zu diskutieren.
Ich bin Hypertextautor. Dreamweaver MX und andere WYSIWYG-Editoren wäre ein mögliches Werkzeug für mich. Deshalb glaube ich durchaus, dass ich meine Fragen und Bedenken dazu äußern kann.
Ich bin sicherlich nicht auf das starre und reine Tippen von Code fixiert, weshalb ich die Hilfsmittel verwende, welche mir am Besten in meiner Arbeit assistieren.
???
Was genau ist dir unklar?
Grüße,
Mathias