Hallo Leute,
ich weiss nicht so recht, ob ich mir GoLive CS kaufen soll. Denn ich habe folgendes Problem:

Wenn ich simple Seiten mit GoLive 6.0.1 erstelle, und dann durch den HTML Validator von WC3 lasse, dann gibt es viele Errors, dass gewisse Tagdefinitionen (vorallem in Tabellen) nicht erlaubt seien.

Hat sich das in der CS Version verbessert? Schreibt GoLive jetzt schöneren HTML? Oder was macht Ihr in dieser Hinsicht?

Ich finde es nämlich eine Frechheit, dass ein Profiprogramm sich nicht an Standards hält!

Gruss Spross

Hallo Spross,

verwende keine Höhenattribute für die Tabelle <table> und die Reihe <tr> und schon ist die Tabelle valider HTML-Code.

Gruß Sabine

ok, das ist etwas....
aber leider hat GoLive noch andere Mankos, wie z.B. mit den td backgrounds... anscheinend müsste man das alles jetzt mit style="" machen... kann das GoLive CS jetzt?

spross

Hallo Spross, das geht auch mit Golive 6.
Du legst eine neue Klasse an. Mit dem CSS-Editor kannst Du für diese Klasse das Hintergrundbild definieren.
In der Layoutansicht kannst Du dann der Zelle die Klasse zuweisen (rechte Maustaste).

Gruß Sabine

ok, stimmt... dann muss man einfach ganz genau wissen, was erlaubt ist und was nicht, da GoLive auch unerlaubtes selbst machen würde.... ok... aber da noch eine kleine Frage, wass kann ich anstelle von:

leftmargin="0" marginheight="0" marginwidth="0" topmargin="0"

im body tag

machen, denn dies ist auch nicht erlaubt....

Vielen Dank für die Hilfe!
Gruess Silvan

Silvan, oh ja das leidige Problem mit den margins.
Das könntest Du so lösen:

body{margin:0px}

Gruß Sabine

Nur noch so 'ne Anmerkung:

Ob "valides HTML" wirklich erste Wahl ist, sollte mit Blick auf die zu unterstützenden Browser IMHO wohl überlegt sein, denn damit reduziert man mal eben die Kompatibilität einer Site. Die größten Problemkinder sind die Netscapes < v5.

2 Beispiele:

Wenn Du kein "marginwidth/marginheight" im Body-Tag angibst sondern stattdessen - W3C-konform - per CSS und der Besucher hat JS deaktiviert, findest Du deinen Seiteninhalt plötzlich mit ~10 Pixel breiten Einzügen oben und unten wieder.

Der IE tut sich manchmal schwer mit Scrollbars, wogegen ein "scroll=auto" im body-Tag hilft. Das ist aber auch nicht W3C-konform.

 
@tömsken
Das tönt ja alles sehr spannend, stimmt aber leider nicht!
Netscape 4.x ist der eintige Browser der margin über CSS nicht unterstützt. Und das hat wohlgemerkt nichts mit JS zu tun. Sondern ist eine Eigenschaft des Browsers. Und wenn wir schon bei validem HTML sind was ist scroll="auto". Wenn dann würde es meiner Meinung nach scrolling="auto" sein und hat dann aber überhaupt nichts im body verloren. Auch in CSS nicht. Das ist also überhaupt nicht konform.

@sspross
Der Anspruch an GL ist ja, dass auch Anwender ohne HTML/CSS Kentnisse Websites herstellen können und diese dann in allen Browsern auch gleich aussehen. Daher deckt es alle Eventualitäten mit reduntanten und veralteten Tags ab, damit auch im NS 3 noch alles super aussieht. Aber das muss nicht sein und es gibt bei den Voreinstellungen sicher Möglichkeiten dies GL auszutreiben.
Was valides HTML betrifft so bin ich nicht sichr wie einfach das mit GL ist. Rein schon mit den CS-Actions (ich glaube sie heissen so) die als JS Ersatz dienen ist das eine schwierige Sache.

Und noch eine Anmerkung:
Valides (X)HTML und CSS reduzieren nicht die Kompabilität, sondern erhöhen sie. Die Site wird dadurch auch mit PDAs und Textbrowsern besser zugänglich und auch die Formatierung für den Ausdruck eröffnet viele neue Möglichkeiten. Das Stichwort heisst hier Vorwärtskompabilität.

Probierts mal aus, Andre

--
Dschinni - Web in alle Richtungen

Hallo andre
>>Netscape 4.x ist der eintige Browser der margin über CSS nicht unterstützt

Oh doch, Netscape kann mit "margin" schon etwas anfangen.

Für den Body-Tag allerdings nicht, das stimmt schon.

Im Zweifelsfall einfach mal margin, margin-top und margin-left ausprobieren:

http://www.w3.org/...current/test5505.htm
http://www.w3.org/...current/test5501.htm
http://www.w3.org/...current/test5504.htm

Für manche HTML-Tags klappte es, für andere wieder nicht.

Gruß Sabine

