Dreamweaver MX

[Kommerzielle Pixelschlampe (schähm?)]

Hallo ins Forum,

ich bin mittlerweile Dreamweaver MX Nutzer geworden.

Mein Eindruck bisher: Wenn's noch Bilder bearbeiten
könnte, bräuchte ich nur noch 'nen OS und das gute
Stück auf meiner Kiste...

Nun zur Frage: Was haltet ihr von Dreamweaver MX

[uepselon]

Hi,

Nun zur Frage: Was haltet ihr von Dreamweaver MX

Ich halte von klicki-klicki HTML Editoren eigentlich recht wenig.
Dreamweaver finde ich persönlich viel zu überladen. Ich will nicht erst ein Handbuch zu einem Editor wälzen um damit Webseiten zu erstellen.

Ich persönlich finde Ulli Meybohm's HTML Editor Phase 5 recht gut.
Entwickelt wird am Code und man kann sein Werk auch in einem internen Browser betrachten. Dazu gibt es viele Plug-ins die einem hilfreich sein können (Tabellenzerleger etc.).

Ich finde einfach das man mehr kompatibilität und mehr wiederverwendbarkeit erreicht wenn man es ohne WYSIWYG EDitor macht.
Von Adobe GoLive und Frontpage will ich jetzt gar nicht erst sprechen.

Gruß

ueps

[Tom Maisch]

Hi,

Nun zur Frage: Was haltet ihr von Dreamweaver MX

Ich halte von klicki-klicki HTML Editoren eigentlich recht wenig.
Dreamweaver finde ich persönlich viel zu überladen. Ich will nicht erst ein Handbuch zu einem Editor wälzen um damit Webseiten zu erstellen.

...

Ich persönlich finde Ulli Meybohm's HTML Editor Phase 5 recht gut.
Entwickelt wird am Code und man kann sein Werk auch in einem internen Browser betrachten. Dazu gibt es viele Plug-ins die einem hilfreich sein können (Tabellenzerleger etc.).

... und das ist nicht überladen?

Ich finde einfach das man mehr kompatibilität und mehr wiederverwendbarkeit erreicht wenn man es ohne WYSIWYG EDitor macht.
Von Adobe GoLive und Frontpage will ich jetzt gar nicht erst sprechen.

Naja, die Meister des Codens schwören natürlich immer auf 'Phase 5'.
Blöd ist nur, wenn trotz aller Codeverliebtheit nur schrott zum
Vorschein kommt.

Ich denke die Mischung machts!

Gruß, Tom

[Phil]

Ich denke die Mischung machts!

Was Dreamweaver kann, kann auch meine Hand.
Und meine Hand schreibt 100%-ig einen besserern und saubereren Code als ein Programm.

CU
http://www.yubb.de

[Tecci]

Ich benutz auch Dreami MX. Ganz ohne Klicki-Klicki-bunt ist schon alleine der Editor Gold wert. Die Templates sind ganz passabel und auch VSS-Unterstüzung ist hilfreich....

[Ole]

hi

Ich benutz auch Dreami MX. Ganz ohne Klicki-Klicki-bunt ist schon alleine der Editor Gold wert. Die Templates sind ganz passabel und auch VSS-Unterstüzung ist hilfreich....

der editor ist aber auche rst seit MX zu gebrauchen, da ham se dann ja auch homesite integriert (obwohl dem MX studio HomeSite+ beiliegt, wenn auch unkommentiert :))

so long
ole
(8-)>

[Wilhelm]

Moin,

der editor ist aber auche rst seit MX zu gebrauchen, da ham se dann ja auch homesite integriert (obwohl dem MX studio HomeSite+ beiliegt, wenn auch unkommentiert :))

Irrtum, Homesite ist schon immer dabei gewesen.
<subjektiv>
BTW: der war auch in der Version3 schon besser als die anderen, incl. der Phasen.
</subjektiv>

Gruesse
Wilhelm

[Ole]

hi

Irrtum, Homesite ist schon immer dabei gewesen.

hab ich ja auhc nicht bestritten, ich habe lediglich gesagt das macromedia die alte source-code-ansicht durch die von homesite ersetzt hat.

<subjektiv>
BTW: der war auch in der Version3 schon besser als die anderen, incl. der Phasen.
</subjektiv>

eine wirkliche steigerung hab ich nur von der 4er auf MX deutlich gesehen....es gab einen erheblichen geschwindigkeitszuwachs beim zugriff und scrollen durch den code

so long
ole
(8-)>

[Axel]

Hi,

eine wirkliche steigerung hab ich nur von der 4er auf MX deutlich gesehen....es gab einen erheblichen geschwindigkeitszuwachs beim zugriff und scrollen durch den code

Sehe ich auch so. Da hat es einen Schub gegeben - mag aber daran liegen, das mein Entwicklungsrechner lediglich einen 650Mhz Athlon mit 512 MB hat und dort auch noch nach Bedarf Apache, IIS, SQL-Server, Oracle und MySQL laufen - also generell nicht viel "Nettopower" übrig ist.

[Pixelschlampe (die kommerzielle)]

Well, Well - das ist schon was dran mit dem "handcoded".
(Plätzchen schmecken ja auch besser, wenn man selber backt)

Aber was machst du,

a) umfangreiche Codes hast und
b) die noch in einer nicht zu knappen Anzahl?

Gruß PixSch

[uepselon]

Hi,

Aber was machst du,

a) umfangreiche Codes hast und
b) die noch in einer nicht zu knappen Anzahl?

??? Dreamweaver macht auch nichts anderes als die Datein in einem Projektordner abzulegen.

Strukturiere dein Projekt eben vorher "von Hand" lege dir die nötigen Ordner an etc. Desweiteren ist Phase 5 auch sehr gut geeignet Projekte zu verwalten, von der genialen include Funktion ganz zu schweigen.

Gruß

ueps

[PixSch]

??? Dreamweaver macht auch nichts anderes als die Datein in einem Projektordner abzulegen.

...HA! hab ich mir's doch gleich gedacht...

Strukturiere dein Projekt eben vorher "von Hand" lege dir die nötigen Ordner an etc.

...MindMaps, Skizzen und das andere, handwerkliche Gewese habe ich doch gar nicht gemeint. Das muß jeder mit seinem Gott ausmachen...
Denn schließlich sind die Zeiten vorbei, wo ein "Projekt" 50 Seiten
hat, oder?

Desweiteren ist Phase 5 auch sehr gut geeignet Projekte zu verwalten, von der genialen include Funktion ganz zu schweigen.

...Mmh, werd' mir die Phase mal ziehen. Trotzdem sollte man nicht
verachten, dass man bei DMX so ziemlich alles includen kannst.

Gruß

ueps

Same.Same - Phase 5 is Freeware, oder?

[uepselon]

Hi,

Denn schließlich sind die Zeiten vorbei, wo ein "Projekt" 50 Seiten
hat, oder?

Kommt drauf an was man unter Seite versteht? Ein CMS verteilt Inhalte auf Seiten, von Einzelseiten würde ich da z.B. nicht mehr sprechen.

Same.Same - Phase 5 is Freeware, oder?

Ja, das ist das schöne daran :-)

ueps

[Danny]

Hi, Du PixSch... ;)

Der Traumweber ist mit MX besser geworden aber trotzdem noch etwas zu schwerfällig...

DW erzeugt standardmäßig immer noch Codemonster. Tabellen als Layouthilfe zu gebrauchen, war bestimmt nicht im Sinne des Erfinders. Das hat sich leider über die Jahre so eingebürgert, ist aber nicht mehr zeitgemäß.

Das Box-Model und einige andere Styles werden in der Vorschau nicht richtig interpretiert, die WYSIWYG-Ansicht zeigt Müll an, damit kann ich wenig anfangen. Also bin ich bei modernen Designs gezwungen auf die Layout-Hilfen komplett zu verzichten.

Stylesheet-Def. sind von Hand auch schneller getippt, wenn man sich entsprechende Vorlagen anlegt. Die Vorlagen des DW MX sind kaum zu gebrauchen, lediglich eine handvoll Tabellen stehen zur Auswahl.

Für Templates verwende ich lieber PHP mit entsprechenden Klassen.

Das einzige was ich an DW schätze, ist die Möglichkeit ein Layout relativ schnell zu rastern, d.h. vom Grafik-Entwurf zu einem Prototypen und die Projekt-Verwaltung. Alles andere hilft mir persönlich nicht wirklich.

a) umfangreiche Codes hast und
b) die noch in einer nicht zu knappen Anzahl?

Wo ist das Problem? Mit etwas Planung und Konzept braucht man sich wiederholende Code-Teile nur einmal zu schreiben. Selbst mit einfachen Texteditoren. Der Schlüssel zum Bausatz sind sog. Includes, z.B. SSI, PHP (Serverseitig) oder Editor-Lösungen (Phase 5 oder HTML Kit). Damit lassen sich externe Codeschnipsel in z.B. eine HTML-Datei einbinden. Die Navigation z.B. braucht so nur einmal erstellt und kann zentral gepflegt zu werden.

Gruß aus Kassel,
Danny

[uepselon]

Hi,

Ich persönlich finde Ulli Meybohm's HTML Editor Phase 5 recht gut.
... und das ist nicht überladen?

nein, wenn ich keine Plug-ins brauche lasse ich sie weg. Der Rest ist ein gundes Maß an fertigen Hilfsmitteln die Code ausgeben. Kann
man verwenden muss man aber nicht, dass ist der Unterschied.

Naja, die Meister des Codens schwören natürlich immer auf 'Phase 5'.

Man kann genausogut Proton oder UltraEdit nehmen, das sind dann reine Text Editoren ohne HTML Schnick-Schnack.

Blöd ist nur, wenn trotz aller Codeverliebtheit nur schrott zum
Vorschein kommt.

Von wessen Schrott redest du?

Ich denke die Mischung machts!

Ein gutes Bildbearbeitungs Programm, ein guter Quelltext-Editor und einen lokalen Webserver zum testen, sowie SelfHTML 8 auf der Platte ist alles was man braucht ;-)

Nichts für ungut

ueps

[Tom Maisch]

Hallo,

Naja, die Meister des Codens schwören natürlich immer auf 'Phase 5'.

Man kann genausogut Proton oder UltraEdit nehmen, das sind dann reine Text Editoren ohne HTML Schnick-Schnack.

Du hast Notepad vergessen. Das ist DAS eigendliche Guru Werkzeug. ;-)

Blöd ist nur, wenn trotz aller Codeverliebtheit nur schrott zum
Vorschein kommt.

Von wessen Schrott redest du?

An welchen Schrott denkst du?

Ich denke die Mischung machts!

Ein gutes Bildbearbeitungs Programm, ein guter Quelltext-Editor und einen lokalen Webserver zum testen, sowie SelfHTML 8 auf der Platte ist alles was man braucht ;-)

Ist natürlich eine feine Sache, wenn ein 386er für die Arbeit reicht.
Ich bezweifele nur, dass du noch so ein Ding mit einer 120 MB Platte
besitzt! ;->

Also, nicht so geizig mit den Resourcen!

Nichts für ungut

Yeap!

Tom

[uepselon]

Hi,

Man kann genausogut Proton oder UltraEdit nehmen, das sind dann reine Text Editoren ohne HTML Schnick-Schnack.

Du hast Notepad vergessen. Das ist DAS eigendliche Guru Werkzeug. ;-)

Notepad ist kein Quelltext-Editor sondern die unterste Editor-Ebene.
Der unterschied in der Leistung ist wie ein Fiat zu einem Mercedes.

Von wessen Schrott redest du?
An welchen Schrott denkst du?

Ich denke an gar nichts, ich hab mich nur gefragt auf was du hier Bezug nehmen wolltest?

Ein gutes Bildbearbeitungs Programm, ein guter Quelltext-Editor und einen lokalen Webserver zum testen, sowie SelfHTML 8 auf der Platte ist alles was man braucht ;-)

Ist natürlich eine feine Sache, wenn ein 386er für die Arbeit reicht.
Ich bezweifele nur, dass du noch so ein Ding mit einer 120 MB Platte
besitzt! ;->

Also, nicht so geizig mit den Resourcen!

??? Es geht nicht darum Plattenplatz zu sparen sondern effizient zu arbeiten. Schon mal davon gehört das nicht unbedingt die bunten klicki Programme die meisten Resourcen brauchen? Eine DB Anwendung und ein paar Hintergrund Transaktionen bringen denke ich sogar deine Hammerkiste in die Knie.

Gruß

ueps

[Tom Maisch]

Hallo,

??? Es geht nicht darum Plattenplatz zu sparen sondern effizient zu arbeiten. Schon mal davon gehört das nicht unbedingt die bunten klicki Programme die meisten Resourcen brauchen? Eine DB Anwendung und ein paar Hintergrund Transaktionen bringen denke ich sogar deine Hammerkiste in die Knie.

woher kennst du meine Kiste?
Es geht hier nicht um 'klicki'. Du glaubst an effizient zu Arbeiten?
Das ist gut! Ist Dein Recht und mit sicherheit nicht schlecht.

Du solltest hingegen nicht versuchen ander Arbeitsweisen als NICHT
effizient abzustempeln.

Gruß, Tom

[uepselon]

Hi,

woher kennst du meine Kiste?

Woher kanntest du meine? Exemplarisches Gegenbeispiel zu deiner Annahme das ich auf einem 386 entwickle.

Es geht hier nicht um 'klicki'. Du glaubst an effizient zu Arbeiten?
Das ist gut! Ist Dein Recht und mit sicherheit nicht schlecht.

Du solltest hingegen nicht versuchen ander Arbeitsweisen als NICHT
effizient abzustempeln.

Wo hab ich eine andere Arbeitsweise als ineffektiv dargestellt?
Ich habe lediglich auf die Schwächen eines WYSIWYG Editors hingewiesen und niemanden gesagt das er schelcht arbeitet.
Ich kenne zu genüge Beispiele aus meinem Umfeld wo die besagten Editoren eben viel unfug im Code stehen haben und eine individuelle nachträgliche Anpassung erheblich erschwert. Daher strukturiere ich persönlich mein Projekt selbst und lasse nicht einen Editor eine solch entscheidende Aufgabe erledigen. Dein Abteilungsleiter (falls Vorhanden) ist ja auch kein Roboter?

Gruß

ueps

[Axel Napolitank]

Hi,

Ich habe lediglich auf die Schwächen eines WYSIWYG Editors hingewiesen und niemanden gesagt das er schelcht arbeitet.

Nein. Du hast mutmaßliche, Deiner Phantasie entspringende Annahmen verbreitet, die eigentlich nicht weiter untermauert worden sind.

Ich kenne zu genüge Beispiele aus meinem Umfeld wo die besagten Editoren eben viel unfug im Code stehen haben und eine individuelle nachträgliche Anpassung erheblich erschwert.

Viel Unfug? Welche Art Unfug meinst Du? Durch richtigen Einsatz und richtige Bedienung eines Editors wie z.B. MX (um den geht es hier) reduziert den Unfug in Richtung null - es liegt Teilweise auch am Nutzer, der nicht so recht weiß wie er ein solches Tool richtig einsetzt.

Daher strukturiere ich persönlich mein Projekt selbst und lasse nicht einen Editor eine solch entscheidende Aufgabe erledigen. Dein Abteilungsleiter (falls Vorhanden) ist ja auch kein Roboter?

Was hat das strukturieren eines Projektes mit der Arbeit an z.B. MX (um den gehts hier) zu tun? Dort legst Du eine Site an, gibst den Deployment-Server an und beginnst Dein Konzept (das Du hoffentlich hast) umzusetzen.

Mittels dem eingebauten Validator kommst Du möglichen Patzern extrem schnell auf die Schliche und kannst diese dann beseitigen.

Gruß

Axel

PS: Ich glaube, das Du voller Vorurteile bist und MX noch nicht wirklich produktiv eingesetzt hast - geschweige denn, das Du Dir die Mühe gemacht hast, das Tool eingehend zu testen.

[uepselon]

Hi Axel,

Was hat das strukturieren eines Projektes mit der Arbeit an z.B. MX (um den gehts hier) zu tun? Dort legst Du eine Site an, gibst den Deployment-Server an und beginnst Dein Konzept (das Du hoffentlich hast) umzusetzen.

Es geht um den grundlegenden Aufbau der Seite. Du kannst mit MX wenn du dich gut eingearbeitet hast, wahrscheinlich recht gut arbeiten.
Das Problem ist jedoch, wenn ich das Layout per Drag n Drop errichte, werden Tabellen etc. nach den wünschen des Editors angelegt. Der Code mag evtl. auch schön strukturiert sein, doch das Problem ist einfach, dass wenn ich später ein paar Erweiterungen machen muss, ich diese u.U. nicht in das von DMX erstellte Codegerüst bekomme. Um solchen Unwegsamkeiten vorzubeugen, bedarf es eines Blickes in den Quelltext und eine quelltextnache Entwicklung.
Wenn ich also sowieso ständig selbst den Quelltext überprüfen muss und mir überlegen muss ob die Struktur meinen Ansprüchen genügt, kann ich genausogut einen Freeware Editor a la HTML Edit nehmen.
Tabellen kann ich auch da einfach erstellen und das Projekt kann auch dort verwaltet werden. Wozu sag mir mal bitte brauch ich da noch einen Dreamweaver MX?

PS: Ich glaube, das Du voller Vorurteile bist und MX noch nicht wirklich produktiv eingesetzt hast - geschweige denn, das Du Dir die Mühe gemacht hast, das Tool eingehend zu testen.

In der Tat habe ich mich vielleicht wenns hoch kommt 3-4 Stunden mit dem Dreamweaver beschäftigt. Das hat mir jedoch schon gereicht um wieder davon wegzugehen. Das Problem mit diesen netten Anwendungen ist einfach das es sich nicht wirklich lohnt sich intensiv damit zu beschäftigen. Was nütz es mir den Dreamweaver in und auswenig zu kennen, wenn ich z.B. in einem Monat gefeuert werde und fortan bei Firma XY mit GoLive oder gar einem Texteditor arbeiten muss?
Da entwickle ich lieber gleich auf unterster Ebene und gut ist!

Gruß

ueps

[Axel]

Hi,

Es geht um den grundlegenden Aufbau der Seite. Du kannst mit MX wenn du dich gut eingearbeitet hast, wahrscheinlich recht gut arbeiten.

Ja. Ausgesprochen gut.

Das Problem ist jedoch, wenn ich das Layout per Drag n Drop errichte, werden Tabellen etc. nach den wünschen des Editors angelegt. Der Code mag evtl. auch schön strukturiert sein, doch das Problem ist einfach, dass wenn ich später ein paar Erweiterungen machen muss, ich diese u.U. nicht in das von DMX erstellte Codegerüst bekomme. Um solchen Unwegsamkeiten vorzubeugen, bedarf es eines Blickes in den Quelltext und eine quelltextnache Entwicklung.

??? Diese Ausführung verstehe ich nicht. Der Editor legt die Tabelle nach dem Wunsch des Users an. Abgesehen davon ist mir nicht klar, welche Änderung dir MX nicht ermöglichen soll - mir ist keine bekannt.

Wenn ich also sowieso ständig selbst den Quelltext überprüfen muss und mir überlegen muss ob die Struktur meinen Ansprüchen genügt, kann ich genausogut einen Freeware Editor a la HTML Edit nehmen.

Die Struktur des Quelltextes ist solange völlig egal, wie die Seite meinem Wunsch entsprechend dargestellt wird, validiert und keine überflüssigen Tags enthält.

Ich denke, das Struktur hier auch das falsche Wort ist.

Tabellen kann ich auch da einfach erstellen und das Projekt kann auch dort verwaltet werden. Wozu sag mir mal bitte brauch ich da noch einen Dreamweaver MX?

Als geborener Spartaner mit viel Zeit und absoluter Gestaltungsfreiheit brauchst Du ein Tool wie Dreamweaver nicht - aber als Gewerbetreibender, der manchmal ad-hoc einen Prototyp (u.U. noch während des Fluges zum oder vom Kunden) erstellen muss, wirst Du ein solches Tool zu schätzen wissen.

Abgesehen davon ist der Code von DMX bei bedachter Nutzung lupenrein.

Was nütz es mir den Dreamweaver in und auswenig zu kennen, wenn ich z.B. in einem Monat gefeuert werde und fortan bei Firma XY mit GoLive oder gar einem Texteditor arbeiten muss?
Da entwickle ich lieber gleich auf unterster Ebene und gut ist!

Was nutzt es Dir heute zu essen, wenn Du morgen ohnehin wieder hunger bekommst? Hunger doch grundsätzlich.

Das ist so ziemlich das unqualifzierteste Statement, das ich seit langem gelesen habe - sorry.

Gruß

Axel

[uepselon]

Hallo,

Als geborener Spartaner mit viel Zeit und absoluter Gestaltungsfreiheit brauchst Du ein Tool wie Dreamweaver nicht - aber als Gewerbetreibender, der manchmal ad-hoc einen Prototyp (u.U. noch während des Fluges zum oder vom Kunden) erstellen muss, wirst Du ein solches Tool zu schätzen wissen.

Oh, ich habe auch nicht mehr Zeit als andere. Ich komme halt ohne Bunte Editoren besser zurecht als mit. Bei anderen ist evtl. andersrum, aber das soll jeder selbst wissen. Ich für meine Seite gebe mich so langsam geschlagen.

Was nütz es mir den Dreamweaver in und auswenig zu kennen, wenn ich z.B. in einem Monat gefeuert werde und fortan bei Firma XY mit GoLive oder gar einem Texteditor arbeiten muss?
Da entwickle ich lieber gleich auf unterster Ebene und gut ist!

Was nutzt es Dir heute zu essen, wenn Du morgen ohnehin wieder hunger bekommst? Hunger doch grundsätzlich.

Das ist so ziemlich das unqualifzierteste Statement, das ich seit langem gelesen habe - sorry.

Dieser Vergelich von dir hinkt ein wenig. Beim Hungern hätte ich einen direkten Nachteil, ob ich nun MX oder UltraEdit benutze ist nicht direkt mit einem Nachteil verbunden.
Was ich damit sagen will ist einfach, dass das man so ist es meine Erfahrung grundsätzlich besser fährt die Grundlagen exakt zu beherrschen, anstatt nur mit einem aufgesetzten Tool an der Oberfläche zu kratzen. Ich wette das man fürs Dreamweaver Handbuch genausolange braucht wie für SelfHTML, was würdest du sagen, ist die bessere Grundlage für die Zukunft?

Gruß

ueps

[Axel]

Hi,

Was ich damit sagen will ist einfach, dass das man so ist es meine Erfahrung grundsätzlich besser fährt die Grundlagen exakt zu beherrschen, anstatt nur mit einem aufgesetzten Tool an der Oberfläche zu kratzen. Ich wette das man fürs Dreamweaver Handbuch genausolange braucht wie für SelfHTML, was würdest du sagen, ist die bessere Grundlage für die Zukunft?

Also...Dreamweaver ist nicht mehr und nicht weniger aufgesetzt aus ein Tool wie Phase 5 - es bietet nur andere Werkzeuge um auf visueller Ebene HTML-Code zu generieren (etwas abstrahiert).

Das Handbuch von Dreamweaver ist sehr dünn - die Hilfe etwas dicker. Sie dient aber nicht zum Erlernen von Kreativität oder tiefen Verständnis von HTML (welches Du im Zweifelsfall beim Einsatz von DMX nicht mal benötigst) es dient in erster Linie dazu, den Umgang mit DMX zu erlernen - und wenn Du Dir das angetan hast und zudem noch Know-how im Bereich HTML, XHTML und CSS besitzt, bist Du entschieden produktiver als ein Handkodierer, der niemals 100% fehlerfrei arbeitet und meistens ungleich mühsamer seine Fehler suchen muss.

Ich denke, das Du ganz einfach der sprichwörtliche "Bauer" bist: "Was ich nicht kenn, fress ich nett".

Setz Dich einfach mal mit dem Tool ein- oder zwei Tage auseinander und dann - erst dann - lass nochmal etwas kritisches dazu hören.

Vorher ist alles, was Du in Bezug auf DMX äußerst mehr Spekulation und Mutmaßung gepaart mit Vorurteilen als alles Andere.

Gruß

Axel

[uepselon]

Hi,

Das Handbuch von Dreamweaver ist sehr dünn - die Hilfe etwas dicker. Sie dient aber nicht zum Erlernen von Kreativität oder tiefen Verständnis von HTML (welches Du im Zweifelsfall beim Einsatz von DMX nicht mal benötigst) es dient in erster Linie dazu, den Umgang mit DMX zu erlernen - und wenn Du Dir das angetan hast und zudem noch Know-how im Bereich HTML, XHTML und CSS besitzt, bist Du entschieden produktiver als ein Handkodierer, der niemals 100% fehlerfrei arbeitet und meistens ungleich mühsamer seine Fehler suchen muss.

Die Fehlersuche ist nicht schwer, gibt es doch recht schlanke Validatoren im Netz. Desweiteren ist man mit D MX schneller was wiederkeherende Abäufe betrifft. Diese können jedoch auch mit Phase 5 o.Ä. auf die individuellen Bedürfnisse festgelegt werden, und sind somit evtl. sogar noch schneller zu bewerkstelligen.
Wie ich schon mal gesagt hab, bei MX musst du Handbuch und Hilfe und zusätzlich noch HTML lernen um gut zu sein.
Obwohl auch nur HTML reicht und ein einfacher nicht komplexer Editor umd gut zu sein. Wo ist der Aufwand nun größer?

Ich denke, das Du ganz einfach der sprichwörtliche "Bauer" bist: "Was ich nicht kenn, fress ich nett".

Wenn du meinst.

Setz Dich einfach mal mit dem Tool ein- oder zwei Tage auseinander und dann - erst dann - lass nochmal etwas kritisches dazu hören.

Wenns die Zeit erlaubt werde ich mich ganz sicher nochmal damit beschäftigen, aber bis dahin Zählt immernoch mein erster Eindruck.

Gruß

ueps

[Christian Seiler]

Hallo Axel,

Die Struktur des Quelltextes ist solange völlig egal, wie die Seite meinem Wunsch entsprechend dargestellt wird, validiert und keine überflüssigen Tags enthält.

Du hast das Prinzip von HTML, nämlich dass es eine _Auszeichnungs_sprache ist, entweder nicht verstanden oder willst es nicht akzeptieren. In letzterem Fall empfehle ich Dir den Einsatz von Flash.

Ich denke, das Struktur hier auch das falsche Wort ist.

Warum?

Grüße,

Christian

P.S.: das Posting mag' jetzt vielleicht etwas "scharf" klingen, ich will aber etwas provozieren...

[Axel]

Hi,

Du hast das Prinzip von HTML, nämlich dass es eine _Auszeichnungs_sprache ist, entweder nicht verstanden oder willst es nicht akzeptieren. In letzterem Fall empfehle ich Dir den Einsatz von Flash.

Blödsinn. Ich sehe es nur nicht so verbissen wie einige Pedanten, die HTML zur neuen e-Religion mutieren lassen wollen.

P.S.: das Posting mag' jetzt vielleicht etwas "scharf" klingen, ich will aber etwas provozieren...

Viel Glück ;-)

Gruß

Axel (Der Rechtfertiger)

[Christian Seiler]

Hallo Axel,

Du hast das Prinzip von HTML, nämlich dass es eine _Auszeichnungs_sprache ist, entweder nicht verstanden oder willst es nicht akzeptieren. In letzterem Fall empfehle ich Dir den Einsatz von Flash.

Blödsinn. Ich sehe es nur nicht so verbissen wie einige Pedanten, die HTML zur neuen e-Religion mutieren lassen wollen.

Ich zitiere Dich nochmals:

Die Struktur des Quelltextes ist solange völlig egal, wie die Seite meinem Wunsch entsprechend dargestellt wird, validiert und keine überflüssigen Tags enthält.

Dir ist also ein einheitliches Ergebnis wichtig und der Rest ist Dir egal? Ich könnte jetzt also praktisch statt <h1> dann also <p style="font-size: 24px; font-weight: bold;"> verwenden, und die Seite würde Deinen Ansprüchen genügen. Natürlich kann man nicht 100%ig die Struktur nachbilden, dazu fehlt es in HTML an genug Tags, aber darum geht es nicht. Du widersetzt Dich jeglicher Struktur. (Zumindest laut Deiner Aussage) Ein Dokument sollte logisch strukturiert sein, zumindestens größtenteils. Zum Thema e-Religion: irgendjemand hatte hier einen Spruch in der Signatur: "Verlange das Unmögliche und Du wirst das Mögliche erreichen, verlange nur das Mögliche und Du wirst nichts erreichen." (oder so ähnlich)

Grüße,

Christian

[molily]

Hallo, Christian,

irgendjemand hatte hier einen Spruch in der Signatur: "Verlange das Unmögliche und Du wirst das Mögliche erreichen, verlange nur das Mögliche und Du wirst nichts erreichen." (oder so ähnlich)

Ich wette darauf, dass Hermann Hesse (»Man muss das Unmögliche versuchen, um das Mögliche zu erreichen«) Michail Bakunins Spruch (»Diejenigen, die immer nur das Mögliche fordern, erreichen gar nichts. Diejenigen, die das Unmögliche fordern, erreichen wenigstens das Mögliche.«) nur paraphrasiert hat. Interessant wäre tatsächlich, ob Hesse Bakunin las... :)
Wie auch immer, diese Idee ist sicherlich kein »geistiges Eigentum« (muha) und zur Ermittlung der tatsächlichen Herkunft von Aphorismen muss sowieso tief gewühlt werden... Meist zitieren die Autoren, denen der Spruch zugeschrieben wird, auch nur usw.

Grüße,
Mathias

[Axel]

Hi,

Die Struktur des Quelltextes ist solange völlig egal, wie die Seite meinem Wunsch entsprechend dargestellt wird, validiert und keine überflüssigen Tags enthält.

Dir ist also ein einheitliches Ergebnis wichtig und der Rest ist Dir egal? Ich könnte jetzt also praktisch statt <h1> dann also <p style="font-size: 24px; font-weight: bold;"> verwenden, und die Seite würde Deinen Ansprüchen genügen.

Sie würde nicht meinen Ansprüchen genügen (wenngleich ich sowas auch teilweise auf meinen Seiten habe) - aber (und darum geht es ja hier) nenne mir bitte einen Grund, der Dich daran hindert eben genau diese "Strukturierung" mittels DMX (sogar schon D3) umzusetzen - nur einen Grund.

Natürlich kann man nicht 100%ig die Struktur nachbilden, dazu fehlt es in HTML an genug Tags, aber darum geht es nicht. Du widersetzt Dich jeglicher Struktur. (Zumindest laut Deiner Aussage) Ein Dokument sollte logisch strukturiert sein, zumindestens größtenteils. Zum Thema e-Religion: irgendjemand hatte hier einen Spruch in der Signatur: "Verlange das Unmögliche und Du wirst das Mögliche erreichen, verlange nur das Mögliche und Du wirst nichts erreichen." (oder so ähnlich)

Dieser Spruch ist m.e. Unsinn.

Gruß

Axel

[Christian Seiler]

Hallo Axel,

Sie würde nicht meinen Ansprüchen genügen (wenngleich ich sowas auch teilweise auf meinen Seiten habe) - aber (und darum geht es ja hier) nenne mir bitte einen Grund, der Dich daran hindert eben genau diese "Strukturierung" mittels DMX (sogar schon D3) umzusetzen - nur einen Grund.

Es ging mir hier nicht speziell um Dreamweaver, sondern um das Prinzip. Mir ist schon klar, dass ich eine <h1>-Überschrift mit Dreamweaver umsetzen kann, das geht sogar mit Frontpage, ich wollte jetzt mal ein krasses Beispiel bringen. Aber wenn ich eine logische Struktur in die Seite bringen will, mit sehr vielen <abbr>s, <q>s, <code>s, <var>s, <ins>s, <del>s, etc. - dann sehe ich wirklich Probleme, wie das mit einem *darstellungsorientierten* WYSIWYG-Editor funktionieren soll. Und selbst wenn das klappt, bin ich 100x schneller im Sourcecode. Der einzige graphische Editor, der mich vom Konzept her überzeugt hat, ist JAXE.

Dieser Spruch ist m.e. Unsinn.

IMHO nicht.

Grüße,

Christian

[Axel]

Hi,

Es ging mir hier nicht speziell um Dreamweaver, sondern um das Prinzip. Mir ist schon klar, dass ich eine <h1>-Überschrift mit Dreamweaver umsetzen kann, das geht sogar mit Frontpage, ich wollte jetzt mal ein krasses Beispiel bringen. Aber wenn ich eine logische Struktur in die Seite bringen will, mit sehr vielen <abbr>s, <q>s, <code>s, <var>s, <ins>s, <del>s, etc. - dann sehe ich wirklich Probleme, wie das mit einem *darstellungsorientierten* WYSIWYG-Editor funktionieren soll. Und selbst wenn das klappt, bin ich 100x schneller im Sourcecode. Der einzige graphische Editor, der mich vom Konzept her überzeugt hat, ist JAXE.

Ich denke, das hängt von 2 Faktoren ab

• Der persönlichen Arbeitsweise
• Der Sicherheit im Umgang mit dem Tool

Da ich Seiten zunächst (auch wenn es altmodisch erscheint) auf Papier entwerfe und die Texte auch im Vorfeld durchgehe - und auf dem Papier bereits strukturiere -  fällt mir die Umsetzung recht leicht. Ich hätte durch einen Quelltexteditor keinen Gewinn sondern vielmehr die Gefahr der Vertipperei - sogesehen ist für mich DMX ein "Produktivity"-Tool.

Recht geben muss ich der Behauptung, das es nicht unbedingt sinnvoll ist, ein Tool wie DMX ohne Grundlagenwissen einzusetzen - das führt zu den hier kritisierten Codefratzen.

Ich werde mir aber mal JAXE ansehen...

Gruß

Axel

[Christian Seiler]

Hallo Axel,

• Der persönlichen Arbeitsweise

Da unerscheiden wir uns wohl ziemlich.

(auch wenn es altmodisch erscheint)

Durchaus nicht. Ich denke, viele machen das hier, mich selbst eingeschlossen. Solange es keinen bezahlbaren elektronischen Papierersatz mit richtigem Stift gibt (PDAs sind zu klein, Tablen PCs zu teuer) wird sich das auch noch einige Zeit halten. Ich entwerfe auch Programmstrukturen auf Papier.

Ich hätte durch einen Quelltexteditor keinen Gewinn sondern vielmehr die Gefahr der Vertipperei

Und ich verklicke mich eher als dass ich mich vertippe.

Recht geben muss ich der Behauptung, das es nicht unbedingt sinnvoll ist, ein Tool wie DMX ohne Grundlagenwissen einzusetzen - das führt zu den hier kritisierten Codefratzen.

Das Problem ist aber, dass Macromedia gerade die Benutzung für Anfänger "erleichtern" will.

Ich werde mir aber mal JAXE ansehen...

Ich habe JAXE nur erwähnt, weil das Konzept mir gut gefallen hat, an sich ist das Programm noch nicht so 100%ig brauchbar... Außerdem verwendet der Autor AWT/Swing...

Grüße,

Christian

[molily]

Aloha, Christian,

wenn ich eine logische Struktur in die Seite bringen will, mit sehr vielen <abbr>s, <q>s, <code>s, <var>s, <ins>s, <del>s, etc. - dann sehe ich wirklich Probleme, wie das mit einem *darstellungsorientierten* WYSIWYG-Editor funktionieren soll.

Gar nicht, das ist per se nicht oder nur äußerst umständlich über die grafische Ebene realisierbar. Diese Elemente lassen sich zwar zum Teil über Schaltflächen einfügen, aber nur als Markup, wodurch die Codeansicht anspringt. Semantisches Markup hat keine eindeutige Relation zur Visualisierung; logischerweise kann ein WYSIWYG-Editor diese Arbeit nicht übernehmen, somit fällt er für diese Aufgabe weg. Das kann überhaupt nicht funktionieren und ist m.M.n. auch nicht als Kritikpunkt eines WYSIWYG-Editor geeignet. Kein Editor wird in diesem Punkt auch nur annähernd die Flexibilität von direkt verfassten Code erreichen, es sei denn, der WYSIWYG arbeitet selbst äußerst codenah... Ein Vergleich fällt mir momentan nicht ein, ich kann mich gar nicht mehr an Amaya erinnern.

Und selbst wenn das klappt, bin ich 100x schneller im Sourcecode.

Müsstest du sowieso, du sparst dir nur das Tippen des rudimentären Markups, welches du durch Klicken einfügen kannst. Mehr nicht. Die Unterstützungsmöglichkeiten eines Editors endet dort.

Diesen JAXE kann ich im Moment nicht ausprobieren... Ich hasse das JRE und überhaupt jede Java-Software (die Performance ist auf meinem Rechner ein Witz, der Anon Proxy wäre das Einzigste, was mich zur Installation von Java verleiten würde) und momentan belegt Dreamweaver den letzten Winkel der Platte.

Mathias

[Axel]

Hi,

Gar nicht, das ist per se nicht oder nur äußerst umständlich über die grafische Ebene realisierbar. Diese Elemente lassen sich zwar zum Teil über Schaltflächen einfügen, aber nur als Markup, wodurch die Codeansicht anspringt. Semantisches Markup hat keine eindeutige Relation zur Visualisierung; logischerweise kann ein WYSIWYG-Editor diese Arbeit nicht übernehmen, somit fällt er für diese Aufgabe weg. Das kann überhaupt nicht funktionieren und ist m.M.n. auch nicht als Kritikpunkt eines WYSIWYG-Editor geeignet. Kein Editor wird in diesem Punkt auch nur annähernd die Flexibilität von direkt verfassten Code erreichen, es sei denn, der WYSIWYG arbeitet selbst äußerst codenah... Ein Vergleich fällt mir momentan nicht ein, ich kann mich gar nicht mehr an Amaya erinnern.

Völlig an den haarsträubender Mischmasch aus Glauben, Annahmen und Überzeugungen - da ist wenig bis nichts haltbares dran.

Wo ist bitte das Problem? Ich kriege Texte im Allgemeinen in digitaler oder "analoger" Form - selten mündlich. D.h. ich schaue mir den Text im Vorfeld an, mache meine Notizen und übertrage ihn. Es ist absolut KEINE Arbeit und KEINE Mühe die entsprechenden "Strukturierungen" vorzunehmen. Wer natürlich erst hackt und dann denkt, wird Schwierigkeiten bekommen - die hat er aber auch auf Quellcode ebene, denn er muss scrollen, suchen und nachträglich strukturieren - also die gleichen Arbeitsschritte wie der WYSIWYG-Nutzer - lediglich die Ansicht ist eine Andere.

Müsstest du sowieso, du sparst dir nur das Tippen des rudimentären Markups, welches du durch Klicken einfügen kannst. Mehr nicht. Die Unterstützungsmöglichkeiten eines Editors endet dort.

Ja himmel hergott - manchmal frage ich mich wirklich, was hier für Gestalten wandeln (sorry - jetzt muss ich mich mal aufregen). Der Editor soll Dich ja nur unterstützen - er soll Dir weder das Denken abnehmen noch die Möglichkeit selber zu bestimmen, was passiert. Meine Güte...

http://dict.leo.org/?p=iB2QE.&search=editor

Gruß

Axel

[molily]

Hallo, Axel,

Gar nicht, das ist per se nicht oder nur äußerst umständlich über die grafische Ebene realisierbar. Diese Elemente lassen sich zwar zum Teil über Schaltflächen einfügen, aber nur als Markup, wodurch die Codeansicht anspringt. Semantisches Markup hat keine eindeutige Relation zur Visualisierung; logischerweise kann ein WYSIWYG-Editor diese Arbeit nicht übernehmen, somit fällt er für diese Aufgabe weg. Das kann überhaupt nicht funktionieren und ist m.M.n. auch nicht als Kritikpunkt eines WYSIWYG-Editor geeignet. Kein Editor wird in diesem Punkt auch nur annähernd die Flexibilität von direkt verfassten Code erreichen, es sei denn, der WYSIWYG arbeitet selbst äußerst codenah... Ein Vergleich fällt mir momentan nicht ein, ich kann mich gar nicht mehr an Amaya erinnern.

Völlig an den haarsträubender Mischmasch aus Glauben, Annahmen und Überzeugungen - da ist wenig bis nichts haltbares dran.

Bitte auseinandernehmen, sonst ist an dieser Behauptung nämlich auch nichts Haltbares dran. *smirk*

Wo ist bitte das Problem? Ich kriege Texte im Allgemeinen in digitaler oder "analoger" Form - selten mündlich. D.h. ich schaue mir den Text im Vorfeld an, mache meine Notizen und übertrage ihn. Es ist absolut KEINE Arbeit und KEINE Mühe die entsprechenden "Strukturierungen" vorzunehmen.

Habe ich nicht behauptet. Es ging um die von Christian genannten Elemente - diese müssen von Hand eingegeben werden, weil ein (visueller) Editor, wie ich sagte nicht von der Visualisierung auf den Code schließen kann. Ab einem gewissen Punkt muss codenah gearbeitet werden - das an sich ist selbstverständlich, hat aber nichts speziell mit WYSIWYG-Werkzeugen zu tun, weshalb ich sagte:

Das kann überhaupt nicht funktionieren und ist m.M.n. auch nicht als Kritikpunkt eines WYSIWYG-Editor geeignet.

Wer natürlich erst hackt und dann denkt, wird Schwierigkeiten bekommen - die hat er aber auch auf Quellcode ebene, denn er muss scrollen, suchen und nachträglich strukturieren - also die gleichen Arbeitsschritte wie der WYSIWYG-Nutzer - lediglich die Ansicht ist eine Andere.

Es ging um die von Christian genannten Elemente. Die Arbeitsschritte sind dieselben, das wolle ich darstellen, denn ein wie auch immer geaarteter Editor kann dies wie gesagt nicht sonderlich automatisieren beziehungsweise vereinfachen. Wie ich darstellte, lassen sich die genannten Elemente nicht über die visuelle Ansicht einfügen, da sie sich nicht eindeutig visuell äquivalent darstellen lassen, weshalb es zwangsweise nötig ist, dass die Auszeichnung auf Codeebene erfolgt. Ich verstehe nicht ganz, worauf du hinauswillst.

Müsstest du sowieso, du sparst dir nur das Tippen des rudimentären Markups, welches du durch Klicken einfügen kannst. Mehr nicht. Die Unterstützungsmöglichkeiten eines Editors endet dort.

Der Editor soll Dich ja nur unterstützen - er soll Dir weder das Denken abnehmen noch die Möglichkeit selber zu bestimmen, was passiert.

Ähm - habe ich doch gesagt. Das war eine generelle Überlegung, die auf das Verfassen von Hypertext und nicht auf WYSIWYG-Editoren bezogen war und auch nicht direkt eine Kritik an WYSIWYGs sein sollte. Die Möglichkeiten eines jeden Editors, vor allem eines visuellen, sind begrenzt. Christian hat das meiner Meinung nach Unmögliche gefordert und wollte daran ein Kriterium für einen (WYSIWYG-)Editor festmachen, dem wollte ich widersprechen. Eigentlich genau mit deinem Argument. ;)

Grüße,
Mathias

[Axel]

Hi,

Ähm - habe ich doch gesagt. Das war eine generelle Überlegung, die auf das Verfassen von Hypertext und nicht auf WYSIWYG-Editoren bezogen war und auch nicht direkt eine Kritik an WYSIWYGs sein sollte. Die Möglichkeiten eines jeden Editors, vor allem eines visuellen, sind begrenzt. Christian hat das meiner Meinung nach Unmögliche gefordert und wollte daran ein Kriterium für einen (WYSIWYG-)Editor festmachen, dem wollte ich widersprechen. Eigentlich genau mit deinem Argument. ;)

Hmmmmmmmmmmmmmmmmm.....Grüüüüüüüüüüübel.... Am Kopf kratz...

Jaja...So oder anders wirds wohl sein ;-)

Grüße

Axel

[Christian Seiler]

Hallo Mathias,

Diesen JAXE kann ich im Moment nicht ausprobieren...

Aber die Screenshots auf der Homepage hast Du Dir angesehen?

Ich hasse das JRE und überhaupt jede Java-Software

Warum verteufeln alle Java? Ich bin jetzt kein Java-"Jünger", aber ich habe kein Problem damit, Java für bestimmte Zwecke einzusetzen.