[Netscape 4 ist mein Freund]

 
Ja Sabine, das ist schon richtig. Man staunt manchmal wieviel dieser alte Knabe kann. Wobei ich finde, dass er padding besser kann wie margin, aber das nur am Rande. Kommt halt auch immer auf die Anwendung an. Aber beim body, da gehts nicht.

Da hast du dir aber einen schönen Freund angelacht. Etwas anhänglich ist er; Hat man ihn mal, wird man ihn fast nicht mehr los. Andre

--
Dschinni - Web in alle Richtungen

@andre5
>Netscape 4.x ist der eintige Browser der margin über CSS nicht >unterstützt. Und das hat wohlgemerkt nichts mit JS zu tun.

CSS hat beim NS4 in sofern etwas mit JS zu tun, dass überhaupt ganz gar kein CSS von dem interpretiert wird, wenn JS deaktiviert ist.

>Sondern ist eine Eigenschaft des Browsers. Und wenn wir schon bei >validem HTML sind was ist scroll="auto". Wenn dann würde es meiner >Meinung nach scrolling="auto" sein und hat dann aber überhaupt nichts >im body verloren. Auch in CSS nicht. Das ist also überhaupt nicht >konform.

Mit meinem Beitrag wollte ich kein Beispiel für valides HTML liefern, sondern Argumente für Ausnahmen davon liefern.
Im IE heißt es tatsächlich "scroll='auto'". Da ist nicht W3C-konform, das ist auch nur IE-proprietär, aber es ist auch die IMHO einzige Variante, um das Scrollbar-Problem beim IE zu beheben.
Und es ist meines erachtens völlig in Ordnung, diesen body-Parameter zu benutzen...
- ... wenn ich damit die Darstellung bei >90% aller Surfer verbessern kann
- ... und es keinem anderen Browser weh tut. Und das tut's ja nun nicht.

 
@Tömsken
Du hast recht. Lustigerweise rendert der NS 4.x CSS tatsächlich nicht wenn JS ausgeschaltet ist. Aber da beschleicht mich wieder die Frage die mich immer beschleicht, wenns um JS ein/aus geht: Gibt es tatsächlich Nutzer die JS ausschalten? Und wenn ja, wieso?

Was das Scrollbar-Problem betrifft, da blick ich immer noch nicht durch: Was ist genau das Problem? Was geht nicht oder falsch?

Und dann noch die Abkürzungsfrage des Tages: Was heisst IMHO?

Danke und bis bald, Andre

--
Dschinni - Web in alle Richtungen

>Gibt es tatsächlich Nutzer die JS ausschalten?

Nach der letzten (auf Heise.de zitierten) Statistik von der ich zu diesem Thema las, haben tatsächlich 99,9% aller Surfer JavaScript aktiviert. Das hat mich außerordentlich überrascht, denn...

>Und wenn ja, wieso?

...die meisten Sicherheitslücken sind durch das Abschalten von Active Scripting abzudichten. Und nach all der Presse während der letzten Monate zu Würmern, Dialern und Co. hatte ich mit einem weitaus geringeren JS-aktiven Anteil gerechnet.

(Wer seinen Browser mal testen möchte: http://www.heise.de/...enste/browsercheck/)

Ich halte es übrigens für eine gute Idee, kein JS zwingend vorauszusetzen. Deshalb baue ich meine Websites so, dass aktives JS ein paar nette Effekte und Möglichkeiten bringt, alle anderen aber ebenfalls problemlos an die Inhalte kommen.


> Was das Scrollbar-Problem betrifft, da blick ich immer
> noch nicht durch: Was ist genau das Problem?

Alle mir bekannten Browser blenden die Scrollbars nur ein, wenn sie auch tatsächlich benötigt werden - nur der IE nicht, denn der zeigt den vertikalen Scrollbar permanent an. Durch <body scroll="auto|no|yes"> lässt sich dieses Verhalten steuern.

Bug oder Feature? Wohl Ansichtssache. Ich schätze dieses Verhalten bei Frame-losen Sites, denn es bewirkt, dass die dynamisch aufgebauten, unterschiedlich langen Seiten nicht verschieden breit gerendert werden, was eine unruhige Bildschirmdarstellung beim Seitenwechsel bedeuten würde.
Diese IE-Eigenschaft mag aber auch als störend empfunden werden, denn wenn eine Seite eine Hintergrundfarbe besitzt, ist am Scrollbar Schluß mit bunt.

Wer W3C-konform bleiben möchte - und hiermit schließe ich dann den ein paar Postings weiter oben aufgespannten Bogen ;) - muß mit diesem unterschiedlichen Verhalten von IE und dem Rest der Welt leben (denn "scroll=auto" wäre ja ein Fehler) und hat im Endeffekt verschiedene Darstellungen. Wer hingegen "schummelt", erzielt Browser-übergreifend konformere Ergebnisse, wird aber vom W3C-Validator abgewatscht.


> Was heisst IMHO?

Foren-Amateur, Du... ;)
In My Humble Opinion -> nach meiner bescheidenen, unmaßgeblichen Meinung


Tom