(die Performance ist auf meinem Rechner ein Witz,

Alle kommen immer mit der Performance - und bei AWT/Swing stimmt das auch. Aber ein reines Applet ohne AWT/Swing bzw. mit etwas anderem (z.B. SWT) ist in der Geschwindigkeit nicht stark von normalen Programmen zu unterscheiden (ein Unterschied ist zwangsläufig da, da der Code "interpretiert" werden muss), das einzige, was imperformant ist, ist das Starten des JRE. Ich rede hier jetzt auch wieder von dem 150er Pentium mit 48 MB RAM.

Grüße,

Christian

[molily]

Christian,

Diesen JAXE kann ich im Moment nicht ausprobieren...

Aber die Screenshots auf der Homepage hast Du Dir angesehen?

Ja, sieht gut aus, die Anzeige der Elemente gefällt mir sehr. Ich wollte es mir auch sofort herunterladen, nur das »J« in »JAXE« machte mich gleich stutzig.

Ich hasse das JRE und überhaupt jede Java-Software

Warum verteufeln alle Java?

Weiß nicht.

Ich bin jetzt kein Java-"Jünger", aber ich habe kein Problem damit, Java für bestimmte Zwecke einzusetzen.

Moi non plus.

(die Performance ist auf meinem Rechner ein Witz,

Alle kommen immer mit der Performance

Wieso und ob alle »damit kommen«, ist mir nicht bekannt.
Die mir bekannte Java-Software ist i.d.R. auf meinem Rechner aus dem genannten Grund nicht benutzbar, Punkt. Deswegen habe ich nichts pauschal gegen Java, es erfreut mich sicherlich nicht, dass ich zahlreiche plattformübergreifend entwickelte Software nicht vernünftig nutzen kann.

und bei AWT/Swing stimmt das auch. Aber ein reines Applet ohne AWT/Swing bzw. mit etwas anderem (z.B. SWT) ist in der Geschwindigkeit nicht stark von normalen Programmen zu unterscheiden

Der Unterschied ist mir nie bewusst geworden, da ich nicht weiß, ob die Java-Programme, die ich bisher verwendet habe, AWT/Swing verwenden. Ich nehme es an, wenn du das sagst und es die Standardbibliotheken dafür sind.

(ein Unterschied ist zwangsläufig da, da der Code "interpretiert" werden muss)

das einzige, was imperformant ist, ist das Starten des JRE.

Ja! Und wie. Zudem reagiert die GUI, als würde man Fernschach spielen - das liegt womöglich an dem von dir beschriebenen Problem.

Ich rede hier jetzt auch wieder von dem 150er Pentium mit 48 MB RAM.

Ich habe es erst kürzlich auf einem P133 und einem P200 installiert, das Anzeigen eines vergleichsweise simplen Applets braucht bis zu einer Minute, von welcher die Hälfte für das Starten des JRE draufgeht - es frisst *extrem* Ressourcen.

Bei 48 MB RAM belegt Windows schon zwanzig Megabyte, den Rest i.d.R. ein Browser. Alles weitere läuft ausschließlich über den Swapspace...

Grüße,
Mathias

[Christian Seiler]

Hallo Mathias,

Christian,

Hatten wir das nicht erst? ;-)

Ja, sieht gut aus, die Anzeige der Elemente gefällt mir sehr.

Du verstehst jetzt, warum ich solche Forderungen (<abbr>&co) an einen WYSIWYG-Editor stelle?

Wieso und ob alle »damit kommen«, ist mir nicht bekannt.

Ja, ich meine damit, ständig meckern viele Menschen, dass Java imperformant ist.

Die mir bekannte Java-Software ist i.d.R. auf meinem Rechner aus dem genannten Grund nicht benutzbar, Punkt.

Habe ich nicht bestritten.

Der Unterschied ist mir nie bewusst geworden, da ich nicht weiß, ob die Java-Programme, die ich bisher verwendet habe, AWT/Swing verwenden. Ich nehme es an, wenn du das sagst und es die Standardbibliotheken dafür sind.

Fast alle Java-Programme, die es im Moment gibt, benutzen AWT/Swing, einschließlich JAXE. Leider...

Ich habe es erst kürzlich auf einem P133 und einem P200 installiert, das Anzeigen eines vergleichsweise simplen Applets braucht bis zu einer Minute, von welcher die Hälfte für das Starten des JRE draufgeht - es frisst *extrem* Ressourcen.

Ich weiß nur folgendes: auf dem von mir genannten Rechner ist Java, sobald das JRE erst mal oben ist, benutzbar (und er swapped *kaum*, obwohl Windows 98SE + Mozilla + JRE 1.4.1 läuft), solange kein AWT/Swing verwendet wird. (Also z.B. Demo-Applets, die selbst mit drawOval o.ä. zeichnen, SWT-Applets habe ich noch nie im Internet 'live' gesehen, bisher nur davon gelesen, muss aber gestehen, dass ich mich mit SWT noch nie so intensiv auseinandergesetzt habe, muss ich noch machen) Es gibt aber nur zwei Argumente, die für AWT/Swing sprechen: Erstens ist es aus OOP-Sicht sauberer als andere (z.B. SWT) und zweitens gibt es ein paar Widgets mehr. Beide sind IMHO keine k.o.-Argument, obwohl einige Java-Verfechter beim ersten da anderer Meinung sind. (Reinheit des OOP - naja, wenn sie wenigstens konsequent wären und Eiffel nehmen würden...) Naja, ich hoffe mal, dass SWT sich durchsetzen wird, damit endlich mal Schluss ist mit diesem Performanceargument.

Grüße,

Christian

[molily]

Aloha,

Ja, sieht gut aus, die Anzeige der Elemente gefällt mir sehr.

Du verstehst jetzt, warum ich solche Forderungen (<abbr>&co) an einen WYSIWYG-Editor stelle?

Nein. Dass du diese Anforderungen an einen Editor generell stellst, ist womöglich legitim, aber sie sind mit dem Konzept eines *WYSIWYG-Editors* nicht vereinbar. Ein WYSIWYG-Editor ist ein Werkzeug, welches eben *nicht* für diese Aufgaben gemacht (spezialisiert) ist, es ist für die grafische Realisation mit HTML-typischen Bausteinen gedacht und wird auch dafür eingesetzt, soweit ich die WYSIWYG-Nutzer verstanden habe. Es assistiert ausschließlich an einer ganz bestimmten Stelle im Schaffungsprozess - ein Editor mit den von dir vorgeschlagenen Features würde an einer anderen Stelle angreifen, somit würden sich beide Editorarten eher nebeneinander koexistent ergänzen, sich aber nicht überblenden lassen.
Zumindest ginge dann viel vom eigentlichen »Was du siehst, bekommst du auch« verloren und anderes würde hinzugefügt, was du vermutlich begrüßen würdest. Wie ich sagte, müsste der WYSIWYG im Endeffekt sehr codenah arbeiten, was ausschließt, dass der Editor eine grafische point'n'click- und drag'n'drop-Oberfläche zum Zusammenklicken des Layouts (grenzt an Seitenbeschreibung, siehe DTP-Programme) besitzt, wie es die klassischen WYSIWYGs wie beispielsweise Dreamweaver momentan bieten. Diese mit der o.g. Fähigkeit auszustatten, würde alles Bestehende gewissermaßen untergraben, die einzelnen Fähigkeiten würden sich (in der Entwurfsansicht) behindern und widersprechen.

Noch einmal:

logischerweise kann ein WYSIWYG-Editor diese Arbeit nicht übernehmen, somit fällt er für diese Aufgabe weg.

Ich habe es erst kürzlich auf einem P133 und einem P200 installiert, das Anzeigen eines vergleichsweise simplen Applets braucht bis zu einer Minute, von welcher die Hälfte für das Starten des JRE draufgeht - es frisst *extrem* Ressourcen.

[...] Naja, ich hoffe mal, dass SWT sich durchsetzen wird, damit endlich mal Schluss ist mit diesem Performanceargument.

Hmmm, schön und gut, Tatsache ist, dass mein Vater meckert, dass die Applets ewig lahm laden und der Browser solange unbenutzbar ist. Mehr als »das ist leider so« kann ich ihm nicht antworten, auf die Frage, woran das liegt - mit der Metamitteilung, ob sich dies beschleunigen lässt - kann ich auch nichts antworten.
MSIE und das Mickeysoft-Java will ich ihm mit Sicherheit nicht installieren, obwohl es schneller lädt, oder schon vorher Speicher belegt, je nachdem. Ich muss gestehen, ich hatte ihm anfangs überhaupt kein JRE installiert, weil es heutzutage m.M.n. nicht nötig ist im Web...

Grüße,
Mathias

[Christian Seiler]

Hallo Mathias,

Ein WYSIWYG-Editor ist ein Werkzeug, welches eben *nicht* für diese Aufgaben gemacht (spezialisiert) ist, es ist für die grafische Realisation mit HTML-typischen Bausteinen gedacht und wird auch dafür eingesetzt, soweit ich die WYSIWYG-Nutzer verstanden habe.

Wenn Du WYSIWYG-Editor so definierst, dann ist Deine Kritik natürlich legitim. Aber nachdem ich persönlich WYSIWYG im Web für eine Illusion halte, dehne ich für gewöhnlich. den Begriff auf Editoren mit Browsernaher darstellung aus.

Diese mit der o.g. Fähigkeit auszustatten, würde alles Bestehende gewissermaßen untergraben, die einzelnen Fähigkeiten würden sich (in der Entwurfsansicht) behindern und widersprechen.

Da hast Du natürlich recht.

MSIE und das Mickeysoft-Java will ich ihm mit Sicherheit nicht installieren, obwohl es schneller lädt, oder schon vorher Speicher belegt, je nachdem. Ich muss gestehen, ich hatte ihm anfangs überhaupt kein JRE installiert, weil es heutzutage m.M.n. nicht nötig ist im Web...

Ich finde es halt schade, dass SUN ihr eigenes, an sich gutes, Konzept durch so etwas versauen...

Grüße,

Christian

[Axel]

Hallo,

Wenn Du WYSIWYG-Editor so definierst, dann ist Deine Kritik natürlich legitim. Aber nachdem ich persönlich WYSIWYG im Web für eine Illusion halte, dehne ich für gewöhnlich. den Begriff auf Editoren mit Browsernaher darstellung aus.

Hmmm....Könnte man sich denn nicht auf "WYSINWYG" (What You See Is Nearly What You Get) oder "WYSIWYETG" (What You See Is What You Expect To Get) oder "WYSIWYHTG" (What You See Is What You Hope To Get) einigen? Das trifft die Sache dann doch - oder?

Regelvorschlag:

Anstelle von "WYSIWYG" wird jetzt ausschließlich "WYSINWYG","WYSIWYETG" oder "WYSIWYHTG" im Zusammenhang mit Editoren wie DMX,FP,NAME,FUSION verwendet ;-)

Grüße

Axel

[Axel Napolitano]

Ich finde einfach das man mehr kompatibilität und mehr wiederverwendbarkeit erreicht wenn man es ohne WYSIWYG EDitor macht.
Von Adobe GoLive und Frontpage will ich jetzt gar nicht erst sprechen.

Hallo,

kannst Du diese etwas merkwürdige und okkulte Aussage ein wenig ausführen?

Grüße

Axel

[uepselon]

Hallo Axel,

Ich finde einfach das man mehr kompatibilität und mehr wiederverwendbarkeit erreicht wenn man es ohne WYSIWYG EDitor macht.
Von Adobe GoLive und Frontpage will ich jetzt gar nicht erst sprechen.

kannst Du diese etwas merkwürdige und okkulte Aussage ein wenig ausführen?

Es ist z.B. sehr schwierig ein mit GoLive erstelltes Projekt neu zu gestalten. Weil die Tabellen endlos verschachtelt und mit unzähligen
Attributen versehen werden.

ueps

[Axel]

Es ist z.B. sehr schwierig ein mit GoLive erstelltes Projekt neu zu gestalten. Weil die Tabellen endlos verschachtelt und mit unzähligen
Attributen versehen werden.

ueps

Hi,

Das mag wohl so stimmen - aber hier ist ja auch nicht von GoLive die Rede. Ich kann das im Falle von GoLive auch nicht kommentieren, da ich das Programm lediglich vom Namen her kenne.

Grüße

Axel

[uepselon]

Hi,

Das mag wohl so stimmen - aber hier ist ja auch nicht von GoLive die Rede. Ich kann das im Falle von GoLive auch nicht kommentieren, da ich das Programm lediglich vom Namen her kenne.

es war auch nur ein Beispiel auf meine deiner Ansicht nach "okkulte" Aussage!

Die Probleme die Dreamweaver u.U. mit sich bringen kann, stehen hier:

[pref:t=32615&m=176899]

Gruß

ueps

[Christian]

Hallo ins Forum,

ich bin mittlerweile Dreamweaver MX Nutzer geworden.

Mein Eindruck bisher: Wenn's noch Bilder bearbeiten
könnte, bräuchte ich nur noch 'nen OS und das gute
Stück auf meiner Kiste...

Nun zur Frage: Was haltet ihr von Dreamweaver MX

hm, also auf der Arbeit schreiben wir mit Ultraedit *g*.
Aber iich gebe zu, dass ich Zuhause für manche Dinge Dreamweaver
benutze, weil es einfach schneller geht und übersichtlicher ist.
z.b. Forms, die in Tabellen verschachtelt sind.
Der Code von DW ist wirlich ok. Jeder der sagt, er würde mit der
Hand besseren produzieren - übersieht oft, dass in handgeschriebenem Code oft auch Fehler sind ... und brezel mal 20 Tabellen ineinander, dann stehste beim editieren manchmal wirklich wie der Ochs vorm Berg (hier wieder mal kein TR geschlossen usw ...)

Dreamweaver ist schon ein annehmbares Tool und wird anscheinend auch immer mehr in professionellen Firmen eingesetzt (weil der AZUBI dann auch Seiten machen kann *g*). Aber der Preis hats auch wirklich in sich :-)

[uepselon]

Hi,

Der Code von DW ist wirlich ok. Jeder der sagt, er würde mit der
Hand besseren produzieren - übersieht oft, dass in handgeschriebenem Code oft auch Fehler sind ... und brezel mal 20 Tabellen ineinander, dann stehste beim editieren manchmal wirklich wie der Ochs vorm Berg (hier wieder mal kein TR geschlossen usw ...)

1. 20 Tabellen ineinander zu verschachteln ist genauso "unsauber" wie iFrames oder von GoLive erstellte Seiten ;-)

2. Schon mal was von eineam Validator gehört?

Gruß

ueps

[Tom Maisch]

Hi,

Hi,

Der Code von DW ist wirlich ok. Jeder der sagt, er würde mit der
Hand besseren produzieren - übersieht oft, dass in handgeschriebenem Code oft auch Fehler sind ... und brezel mal 20 Tabellen ineinander, dann stehste beim editieren manchmal wirklich wie der Ochs vorm Berg (hier wieder mal kein TR geschlossen usw ...)

1. 20 Tabellen ineinander zu verschachteln ist genauso "unsauber" wie iFrames oder von GoLive erstellte Seiten ;-)

definiere 'unsauber'.

2. Schon mal was von eineam Validator gehört?

Ja, und?

Gruß

ueps

[Stonie]

Hi Tom,

auch wenn ich fürchte, dafür wieder mal einen auf die Mütze zu kriegen:

Das ist eigentlich _kein_ Diskussionsbeitrag. Sei doch so nett und sag' deine Meinung - mit hochgezogenen Augenbrauen einfach so hingeworfenen Kurzbemerkungen entsteht kein Meinungsaustausch, höchstens Missverständnisse.

File Griese,

Sto*baldbinichwiederganzda*nie

[Tom Maisch]

Hi,

Hi Tom,

auch wenn ich fürchte, dafür wieder mal einen auf die Mütze zu kriegen:

Das ist eigentlich _kein_ Diskussionsbeitrag. Sei doch so nett und sag' deine Meinung - mit hochgezogenen Augenbrauen einfach so hingeworfenen Kurzbemerkungen entsteht kein Meinungsaustausch, höchstens Missverständnisse.

warum auf die Mütze? Ich glaube eine Diskussion ist hier leider
nicht mehr denkbar. Deshalb keine Bemühungen mehr von meiner Seite.

Gruß

[uepselon]

Hi,

warum auf die Mütze? Ich glaube eine Diskussion ist hier leider
nicht mehr denkbar. Deshalb keine Bemühungen mehr von meiner Seite.

Werft Sie auf den Scheiterhaufen, die anderer Meinung sind!

[PixSch]

Tach,

Der Code von DW ist wirlich ok. Jeder der sagt, er würde mit der
Hand besseren produzieren - übersieht oft, dass in handgeschriebenem Code oft auch Fehler sind ... und brezel mal 20 Tabellen ineinander, dann stehste beim editieren manchmal wirklich wie der Ochs vorm Berg (hier wieder mal kein TR geschlossen usw ...)

Wo er recht hat, hat er recht.

1. 20 Tabellen ineinander zu verschachteln ist genauso "unsauber" wie iFrames oder von GoLive erstellte Seiten ;-)

2. Schon mal was von eineam Validator gehört?

Und wenn man die 20 Tabellen braucht?

Gruß
ueps

Same.Same.

[uepselon]

Hi,

Und wenn man die 20 Tabellen braucht?

Dann sollte man nochmal an seinem Konzept arbeiten ;-)

ueps

[Danny]

Und wenn man die 20 Tabellen braucht?

Man braucht gar KEINE Tabellen. Selbst für komplexe Layouts nicht. Lediglich für Daten, bzw. Listen von irgendwelchen Artikeln und so Zeug...

[Danny]

Hi,

und brezel mal 20 Tabellen ineinander, dann stehste beim editieren manchmal wirklich wie der Ochs vorm Berg (hier wieder mal kein TR geschlossen usw ...)

Welche Tabellen ??? Ich verzichte bei neuen Layouts komplett darauf... CSS2 sei dank!

Gruß,
Danny

[Axel Napolitano]

Hi,

und brezel mal 20 Tabellen ineinander, dann stehste beim editieren manchmal wirklich wie der Ochs vorm Berg (hier wieder mal kein TR geschlossen usw ...)

Welche Tabellen ??? Ich verzichte bei neuen Layouts komplett darauf... CSS2 sei dank!

Gruß,
Danny

Hallo,

technisch wertvoll - aber leider aufwändig bei komplexen Layouts und wenn es zu alten bzw. exotischen Browsern kompatibel sein soll.

Zudem ist der Rechenaufwand bei Tabellen mit Maßangaben erheblich geringer als bei Deinen Aktionen - der Bildaufbau ist schneller. Das macht bei aktuellen Rechnern nicht viel aus - aber wohl bei alten Rechnern - und die gibt's auch noch.

Gruß

Axel

[Christian Seiler]

Hallo Axel,

aber leider aufwändig bei komplexen Layouts

Wie das? Entschuldige, was ist aufwändiger? 3 Divs oder 20 verschachtelte Tabellen?

und wenn es zu alten bzw. exotischen Browsern kompatibel sein soll.

An welche denkst Du da? Cyx wollte ja mal was zum Thema CSS-Layouts und Netscape 4 ins Netz stellen, da bin ich ganz gespannt darauf. Außerdem sind gerade CSS-Layouts kompatibler zu exotischen Browsern wie lynx, w3m, links und ScreenReadern.

Zudem ist der Rechenaufwand bei Tabellen mit Maßangaben erheblich geringer als bei Deinen Aktionen

Häääää? Beim Netscape 4 *könnte* das vielleicht stimmen (da bin ich mir aber auch nicht sicher), aber CSS-Layouts werden von den meisten Browsern schneller gerendert als Tabellen-Layouts. Warum? Ganz einfach: Bei verschachtelten Tabellen muss erst mal zumindest eine Zeile geladen werden, beovr etwas angezeigt wird. Wenn Du mit Maßangaben feste Pixelgrößen meinst, dann hast Du in meinen Augen schon kein Argument mehr, dann ist die Seite überhaupt nicht skalierbar.

aber wohl bei alten Rechnern - und die gibt's auch noch.

http://www.fractatulum.de/fraccss/ wird auf einem P150 (ohne MMX) mit 48 MB RAM (Win98SE) und einem Mozilla 1.2.1 (dessen Systemanforderungen *viel* höher sind) sehr flüssig gerdendert.

Grüße,

Christian

[Axel]

Hi Christian,

Hallo Axel,

aber leider aufwändig bei komplexen Layouts

Wie das? Entschuldige, was ist aufwändiger? 3 Divs oder 20 verschachtelte Tabellen?

Hängt vom Layout ab. Dein Beispiel, aus 20 Tabellen 3 Divs zu machen trifft wohl auf einen unteren Prozentsatz zu - ist aber natürlich möglich und dort würde es unter bestimmten Bedingungen (die mir nicht passen) Sinn machen.

Zudem ist der Rechenaufwand bei Tabellen mit Maßangaben erheblich geringer als bei Deinen Aktionen

Häääää? Beim Netscape 4 *könnte* das vielleicht stimmen (da bin ich mir aber auch nicht sicher), aber CSS-Layouts werden von den meisten Browsern schneller gerendert als Tabellen-Layouts.

Da sind wir unterschiedlicher Auffassung und verwenden wohl unterschiedliche Daten als Grundlage - kann vorkommen (traue keinem Benchmark, den Du nicht selber manipuliert hast ;-))

Warum? Ganz einfach: Bei verschachtelten Tabellen muss erst mal zumindest eine Zeile geladen werden, beovr etwas angezeigt wird. Wenn Du mit Maßangaben feste Pixelgrößen meinst, dann hast Du in meinen Augen schon kein Argument mehr, dann ist die Seite überhaupt nicht skalierbar.

Wer behauptet denn, das eine Seite skalierbar sein muss? Das ist bei einem Teil meiner Kunden Anforderung bei einem anderen Teil geht es um die Umsetzung konkreter Vorstellungen. Zudem arbeite ich gerne so, das ich ein vorhersehbares Ergebnis erhalte - und dazu gehören auch fixe Angaben bestimmte Formate.

Abgesehen davon muss auch erstmal das Stylesheet geladen und angewendet werden - also ohne Laden wenigstens einer Zeile geht da auch nix. Ich will ja CSS nicht schlechtreden - aber ich setze die Formatiermöglichkeiten nicht ausschließlich ein.

Es nutzt mir nichts, wenn die Seite skalierbar ist aber dann vieleicht ein Contentblock auf einem PDA nur noch 3 Zeichen Laufweite hat, weil die Navigation am linken Rand sowie der Skyscraper am rechten Rand alles zusammendrücken. Alles Humbug - die Anforderungen entscheiden, ob fixiert oder nicht - nicht die Eitelkeit des Designers in Bezug auf die technische Brillianz der Lösung.

Zudem sind relative Seiten generell für den Browser schwerer zu rendern - gerade beim Entwickeln für mobile Endgeräte mit vergleichsweise geringen Leistungen und hohen Verbindungskosten (GSM, GPRS etc.) sollte das berücksichtigt werden.

Letztlich ist es aber eine Einstellungssache - ich werde mich aber nicht von meiner Vorgehensweise abbringen lassen - die Seiten die ich mir hier schon angesehen hatte (und die technologisch einwandfrei sowie absolut am limit waren) bestätigen mich.

http://www.fractatulum.de/fraccss/ wird auf einem P150 (ohne MMX) mit 48 MB RAM (Win98SE) und einem Mozilla 1.2.1 (dessen Systemanforderungen *viel* höher sind) sehr flüssig gerdendert.

Im Vergleich zu was?

Gruß

Axel

[Christian Seiler]

Hallo Axel,

Hängt vom Layout ab. Dein Beispiel, aus 20 Tabellen 3 Divs zu machen trifft wohl auf einen unteren Prozentsatz zu - ist aber natürlich möglich und dort würde es unter bestimmten Bedingungen (die mir nicht passen) Sinn machen.

3 Divs waren natürlich übertrieben, aber mit 4-6 kannst Du die meisten Layouts, wozu Du 20 Tabellen brauchst, einigermaßen abbilden.

Wer behauptet denn, das eine Seite skalierbar sein muss?

Das ist so ein Punkt. Es gibt durchaus Seiten, bei denen die nicht-skalierbarkeit gerechtfertigt ist, ich zitiere mal hier wieder das Stempelgeheimnis. Aber wenn man nicht einen guten Grund dagegen hat, sollte eine Seite durchaus schon skalierbar sein, zumindest bis zu einem gewissen Grade.

Zudem arbeite ich gerne so, das ich ein vorhersehbares Ergebnis erhalte - und dazu gehören auch fixe Angaben bestimmte Formate.

Dir ist klar, dass im Web nichts vorhersehbar ist?

Abgesehen davon muss auch erstmal das Stylesheet geladen und angewendet werden - also ohne Laden wenigstens einer Zeile geht da auch nix. Ich will ja CSS nicht schlechtreden - aber ich setze die Formatiermöglichkeiten nicht ausschließlich ein.

In den seltensten Fällen hat das nachladen einer CSS-Datei selbst bei Modem-Verbindung lange gedauert. Außerdem sind CSS-Layout-basierende Dateien kleiner als Dateien mit vielen Tabellen, spätestens wenn der Besucher auf die dritte Seite des "Angebots" kommt, wäre dieser "Vorteil" wieder wettgemacht.

Es nutzt mir nichts, wenn die Seite skalierbar ist aber dann vieleicht ein Contentblock auf einem PDA nur noch 3 Zeichen Laufweite hat, weil die Navigation am linken Rand sowie der Skyscraper am rechten Rand alles zusammendrücken.

Wieso das? Gerade _wenn_ eine Seite skalierbar ist, ist es kein Problem, sie auf einem kleineren Anzeigegerät anzuzeigen. Wenn PDA-Browser desweiteren noch media="handheld" unterstützen _würden_, könntest Du sogar ein anderes, auf PDA angepasstes Layout anbieten,

Alles Humbug - die Anforderungen entscheiden, ob fixiert oder nicht - nicht die Eitelkeit des Designers in Bezug auf die technische Brillianz der Lösung.

Natürlich entscheiden die Anforderungen, das stelle ich ja auch nicht in Frage. Aber wann ist die Anforderung denn, dass eine Seite unbedingt fixiert sein soll? (Und bedenke nie nur die Anforderung Deines Kunden sondern auch die dessen Besucher)

Zudem sind relative Seiten generell für den Browser schwerer zu rendern

Wie das? Dir ist klar, dass das bisschen Rechenaufwand nicht ins Gewicht fällt, wenn Du es mit verschachtelten Tabellen vergleichst? Warscheinlich sind verschachtelte Tabellen sogar langsamer... (da bei jeder Zelle geprüft werden muss, ob nicht eine width-Angabe das ganze Layout verändert)

• gerade beim Entwickeln für mobile Endgeräte mit vergleichsweise geringen Leistungen und hohen Verbindungskosten (GSM, GPRS etc.) sollte das berücksichtigt werden.

Dir ist klar, dass

a) die mobilen Endgeräte nicht sooo leistungsunfähig sind
b) eine JPEG-Graphik zu dekomprimieren bestimmt mehr kostet, als ein paar Angaben zu berechnen
c) gerade wegen den hohen Verbindngskosten kleinere Seiten besser sind

?

ich werde mich aber nicht von meiner Vorgehensweise abbringen lassen

Schade, wenn Du mir überzeugend dargelegt hättest, dass Tabellenlayouts besser wären, dann hätte ich meine Meinung geändert.

die Seiten die ich mir hier schon angesehen hatte (und die technologisch einwandfrei sowie absolut am limit waren) bestätigen mich.

Beispiele + Begründungen?

http://www.fractatulum.de/fraccss/ wird auf einem P150 (ohne MMX) mit 48 MB RAM (Win98SE) und einem Mozilla 1.2.1 (dessen Systemanforderungen *viel* höher sind) sehr flüssig gerdendert.

Im Vergleich zu was?

Zu nichts, Du sagtest ja, dass schlechtere Rechner mit CSS-Layouts probleme haben, das habe ich hier wiederlegt. (Ich denke, dass kaum jemand mit einer viel schlechteren Systemanforderung unterwegs sein wird)

Grüße,

Christian

[Axel]

Hi,

Das ist so ein Punkt. Es gibt durchaus Seiten, bei denen die nicht-skalierbarkeit gerechtfertigt ist, ich zitiere mal hier wieder das Stempelgeheimnis. Aber wenn man nicht einen guten Grund dagegen hat, sollte eine Seite durchaus schon skalierbar sein, zumindest bis zu einem gewissen Grade.

Warum? Nenne mir einen zwingenden Grund. Wenn das Layout es vorsieht, wird sie auch skalierbar sein - wenn nicht, dann halt nicht. Ich werde keine Seite skalierbar machen, nur damit sie es ist.

Zudem arbeite ich gerne so, das ich ein vorhersehbares Ergebnis erhalte - und dazu gehören auch fixe Angaben bestimmte Formate.

Dir ist klar, dass im Web nichts vorhersehbar ist?

Och.. In gewisser Weise schon.

In den seltensten Fällen hat das nachladen einer CSS-Datei selbst bei Modem-Verbindung lange gedauert. Außerdem sind CSS-Layout-basierende Dateien kleiner als Dateien mit vielen Tabellen, spätestens wenn der Besucher auf die dritte Seite des "Angebots" kommt, wäre dieser "Vorteil" wieder wettgemacht.

Da hast Du nicht ganz unrecht. Nur nehmen wir mal die Realität: Die wenigsten Layouts, die ich bisher erstellt habe, benötigen mehr als 3 verschachtelte Tabellen.

Wieso das? Gerade _wenn_ eine Seite skalierbar ist, ist es kein Problem, sie auf einem kleineren Anzeigegerät anzuzeigen.

Hast Du schonmal gesehen, was dabei zum Teil rauskommt - es ist grausam! Lieber lasse ich den User ein wenig scrollen.

Wenn PDA-Browser desweiteren noch media="handheld" unterstützen _würden_, könntest Du sogar ein anderes, auf PDA angepasstes Layout anbieten,

Wenn! Genau das ist mein Problem. Natürlich nutze ich derartige Möglichkeiten - aber gerade mit dem "media" habe ich ernsthafte Schwierigkeiten.

Mach' Dir mal den Spass und besorge Dir ein paar gängige (nicht die neuesten) PDAs und betrachte mal dort die Ergebnisse von "skalierbaren" Seiten - du wirst recht oft Schreikrämpfe bekommen.

Natürlich entscheiden die Anforderungen, das stelle ich ja auch nicht in Frage. Aber wann ist die Anforderung denn, dass eine Seite unbedingt fixiert sein soll?

Nehmen wir mal das Beispiel einer Online-Zeitung. Hier _kann_ relativ gearbeitet werden. Der Auftraggeber wünscht sich jedoch ein "vorhersehbares" Ergebnis. Und 500px sind nunmal 500px - egal ob das Pixle nun 0,01 oder 0,1 mm groß ist. Der Textfluss ist auch annähern vorhersehbar.

(Und bedenke nie nur die Anforderung Deines Kunden sondern auch die dessen Besucher)

Danke Pappa.

Wie das? Dir ist klar, dass das bisschen Rechenaufwand nicht ins Gewicht fällt, wenn Du es mit verschachtelten Tabellen vergleichst?

Auf einem aktuellen rechner nicht - bei normalen Layouts sicher auch nicht. Aber da es hier um die Schachtelung geht, müssen wir vom Worstcase ausgehen - und da sind Fixangaben ein Vorteil, da der Browser dann unmittelbar die Dimensionen kennt und diese nicht anhand der prozentualen Angaben in Abhängigkeit zur Größe des Ausgabebereichs errechnen muss (kein geringer Aufwand).

Warscheinlich sind verschachtelte Tabellen sogar langsamer... (da bei jeder Zelle geprüft werden muss, ob nicht eine width-Angabe das ganze Layout verändert)

Nein. Der Browser ist zunächst optimistisch und geht von Außen nach innen. Ist innen etwas größer als außen, wird korrigiert - das frißt dann in der Tat Zeit - aber das wäre ein Fehler des Entwicklers.

Dir ist klar, dass

a) die mobilen Endgeräte nicht sooo leistungsunfähig sind

Davon rede ich.

b) eine JPEG-Graphik zu dekomprimieren bestimmt mehr kostet, als ein paar Angaben zu berechnen

Kommt auf die Komplexität der Angaben an - über den Daumen hast Du aber recht.

c) gerade wegen den hohen Verbindngskosten kleinere Seiten besser sind

Genau. Auf dem PC hast Du den Vorteil des Caches (CSS Datei) ich bin mir aber nicht wirklich sicher, ob jeder PDA ein solches Kosntrukt seitenübergreifend enthält - also nicht jedesmal wieder zugreifen muss.

Sogesehen...

Schade, wenn Du mir überzeugend dargelegt hättest, dass Tabellenlayouts besser wären, dann hätte ich meine Meinung geändert.

Will ich ja nicht. Jeder muss so arbeiten, das er zum Ergebnis stehen kann.

die Seiten die ich mir hier schon angesehen hatte (und die technologisch einwandfrei sowie absolut am limit waren) bestätigen mich.

Beispiele + Begründungen?

Denunzierungen finde ich unangebracht. Begründung: Sie sind meistens nur mit den aktuellsten Browsern in voller Pracht zu bewundern - dann sehen die meisten klasse aus...Aber wehe, Du kommst mit einem Uralt Netscape daher - dann geht das nicht und jenes sieht nicht gut aus und ein Layer wird deplatziert oder mittels wahnsinniger (aber interessanter) Tricks wird dann für jeden Browser wieder etwas "zurechtgebogen".

Es bringt nichts, um jeden Preis alles technisch machbare auch zu machen . manchmal sollte man bneuen Entwicklungen etwas mehr Zeit zum reifen geben.

Ich denke bestimmt in ein paar Monaten etwas anders über die Sache - dann ist die Wahrscheinlichkeit alter Browser ohne gute CSS-Unterstützung wieder etwas gesunken - aber im Moment gibt es noch zuviele Wenn und Abers.

Im Vergleich zu was?

Zu nichts, Du sagtest ja, dass schlechtere Rechner mit CSS-Layouts probleme haben, das habe ich hier wiederlegt. (Ich denke, dass kaum jemand mit einer viel schlechteren Systemanforderung unterwegs sein wird)

Ja ohne Vergleich nutzt das nichts. Ist schön, das es flott geht - aber das hat keine Aussagekraft.

Gruß

Axel

[Christian Seiler]

Hallo Axel,

Warum? Nenne mir einen zwingenden Grund. Wenn das Layout es vorsieht, wird sie auch skalierbar sein - wenn nicht, dann halt nicht. Ich werde keine Seite skalierbar machen, nur damit sie es ist.

Dir sind die Vorteile der Skalierbarkeit nicht bewußt?

Dir ist klar, dass im Web nichts vorhersehbar ist?

Och.. In gewisser Weise schon.

Das möchte ich sehen.

Mach' Dir mal den Spass und besorge Dir ein paar gängige (nicht die neuesten) PDAs und betrachte mal dort die Ergebnisse von "skalierbaren" Seiten - du wirst recht oft Schreikrämpfe bekommen.

Ich hab nicht das Geld, ansonsten würde ich es gerne tun...

Nehmen wir mal das Beispiel einer Online-Zeitung. Hier _kann_ relativ gearbeitet werden.

Eben.

Der Auftraggeber wünscht sich jedoch ein "vorhersehbares" Ergebnis.

Das wird er im Web nie bekommen.

Und 500px sind nunmal 500px - egal ob das Pixle nun 0,01 oder 0,1 mm groß ist. Der Textfluss ist auch annähern vorhersehbar.

Und wenn 500px etwa nur die Hälfte meines Browserfensters einnehmen?

Auf einem aktuellen rechner nicht - bei normalen Layouts sicher auch nicht. Aber da es hier um die Schachtelung geht, müssen wir vom Worstcase ausgehen - und da sind Fixangaben ein Vorteil, da der Browser dann unmittelbar die Dimensionen kennt und diese nicht anhand der prozentualen Angaben in Abhängigkeit zur Größe des Ausgabebereichs errechnen muss (kein geringer Aufwand).

Noch ein Grund, warum man keine Tabellenlayouts nehmen soll... Wenn Du ein paar <div>s hast, dann werden die idealierweise nur zum <body> ausgerichtet.

ich bin mir aber nicht wirklich sicher, ob jeder PDA ein solches Kosntrukt seitenübergreifend enthält - also nicht jedesmal wieder zugreifen muss.

Ich bezweifle, dass die PDAs keinen Cache haben, zumindest einen kleinen wird es geben. Und normale CSS-Dateien sind nicht groß.

Will ich ja nicht. Jeder muss so arbeiten, das er zum Ergebnis stehen kann.

Wenn Du mit dieser Einstellung kommst, dann ist eine Diskussion sinnlos. Eine Diskussion funktioniert nur, wenn auch nur die geringste Chance besteht, dass einer der beiden Diskussionspartner den anderen überzeugt.

Aber wehe, Du kommst mit einem Uralt Netscape daher - dann geht das nicht und jenes sieht nicht gut aus und ein Layer wird deplatziert oder mittels wahnsinniger (aber interessanter) Tricks wird dann für jeden Browser wieder etwas "zurechtgebogen".

Bei Tabellenlayouts trickst man doch auch, das hat man schon immer getan.

Es bringt nichts, um jeden Preis alles technisch machbare auch zu machen .

Natürlich nicht. Deswegen halte ich mich auch in vielen Bereichen noch zurück. Ich könnte für mathematische Formeln prima MathML nehmen, aber bisher verstehen das nur Mozilla und Amaya...

manchmal sollte man bneuen Entwicklungen etwas mehr Zeit zum reifen geben.

Entschuldige mal, aber CSS2 existiert als Recommendation seit 1998, CSS1 seit 1996.

Ich denke bestimmt in ein paar Monaten etwas anders über die Sache - dann ist die Wahrscheinlichkeit alter Browser ohne gute CSS-Unterstützung wieder etwas gesunken - aber im Moment gibt es noch zuviele Wenn und Abers.

Ich spreche Dich noch mal darauf an.

Ja ohne Vergleich nutzt das nichts. Ist schön, das es flott geht - aber das hat keine Aussagekraft.

flott = genausoschnell angezeigt, wie alle anderen Webseiten mit etwa der gleichen gesamten Dateigröße.

Grüße,

Christian

[Axel]

Hallo,

Warum? Nenne mir einen zwingenden Grund. Wenn das Layout es vorsieht, wird sie auch skalierbar sein - wenn nicht, dann halt nicht. Ich werde keine Seite skalierbar machen, nur damit sie es ist.

Dir sind die Vorteile der Skalierbarkeit nicht bewußt?

Ja und auch die Nachteile. Allerdings geht mir Deine Fragestellung auf den Geist - sie impliziert potenzielle Dummheit beim Gegenüber ohne das der Fragestellende seine vermeindliche Kompetenz zur Geltung gebracht hat.

Mach' Dir mal den Spass und besorge Dir ein paar gängige (nicht die neuesten) PDAs und betrachte mal dort die Ergebnisse von "skalierbaren" Seiten - du wirst recht oft Schreikrämpfe bekommen.

Ich hab nicht das Geld, ansonsten würde ich es gerne tun...

Tja... Du könntest so etwas auch ohne Geld bewerkstelligen: Leihen von Freunden, im Geschäft testen etc.

Und 500px sind nunmal 500px - egal ob das Pixle nun 0,01 oder 0,1 mm groß ist. Der Textfluss ist auch annähern vorhersehbar.

Und wenn 500px etwa nur die Hälfte meines Browserfensters einnehmen?

Dann ist das völlig belanglos, weil ich trotzdem das gewünschte Layout habe. Einziger Nachteil für jemanden, den es stört ist der freie Raum am Rand.

Wenn die Aufgabenstellung lautet "Erstelle mir ein Layout, das unter allen Umständen mit dem Fenster des Users skaliert" ist das ein völlig anderes paar Schuhe.

Noch ein Grund, warum man keine Tabellenlayouts nehmen soll... Wenn Du ein paar <div>s hast, dann werden die idealierweise nur zum <body> ausgerichtet.

Idealerweise - und dann kommen ein paar Hanseln daher und basteln mit Positionsangaben an den Divs rum (weil es ja möglich ist) und siehe da, der Käse fällt unter nicht allzu abwegigen Umständen zu einem wirren Geklumpe zusammen.

Ich bezweifle, dass die PDAs keinen Cache haben, zumindest einen kleinen wird es geben. Und normale CSS-Dateien sind nicht groß.

Ich habe auf vielen Seiten CSS-Datei gesehen, die die 16KB-Grenze deutlich überschreiten. Und interessant beim Cache ist, wie dieser arbeitet - natürlich habe auch diese Geräte ein, denn sonst könnten sie die Seite schwerlich herunterladen um sie anzuzeigen.

Wenn Du mit dieser Einstellung kommst, dann ist eine Diskussion sinnlos. Eine Diskussion funktioniert nur, wenn auch nur die geringste Chance besteht, dass einer der beiden Diskussionspartner den anderen überzeugt.

Quatsch.

Bei Tabellenlayouts trickst man doch auch, das hat man schon immer getan.

Nein. Wo ist der Trick? Ich benutze eine Tabelle um Informationen in einem Raster auszugeben.

manchmal sollte man bneuen Entwicklungen etwas mehr Zeit zum reifen geben.

Entschuldige mal, aber CSS2 existiert als Recommendation seit 1998, CSS1 seit 1996.

Um es mal mit Deiner Fragetechnik zu erledigen:

• Du weißt, was "Recommendation" bedeutet? http://dict.leo.org/?search=recommendation&searchLoc=0&relink=on&spellToler=std&sectHdr=off&tableBorder=1&cmpType=relaxed&lang=de

• Du weißt, wie es um die Unterstützung von CSS (insb. CSS2) bei Browsern bestellt ist?

Ja ohne Vergleich nutzt das nichts. Ist schön, das es flott geht - aber das hat keine Aussagekraft.

flott = genausoschnell angezeigt, wie alle anderen Webseiten mit etwa der gleichen gesamten Dateigröße.

• Du weißt, wie man Vergleichstests durchführt?

Gruß

Axel

[Christian Seiler]

Hallo Axel,

Allerdings geht mir Deine Fragestellung auf den Geist - sie impliziert potenzielle Dummheit beim Gegenüber ohne das der Fragestellende seine vermeindliche Kompetenz zur Geltung gebracht hat.

Sorry, das meinte ich nicht und ich wollte damit auch nichts implizieren, aber jetzt, wo Du es sagst...

Tja... Du könntest so etwas auch ohne Geld bewerkstelligen: Leihen von Freunden,

Hmm, ja, Danke für den Tipp.

Dann ist das völlig belanglos, weil ich trotzdem das gewünschte Layout habe. Einziger Nachteil für jemanden, den es stört ist der freie Raum am Rand.

Tja, in dem Punkt kommen wir wohl nie weiter aufeinander zu...

und dann kommen ein paar Hanseln daher und basteln mit Positionsangaben an den Divs rum (weil es ja möglich ist) und siehe da, der Käse fällt unter nicht allzu abwegigen Umständen zu einem wirren Geklumpe zusammen.

Wenn jemand mit den Positionsangaben so rumfummelt, dass das ganze zusammenbricht, dann ist er auch imstande, jedes Layout zu zerschießen, egal, worauf es basiert.

Ich habe auf vielen Seiten CSS-Datei gesehen, die die 16KB-Grenze deutlich überschreiten.

Das ist natürlich ein Problem, am besten sollten vor dem Veröffentlichen alle Kommentare herausgenommen werden und alle Angaben kompaktifiziert werden. Denn Kommentare sind die Dinge, die CSS-Dateien am meisten aufblähen.

Wenn Du mit dieser Einstellung kommst, dann ist eine Diskussion sinnlos. Eine Diskussion funktioniert nur, wenn auch nur die geringste Chance besteht, dass einer der beiden Diskussionspartner den anderen überzeugt.

Quatsch.

Warum? Anders gefragt: Welchen materiellen/immateriellen Nutzen sollte eine Diskussion haben, bei dem sich die Teilnehmer nicht aufeinander zu bewegen können?

Bei Tabellenlayouts trickst man doch auch, das hat man schon immer getan.

Nein. Wo ist der Trick? Ich benutze eine Tabelle um Informationen in einem Raster auszugeben.

Und wenn Du Ränder bei einer Tabelle haben willst? Dann verschachtelst Du Tabellen und lässt die Hintergrundfarbe durchseinen. Wenn das kein Trick ist... (nur mal so als Beispiel)

• Du weißt, was "Recommendation" bedeutet? http://dict.leo.org/?search=recommendation&searchLoc=0&relink=on&spellToler=std&sectHdr=off&tableBorder=1&cmpType=relaxed&lang=de

Ja. Mir ist aber auch die Bedeutung im Kontext vom W3C klar.

• Du weißt, wie es um die Unterstützung von CSS (insb. CSS2) bei Browsern bestellt ist?

Ja. Es ist schon sehr nervig, was sich einige Browser erlauben, aber so extrem schlecht, wie sie oft dargestellt wird, ist sie nicht.

• Du weißt, wie man Vergleichstests durchführt?

Prinzipiell ja. Hier ging es um das subjektive Empfinden des Seitenaufbaus. Andersherum: Wie würdest Du denn Deine These belegen, dass CSS-Layouts auf älteren Computern langsamer gerendert werden, als Tabellenlayouts. Ich bin gerne bereit, diese Tests durchzuführen.

Grüße,

Christian

[Axel]

Hi,

Sorry, das meinte ich nicht und ich wollte damit auch nichts implizieren, aber jetzt, wo Du es sagst...

;-)

Dann ist das völlig belanglos, weil ich trotzdem das gewünschte Layout habe. Einziger Nachteil für jemanden, den es stört ist der freie Raum am Rand.

Tja, in dem Punkt kommen wir wohl nie weiter aufeinander zu...

Wohl leider war. Dennoch - ich bin kein vehementer Gegner von "Skalierbarkeit" - sehe sie jedoch nicht als oberste Direktive an.

Wenn jemand mit den Positionsangaben so rumfummelt, dass das ganze zusammenbricht, dann ist er auch imstande, jedes Layout zu zerschießen, egal, worauf es basiert.

Da hst Du leider recht :-(

Das ist natürlich ein Problem, am besten sollten vor dem Veröffentlichen alle Kommentare herausgenommen werden und alle Angaben kompaktifiziert werden. Denn Kommentare sind die Dinge, die CSS-Dateien am meisten aufblähen.

In der Tat sind es die Kommentarzeilen, die die Seiten derart aufblähen. Ich hatte mal darüber nachgedacht, ein Tool zu entwickeln, dass das Erstellen von Stylesheets mit Kommentarzeilen erlaubt - diese aber extern ablegt (Hab's aber wegen einiger Haken wieder verworfen).

Warum? Anders gefragt: Welchen materiellen/immateriellen Nutzen sollte eine Diskussion haben, bei dem sich die Teilnehmer nicht aufeinander zu bewegen können?

Naja... Überzeugen sollte nicht oberstes Ziel sein - vielmehr der Meinungsaustausch. Andererseits fand' ich die Diskussion (obwohl etwas vom Thema abschweifend) garnicht _so_ schlecht.

Und wenn Du Ränder bei einer Tabelle haben willst? Dann verschachtelst Du Tabellen und lässt die Hintergrundfarbe durchseinen. Wenn das kein Trick ist... (nur mal so als Beispiel)

Höchstens ein Taschenspielertrick, weil das "Border"-Attribut nicht wirklich befriedigende Ergebnisse liefert - aber Recht hast Du irgendwie schon.

• Du weißt, wie es um die Unterstützung von CSS (insb. CSS2) bei Browsern bestellt ist?

Ja. Es ist schon sehr nervig, was sich einige Browser erlauben, aber so extrem schlecht, wie sie oft dargestellt wird, ist sie nicht.

"Extrem" nicht - aber leider auch nicht wirklich gut. Daher werde ich mir noch ein wenig Zeit mit bestimmten Finessen lassen.

Prinzipiell ja. Hier ging es um das subjektive Empfinden des Seitenaufbaus. Andersherum: Wie würdest Du denn Deine These belegen, dass CSS-Layouts auf älteren Computern langsamer gerendert werden, als Tabellenlayouts. Ich bin gerne bereit, diese Tests durchzuführen.

Ehrlichgesagt würde mich so ein Test reizen - u.U. ist die Erfahrung daraus durchaus nützlich. Auch meine Aussagen beruhen zum Teil auf Vermutungen und zum Teil auf Aussagen aus verschiedenen Quellen.

Mich persönlich interessiert allerdings vor allem die Thematik rund um PDAs - denn hier wird in Zukunft ein Wachstum zu erwarten sein. Ich mcöhte auch auf derartigen Geräten ansehnliche Ergebnisse in möglichst kurzer Zeit haben - leider habe auch ich nicht die Möglichkeit die Geräte unbegrenzt zum Teste zur Verfügung zu haben.

Gruß

Axel

[Christian Seiler]

Hallo Axel,

Wohl leider war. Dennoch - ich bin kein vehementer Gegner von "Skalierbarkeit" - sehe sie jedoch nicht als oberste Direktive an.

Ich bin da wie gesagt anderer Ansicht: Skalierbarkeit wenn möglich, nur wenn es einen triftigen Grund dagegen gibt, dann nicht. (Ich bin auch nicht vehementer Anhänger von Skalierbarkeit)

In der Tat sind es die Kommentarzeilen, die die Seiten derart aufblähen. Ich hatte mal darüber nachgedacht, ein Tool zu entwickeln, dass das Erstellen von Stylesheets mit Kommentarzeilen erlaubt - diese aber extern ablegt (Hab's aber wegen einiger Haken wieder verworfen).

Ich dachte da vielleicht an ein Script, dass die Dateien durchgeht und alle Kommentare entfernt, bevor die Dateien hochgeladen werden.

"Extrem" nicht - aber leider auch nicht wirklich gut.

Das größte Problem ist die untesrchiedliche Interpretation von diversen Eigenschaften. Dass *alle* Browser eine bestimmte Eigenschaft nicht können, ist weniger problematisch.

Ehrlichgesagt würde mich so ein Test reizen - u.U. ist die Erfahrung daraus durchaus nützlich.

Ich wäre auch dabei, dann könnten wir vielleicht eine Art Tabelle machen, welche Angaben bzw. welche Kombinationen derselben zu großen Geschwindigkeitseinbußen, etc. führen und versuchen, zu interpretieren, warum dem so ist.

Mich persönlich interessiert allerdings vor allem die Thematik rund um PDAs - denn hier wird in Zukunft ein Wachstum zu erwarten sein.

Interesse habe ich auch.

Ich mcöhte auch auf derartigen Geräten ansehnliche Ergebnisse in möglichst kurzer Zeit haben - leider habe auch ich nicht die Möglichkeit die Geräte unbegrenzt zum Teste zur Verfügung zu haben.

Warscheinlich wäre das beste, dass man einmal einen intensiven Test mit allem möglichen macht, und dann "Richtlinien" erstellt. Diese Richtlinien können dann bei der Erstellung helfen und im _Idealfall_ die Dauer der Testphase auf 0 verkürzen. Schade, dass es so gut wie keine Emulatoren gibt...

Grüße,

Christian

[Axel]

Hi,

Ich dachte da vielleicht an ein Script, dass die Dateien durchgeht und alle Kommentare entfernt, bevor die Dateien hochgeladen werden.

Nachteil wäre, das die Kommentare dann weg wären - mein Ziel war, sie zu erhalten aber von der eigentlichen Datei getrennt aufzubewahren.

Ich mcöhte auch auf derartigen Geräten ansehnliche Ergebnisse in möglichst kurzer Zeit haben - leider habe auch ich nicht die Möglichkeit die Geräte unbegrenzt zum Teste zur Verfügung zu haben.

Warscheinlich wäre das beste, dass man einmal einen intensiven Test mit allem möglichen macht, und dann "Richtlinien" erstellt. Diese Richtlinien können dann bei der Erstellung helfen und im _Idealfall_ die Dauer der Testphase auf 0 verkürzen. Schade, dass es so gut wie keine Emulatoren gibt...

Tja leider. Und bei Emulatoren hast Du meist das Problem, das sie lediglich die Software und nicht die Hardware emulieren - auch die Bedienbarkeit einer Seite ist von Interesse - hier können nicht zwangsläufig die gleichen Grudsätze wie für "gewöhnliche" Rechner gelten.

Gruß

Axel

[Tim Tepaße]

Hallo Axel,

Nein. Wo ist der Trick? Ich benutze eine Tabelle um Informationen in einem Raster auszugeben.

Ähm - Tabellen sind aber kein Element, um etwas in einem Raster anzuzeigen, sondern sie sind für tabellarisch angeordnete Daten vorgesehen.

Ebenso könnte man sagen: "Ich benutze <blockquote>, weil ich damit so schön Text einrücken kann."

• Tim

[Axel]

Hi,

Ähm - Tabellen sind aber kein Element, um etwas in einem Raster anzuzeigen, sondern sie sind für tabellarisch angeordnete Daten vorgesehen.

Sei mir nicht böse - aber derartige Auffassungen, die m.E. von einem eingeschränkten Blickfeld zeugen, vertrete ich nicht.

Zudem:

Definiere mal Daten und tabellarische Anordnung.

Gruß

Axel

[Tim Tepaße]

Hallo Axel,

Sei mir nicht böse - aber derartige Auffassungen, die m.E. von einem eingeschränkten Blickfeld zeugen, vertrete ich nicht.

Das sei Dir unbenommen. Allerdings mißbrauchst Du dann Tabellen gegenüber dem ursprünglichen Sinn - das ist Dir klar, oder?

Definiere mal Daten und tabellarische Anordnung.

Daten sind Informationen, können also alles sein, Test, Bilder, gottweiswas.

Wichtiger ist hier die "tabellarische Anordnung". Die Daten stehen im Zusammenhang und die Tabelle ist dafür da, diesen Zusammenhang deutlich zu machen. Dies geschieht durch Tabellenzeilen und -spalten, in denen Daten einer gleichen Eigenschaft stehen. Dazu gehören Überschriften über den Zeilen und Spalten - man kann diese auch noch in Gruppen organisieren. Und zuguterletzt noch eine Beschreibung, worum es sich in der Tabelle handelt.

All das können geeignete Browser verarbeiten und anzeigen bzw. vorlesen.

Hmmm. Anscheinend beschränkst Du Dich ziemlich und nimmst keine dieser Möglichkeiten war, indem Dein einziges Wesensmerkmal einer Tabelle dieses zu sein scheint: "Damit kann man Dinge nebeneinander anordnen.".

Nix für ungut. :-)

• Tim

[Axel]

Hi,

Definiere mal Daten und tabellarische Anordnung.

Daten sind Informationen, können also alles sein, Test, Bilder, gottweiswas.

Aha... Da sind wir uns also schonmal einig.

Wichtiger ist hier die "tabellarische Anordnung". Die Daten stehen im Zusammenhang und die Tabelle ist dafür da, diesen Zusammenhang deutlich zu machen.

Dies geschieht durch Tabellenzeilen und -spalten, in denen Daten einer gleichen Eigenschaft stehen. Dazu gehören Überschriften über den Zeilen und Spalten - man kann diese auch noch in Gruppen organisieren. Und zuguterletzt noch eine Beschreibung, worum es sich in der Tabelle handelt.

Treffen nicht diese Punkte auch auf ein Seitenlayout zu, das mittels Tabellen umgesetzt wurde? Auch hier gibt es Daten gleicher Eigenschaft, die sich gegenüber und untereinander stehen. Auch dort ist etwas in Zeilen und Spalten organisiert u.U. auch in Gruppen.

Wir sind also nur millimeter voneinander entfernt.

Hmmm. Anscheinend beschränkst Du Dich ziemlich und nimmst keine dieser Möglichkeiten war, indem Dein einziges Wesensmerkmal einer Tabelle dieses zu sein scheint: "Damit kann man Dinge nebeneinander anordnen.".

Ich glaube, das Du dich unnötig beschränkst. Ich nutze Tabellen nur etwas merh als jemand der in bei Tabelle nur an Zahlenfriedhof denkt.

Nix für ungut. :-)

dito

Gruß

Axel

[Christian Seiler]

Hallo Axel,

ich klinke mich hier noch mal ein...

Treffen nicht diese Punkte auch auf ein Seitenlayout zu, das mittels Tabellen umgesetzt wurde?

IMHO: nein.

Auch hier gibt es Daten gleicher Eigenschaft, die sich gegenüber und untereinander stehen.

Erläutere das mal bitte genauer.

Auch dort ist etwas in Zeilen und Spalten organisiert u.U. auch in Gruppen.

Organisiert: ja. Aber die Daten stehen in keiner einzigen Relation, die durch eine Tabelle ausgedrückt werden kann, zueinander.

Ich glaube, das Du dich unnötig beschränkst. Ich nutze Tabellen nur etwas merh als jemand der in bei Tabelle nur an Zahlenfriedhof denkt.

Was hat Tabelle mit Zahlenfriedhof zu tun? Ich kann genausogut eine Tabelle machen, in der ich Autos mit Fahhrädern vergleiche und die Vor- und Nachteile aufliste. Das hat nichts mit Zahlen zu tun, aber trotzdem stehen die einzelnen Zellen in beziehung zur Spalte und zur Zeile. Bei einem Tabellenlayout ist dem *nicht* der Fall.

Grüße,

Christian

[Axel]

Hi,

Was hat Tabelle mit Zahlenfriedhof zu tun? Ich kann genausogut eine Tabelle machen, in der ich Autos mit Fahhrädern vergleiche und die Vor- und Nachteile aufliste. Das hat nichts mit Zahlen zu tun, aber trotzdem stehen die einzelnen Zellen in beziehung zur Spalte und zur Zeile. Bei einem Tabellenlayout ist dem *nicht* der Fall.

Na und? Wo ist denn das Problem? Es tut mir leid, das ich nicht willens bin, mich selbstauferlegten und unnötigen Beschränkungen zu unterwerfen.

Aber hier eine persönliche Selbstbeschränkung derart aufzubauschen grenzt schon ein wenig an Fanatismus.

Gruß

Axel

[Christian Seiler]

Hallo Axel,

Es tut mir leid, das ich nicht willens bin, mich selbstauferlegten und unnötigen Beschränkungen zu unterwerfen.

Warum unnötig? HTML ist eine Auszeichnungssprache, sie soll den Inhalt semantisch beschreiben. Eine Tabelle hat semantisch gesehen nichts mit Positionierung zu tun. Warum soll ich ein HTML-Element zu etwas mißbrauchen, wofür es nicht gedacht ist?

Aber hier eine persönliche Selbstbeschränkung derart aufzubauschen grenzt schon ein wenig an Fanatismus.

Was hat das mit Fanatismus zu tun? Die Frage ist einfach die: Was erwarte ich von HTML? Und meine Vorstellung heißt halt nun mal: Semantische, logische Strukturierung des Inhalts. Wenn Du darauf verzichten kannst, oder dich teilweise darin einschränken kannst, dann gibt es keine Einwände gegen ein Tabellenlayout. Ich kann nicht darauf verzichten, da für mich Hypertext mehr als bloß Visualisierung ist.

Grüße,

Christian

[Moses]

Zu nichts, Du sagtest ja, dass schlechtere Rechner mit CSS-Layouts probleme haben, das habe ich hier wiederlegt. (Ich denke, dass kaum jemand mit einer viel schlechteren Systemanforderung unterwegs sein wird)

Hallo Christian,
Du wärst überrascht wieviele "schlechtere" REchner noch im www unterwegs sind.
Ich z.B. arbeite noch mit einem P100 mit 8MB Ram und Win 95 - versuch da mal was zu laden.....
Grüße Moses

[Christian Seiler]

Hallo Moses,

Du wärst überrascht wieviele "schlechtere" REchner noch im www unterwegs sind.

Ja, das bin ich in der Tat. Ich dachte, die meisten würden zumindest 24 MB RAM haben...

Ich z.B. arbeite noch mit einem P100 mit 8MB Ram und Win 95 - versuch da mal was zu laden.....

Mein Beileid... Aber das ist ein prinzipielles Problem Deiner Rechnerkonfiguration und spiegelt sich nicht nur in CSS-Layouts sondern in vielen anderen Dingen auch wieder.

Grüße,

Christian

[Axel]

Hi,

Ich z.B. arbeite noch mit einem P100 mit 8MB Ram und Win 95 - versuch da mal was zu laden.....

Naja...Das ist ein extremes Beispiel - kommt aber performance-mäßig in die Richtung einiger PDAs (wenngleich hier ein Fallobstvergleich stattfindet).

Aber Christian hat recht: Mit dieser Konfiguration hast Du nicht nur bei CSS Probleme - 8 MB sind zu wenig (der Prozessor ist noch passabel zum Surfen ohne Flash und ähnlichem Kram).

Dein Problem kriegst Du mit einem 16MB-Riegel halbwegs in den Griff (sollte es bei I-Bääh für 'nen Euro fünfzig geben)

Grüße

Axel

[molily]

Hallo, Axel und Christian,

Zudem sind relative Seiten generell für den Browser schwerer zu rendern

Wie das? Dir ist klar, dass das bisschen Rechenaufwand nicht ins Gewicht fällt, wenn Du es mit verschachtelten Tabellen vergleichst? Warscheinlich sind verschachtelte Tabellen sogar langsamer... (da bei jeder Zelle geprüft werden muss, ob nicht eine width-Angabe das ganze Layout verändert)

Dazu habe ich eine Erfahrung gemacht, zwar eher unfreiwillig, aber wie auch immer: Mozilla tut sich beim Rendern meiner CSS-formatierten Startseite manchmal äußerst schwer, die Links, welche in vier Spalten untergebracht sind, werden vielleicht mit drei Zeilen pro Sekunde auf den Bildschirm geschrieben, sodass man das Aufbauen der Seite verfolgen kann. Es sieht sehr so aus, als würde Mozilla den Code zu diesem Zeitpunkt Zeile für Zeile lesen (sicher nicht aus der Datei, sondern aus seinem internen Cache, zu diesem Zeitpunkt sollte zwar die Datei schon mit dem XML-Parser in Objekte zerhackt worden sein, was aber nichts an der Beobachtung ändert). Der Code, der am Ende der Datei steht, wird zumindest erst zum Schluss positioniert, auch wenn er räumlich gesehen vor dem anderen Code (bspw. in der ersten Spalte) stehen mag.
Nun lässt sich beobachten, dass die Links nacheinander spaltenweise (in dieser Reihenfolge stehen sie im Code) einsortiert werden, wobei das den Inhalt der Spalte umfassende Element offensichtlich erst angezeigt wird, wenn auch der Inhalt angegangen wird:

<div id="spalte4" style="min-height:2em; border:medium solid black; background-color:gray;">
<div style="display:none">
...
</div>
</div>

...würde natürlich erst erscheinen, wenn Der Browser sich bis zu diesem Punkt vorgearbeitet hat, der Style ist schon im head-Element bekannt.

Ich mutmaße deshalb, dass bei einem Tabellenlayout, bei welchem nicht die komplette Anzeige bereits Interpretieren des Markups bekannt ist (das heißt die Styles nicht schon im Kopfbereich deklariert und das Aussehen determiniert ist), der Browser erst nach dem letzten table-Endtag Berechnungen über die Anzeige stellen kann, da die Zellen voneinander abhängen in Höhe und Breite.

Hierbei wird der Unterschied zwischen Opera 6.05 und 7 Beta deutlich, denn Opera 6.05 rendert bei einem Tabellenlayout (Beispiel http://www.deviantart.com/, Tabellen zuhauf, dutzendfach verschachtelt, alles steckt in einer großen allesumfassenden Tabelle) erst die *komplette* Seite intern und zeigt sie dann erst an (das Resultat ist eine ewig lange Renderzeit, in welcher nichts angezeigt wird). Opera 7 macht es wie Mozilla, die Tabellen werden schon halbfertig angezeigt, wodurch die Anzeige mehrmals beim Rendern »springt«, weil erst nach dem Rendern des Inhalts einer Zelle deren endgültige Größe berechnet werden kann (weil Zellen nicht etwas wie overflow:hidden haben).

a) die mobilen Endgeräte nicht sooo leistungsunfähig sind

<besserwisser>
*fg* Du mixt immer soooo ;) schön Schriftsprache und gesprochene Sprache, die Emphase auf »so« hätte ich eher anders gelöst, »dermaßen« wäre wohl eher ein Schriftsprachenäquivalent, oder »nicht so leistungsfähig, wie du denkst«, oder positiviere es schlichtweg, »sie sind leistungsfähiger als du denken magst«.
</besserwisser>

(Ich denke, dass kaum jemand mit einer viel schlechteren Systemanforderung unterwegs sein wird)

Öhm... *handheb* Aber immerhin 64 MB RAM.

Grüße,
Mathias

[Tim Tepaße]

Hallo Christian,

(hier wieder mal kein TR geschlossen usw ...)

Gute Texteditoren fügen beim schreiben eines Elementes gleich das schließende Tag ein.

• Tim

[mamue]

hallo,

ich glaube, viele von euch kennen die fähigkeiten von dreamweaver mx nicht; ich würde euch raten, dieses programm einmal genauer unter die lupe zu nehmen, bevor ihr zum teil so negative kommentare abgebt; ihr könnt ja ohne weiteres ein anderes programm verwenden, aber man sollte doch fair bleiben und die stärken einer software ehrlich darlegen oder sich ein wenig zurückhalten, wenn man das Programm nicht genau kennt ...

vor allem für größere projekte ist dreamweaver gold wert: etwa tolles site-management; css-möglichkeiten; fehlersuch- und analysemöglichkeiten; templates; bibliothek; verknüpfung mit fireworks mx; vor allem im dynamischen bereich (etwa php-mysql) hat dreamweaver mx stärken, weil hier viele nützliche hilfen angeboten werden;

nachteile sind etwa der verhältnismäßig hohe preis, ein für den einsteiger kaum zu überklickendes funktionsangebot, das eine lange einarbeitungszeit zur folge hat;

mfg
mamue

[PixSch]

.

[Christoph]

Hi

ich benutzte Dreamweaver nur um mir die Tabellen in der Vorschau anzeigen zu lassen, das ist das einzigste was mir dabei hilft! Ansonsten lege ich grossen Wert auf Editplus also reinen texteditor!

Gruß Christoph

[Mathias Bigge]

Hi Kommerzielle Pixelschlampe,

schade, das Niveau der Diskussion ist leider unterhalb der Grasnarbe verlaufen. Schon die vielen Fullquotes zeigen, was von den herrlichen Bekenntnissen zu halten ist. Man kritisiert, was man nicht kennt, getreu dem Motto:

A: "Heine ist doch kein Dichter!"
B: "Sondern?"
A: "Goethe!"

Dass Phase 5 ein tolles Tool ist, ist keine Antwort auf die Frage, was man von Dreamweaver MX hält, oder?

ich bin mittlerweile Dreamweaver MX Nutzer geworden.

Wir haben in der Firma Studio MX angeschafft, vor allem weil's nicht viel mehr gekostet hat als ne Flash-Version, die wir eigentlich kaufen wollten.

Was mich zuerst mal stört, sind zwei Dinge:
1. Das Ding ist derart komplex, dass man erstmal ein paar Tage braucht, bis man die Features auch nur soweit übersieht, bis man flüssig damit arbeiten kann.
2. Die Bildschirme sind derart überfüllt, dass man eigentlich mit einem Einzelbildschirm kaum noch damit arbeiten kann.

Aber einige Schmankerl habe ich auch schon entdeckt, so scheint mir Dreamweaver ganz nebenbei ein HTML-Lerninstrument geworden zu sein, wenn man sich zu dem, was man auf der Wysiwyg-Ebene macht die Tag-Erläuterungen von O'Really einblenden lässt. Die Projektverwaltung war schon immer gut, Linkkontrolle, Verbindung zwischen Website und lokaler SIte usw. Das habe ich schon immer gern genutzt.

Die Tabellenfunktion von Dreamweaver fand ich früher immer schwach, weil sich schnell ungewollte Formatierungen einschleichen, die man nachher dann lustig von Hand korrigieren kann und weg ist der Geschwindigkeitsvorteil. Was ich mehr nutze als Dreamweaver ist das mitgelieferte Homesite, das ich wirklich toll finde, wenn man's erstmal auf seine Bedürfnisse eingestellt hat.

Was ich bei Dreamweaver ganz nett finde, ist die Möglichkeit, ein Bild mal eben in Fireworks zu klicken, um 5 Pixel zu verkleinern und weiter geht's. Auch die Qualität der JPEG-Komprimierung und der GIFs finde ich gut.

Mein Eindruck bisher: Wenn's noch Bilder bearbeiten
könnte, bräuchte ich nur noch 'nen OS und das gute
Stück auf meiner Kiste...

Kann's ja mit Fireworks zusammen ziemlich perfekt, aber auf den guten Photoshop möchte ich doch nicht zu verzichten. Als, mein Fazit: Weniger proprietärer Kram wäre schön, also irgendein Button, mit dem man diesen ganzen Cold Fusion Blödsinn mit einem Klick aus den Menüs verbannen könnte. Etwas weniger überladene Bildschirme wären auch nett. Vorbildlich dagegen die Online-Unterstützung durch Macromedia und entsprechende Foren, Newsgroups usw.

Es ist schon lustig, dass es inzwischen ungefähr genauso komplex ist, eine der größeren Anwendungen vernünftig nutzen zu können, wie eine Programmiersprache zu lernen, aber das gilt ja auch für Photoshop, Access und ähnliche Dinger, von den großen Datenbanken und Programmierumgebungen ganz zu schweigen. Es ist immer eine echte Überlegung, ob es sich lohnt, die Zeit zu investieren, oder ob man bestimmte einfache Aufgaben nicht doch besser von Hand realisiert, etwa mit Phase 5 oder Homesite, die ja auch in vielen Bereichen Unterstützung liefern, dateiübergreifendes Suchen und ersetzen, Linkcheck, Projektverwaltung usw.

Wir können hier kein Macromedia-Forum aufmachen, aber viele Macromedia-Nutzer werden hier immer wieder mitlesen und mitdiskutieren, denn eine simple Weisheit gilt immer noch: Kein WYSIWYG-Editor ist ohne Code-Kenntnisse und WIssen über die zugrundeliegenden Strukturen handhabbar, oder die Projekte enden in der kompletten Katastrophe....

Viele Grüße
Mathias Bigge

[Wilhelm]

Moin Mathias,

Dass Phase 5 ein tolles Tool ist, ist keine Antwort auf die Frage, was man von Dreamweaver MX hält, oder?

Was mich wundert: Die Emacs- und vi-Fraktion meldet sich nicht zu Wort. :)

Jeder soll doch benutzen, was er will und mit was er am besten klar kommt. Ich kenne einen wirklich guten Designer, der von HTML null Schimmer hat(te), aber mit GoLive excellente Seiten erstellte. Ob im Code jetzt Muell enthalten ist oder nicht, spielt keine Rolle, alle gaengigen Browser zeigen die Seiten korrekt an. Der Code interessiert ihn nicht, er macht ja auch keine Auftragsseiten.

Manche Leute sollten sich mal ihre Korinthenkackerei abgewoehnen und den anderen Ihre Meinung lassen. Viele "valide und sauber codierte" Seiten mit den hipsten und letzten CSS-Feature sind oft eine Beleidigung fuers Auge und sehen oftmals auch gleich aus. (gefixte dotted-Boxes nur als Beispiel, die kann ich nicht mehr sehen).

Die ganzen Hardliner sollten auch endlich mal zur Kenntnis nehmen, dass sich auch das WWW veraendert hat. Es ist nicht mehr nur Infoquelle, sondern auch Werbeplatz. Und da kommen Textwuesten nicht mehr so gut an. Ob das jetzt gut ist oder nicht, das ist ein anderes Thema.

Aber die "Moechtegerne-Diktatur" der Hardliner haengt mir persoenlich langsam zum Hals raus, egal ob hier, bei Heise oder sonstwo, egal ob Windows oder Linux, Fanatismus gehoert in die Muelltonne.

Gruesse
Wilhelm

[Axel Napolitano]

Moin Mathias,

Dass Phase 5 ein tolles Tool ist, ist keine Antwort auf die Frage, was man von Dreamweaver MX hält, oder?

Hallo,

ich persönlich finde Phase 5 eigentlich eher mittelmässig. Eigentlich ist nur der nichtvorhandene Preis für mich ein Argument das Tool zu nutzen.

Ich arbeite zur Zeit auf Quellcode-Ebene mit UltraEdit (meinem Lieblingseditor) und ansonsten mit dem MX.

Da MX mittlerweile wirklich guten Output bietet wurde mein Ultraedit eigentlich zum reinen PHP-Editor degradiert - aber das ist auch gut so.

Was mich wundert: Die Emacs- und vi-Fraktion meldet sich nicht zu Wort. :)

Tscha...Wundert mich auch. Mal ehrlich - Emacs ist ein toller Editor, wenn man damit umgehen kann - leider ist die Einarbeitungszeit derart lange, das er sich kaum für einen "Neueinsteiger" lohnt - lediglich Leute die sich eben für diesen Editor interessieren oder ihn schon seit Jahren nutzen haben wirklich etwas davon - und das reichlich.

Ich habe einige Herren älteren Jahrgangs gesehen, die mit Emacs eine Arbeitsperformance hinlegen, die mich wirklich, wirklich beeindruckt hat - ein sehr mächtiges Tool.

Dennoch: Es sollte in die Zukunft geschaut werden - kryptische Bedienung ist nicht mehr zeitgemäß und auch nicht mehr notwendig.

Jeder soll doch benutzen, was er will und mit was er am besten klar kommt.

Da bin ich Deiner Meinung. Mich stören nur einige Leute hier im Forum, die wie Blinde von Farbe sprechen - die Statements dieser Leute sind meist voll von Vorurzeilen (sei es nun die M$-Fraktion oder die WYSIWYG-Hasser-Fraktion). Wenige diskutieren hier fundiert auf Grund eigener Erfahrungen - es gilt ja "cool" zu sein.

Ich kenne einen wirklich guten Designer, der von HTML null Schimmer hat(te), aber mit GoLive excellente Seiten erstellte. Ob im Code jetzt Muell enthalten ist oder nicht, spielt keine Rolle, alle gaengigen Browser zeigen die Seiten korrekt an. Der Code interessiert ihn nicht, er macht ja auch keine Auftragsseiten.

Auch bei Auftragsseiten legitim. Ein Kunde dankt es einem selten, wenn eine Seite 25% mehr kostet, nur weil die Coder den letzten "Kniff" einbauen musste und dann in Kompatibilitätsprobleme gerät, weil der eine Browser diesen Kniff nicht genau so darstellt, wie ein anderer Browser.

Da ist es manchmal besser vielleicht doch auf altmodische Tabellen und und Grafiken zurückzugreifen als irgendwelche technisch wertvollen aber praktisch unrelevanten CSS-Spielerein durchzuziehen.

Dennoch: Valider Code ist wichtig - und wann immer genug Zeit und Budget da ist, sollte sich jemand die Zeit nehmen und dies sicherstellen.

Manche Leute sollten sich mal ihre Korinthenkackerei abgewoehnen und den anderen Ihre Meinung lassen. Viele "valide und sauber codierte" Seiten mit den hipsten und letzten CSS-Feature sind oft eine Beleidigung fuers Auge und sehen oftmals auch gleich aus. (gefixte dotted-Boxes nur als Beispiel, die kann ich nicht mehr sehen).

Tja... Da waren meist Techniker am Werk. Andererseits bringen diese Tüftler die Designer manchmal durch Detaillösungen auf Ideen. Jedoch bin auch ich der Meinung, das viele Seiten technisch einen hohen Perfektionsgrad erreicht haben mögen und am Limit des machbaren sind - aber optisch sind sie einfach potthässlich.

Die ganzen Hardliner sollten auch endlich mal zur Kenntnis nehmen, dass sich auch das WWW veraendert hat. Es ist nicht mehr nur Infoquelle, sondern auch Werbeplatz. Und da kommen Textwuesten nicht mehr so gut an. Ob das jetzt gut ist oder nicht, das ist ein anderes Thema.

Ist ein Argument - aber wenn nur noch nichtssagende Grafiken übrigbleiben, ist der Sinn genauso verfehlt. Es gilt alte Tugenden mit neuen Treibern zu kombinieren. Text ist nunmal das Wichtigste am Web. Grafiken sollten nur zur Verstärkung der Information - nicht aber als Ersatz verwendet werden.

Aber die "Moechtegerne-Diktatur" der Hardliner haengt mir persoenlich langsam zum Hals raus, egal ob hier, bei Heise oder sonstwo, egal ob Windows oder Linux, Fanatismus gehoert in die Muelltonne.

Jepp.. Ausserdem erinnert mich das an die infantilen C64-Amiga-Atari-Schlachten - ziemlich kindisch. Aber die meisten haben diese Entwicklung mit durchlebt und haben einen (wenngleich überzogenen) Hang zum Patriotismus. Das wird sich nicht ausrotten lassen.

Aber um es mal mit den Worten eines bayrischen Parodisten zu sagen: "Toleranz!"

Gruesse
Wilhelm

Gruß

Axel

[Orlando]

Hi Axel,

verd... das gesamte Posting ging soeben den Bach 'runter, es war das umfassendste seit langem... Nichts im Cache, wieder einen Opera7-Bug entdeckt, *argh*. Hier eine Kurzfassung:

Mich stören nur einige Leute hier im Forum, die wie Blinde von Farbe sprechen

Ich danke dir für diesen Satz. Wie sieht's denn bei MX mit der Barrierefreiheit aus? Hast dich mit dieser Thematik schon beschäftigt? Das solltest du, es wird die Lieblingskeule der CSS-Fundi-Fraktion werden...

die Statements dieser Leute sind meist voll von Vorurzeilen (sei es nun die M$-Fraktion oder die WYSIWYG-Hasser-Fraktion). Wenige diskutieren hier fundiert auf Grund eigener Erfahrungen

Ich habe keinerlei Erfahrungen mit WYSIWYG-Tools, Frontpage anno '98 ist nicht erwähnenswert, Macromedia-Produkte benötige ich nicht (das Preis-Leistungs-Verhältnis ist IMHO ein Witz). Dennoch ist eine theoretische Diskussion sinnvoll, das zeigt dieser Thread sehr schön. Ich muss auch keine 300kb schweren Bilder erzeugen, um zu wissen, dass 'man das nicht soll'.

es gilt ja "cool" zu sein.

Mich interessiert jetzt, was du mir als "cool" zu empfinden unterstellst. Die ewige Leier macht auf Dauer nicht wirklich Spaß, zu viele Ignoranten wachsen nach.

Ein Kunde dankt es einem selten, wenn eine Seite 25% mehr kostet, nur weil die Coder den letzten "Kniff" einbauen musste und dann in Kompatibilitätsprobleme gerät, weil der eine Browser diesen Kniff nicht genau so darstellt, wie ein anderer Browser.

Beiden Aussagen muss ich widersprechen:

Ein CSS-Layout ist nicht 25% teurer als ein 'herkömmliches', wie berechnest du diesen Wert eigentlich? ;) Ganz im Gegenteil, bei der Entwicklung ist es wesentlich flexibler und liefert somit schneller Ergebnisse. Wie sieht's denn bei gröberen Änderungen aus, kann da ein WYSIWYIG-Tool auch nur annähernd mithalten? Ich denke nicht, denn selbst, wenn es ausgeklügelte Möglichkeiten (ich denke da an Modularisierung und Auslagerung von Bausteinen) gibt, ist die simple Änderung von ein paar Zeilen im Stylesheet wesentlich effizienter und somit billiger. Ebenso sieht es mit unterschiedlichen Ausgabemedien aus, vor allem bei 'print', da die Unterstützung von 'handheld' derzeit ein schlechter Witz ist. In Anbetracht der Tatsache, dass sich dies sehr schnell ändern kann, verbietet sich der Einsatz von Tabellen allerdings schon derzeit. Und ja, auch Screenreader sollten vernünftig bedient werden. Das schließt den Einsatz von Tabellen nicht grundsätzlich aus, schränkt ihn jedoch gehörig ein.

Zweitens ist es legitim, dass Seiten nicht in allen Browsern gleich aussehen (Fundi: Dazu wurde HTML auch nicht erschaffen, nimm doch PDF, bla), das verhindern die kaputten Browser. Für mich ist dieser Punkt absolut irrelevant, kein Durchschnittsbesucher sucht Unterschiede. Ich sehe es absolut nicht ein, auf Wracks so weit Rücksicht zu nehmen, dass dies die Verwendung neuerer Methoden für bessere Browser erschwert oder gar verhindert. Dieser Preis ist mir zu hoch.

Da ist es manchmal besser vielleicht doch auf altmodische Tabellen und und Grafiken zurückzugreifen als irgendwelche technisch wertvollen aber praktisch unrelevanten CSS-Spielerein durchzuziehen.

CSS-Spielereien, wie du sie nennst, sind für mich durchaus relevant. Sie sprechen die 'Besserverdienenden' unter den Browsernutzern an (diese sehe ich als bevorzugte Zielgruppe an) und entfalten dort ihre Wirkung, das heißt, sie werden oft mit entsprechendem Feedback belohnt. Oder mit Supportanfragen...

Dennoch: Valider Code ist wichtig - und wann immer genug Zeit und Budget da ist, sollte sich jemand die Zeit nehmen und dies sicherstellen.

ACK, mit Ausnahme der Unterstellung bezüglich des Budgets. Oder hast du mit reinen CSS-Layouts Erfahrung? >;)

Manche Leute sollten sich mal ihre Korinthenkackerei abgewoehnen und den anderen Ihre Meinung lassen.

Jedem das Seine, wenn es allerdings nicht erwünscht sein sollte, dass ich hier *meine* Meinung postuliere, muss ich mir einen anderen Ort dafür suchen. Jemandem ein horrendes Validator-Ergebnis um die Ohren zu schlagen ist durchaus berechtigt, oder soll ich etwa raten, was verschiedene Browser zu erraten versuchen?

Viele "valide und sauber codierte" Seiten mit den hipsten und letzten CSS-Feature sind oft eine Beleidigung fuers Auge und sehen oftmals auch gleich aus. (gefixte dotted-Boxes nur als Beispiel, die kann ich nicht mehr sehen).

Das sehe ich ähnlich, viele verzichten leider auf den durchaus sinnvollen Einsatz von Grafiken. Da meine Boxen 'solid' definiert sind, kannst du mich damit gottlob nicht meinen...

Jedoch bin auch ich der Meinung, das viele Seiten technisch einen hohen Perfektionsgrad erreicht haben mögen und am Limit des machbaren sind - aber optisch sind sie einfach potthässlich.

Schönheit entsteht im Auge des Betrachters. Ich empfinde eine semantisch korrekte, voll skalierbare Seite als schön, schon alleine aus dem Grund, da ich dann trotz meiner geringfügigen Sehschwäche keine Probleme damit habe. Ein in 100 Stunden 'geraytraceter' Hintergrund oder welche Seitenbreite/Schriftgröße der Ersteller als angenehm empfindet, interessiert *mich* dagegen wenig.

Die ganzen Hardliner sollten auch endlich mal zur Kenntnis nehmen, dass sich auch das WWW veraendert hat.

Es verändert sich laufend, derzeit schlägt das Pendel IMHO sogar in Richtung der 'Hardliner' (wen immer du auch als solchen ansiehst) aus.

[...] Text ist nunmal das Wichtigste am Web. Grafiken sollten nur zur Verstärkung der Information - nicht aber als Ersatz verwendet werden.

FULL ACK, endlich mal ;)

Aber die "Moechtegerne-Diktatur" der Hardliner haengt mir persoenlich langsam zum Hals raus, egal ob hier, bei Heise oder sonstwo, egal ob Windows oder Linux, Fanatismus gehoert in die Muelltonne.

Lieber Wilhelm, dann schalte dich doch einfach in solche Diskussionen ein - diesen Rundumschlag kann ich nicht passend einordnen.

Aber um es mal mit den Worten eines bayrischen Parodisten zu sagen: "Toleranz!"

Für meine Meinung bitte auch, ja.

LG Roland

[Schuer]

Hallo,

Jeder soll doch benutzen, was er will und mit was er am besten klar kommt.

Manche Leute sollten sich mal ihre Korinthenkackerei abgewoehnen und den anderen Ihre Meinung lassen.

Die ganzen Hardliner sollten auch endlich mal zur Kenntnis nehmen, dass sich auch das WWW veraendert hat. Es ist nicht mehr nur Infoquelle, sondern auch Werbeplatz.

Aber die "Moechtegerne-Diktatur" der Hardliner haengt mir persoenlich langsam zum Hals raus,

Wilhelm, das ist das erste Posting, das ich von dir lese, dass ich persönliche in jeder Hinsicht und vollkommen unterstreichen kann! :-)

Gruß,
_Dirk

[uepselon]

Hallo,

Dass Phase 5 ein tolles Tool ist, ist keine Antwort auf die Frage, was man von Dreamweaver MX hält, oder?

Nein, sicher nicht. Die Antwort war jedoch auch nicht Phase 5 ist toll und MX ist schlecht, sondern es war ein vergleich über die _wichtige_ Funktionalität der beiden Tools. Und im Vergleich zu den Problemen die mit D MX auftauchen war der Hinweis das Phase 5 besser zu Handhaben ist, eine klare Aussage zu dem was man von MX halten soll.

Die ganzen Hardliner sollten auch endlich mal zur Kenntnis nehmen, dass sich auch das WWW veraendert hat. Es ist nicht mehr nur Infoquelle, sondern auch Werbeplatz. Und da kommen Textwuesten nicht mehr so gut an. Ob das jetzt gut ist oder nicht, das ist ein anderes Thema.

Das bestreitet ja auch niemand, aber so wie du das hier schreibst hört es sich an, wie wenn man ohne ein WYSIWYG Editor keine Seiten fürs Auge erstellen könnte. Das stimmt nicht, und ich wage mal zu behaupten, das man ohne diese Editoren Designtechnisch die besten Seiten gestalten kann. Weil man zum einen durch die Quelltextkenntnis sämtliche Möglichkeiten vor Augen hat, die einem HTML und Co bieten. Wer nicht das Handbuch von Dreamweaver auswenig kann, wird niemals auf anhieb die Möglichkeiten der Gestaltung voll ausreizenn können.

Gruß

ueps

[Axel]

Hi,

Nein, sicher nicht. Die Antwort war jedoch auch nicht Phase 5 ist toll und MX ist schlecht, sondern es war ein vergleich über die _wichtige_ Funktionalität der beiden Tools. Und im Vergleich zu den Problemen die mit D MX auftauchen war der Hinweis das Phase 5 besser zu Handhaben ist, eine klare Aussage zu dem was man von MX halten soll.

Das ist ein Vergleich zwischen Äpfel und Birnen - beides ist Fallobst mit Kernen und trotzdem ist es nicht das Gleiche. Abgesehen davon hast Du bereits geäußert, das Du Du DMX nicht wirklich kennst - also objektiv gesehen nicht urteilsfähig bist.

Das bestreitet ja auch niemand, aber so wie du das hier schreibst hört es sich an, wie wenn man ohne ein WYSIWYG Editor keine Seiten fürs Auge erstellen könnte. Das stimmt nicht, und ich wage mal zu behaupten, das man ohne diese Editoren Designtechnisch die besten Seiten gestalten kann. Weil man zum einen durch die Quelltextkenntnis sämtliche Möglichkeiten vor Augen hat, die einem HTML und Co bieten.

Unsinn. Wirklich einfach nur Unsinn und meiner Meinung nach etwas okkult.

Wer nicht das Handbuch von Dreamweaver auswenig kann, wird niemals auf anhieb die Möglichkeiten der Gestaltung voll ausreizenn können.

Wer HTML "auswenig" kann, genausowenig. Talent kann nicht durch eine Spezifikation oder durch eine bestimmte Arbeitsweise "erschaffen" werden. Abgesehen davon dient das Handbuch dem Erlernen der Benutzung des Programms und nicht dem Erlernen von Kreativität - das hast Du offensichtlich nicht verstanden.

Gruß

Axel

[uepselon]

Hi,

Wer HTML "auswenig" kann, genausowenig. Talent kann nicht durch eine Spezifikation oder durch eine bestimmte Arbeitsweise "erschaffen" werden. Abgesehen davon dient das Handbuch dem Erlernen der Benutzung des Programms und nicht dem Erlernen von Kreativität - das hast Du offensichtlich nicht verstanden.

Um kreative Gedanken umzusetzten bedarf es nun mal gültigen und anwendbaren Formalismen. Ob ich diese nun direkt umsetze oder über ein Tool ist im Prinzip egal. Das Tool ist jedoch eine Barriere weil ich erst das Tool kennen muss um die gültigen Formalismen anzuwenden.
D.H. um sauber arbeiten zu können, die doppelte Arbeit. Wer ohne Grundlagen mit dem Tool arbeitet, macht das auf Halbwissen, und das ist schlecht, weil keine langfristigen und umfassenden Aussagen über die Arbeit gemacht werden können.

[Christian Kruse]

Hallo uepselon,

Wer HTML "auswenig" kann, genausowenig. Talent kann
nicht durch eine Spezifikation oder durch eine bestimmte
Arbeitsweise "erschaffen" werden. Abgesehen davon dient
das Handbuch dem Erlernen der Benutzung des Programms
und nicht dem Erlernen von Kreativität - das hast Du
offensichtlich nicht verstanden.

Um kreative Gedanken umzusetzten bedarf es nun mal gültigen
und anwendbaren Formalismen.

Wenn jeder so denken wuerde, wuerde es keinen Fortschritt
geben.

Ob ich diese nun direkt umsetze oder über ein Tool ist im
Prinzip egal. Das Tool ist jedoch eine Barriere weil ich
erst das Tool kennen muss um die gültigen Formalismen
anzuwenden.

Hae? Du hast den Sinn von WYSIWYG-Editoren nicht verstanden.
Sie sollen einem das das Verstehen der Formalismen abnehmen.
Das scheint im Falle von DW MX relativ gut zu gehen (auch
wenn ich es hasse, DW-Sourcecode als Templates zu bekommen).

D.H. um sauber arbeiten zu können, die doppelte Arbeit.
Wer ohne Grundlagen mit dem Tool arbeitet, macht das auf
Halbwissen, und das ist schlecht, weil keine langfristigen
und umfassenden Aussagen über die Arbeit gemacht werden
können.

Kannst du das belegen?

Gruesse,
 CK

[uepselon]

Hi Christian,

Um kreative Gedanken umzusetzten bedarf es nun mal gültigen
und anwendbaren Formalismen.

Wenn jeder so denken wuerde, wuerde es keinen Fortschritt
geben.

Das hat doch mit Fortschritt nichts zu tun? Wenn ich die Sprache beherrsche brauche ich doch keinen Übersetzer, der unter umständen Zeit kostet. Du wirst ja nicht abstreiten das man wenn man z.B. Spanisch lernt, besser Reden kann als wenn man in Deutsch denkt und es von der Maschine übersetzen lässt?

Hae? Du hast den Sinn von WYSIWYG-Editoren nicht verstanden.
Sie sollen einem das das Verstehen der Formalismen abnehmen.
Das scheint im Falle von DW MX relativ gut zu gehen (auch
wenn ich es hasse, DW-Sourcecode als Templates zu bekommen).

Eben da ist find eich das Problem, wenn mir das verstehen abgenommen wird verliere ich mit der Zeit den Überblick. Wenn alle nur noch mit den Editoren arbeiten würden, gäbe es noch eine Handvoll die das eigentliche Prinzip verstanden haben und evtl. Fehler aufdecken und verbesserungen am Formalismus durchführen können, das kann es doch nicht sein?

Halbwissen, und das ist schlecht, weil keine langfristigen
und umfassenden Aussagen über die Arbeit gemacht werden
können.

Kannst du das belegen?

Nein, natürlich nicht. Es ist eine Ansichtssache, die jedoch für mich in vielen Fällen bestätigt wurde.

Gruß

ueps

[Mathias Bigge]

Hi uepselon,

tut mir leid, aber es scheint so, als redetest Du über Dinge, die Du nicht kennst:

Dass Phase 5 ein tolles Tool ist, ist keine Antwort auf die Frage, was man von Dreamweaver MX hält, oder?
Nein, sicher nicht. Die Antwort war jedoch auch nicht Phase 5 ist toll und MX ist schlecht, sondern es war ein vergleich über die _wichtige_ Funktionalität der beiden Tools. Und im Vergleich zu den Problemen die mit D MX auftauchen war der Hinweis das Phase 5 besser zu Handhaben ist, eine klare Aussage zu dem was man von MX halten soll.

Der Vergleich wäre hier Homesite und Phase 5, das wüsstest Du, wenn Du Dreamweaver MX kennen würdest...

Das stimmt nicht, und ich wage mal zu behaupten, das man ohne diese Editoren Designtechnisch die besten Seiten gestalten kann. Weil man zum einen durch die Quelltextkenntnis sämtliche Möglichkeiten vor Augen hat, die einem HTML und Co bieten. Wer nicht das Handbuch von Dreamweaver auswenig kann, wird niemals auf anhieb die Möglichkeiten der Gestaltung voll ausreizenn können.

Also, wenn man schon Designs entwickelt, wird man das in einem spezialisierten Laden sicher eher in Photoshop tun, und dann die Sache codieren oder von einem Fachmann proggen lassen. Natürlich muss der Designer Vorstellungen haben, was im Netz möglich ist, sonst gehen seine Layoutvorschläge ganz ins Leere. Die Behauptung, man könne auf Quelltextebene Layouts entwickeln ist Unfug, vielleicht wären da ein Zeichenstift und ein Block die besseren Werkzeuge, wenn's schon puristisch sein soll.

Also, mal ganz ehrlich, wieviele Stunden hast Du bisher mit dem Dreamweaver gearbeitet? Mir kommt's fast so vor, als seien Deine Argumente aus zweiter Hand.....

Viele Grüße
Mathias Bigge

[uepselon]

Hi,

Also, mal ganz ehrlich, wieviele Stunden hast Du bisher mit dem Dreamweaver gearbeitet? Mir kommt's fast so vor, als seien Deine Argumente aus zweiter Hand.....

Quasi 3-4 Stunden, ist eine recht bescheidene Zeit, ich weiß.
Aber die ersten Eindrücke haben mich negativ gestimmt. Und man muss sich ja ein Produkt nicht unnötig schönreden.
Bei mir wird eine Anwendung installiert die auf Anhieb gut ist!
Desweiteren sind mir einige parallelen zu GoLive und Frontpage aufgefallen, die ich besser kenne.

Ich finde es jetzt z.b. auch Editor unabhängig, viel einfacher und eleganter wenn ich mal eben schnell was testen muss einen Texteditor zum erstellen zu nehmen. Bei den Grafischen muss ich mich oft erst durch eine Wüste vin Dialogen und Einstellungen klicken, zumal dann jedes Programm anders aufgebaut ist. Das schöne an UltraEdit, Proton, MultiEdit und co ist, das viele Dinge ähnlich und Gleich aufgebaut sind. D.h. ich bin Arbeitsplatz unabhängig.

Gruß

ueps

[Axel]

Hallo,

Ich finde es jetzt z.b. auch Editor unabhängig, viel einfacher und eleganter wenn ich mal eben schnell was testen muss einen Texteditor zum erstellen zu nehmen. Bei den Grafischen muss ich mich oft erst durch eine Wüste vin Dialogen und Einstellungen klicken, zumal dann jedes Programm anders aufgebaut ist. Das schöne an UltraEdit, Proton, MultiEdit und co ist, das viele Dinge ähnlich und Gleich aufgebaut sind. D.h. ich bin Arbeitsplatz unabhängig.

??? <etwas ratlos angesichts der etwas komischen schlussfolgerung und ansicht>

Gruß

Axel

[Wilhelm]

Moin,

Ich finde es jetzt z.b. auch Editor unabhängig, viel einfacher und eleganter wenn ich mal eben schnell was testen muss einen Texteditor zum erstellen zu nehmen. Bei den Grafischen muss ich mich oft erst durch eine Wüste vin Dialogen und Einstellungen klicken, zumal dann jedes Programm anders aufgebaut ist. Das schöne an UltraEdit, Proton, MultiEdit und co ist, das viele Dinge ähnlich und Gleich aufgebaut sind. D.h. ich bin Arbeitsplatz unabhängig.

^^^^^^^^^^^^^^^^^^^^^^^^
Schoen langsam erzaehlst Du wirklich Stuss, sorry.

Opposition um der Opposition willen.

In der Softwareentwicklung gibt es fuer bald jede Programmiersprache Case-Tools. Der Einsatz derselbigen haengt meistens davon ab, wie Deine Arbeitsumgebung aussieht. Bist Du Einzelkaempfer, bleibt es Dir unbenommen auf Papyrus zu schreiben. Wird in einer Entwicklungsgruppe jedoch ein Tool eingesetzt, sorry, dann hast Du das zu akzeptieren oder den Job zu wechseln. Bekehrungen sind dort meist fehl am Platz.

Gruesse
Wilhelm

[Wilhelm]

Moin,

Die ganzen Hardliner sollten auch endlich mal zur Kenntnis nehmen, dass sich auch das WWW veraendert hat. Es ist nicht mehr nur Infoquelle, sondern auch Werbeplatz. Und da kommen Textwuesten nicht mehr so gut an. Ob das jetzt gut ist oder nicht, das ist ein anderes Thema.

Das bestreitet ja auch niemand, aber so wie du das hier schreibst hört es sich an, wie wenn man ohne ein WYSIWYG Editor keine Seiten fürs Auge erstellen könnte.

Aehhemm, ich habe noch nie eine Seite mit einem WYSIWIG erstellt. Allerdings beschaftige ich mich ausgiebig mit Trial-Versionen, man sollte wissen ueber was man schimpft. ;)
Das heisst aber noch lange nicht, dass ich WYSIWIG-Benutzern das Koennen abspreche.

Gruesse
Wilhelm

[Mathias Bigge]

Hi Wilhelm,

ich setz mich mal neben die statt unter einen der Zustimmer *g*

Dass Phase 5 ein tolles Tool ist, ist keine Antwort auf die Frage, was man von Dreamweaver MX hält, oder?
Was mich wundert: Die Emacs- und vi-Fraktion meldet sich nicht zu Wort. :)

Uahh, die Glaubensdebatten machen echt müde. Dass das überhaupt Spaß macht, solche immer gleichen Postings abzusetzen, anstatt sich mal inspirieren zu lassen und was Neues auszuprobieren...

Ich kenne einen wirklich guten Designer, der von HTML null Schimmer hat(te), aber mit GoLive excellente Seiten erstellte.

Es ist auch bei Dreamweaver sehr selten, dass der Code in einem Browser nicht funzt, obwohl die Javascript-Konstrukte so aussehen, als müssten sie eigentlich daneben gehen *g*
Das Hauptproblem für Ahnungslose dürfte sein, dass sie nicht wissen, was sie tun. Ich will mal ein Beispiel geben: Wenn man im Dreamweaver einen Textbereich direkt formatiert, setzt der gute meist ein span rein, wenn man dann einen Buchstaben beim Markieren ausgelassen hat, und denkt, Moment, das mach ich nochmal, kriegt man lustige verschachtelte Span-Konstruktionen, die man einfach nur noch von Hand korrigieren kann. Manchmal kriegt man die Formatierungen auf der WYSIWYG-Ebene schon nach einigen Operationen nicht mehr gerade gestellt. Solche Effekte gibt es auch im JS-Bereich, etwa bei der Veränderung von JS-Menüs usw. Für den Laien gibt's allerdings immer noch die Chance, das betreffende Element komplett zu löschen  und neu zusammenzuklicken. Wenn man aber gerafft hat, was passiert(zudem ist fast alles per Einstellung veränderbar und auf persönliche Vorlieben anzupassen), kann man recht flott ganz ordentliche Ergebnisse zusammenklicken und auch wenn der Validator in Homesite nicht der offizielle Vali ist, sagt er doch ziemlich treffsicher voraus, welche Elemente in welchem Brauser Probleme machen.

Manche Leute sollten sich mal ihre Korinthenkackerei abgewoehnen und den anderen Ihre Meinung lassen. Viele "valide und sauber codierte" Seiten mit den hipsten und letzten CSS-Feature sind oft eine Beleidigung fuers Auge und sehen oftmals auch gleich aus. (gefixte dotted-Boxes nur als Beispiel, die kann ich nicht mehr sehen).

Au ja, das ist im Moment die Masche. Habe gerade auch mal sowas gemacht (schäm). Ähnlich wie mal die Mode mit den feinen Querstreifen a la kaputter Fernseher -  wie hießnoch das Photoshop-Plugin? *g*

Die ganzen Hardliner sollten auch endlich mal zur Kenntnis nehmen, dass sich auch das WWW veraendert hat. Es ist nicht mehr nur Infoquelle, sondern auch Werbeplatz. Und da kommen Textwuesten nicht mehr so gut an. Ob das jetzt gut ist oder nicht, das ist ein anderes Thema.

Ja, Werbung ist ein Thema. Ein anderes wären die Texte selbst. Wenn man die Schreibe von einigen Möchtegern-Textpuristen sieht, geht einem als Journalist das Messer in der Tasche auf, so ein eckiger, langweiliger und unverständlicher Mist wird da verzapft.

Aber das gehört vielleicht auch zu dieser Abteilung: "unverständlich - deshalb genial". Wenn ich hier manchmal die Debatten lese, ob es Sinn macht, Zusammenhänge im Netz auch grafisch zu veranschaulichen, dann lach ich mich tot. Einige reden wie 1976 eingeschlafen und gerade wieder von einer bösen Fee wiedererweckt, sind aber häufig im gleichen Jahr des Herrn geboren oder auch später...

Aber die "Moechtegerne-Diktatur" der Hardliner haengt mir persoenlich langsam zum Hals raus, egal ob hier, bei Heise oder sonstwo, egal ob Windows oder Linux, Fanatismus gehoert in die Muelltonne.

Recht so, obwohl mir die Windows-Entwicklung in Zusammenhang mit Intel im Moment echt Angst macht, aber nicht aus Glaubensüberzeugung, sondern weil ich die Versuche verfolge, den Computer gegenüber seinem Besitzer dicht zu machen. Gott sei Dank gibt es Alternativen, wenn man auch im Grafik und Video-Bereich sowieso nicht an den Kisten vorbeikommt, und wenn jemand meint, Apple wäre die unabhängige Alternative: Die gibt's hauptsächlich, weil Microsoft für seine Prozesse etwas brauchte, das nach einer unabhängigen Alternative aussieht...

Viele Grüße
Mathias Bigge

[Axel]

Hi,

Recht so, obwohl mir die Windows-Entwicklung in Zusammenhang mit Intel im Moment echt Angst macht, aber nicht aus Glaubensüberzeugung, sondern weil ich die Versuche verfolge, den Computer gegenüber seinem Besitzer dicht zu machen. Gott sei Dank gibt es Alternativen, wenn man auch im Grafik und Video-Bereich sowieso nicht an den Kisten vorbeikommt, und wenn jemand meint, Apple wäre die unabhängige Alternative: Die gibt's hauptsächlich, weil Microsoft für seine Prozesse etwas brauchte, das nach einer unabhängigen Alternative aussieht...

Tja...Da steckt viel Wahrheit drin. Immerhin hat Microsoft Apple schon kräftig Finanzhilfe geleistet - ganz ohne Eigennutz sicher nicht ;-)

Gruß

Axel

[molily]

Hallo, Wilhelm,

Viele "valide und sauber codierte" Seiten mit den hipsten und letzten CSS-Feature sind oft eine Beleidigung fuers Auge und sehen oftmals auch gleich aus.

Hundert Gummipunkte, damit hast du deine Argumentation auf einer Verallgemeinerung, einem Vorurteil beziehungsweise auf einem Mythos aufgebaut.
Dein Posting liest sich ungefähr wie [pref:t=32357&m=175423], deshalb verweise ich einfach auf meine Antwort darauf.

Die ganzen Hardliner sollten auch endlich mal zur Kenntnis nehmen, dass sich auch das WWW veraendert hat.

Die Softliner nicht?

die "Moechtegerne-Diktatur" der Hardliner

Das ist eine selektive Wahrnehmung. Zweifellos sind die Hardliner (was ist das überhaupt? bin ich ein solcher?) *Möchtegern*-Diktatoren, diejenigen, die wirlich diktieren, sind andere (die »Softliner«?)
Auf zehn Webseiten wirst du auf neun fehlerhaften Code und »optimiet für ...« finden, auf fünf unzugängliche JavaScripte, auf drei Flashintros ohne »skip intro«-Link und acht enthalten schwerwiegende Barrieren, wodurch große Teile der Besucher ausgeschlossen werden. Davon wird vielleicht eine Seite eine außergewöhnlich ansprechende Gestaltung besitzen, jedoch oft gemixt mit den genannten Problemen. Ob die Seite *validen* Code hat, hat so gut wie gar nichts mit der Gestaltung zu tun. Ob du Seite sauberen (klinisch reinen, sterilen) Code hat, mag etwas mit der Gestaltung zu tun haben, aber die »Hardliner (wer auch immer das sein mag) würden womöglich das Möglichste anstreben beziehungsweise »fordern«.

egal ob hier

Ich weiß nicht, auf was du diese Behauptung stützt beziehungsweise was du mit dieser Aussage bezweckst. Täglich werden hier Diskussionen geführt, warum man validen Codes schreiben sollte; bevor du über diese Diskussionen diskutierst und pauschal sagst, sie hängten dir zum Hals heraus, beteilige dich besser an diesen Diskussionen.

bei Heise

Bitte vergleiche nicht das Selfforum mit dem Heise »Forum«, Dazwischen liegen Welten. (Außerdem, wer sich das Heise Forum freiwillig antut, soll nicht klagen.)

(Urg, muss das Posting absenden, die Hochfrequenz malträtiert meine Tastaturcontroller.)

Grüße,
Mathias

[Wilhelm]

Moin,

Hundert Gummipunkte, damit hast du deine Argumentation auf einer Verallgemeinerung, einem Vorurteil beziehungsweise auf einem Mythos aufgebaut.
Dein Posting liest sich ungefähr wie [pref:t=32357&m=175423], deshalb verweise ich einfach auf meine Antwort darauf.

Danke! :)

Auf zehn Webseiten wirst du auf neun fehlerhaften Code und »optimiet für ...« finden, auf fünf unzugängliche JavaScripte, auf drei Flashintros ohne »skip intro«-Link und acht enthalten schwerwiegende Barrieren, wodurch große Teile der Besucher ausgeschlossen werden.

Wieso entnimmst Du meiner Aeusserung, dass ich diese Tatsachen fuer gut halte?

Ich weiß nicht, auf was du diese Behauptung stützt beziehungsweise was du mit dieser Aussage bezweckst. Täglich werden hier Diskussionen geführt, warum man validen Codes schreiben sollte; bevor du über diese Diskussionen diskutierst und pauschal sagst, sie hängten dir zum Hals heraus, beteilige dich besser an diesen Diskussionen.

Woraus entnimmst Du meiner Aeusserung, dass ich validen Code ablehne?

bevor du über diese Diskussionen diskutierst und pauschal sagst, sie hängten dir zum Hals heraus, beteilige dich besser an diesen Diskussionen

Vielleicht beteilige ich mich nicht mehr, weil sie mir zum Hals raushaengen, genauso wie 2-Frame-Aenderung oder sonstwas. Vielleicht auch deshalb, weil mir die Ausrichtung hier nicht mehr so zusagt. (was ist erwuenscht, was nicht etc.). Aber das ist rein subjektiv und gegen niemand gerichtet. Ich habe es einfach aufgegeben, Leute zu missionieren, was aber nicht heisst, dass ich Missionaren meine Bewunderung fuer ihre Geduld verweigere.

Bitte vergleiche nicht das Selfforum mit dem Heise »Forum«, Dazwischen liegen Welten. (Außerdem, wer sich das Heise Forum freiwillig antut, soll nicht klagen.)

Ja, ich tue mir Heise von Zeit zu Zeit an.
Die Evangelismus-Diskussionen hier naehern sich IMHO seit geraumer Zeit den Diskussionen dort.

Worum es mir hier in diesem Thread alleine geht:
Lasst den Leuten doch ihr Werkzeug, mit dem Sie arbeiten. Sie werden ueber kurz oder lang selber merken, dass ohne Hintergrundwissen vieles komplizierter ist. Leben und leben lassen, nichts anderes, jeder nach seinem Gusto. Was aber nervt ist die Tatsache, dass jemand ein Produkt kritisiert, von dem er null Schimmer hat.

(Urg, muss das Posting absenden, die Hochfrequenz malträtiert meine Tastaturcontroller.)

Trink ein Glas guten Rotwein, das beruhigt die Nerven. ;-)

Grüße,
Mathias

Auch
Wilhelm

[molily]

Hallo, Wilhelm,

Auf zehn Webseiten wirst du auf neun fehlerhaften Code und »optimiet für ...« finden, auf fünf unzugängliche JavaScripte, auf drei Flashintros ohne »skip intro«-Link und acht enthalten schwerwiegende Barrieren, wodurch große Teile der Besucher ausgeschlossen werden.

Wieso entnimmst Du meiner Aeusserung, dass ich diese Tatsachen fuer gut halte?

Dies hatte ich nicht vor, ich wollte damit belegen, dass die Diktatur der »Hardliner« wie du sagtest nichts als eine Möchtegern-Diktatur ist, welche gegen eine andere, tatsächlich vorherrschende Diktatur gerichtet ist (so nehme ich es wahr).
Es ist im Grunde nur ein Freiheitskampf und insofern legitim. ;) (So hört es sich an, ich meinte es nicht anders.)

Ich weiß nicht, auf was du diese Behauptung stützt beziehungsweise was du mit dieser Aussage bezweckst. Täglich werden hier Diskussionen geführt, warum man validen Codes schreiben sollte; bevor du über diese Diskussionen diskutierst und pauschal sagst, sie hängten dir zum Hals heraus, beteilige dich besser an diesen Diskussionen.

Woraus entnimmst Du meiner Aeusserung, dass ich validen Code ablehne?

Das habe ich nicht behauptet, aber deine Aussage, dass deiner Erfahrung nach viele Seiten mit validem Code schlicht^Wschlecht (freud'scher Vertipper, passt aber) aussehen und du dies als pauschalen Beleg dafür anführst, dass (auch) »valide und sauber codierte« schlecht aussehen können, klang so, als ob du den »Korinthenkackern«, welche, wenn ich dich richtig verstanden habe, »validen und sauberen Code« forcieren, widersprechen wolltest, weil ich zudem annahm, dass du nicht untermauern wolltest, dass valide und sauber codierte Seiten oft genauso scheiße[tm] wie invalide und unsauber codierte Seiten aussehen können, denn dies bezweifelte niemand. Wie ich das verstanden habe, hast *du* die Korrelation zwischen validem Code und schlechtem Design in die Diskussion gebraucht.

bevor du über diese Diskussionen diskutierst und pauschal sagst, sie hängten dir zum Hals heraus, beteilige dich besser an diesen Diskussionen

Vielleicht beteilige ich mich nicht mehr, weil sie mir zum Hals raushaengen, genauso wie 2-Frame-Aenderung oder sonstwas.

Hm, das verstehe ich durchaus.

Vielleicht auch deshalb, weil mir die Ausrichtung hier nicht mehr so zusagt. (was ist erwuenscht, was nicht etc.).

Was meinst du mit der »Ausrichtung«?

Sicherlich sind hier einige Fragen und Diskussionen nicht erwünscht (falls du das mit »erwünscht« meintest), beispielsweise wird neben der Antwort auf eine Frage, welche offensichtlich zum Ziel hat, die Webseitenbenutzer zu nerven oder sie auszuschließen, angemerkt, warum sich der Webautor damit seine eigene Grube gräbt. Diese hier verbreitete Praxis halte ich persönlich für äußerst wichtig und nötig...

Falls du auf WYSIWYG-Diskussionen anspielst, magst du vielleicht recht haben, dennoch solltest auch du nicht pauschal diejenigen verurteilen, welche sich für die Benutzung eines speziellen Werkzeuges entschieden haben (hast du selbst gesagt - darin stimme ich dir uneingeschränkt zu), weil sie so am effektivsten arbeiten können. Soweit ich diesen Thread verfolgt habe, hat niemand behauptet, dass andere mit anderen Werkzeugen nicht ähnliches ebenso effizient realisieren können.

Aber das ist rein subjektiv und gegen niemand gerichtet. Ich habe es einfach aufgegeben, Leute zu missionieren, was aber nicht heisst, dass ich Missionaren meine Bewunderung fuer ihre Geduld verweigere.

Naja, es wird wohl das Missionieren als sein erklärtes Ziel ansehen. :)

Die Evangelismus-Diskussionen hier naehern sich IMHO seit geraumer Zeit den Diskussionen dort.

Wie es im Heise-Forum zugeht, kann ich nicht beurteilen, aber dass hier ein Grundkonsens herrscht, dass jeder Webautor einigermaßen fehlerfreies und zugängliches Markup verfassen sollte, finde ich keinesfalls bedenkenswert. Hier wird bei weitem niemand gesteinigt, wenn ersiees nicht die höchsten Anforderungen der Trennung von Markup und Styles berücksichtigt ähnliches...

Worum es mir hier in diesem Thread alleine geht:
Lasst den Leuten doch ihr Werkzeug, mit dem Sie arbeiten. Sie werden ueber kurz oder lang selber merken, dass ohne Hintergrundwissen vieles komplizierter ist.

Volle Zustimmung. :)

Leben und leben lassen, nichts anderes, jeder nach seinem Gusto.

»Naja«, es ist nicht so, dass einen gemeinen Webbenutzer die Arbeit von anderen Seitenautoren nicht betrifft...

Was aber nervt ist die Tatsache, dass jemand ein Produkt kritisiert, von dem er null Schimmer hat.

Ja. Aber für meine theoretischen Überlegungen über die Fähigkeiten von WYSIWYG-Editoren muss ich kein einziges spezielles Produkt kennen, Kritik ist meiner Meinung nach auch ohne diese Kenntnis legitim.
Im Endeffekt ist, wie du und Mathias sagen, das Werkzeug nur so gut wie sein Anwender es zu benutzen weiß.
Da das Web voller von abscheulichem »ineffizientem«, proprietären und pixelgenauem WYSIWYG-Code ist, wirst du es schwer haben, auf Sachlichkeit zu plädieren, denn wenn den WYSIWYGs ihr Ruf vorauseilt, wird es denkbar schwer sein, mit Vorurteilen aufzuräumen - will heißen, viele haben durchaus Erfahrung mit WYSIWYGs, selbst wenn sie sich noch nicht extensiv in diese Programme eingearbeitet haben - das haben offensichtlich die wenigsten hier, weshalb diese Diskussion albern wäre, wenn wir uns gegenseitig vorwerfen würden, dass die Erfahrungen des einen mehr zählen als die des anderen.

Wie ich in einem anderen Thread belegt habe ([pref:t=32488&m=176044], [pref:t=32488&m=176338]), ist es einem WYSIWYG per se unmöglich, semantischen Hypertext zu produzieren, und wie ich vermutete, produziert dieses Werkzeug von sich aus nichts, was ich unter Hypertext verstehe - zumindest nur soviel, wie der Anwender hineinsteckt, indem er den Code doch zum Teil per Hand schreibt. Wenn aber eine grafische Ausgabe entworfen wird, produziert Dreamweaver logischerweise auf Bildschirmpräsentation ausgelegtes Markup, HTML ist dazu, mit all seinen Präsentations-»Tags« das Mittel zum Zweck.

Dreamweaver kann womöglich validen Code produzieren, dieser ist aber zwangsläufig (und darum ging es mir) auf eine grafische Präsentation zugeschnitten. Überhaupt für alles verwendet dieses Programm Tabellen (Beobachtung, nicht Mutmaßung), selbst für einen Breadcrumb-Trail aus der Sparte »zugänglich« (ich beziehe mich auf die Codeschnipsel).

Genau diesen Sachverhalt sprach ich an, als ich meinte, dass die Softliner die CSS-Revolution verschlafen haben. Effizientes CSS setzt immer semantisches Markup voraus, nicht hunderte div- und span-Elemente, welche in sich keinen Zweck erfüllen und nur als Container für Inline-Syles dienen. Gegenüber HTML-Formatierungen hat der CSS-Output von Dreamweaver keine Vorteile, weil wie gesagt die Abstraktionsebene fehlt, welche auch kein Programm leisten kann, sondern welche der Autor selbst leisten muss. Ich persönlich würde neunzig Prozent der Zeit im »Stylesheet bearbeiten«-Dialog verbringen, da die CSS-Effekte, die ich extensiv nutze, überhaupt nicht mit Tabellen zu lösen sind, somit würde mir Dreamweaver den Arbeitsschritt des Entwerfens eines anpassungsfähigen CSS-Layout nicht assistieren können.

Das Beste ist natürlich, dass die Entwurfsansicht meine CSS-Regeln überhaupt nicht versteht/anwendet; @media wird als Selektor identifiziert,  für Einrückungen wird Blockquote verwendet...

<p>fließtext</p>
<blockquote cite="..."><p>ein wirkliches zitat</p></blockquote>

Wenn man den ersten Absatz markiert und über die »Einrücken«-Schaltfläche einrückt, passiert folgendes:

<blockquote cite="...">
<p>fließtext</p>
<p>ein wirkliches zitat</p>
</blockquote>

Was nützt mir das denn...?
Die Einheit »em« kennt das Programm gar nicht, es gibt einen Fehler aus, wenn ich eine Ebene damit formatieren möchte. Tabellenformatierungen wie border-collapse ignoriert das Programm völlig, beispielsweise ist der absolute Overkill dieses recht einfache CSS-Layout: http://home.t-online.de/home/dj5nu/sterne-tourtermine.html. Klar, Tabellenrahmen werden schließlich mit verschachtelten Tabellen gelöst, wie schon vor circa fünf Jahren.

Mir persönlich legt dieses Programm nur Steine in den Weg, ich sehe bei jedem Codefragment, bei jeder Vorlage, sogar den »zugänglichen« verschachtelte Tabellen, noch und nöcher. Früher beziehungsweise in alten Browsern, welche CSS nur unzureichend verstehen, war dies alles notwendig, das ist mir völlig klar, vor zwei bis drei Jahren war man dazu gezwungen, für jeden Rahmen verschachelte Tabellen zu nutzen, nur ein Programm aus dem Jahr 2002 sollte eine gewisse Weiterentwicklung zumindest ermöglichen, wenn auch nicht als Standard anwenden, denn aus Kompatibilitätsgründen kann man gegen solche Tabellenlösungen tatsächlich nichts einwenden, weil Netscape 4 nichts anderes schluckt.

Ich denke doch, mittlerweile beurteilen zu können, dass die GUI selbst für die CSS-Formatierungen nicht viel der Arbeit abnehmen kann - in Endeffekt müssen die wirklich effektiven Styles (Selektoren!) per Hand geschrieben werden, oder eben jedes Element Element mit dem class-Attribut zugekleistert werden. Der Wizard, das heißt die Dialogfeldre zum Erstellen von Styles, ist nur eine kleine Abhilfe.

Für die Arbeitsschritte, für welche viele hier den Dreamweaver als passend befinden, benutze ich ehrlich gesagt eher ein Grafikprogramm (Form- und Farbwahl, Grafikeinpassung, generell »Komposition«) oder schlichtweg Graphit oder Pinsel und Farbe... Das hat mit Hypertext sehr wenig zu tun, deshalb entwickle ich ein Layout nicht mit einem Programm, welches Hypertext generiert.

Die Codefragmente sind zum Teil fehlerhaft, beispielsweise:
onClick="javascript:self.close();"
         ^^^^^^^^^^^ Das ist überflüssig.
Was in der Rubrik »zugänglich« aufbewahrt ist (was mich speziell interessiert), ist eigentlich nicht zugänglicher als der Rest der Codefragmente... naja, immerhin wird bei Datentabellen td und scope verwendet.

Andere Hyperlinkfarben werden natürlich folgendermaßen gelöst:
<a href="#"><font color="#FF0000">xxx</font></a>
Naja, ich übertreibe, man würde es wohl über Design -> CSS-Stile -> CSS-Stile anwenden lösen.

Grüße,
Mathias

[Mathias Bigge]

Hi molily,

Deine Signatur:

Mein Leben, ein Leben ist es kaum,
Ich gehe dahin als wie im Traum.
Wie Schatten huschen die Mensch hin,
Ein Schatten dazwischen ich selber bin.
Und im Herzen tiefe Müdigkeit -
Alles sagt mir: Es ist Zeit ...
(Theodor Fontane, Mein Leben)

Ein schönes Zitat, sticht richtig aus dem Textgewühl hier hervor. Ich hoffe, es ist mehr die Freude am Text als Dein eigenes Lebensgefühl, das hier zum Ausdruck kommt. Es gab mal Leute, die intensiver an ihren Texten arbeiteten als wir Heutigen in den meisten Fällen. Schade eigentlich.

Oft sind sie wirklich öde hier und überflüssig, die Glaubensdiskussionen im Selfraum, nur selten eröffnet sich durch solche Bekenntnisse ein Blick auf eine Erfahrung oder eine neue Perspektive. Auch hier im Thread zu Dreamweaver finde ich jeden Beitrag der Sorte: "Benutz doch lieber einen Texteditor!" dumm und überflüssig.

Sicher kann man mal zu einer offenkundigen Anfrage hinzufügen, dass es bessere als die angestrebte Lösung gibt, aber meines Erachtens würde es das Niveau des Forums verbessern, wenn wir uns in einer Frage einig wären: Solche Antworten ohne konkrete Lösungsansätze sind einfach nur Wichtigtuerei und überflüssig.

Also: Wer etwas zu Dreamweaver schreibt, sollte damit Erfahrung haben oder den Mund halten, Punkt! Damit meine ich nicht Deinen Beitrag, denn Du bringst ja Argumente.

Es ist im Grunde nur ein Freiheitskampf und insofern legitim. ;) (So hört es sich an, ich meinte es nicht anders.)

verstehe ich nicht

Die Evangelismus-Diskussionen hier naehern sich IMHO seit geraumer Zeit den Diskussionen dort.
Trennung von Markup und Styles

Ja, die Trennung von Form und Inhalt, eine interessante Debatte, die hier oft als Glaubensdiskussion daherkommt.

Glaubenssatz 1: Der Herr befiehlt die Trennung von Form und Inhalt.

Beispiel: Der legitime Einsatz von Tabellen beschränkt sich auf das Anzeigen von - Tabellen.

Ganz interessant, wo das ganze Netz, vor allem aber auch der Selfraum voller Tabellenlayouts steckt, die einwandfrei und vor allem browserübergreifend funktionieren. Hier zeigt sich auch der Pferdefuß der Prinzipienreiterei: Wenn man eine bestimmte Form der Darstellung wünscht, nichts exotisches, etwa das Aussehen einer Standard SelfHTML-Seite, ist das in CSS browserübergreifend schwer zu realisieren. Stefan Münz hatte mal einen Wettbewerb ausgeschrieben, eine normale SelfHTML-Seite ohne Tabellen nachzubauen, und es gab einen passablen Vorschlag von Herbalizer, die Glaubenskrieger haben sich dabei aber auffallend zurückgehalten *g*

Warum aber nicht einfach wirklich alles auf CSS umstellen, wenn Glaubenssatz 1 richtig ist? Ein paar Fragen:
1. Wer bezahlt das?
2. Häufig bleibt der angestrebte Vorteil darauf reduziert, einem Prinzip entsprochen zu haben.
3. Teilweise geht es nicht.

Ich sehe das Problem der extensiven CSS-Formatierung in der Notwendigkeit komplexer Browserweichen und entsprechend komplexer Kaskaden von Formatierungen, manchmal sogar ergänzt um Zusatzformate in der HTML-Datei, weil's einige Browser sonst nicht packen. Dabei interessiert mich vor allem auch die Frage der weiteren Entwicklung.

Die Browserweichenmöglichkeit ist ja sozusagen zufällig entstanden, weil man so gerade alle wichtigen Browser mit den verschiedenen Import- und Syntaxformen erfassen kann. Es ist auf jeden Fall nicht die angestrebte Vereinfachung und simple Wartbarkeit, die auf diese Weise entsteht. Und: Wird man allen zukünftigen Browsern weitere neu Importformate mit auf den Weg geben, um für sie das ständig wachsende Reservoir an CSS-Möglichkeiten aktivieren zu können, oder braucht man irgendwann die verhassten JS-Weichen, um überhaupt noch sinnvoll die neuen Möglichkeiten nutzen zu können?

Vielleicht könnte man Glaubenssatz 1 ein wenig korrigieren, indem man Anfängern mit auf den Weg gäbe:

"Oft erweist es sich als nützlich, möglichst viele Formatierungen in eine externe CSS-Datei zu packen."

Was aber nervt ist die Tatsache, dass jemand ein Produkt kritisiert, von dem er null Schimmer hat.
Ja. Aber für meine theoretischen Überlegungen über die Fähigkeiten von WYSIWYG-Editoren muss ich kein einziges spezielles Produkt kennen, Kritik ist meiner Meinung nach auch ohne diese Kenntnis legitim.

Ich habe diese "theoretische" Debatte schonmal vor Jahren im Feld der Textverarbeitungen erlebt: Eine Klicki-Bunti Textverarbeitung, mit der man alle möglichen Dateiformate in einer Datei zusammenfassen kann und deren Bildschirmansicht weitgehend dem Drucklayout entspricht, kann es aus prinzipiellen Gründen nicht geben. Es gibt sie inzwischen und es wird immer bessere WYSYWYG-Tools fürs Netz geben, einfach weil's ein guter Markt ist und sich die Dinge entwickeln. "Prinzipielle" Argumente finde ich da zweifelhaft.

Wenn aber eine grafische Ausgabe entworfen wird, produziert Dreamweaver logischerweise auf Bildschirmpräsentation ausgelegtes Markup, HTML ist dazu, mit all seinen Präsentations-»Tags« das Mittel zum Zweck.

Entwirfst Du per Hand keine grafische Ausgabe für den Bildschirm oder schreibst Du für den Quelltexteditor? *g*

Dreamweaver kann womöglich validen Code produzieren, dieser ist aber zwangsläufig (und darum ging es mir) auf eine grafische Präsentation zugeschnitten. Überhaupt für alles verwendet dieses Programm Tabellen

Das verstehe ich nicht. Wenn man eine Ebene aufzieht, verwendet es divs und fertig. Wo siehst Du darin die große Vorgabe, auf die Du immer anspielst? Dass viele Schnippsel für Tabellen vorliegen, zwingt doch niemanden, sie zu benutzen. Die meisten CSS-Eigenschften sind überdies per Klick zugänglich.

semantisches Markup [....] weil wie gesagt die Abstraktionsebene fehlt, welche auch kein Programm leisten kann, sondern welche der Autor selbst leisten muss.

Denken muss man schon selbst, aber was spricht gegen Tools, die mir die meisten CSS-Eigenschaften anzeigen und die Wirkung auf das ausgewählte Element veranschaulichen? Das mitgelieferte TopStyle Lite finde ich gar nicht so schlecht, es bleibt noch Platz für Aktivitäten zu Fuß, aber für eine Grundformatierung reichts allemal.

Das Beste ist natürlich, dass die Entwurfsansicht meine CSS-Regeln überhaupt nicht versteht/anwendet; @media wird als Selektor identifiziert,  für Einrückungen wird Blockquote verwendet...

Das ist ein Fehler, stimmt. Jetzt wird's konkret und damit interessant. Teilweise stimmt auch die übrige Kritik, bis auf den gewissen "Konservatismus" der Lösungen von Dreamweaver, die auch ihre guten Seiten hat, obwohl sie oft angegriffen wird, Du schreibst es ja selber, denn es gibt sie immer noch, die Brauser, die die neuesten CSS-Styles nicht verstehen:

denn aus Kompatibilitätsgründen kann man gegen solche Tabellenlösungen tatsächlich nichts einwenden, weil Netscape 4 nichts anderes schluckt.

Für die Arbeitsschritte, für welche viele hier den Dreamweaver als passend befinden, benutze ich ehrlich gesagt eher ein Grafikprogramm

ich auch

Andere Hyperlinkfarben werden natürlich folgendermaßen gelöst:
<a href="#"><font color="#FF0000">xxx</font></a>
Naja, ich übertreibe, man würde es wohl über Design -> CSS-Stile -> CSS-Stile anwenden lösen.

eben. Vielleicht ist der Dreamweaver doch auch ein Lerntool, das Newbees die CSS-Möglichkeiten erstmals zur Verfügung stellt.

Viele Grüße
Mathias Bigge

[Axel]

Hi,

»»gut wie gar nichts mit der Gestaltung zu tun. Ob du Seite sauberen (klinisch reinen, sterilen) Code hat, mag etwas mit der Gestaltung zu tun haben, aber die »Hardliner (wer auch immer das sein mag) würden womöglich das Möglichste anstreben beziehungsweise »fordern«.

Genau das ist hier das Problem. Das ist wirklich einfach nur aufdringlich. Jeder Designer sollte bemüht sein, sich am Standard zu orientieren und diesen auch einzuhalten - aber in welcher Weise hier teilweise auf Leute losgegangen wird, die sich erdreisten z.B. PostNuke einzusetzen oder ein paar zappelnde GIFs auf eine Homepage zu packen ist absolut entwürdigend und geht sogar - und diesen Ausdruck meine ich auch so - in Einzelfällen in Richtung e-Faschismus.

Sachliche Kritik ist immer gut und bringt weiter - aber wenn es zu einen Verriss wird, wo persönliche Vorlieben und völlig unnötige Pedanterie mit einfließen, dann geht es mir gegen den Strich.

Sicher gibt es von den millitanten Extremisten hier nur eine Handvoll - aber diese Handvoll genügt.

Ein wenig mehr Toleranz würde allen gut tun (da will ich mich nicht mal ausschließen).

Bitte vergleiche nicht das Selfforum mit dem Heise »Forum«, Dazwischen liegen Welten. (Außerdem, wer sich das Heise Forum freiwillig antut, soll nicht klagen.)

Auch wenn es vielen jetzt übel aufstoßen mag...Bei Heise sind es die "Mit Linux wär' das nicht passiert" idioten hier sind das CSS-fetischisten, die alles was nicht mit CSS formatiert ist sowieso schonmal aus Prinzip schlecht finden.

Der Unterschied zum Heise-Forum liegt hier lediglich in der Themenfokussierung und in der (glücklicherweise) geringen Zahl von Trollen sowie der fehlenden Benutzerregistrierung - die Qualität der Diskussionen steht manchmal denen bei Heise in nichts nach.

Grüße

Axel

[Christian Seiler]

Hallo Axel,

Auch wenn es vielen jetzt übel aufstoßen mag...Bei Heise sind es die "Mit Linux wär' das nicht passiert" idioten hier sind das CSS-fetischisten, die alles was nicht mit CSS formatiert ist sowieso schonmal aus Prinzip schlecht finden.

Nö, es geht weniger um CSS als Formatierungsmittel als um HTML als Struktursprache. *scnr*

Naja, mal im Ernst:

a) ich finde nicht prinzipiell alles schlecht, was nicht mit CSS formatiert ist (wie auch, es gibt genug Tabellenlayouts im Internet mit durchaus guten Inhalten, das eine sagt nichts über das andere aus)
b) ich habe Argumente in meiner Tasche, im Gegensatz zu den "Mit Linux wär' das nicht passiert (nt)"-Elchen bei Heise. Ich persönlich verwende auch Linux, aber nicht, weil ich irgendwie "cool" sein will, sondern weil ich Argumente für dieses System habe. (bitte jetzt keine Diskussion darüber...) Genauso habe ich Argumente für CSS.

die Qualität der Diskussionen steht manchmal denen bei Heise in nichts nach.

Dir ist klar, was Du da sagst?

Grüße,

Christian

[Axel]

Hi,

Nö, es geht weniger um CSS als Formatierungsmittel als um HTML als Struktursprache. *scnr*

;-)

Naja, mal im Ernst:

a) ich finde nicht prinzipiell alles schlecht, was nicht mit CSS formatiert ist (wie auch, es gibt genug Tabellenlayouts im Internet mit durchaus guten Inhalten, das eine sagt nichts über das andere aus)

Genau das ist der strittige Punkt - einige sind in ihrer Auffassung leider fanatisch genug genau hier eine Aussage treffen zu wollen.

b) ich habe Argumente in meiner Tasche, im Gegensatz zu den "Mit Linux wär' das nicht passiert (nt)"-Elchen bei Heise. Ich persönlich verwende auch Linux, aber nicht, weil ich irgendwie "cool" sein will, sondern weil ich Argumente für dieses System habe. (bitte jetzt keine Diskussion darüber...) Genauso habe ich Argumente für CSS.

Ich sag ja... CSS ist gut und wichtig - aber Leute zu verteufeln, die CSS nicht _ausschließlich_ zur Formatierung der Inhalte einsetzen ist einfach nervend. Abgesehen davon: Ich nutze auch Linux und das hat auch gute Gründe.

die Qualität der Diskussionen steht manchmal denen bei Heise in nichts nach.

Dir ist klar, was Du da sagst?

Absolut - und ich meine es so, wie ich es geschrieben habe. Bestes Beispiel ist ein aktueller Artikel hier im Forum über Windows XP.

Gruß

Axel

[Christian Seiler]

Hallo Axel,

Ich sag ja... CSS ist gut und wichtig - aber Leute zu verteufeln, die CSS nicht _ausschließlich_ zur Formatierung der Inhalte einsetzen ist einfach nervend.

Wozu willst Du CSS sonst einsetzen? Ich verstehe diese Aussage jetzt nicht so ganz... Du meinst vmtl. etwas komplett anderes.

Absolut - und ich meine es so, wie ich es geschrieben habe.

Das ist schade. Ich treibe mich hier rum, weil dieses Forum IMHO eben *nicht* das Niveau von Heise hat.

Bestes Beispiel ist ein aktueller Artikel hier im Forum über Windows XP.

Heise-Niveau ist das noch nicht, aber ich kann Deine Bedenken zumindest ansatzweise nachvollziehen.

Grüße,

Christian

[Axel]

Hi,

Ich sag ja... CSS ist gut und wichtig - aber Leute zu verteufeln, die CSS nicht _ausschließlich_ zur Formatierung der Inhalte einsetzen ist einfach nervend.

Wozu willst Du CSS sonst einsetzen? Ich verstehe diese Aussage jetzt nicht so ganz... Du meinst vmtl. etwas komplett anderes.

Nicht wozu... Ich setze es auch - aber nicht ausschließlich ein.

Gruß

Axel

[Christian Seiler]

Hallo Axel,

Nicht wozu... Ich setze es auch - aber nicht ausschließlich ein.

Hmmm. Für Formatierungen habe ich CSS immer ausschließlich eingesetzt, auch als ich noch mit Frames gearbeitet habe, damals halt nur nicht fürs Layout.

Grüße,

Christian

[Axel]

Hi,

<trollmode>
och ist der Thread schön lang...
</trollmode>

Grüße

Axel