nicht angemeldet
Seitenlayout: div Container mit float vs. absulute Bereiche
Hi,
beim Lernen von CSS für meine eigene Homepage ist mir aufgefallen, dass es offenbar 2 Möglichkeiten zur Gestaltung von Bereichen für zB Titel, Menü und Inhalt gibt.
Auf der einen Seite werden die Bereiche Menü (links), Inhalt(rechts) über die float Eigenschaft und div Container realisiert , wie zB im Workshop "Layouten ohne Tabellen" auf der www.css4you.de Seite.
Andererseits können aber solche Bereiche auch absolut definiert werden, zB Menü (top:80px,left:0px,width:150px;height:auto) und Inhalt Inhalt (top:80px,left:120px,width:450px;height:auto), wenn man von einem fixen Layout mit 800*600 ausgeht.
Sind dies nur einfach verschiedene Herangehensweisen oder haben diese unterschiedlichen Methoden auch Sinn?
Welche Methode könnt ihr empfehlen, vorallem um möglichst viele Browser anzusprechen?
Vielen Dank für eure Hilfe und
LG,
Sheridan!
-
Hi
Welche Methode könnt ihr empfehlen, vorallem um möglichst
viele Browser anzusprechen?"Flüssiges Layout" mit möglichst vielen relativen
Angaben/Einheiten (ex, em, %, ) bzw. möglichst wenig Absolute
Angaben (px, pt, ...)Gruss
chlori -
Hi,
Welche Methode könnt ihr empfehlen, vorallem um möglichst viele Browser anzusprechen?
Entweder floast oder - je nach dem konkreten Fall - auch die zweite, wobei ich jedoch nur den Menübereich absolut positionieren (top:0; left:0; dürfte in den meisten Fällen problemlos sein) und den Inhaltsbereich über margin auf Abstand halten würde.
freundliche Grüße
Ingo -
Hallo,
Welche Methode könnt ihr empfehlen, vorallem um möglichst viele Browser anzusprechen?
den Vergleich ("Mehrwert" o.ä.) mit der Tabelle.
Mit der Tabelle kannst du ein recht flexibles Layout für eigentlich alle Browser verwirklichen.
Was soll nun der Nutzen von CSS sein?
Welche Anforderungen ergeben sich an den Code?Tableless Layout an sich ist noch kein so grosser Fortschritt, interessant wird es bei besserer Barrierefreiheit, flexiblerer Darstellung, semantisch richtigem HTML, besser wartbaren Seiten dank Trennung von "Layout" und "Inhalt".
Daraus ergibt sich für mich bei CSS-basiertem Layout die Notwendigkeit einen wirklich sauberen HTML-Code ohne Hilfselemente und Container zu erhalten.
Dann möchte ich die Flexibilität der Tabelle erhalten, was für die IE, also die zu 90% genutzten Browser, kaum möglich ist.Aus diesen und weiteren Widersprüchen ergibt sich m.E. dass der Ansatz "offenbar 2 Möglichkeiten" nicht ganz richtig ist, sondern das ggf. per Browserweiche/ CSS-Weiche für die IEs ein anderer Aufbau erfolgen kann als für Mozilla und Opera, um die eigentlichen Ziele für alle Browser zu verwirklichen.
Grüsse
Cyx23
-
Hi,
Mit der Tabelle kannst du ein recht flexibles Layout für eigentlich alle Browser verwirklichen.
Es _gibt_ barrierefreies Tabellenlayout.
Was soll nun der Nutzen von CSS sein?
Die Trennung von Inhalt und Layout - etwas, das sich mit Tabellenlayouts nur bedingt erreichen läßt. (Von td#menu {position:fixed; top:0; right:0;} möchte ich jetzt nicht sprechen, aber natürlich geht auch das.)
Tableless Layout an sich ist noch kein so grosser Fortschritt, interessant wird es bei besserer Barrierefreiheit, flexiblerer Darstellung, semantisch richtigem HTML, besser wartbaren Seiten dank Trennung von "Layout" und "Inhalt".
ACK
Daraus ergibt sich für mich bei CSS-basiertem Layout die Notwendigkeit einen wirklich sauberen HTML-Code ohne Hilfselemente und Container zu erhalten.
Was sind "Hilfselemente"? Was spricht gegen semantisch bedeutungslose, aber hilfreich einsetzbare Zusatzcontainer? Es gilt, abzuwägen zwischen Maß und Übermaß.
Dann möchte ich die Flexibilität der Tabelle erhalten, was für die IE, also die zu 90% genutzten Browser, kaum möglich ist.
Definiere "Flexibilität der Tabelle". Eine eher ungewöhnliche Aussage.
Daß der IE display:table-cell usw. nicht beherrscht, ist natürlich etwas anderes...
Aus diesen und weiteren Widersprüchen ergibt sich m.E. dass der Ansatz "offenbar 2 Möglichkeiten" nicht ganz richtig ist,
ACK. Es gibt für jede Zielsetzung mehrere Herangehensweisen.
sondern das ggf. per Browserweiche/ CSS-Weiche für die IEs ein anderer Aufbau erfolgen kann als für Mozilla und Opera, um die eigentlichen Ziele für alle Browser zu verwirklichen.
Ja: * html {display:none;}
*SCNR*Viele Grüße,
Bubax-
Hallo,
Es _gibt_ barrierefreies Tabellenlayout.
ist wohl nicht bestritten worden.
Die Trennung von Inhalt und Layout - etwas, das sich mit Tabellenlayouts nur bedingt erreichen läßt.
[ ... ]
Was sind "Hilfselemente"? Was spricht gegen semantisch bedeutungslose, aber hilfreich einsetzbare Zusatzcontainer? Es gilt, abzuwägen zwischen Maß und Übermaß.
Solche Hilfsmittel heben eben diese Trennung auf, erschweren Wartung und Änderung usw..
Und was soll Maß und Übermaß (lol), denn wenn es deiner Meinung nach sematisch eh egal ist kann es wohl auch kein zuviel geben?Dann möchte ich die Flexibilität der Tabelle erhalten, was für die IE, also die zu 90% genutzten Browser, kaum möglich ist.
Definiere "Flexibilität der Tabelle". Eine eher ungewöhnliche Aussage.
Der IE kann mit Breiten nicht flexibel umgehen, kennt kein min-width usw., Tabellenlayout ist da wie bei anderen Punkten auch flexibler und meist auch noch sparsamer im Code.
Ähnlich schaut es mit Pixeln aus, Mozilla und Opera verhalten sich ja anders bei festen Schriftgrössen, der IE braucht eher relative Schriftgrössen, hat dann aber wieder mehr Probleme mit Grössenangaben (ausser bei Tabellen).
Grüsse
Cyx32
-
Hi,
Es _gibt_ barrierefreies Tabellenlayout.
ist wohl nicht bestritten worden.
Das ist in der Tat nie bestritten worden - ich wollte das mit meiner Aussage nur unterstreichen :)
Was sind "Hilfselemente"? Was spricht gegen semantisch bedeutungslose, aber hilfreich einsetzbare Zusatzcontainer? Es gilt, abzuwägen zwischen Maß und Übermaß.
Solche Hilfsmittel heben eben diese Trennung auf, erschweren Wartung und Änderung usw..
Ist ein <div id="#content"> wirklich so hinderlich für die Wartung, wenn man damit ein paar Absätze und Überschriften zusammenfassen will...?
Und was soll Maß und Übermaß (lol), denn wenn es deiner Meinung nach sematisch eh egal ist kann es wohl auch kein zuviel geben?
Es ist dann zu viel, wenn es einen semantisch bedeutungsvollen Ersatz gibt - und, wenn es überflüssig ist. <div id="#navigation"> ist oft genug überflüssig, da es bereits ein gruppierendes Element (ul oder was auch immer) gibt. Mit dem leeren Gerede (Maß - Übermaß) wollte ich nur ausdrücken, daß es zur Anzahl gebilligter Hilfscontainer innerhalb gewisser Grenzen verschiedene, aber nahezu gleichberechtigte Ansichten geben kann.
Beim Rest (Tabellen als praktikabler Würgaround für hochgradig CSS-unfähige Browser) kann ich Dir im wesentlichen zustimmen. Wobei ich eher sagen würde, daß ein semantisch bedeutungsloses Layoutdiv ästhetisch weniger anstößig ist, als eine von ihrer semantischen Bedeutung befreite Layouttabelle.
Viele Grüße,
Bubax-
Hallo,
Solche Hilfsmittel heben eben diese Trennung auf, erschweren Wartung und Änderung usw..
Ist ein <div id="#content"> wirklich so hinderlich für die Wartung, wenn man damit ein paar Absätze und Überschriften zusammenfassen will...?
dein Beispiel ist vielleicht ungeeignet weil es noch eine inhaltliche, strukturelle Unterstützung suggeriert (mag ja i.d. Praxis auch oft zutreffen).
M.E. sind solche Hilfscontainer dennoch lästiger als z.B. ein nicht valides allign=center Attribut.Es ist dann zu viel, wenn es einen semantisch bedeutungsvollen Ersatz gibt - und, wenn es überflüssig ist. <div id="#navigation"> ist oft genug überflüssig, da es bereits ein gruppierendes Element (ul oder was auch immer) gibt. Mit dem leeren Gerede (Maß - Übermaß) wollte ich nur ausdrücken, daß es zur Anzahl gebilligter Hilfscontainer innerhalb gewisser Grenzen verschiedene, aber nahezu gleichberechtigte Ansichten geben kann.
Das "zuviel" wird jetzt von dir als "vermeidlich" umschrieben.
Das grundlegende Problem bei CSS ist dessen geringe Leistungsfähigkeit bei reduziertem HTML (und üblichen Browsern), dein Beispiel-Div wird bei geringen Anforderungen an das Layout wie etwa Rahmen und bestimmte Hintergrundgestaltung mit bestimmten Abständen dringend benötigt.
Auch wenn hier ein umgebendes Div der Seitenstruktur folgt und damit auch eine menschliche Beurteilung des Codes kaum behindert, es wird Layout mit Inhalt vermengt.Eine Lösung wäre jedem Element vorsorglich immer zwei umgebende Container zu geben und diese dann immer im HTML-Code zu belassen und nach Bedarf per CSS zu gestalten, vorsorglich noch ein paar übergeordnete Container etc., dann muss nicht bei Layoutänderungen der HTML-Code geändert werden solange sich keine andere Verschachtelung ergibt...
Beim Rest (Tabellen als praktikabler Würgaround für hochgradig CSS-unfähige Browser) kann ich Dir im wesentlichen zustimmen. Wobei ich eher sagen würde, daß ein semantisch bedeutungsloses Layoutdiv ästhetisch weniger anstößig ist, als eine von ihrer semantischen Bedeutung befreite Layouttabelle.
Es ging mir besonders um die Vorteile von Tabellen für den IE bis zum IE6; die Tabelle ist leistungsfähiger als das CSS-Angebot bis auf den kaum genutzten bzw. i.d. Praxis meist verpfuschten Sonderfall dass floatende Elemente auch untereinander sitzen können.
Und bei der Grundsatzdiskussion Tabelle würde ich z.B. eine zweispaltige Layouttabelle durchaus auch als richtig eingesetzt betrachten können, denn bei einer Seitenteilung Navigation-Inhalt gibt es eigentlich kein richtiges Mittel, vielleicht noch Frames, ein Bezug der Navigation mit ausgewähltem Menupunkt zum daneben angezeigten Teil der Seite besteht ja auch, und per <link.. ist das Problem der Navigation auch noch nicht lösbar.
Grüsse
Cyx23
-
Hallo Cyx23,
Eine Lösung wäre jedem Element vorsorglich immer zwei umgebende Container zu geben und diese dann immer im HTML-Code zu belassen und nach Bedarf per CSS zu gestalten, vorsorglich noch ein paar übergeordnete Container etc., dann muss nicht bei Layoutänderungen der HTML-Code geändert werden solange sich keine andere Verschachtelung ergibt...
http://www.csszengarden.com/ *SCNR* ;)
die Tabelle ist leistungsfähiger als das CSS-Angebot bis auf den kaum genutzten bzw. i.d. Praxis meist verpfuschten Sonderfall dass floatende Elemente auch untereinander sitzen können.
In der Tat beobachte ich meist, daß
1. mit Vehemenz kein position:absolute, sondern float eingesetzt wird, weil "ersteres schlecht, letzteres gut sein soll"
2. auf die per float angeordneten Elemente dann so feste Restriktionen angewandt werden, daß sie sich wie absolut positionierte verhalten, womit alles hinüber ist - siehe z.B. unser seit ein paar Wochen neues Layout bei stern.de (ich habe zwar bei den Grundlagen mitentwickelt, war aber nicht für die Umsetzung verantwortlich)
Von daher mein Appell an Sheridan, sich von allen fixen Vorstellungen zu lösen...
Viele Grüße,
Bubax-
Hi,
siehe z.B. unser seit ein paar Wochen neues Layout bei stern.de (ich habe zwar bei den Grundlagen mitentwickelt, war aber nicht für die Umsetzung verantwortlich)
bist Du dann auch dafür mitverantwortlich, daß der NN4 wieder ein (zwar angepaßtes) CSS bekommt und die Seiten dadurch nicht mehr komplett nutzbar für ihn sind?
Ok, zwar immer noch besser als am Anfang der Umstellung, aber doch schlechter als zuvor ganz ohne CSS (naja, bis auf die leidigen den Text überlappenden Skyscraper manchmal).freundliche Grüße
Ingo-
Hallo Ingo,
bist Du dann auch dafür mitverantwortlich,
Nein :)
daß der NN4 wieder ein (zwar angepaßtes) CSS bekommt
Teils - ich habe häufiger die Auffassung geäußert, daß man den NS4 ja nicht ganz vernachlässigen muß - vehementer habe ich mich gegen die fixe Schriftgröße (px) eingesetzt ;)
Daß nur mein geringeres Anliegen geändert wurde, ist mehr oder weniger Zufall, zumal ich dort nichts mit Webentwicklung zu tun habe/gehabt haben sollte.
Falls Du noch Steine für mich übrig hast: Die fixe Navigation (auf allen Unterseiten) ist mehr oder weniger auf mich zurückzuführen, weil ich auf die Frage des Cheflayouters geantwortet hatte: "Selbstverständlich läßt sich das auch für den IE umsetzen!" ;)
und die Seiten dadurch nicht mehr komplett nutzbar für ihn sind?
Ich schaue mir die Seiten selten an - schon gar nicht mit NS4. Was funktioniert denn nicht?
Viele Grüße,
Bubax-
Hi,
Falls Du noch Steine für mich übrig hast: Die fixe Navigation (auf allen Unterseiten) ist mehr oder weniger auf mich zurückzuführen, weil ich auf die Frage des Cheflayouters geantwortet hatte: "Selbstverständlich läßt sich das auch für den IE umsetzen!" ;)
;-)
nunja, ich finde sie überflüssig, aber wundere mich, daß das sogar im IE mit deaktiviertem JS so klappt; ich dachte, expressions macht der dann nicht (oder das ist garnicht nötig).Ich schaue mir die Seiten selten an - schon gar nicht mit NS4. Was funktioniert denn nicht?
nunja, auf der Startseite werden rechts Inhalte abgeschnitten (natürlich ohne Scrollbalken), z.B. werden von den 3*2 Teaser mit Links zu den Artikeln 4 1/2 in einer Zeile dargestellt. Und das Menü der Unterseiten ist nur sehr schwer zu nutzen (man muß manchmal mehrmals über einen Link fahren und auch die richtige Position erwischen, damit ein Link aktiv wird. Und auf der Wissenschafts-Hauptseite stehen die Texte rechts wortweise untereinander, obwohl noch reichlich Platz vorhanden wäre.
Alles in allem: Murks. Kein CSS wie vorher wäre da tausendmal besser.Übrigens: mir fiel das Ganze nur deshalb auf, weil ich die Entwicklung der Stern-Seiten wegen Meiner Mutter mitverfolgt habe und mir die allererste Änderung viel Arbeit beschwerte: Ich mußte, da es die Lieblingsseiten meiner Mutter sind, für ihren uralt-Mac einen moderneren Browser auftreiben als den NN4 und ihr diesen natürlich auch "beibringen". Nunja, jetzt nutzt sie für den Stern den IE5.2 und muß ihre Stern-Newsletter erst in OE laden, um sie sehen zu können..:-(
freundliche Grüße
Ingo-
Hi,
fixe Navigation
nunja, ich finde sie überflüssig, aber wundere mich, daß das sogar im IE mit deaktiviertem JS so klappt; ich dachte, expressions macht der dann nicht (oder das ist garnicht nötig).
Das ist gar nicht nötig - außerdem ruckelt es mit der Methode fürchterlich. Das ist hier mit overflow umgesetzt.
Vielen Dank für den bug report - ich werde es in meinen letzten zwei Arbeitstagen mal anmerken ;)
Leider mußte ich gerade mit Entsetzen feststellen, daß ich gar keinen NS4 für mein Betriebssystem herumliegen habe. Mal schauen, wann ich dazu komme, wieder Windows zu booten.
Und das Menü der Unterseiten ist nur sehr schwer zu nutzen (man muß manchmal mehrmals über einen Link fahren und auch die richtige Position erwischen, damit ein Link aktiv wird.
Da hatte hauptsächlich der IE für den Mac (der ja position:fixed versteht) Probleme bereitet. Ich weiß nicht genau, welche Variante jetzt gerade aktiv ist, jedenfalls hatten wir für den zeitweise ein wegscrollendes Menü.
Alles in allem: Murks. Kein CSS wie vorher wäre da tausendmal besser.
Gut. Ich werd's mir nochmal anschauen und mit dem Verantwortlichen besprechen - wenn er Zeit hat (wir haben gemeinsam viele hacks gewälzt - jetzt ist er reif für den Urlaub ;)
Ich bedanke mich für Deine Beurteilung und entschuldige mich ganz offiziell für die Mühen, die der relaunch Dir und Deiner Mutter bereitet hat ;)
Viele Grüße,
Bubax-
Hi,
nunja, ich finde sie überflüssig, aber wundere mich, daß das sogar im IE mit deaktiviertem JS so klappt; ich dachte, expressions macht der dann nicht (oder das ist garnicht nötig).
Das ist gar nicht nötig - außerdem ruckelt es mit der Methode fürchterlich. Das ist hier mit overflow umgesetzt.
hmm ... warum ist die expression dann überhaupt noch drin? In meinem IE wurde die Seite ohne Javascript optimal angezeigt ohne jegliches Ruckeln.
Ich bedanke mich für Deine Beurteilung und entschuldige mich ganz offiziell für die Mühen, die der relaunch Dir und Deiner Mutter bereitet hat ;)
Ich werd's weitergeben ;-)
Das Ganze hätte übrigens durchaus einen Vorteil gehabt, wenn ich den Mozilla auf dem alten Mac unter OS 9 stabil zum laufen gebracht hätte. Der hat ja im classic-Style nahezu dieselbe Oberfläche wie ihr vertrauter Netscape. Nur leider stürzte der ständig ab und aktuellere Versionen wurden für OS 9 nicht mehr angeboten.freundliche Grüße
Ingo-
Hallo Ingo,
hmm ... warum ist die expression dann überhaupt noch drin? In meinem IE wurde die Seite ohne Javascript optimal angezeigt ohne jegliches Ruckeln.
Du meinst das:
#rahmen {
[...]
height:expression(document.body.clientHeight - 57 + "px");
[...]
}Das dient dazu, den Inhalt (#rahmen umfaßt den gesamten Inhalt außer der Navigation) um die Höhe der Navigation nach unten zu verschieben. Am Scrollbalken müßtest Du das erkennen können [1]. Andernfalls würde die Navigation sich *über* den Scrollbalken bis zum rechten Fensterrand schieben, was irritierend ist...
Ich bedanke mich für Deine Beurteilung und entschuldige mich ganz offiziell für die Mühen, die der relaunch Dir und Deiner Mutter bereitet hat ;)
Ich werd's weitergeben ;-)
:)
Viele Grüße,
Bubax[1] ich bin irritiert - bei meinem IE fängt der Scrollbalken ganz regulär oben an; aber er läuft unter Linux... immerhin war mir dieser Unterschied bisher noch nicht aufgefallen.
-
Hi,
Du meinst das:
#rahmen {
[...]
height:expression(document.body.clientHeight - 57 + "px");
[...]
}genau.
Das dient dazu, den Inhalt (#rahmen umfaßt den gesamten Inhalt außer der Navigation) um die Höhe der Navigation nach unten zu verschieben. Am Scrollbalken müßtest Du das erkennen können [1]. Andernfalls würde die Navigation sich *über* den Scrollbalken bis zum rechten Fensterrand schieben, was irritierend ist...
Genau das ist bei mir der Fall. Nur finde ich das überhaupt nicht irritierend, da das bei allen Framesets so ist und ich mich eher wundern würde, wenn der Scrollbalken über der Navigation liegt und diese trotzdem nicht wegscrollt. Diese Seite macht also ohne expression im IE exakt den (gewohnten) Eindruck einer Frameset-Seite und das finde ich auch besser so - zumindest bis position:fixed auch vom IE umgesetzt wird und dieses - eigentlich doch eher merkwürdige - Verhalten der Scrollfunktion geläufiger wird.
freundliche Grüße
Ingo
-
-
-
-
-
Hallo Bubax,
daß der NN4 wieder ein (zwar angepaßtes) CSS bekommt
Teils - ich habe häufiger die Auffassung geäußert, daß man den NS4 ja nicht ganz vernachlässigen muß - vehementer habe ich mich gegen die fixe Schriftgröße (px) eingesetzt ;)
[ ... ]
und die Seiten dadurch nicht mehr komplett nutzbar für ihn sind?
Ich schaue mir die Seiten selten an - schon gar nicht mit NS4. Was funktioniert denn nicht?
da sind wohl mehrere Punkte problematisch, ob da die Zeit das Ganze nochmals auf freier Wildbahn mit unterschiedlichen Inhalten gründlich anzuschauen fehlte? Es werden Seitenteile in erheblichem Umfang nicht angezeigt.
Bei dem Volumen der Seiten, angesichts der noch bestehenden Verbreitung des Netscape 4 (und des Riskos einen IE zu benutzen) halte ich aber bei diesen Seiten eine CSS-Anpassung und richtige Darstellung für erforderlich, eine Darstellung mit deaktivierten Styles ist m.E. hier nicht zumutbar da es einfach zu unübersichtlich und unstrukturiert wird, der Inhalt dürfte nach üblichen Maßstäben nicht mehr zugänglich sein.
Im Zusammenhang mit den Werbe- oder Newsblöcken, JavaScripten, dazu vmtl. Inlinestyles oder falsch deklarierte Style-Tags i.d. generierten Seite sowie JavaScript-Fehlern (da wird z.B. einfach getElementById vorausgesetzt) ist schonmal die eigentlich sehr komfortable Verwendung von JSSS in diesem Umfeld eher ungeeignet.
Methoden a la document.write('<link... sind leider oft auch keine Lösung, also müße wohl eine ander Weiche für <link eingesetzt werden, u.U. auch serverseitig, und/oder CSS-Weichen.
Grüsse
Cyx23
-
Hallo Cyx23,
danke auch für Deine Anmerkungen.
Obwohl ich minimalistisches Layout für den NS4 bevorzuge, ist es natürlich traurig, daß hier wieder über das Ziel hinausgeschossen wurde ;)
- Wie auch immer, die NS4-Unterstützung fliegt wieder raus. Ich habe eben mit unserem Entwickler telephoniert (ich bin gerade zu Hause und habe sowieso nur noch zwei Arbeitstage), der einige der Probleme schon bemerkt hatte. (Zu mir: Ich habe nur in der Anfangsphase und bei einigen besonderen Zwischenfällen mit ihm zusammen gebrütet; die ausgiebigeren Tests und speziellen Anpassungen hat er alleine vorgenommen.)
Mein Anruf aber hat das Faß zum Überlaufen gebracht :)
...
Im Zusammenhang mit den Werbe- oder Newsblöcken, JavaScripten, dazu vmtl. Inlinestyles oder falsch deklarierte Style-Tags i.d. generierten Seite sowie JavaScript-Fehlern (da wird z.B. einfach getElementById vorausgesetzt) ist schonmal die eigentlich sehr komfortable Verwendung von JSSS in diesem Umfeld eher ungeeignet.
Viele Probleme entstanden wegen eingebundener Werbung (deren Code von uns nicht beeinflußt werden konnte bzw. durfte). Immer wieder ziehen solche Codefragmente arge Fehler nach sich; im schlimmsten Fall gab es fatale Klassendefinitionen, die sich mit denen von stern.de deckten... Eine Zeit lang (vor der Layoutumstellung) mußte die Startseite wegen eingebundener Werbung im quirks mode betrieben werden (der Quellcode war weiterhin XHTML - mit einem quirkenden HTML 4.01 Doctype). Das war gerade die Zeit, zu der stern.de einen Preis zur Barrierefreiheit gewann - mit der Note "befriedigend: http://www.biktest.de/main.php?a=ps&prid=1&sid=17
Der Doctype war denen gleich negativ aufgefallen...Zu guter letzt gibt es einen ausgiebigen alten Datenbestand, zu dem CSS-Angaben kompatibel gehalten werden müssen. Das war's für heute also mit der Unterstützung des NS4 - Ingo, bestelle bitte schöne Grüße an Deine Mutter! ;)
Viele Grüße,
Bubax-
Hallo Bubax,
- Wie auch immer, die NS4-Unterstützung fliegt wieder raus.
ja, der NC4-Frust. Klar, diese Netscape 4 Unterstützung funktioniert nicht optimal, ansonsten wundert mich das etwas, gerade weil das CSS ("ausgiebigen alten Datenbestand") ja eher konstant bleibt und z.B. ein Tag zusätzlicher Entwicklung doch im Verhältnis zu den bis zu vielleicht 2% Besuchern (3.6 nach webhits.de) gerechtfertig wäre.
Viele Probleme entstanden wegen eingebundener Werbung (deren Code von uns nicht beeinflußt werden konnte bzw. durfte).
Eben deswegen sollte Netscape 4 m.E. hier nicht per jss angesprochen werden, sondern ein "normales" CSS erhalten.
Im Idealfall nur mit * Selektor vor problematischen Anweisungen und ggf. eine CSS-Weiche, z.B. Caio/Kommentar weiterentwickelt wie hier http://www.lipfert-malik.de/webdesign/tutorial/bsp/kristof-lipfert-nc4-crossover.html. Allerdings ist dann das Ganze natürlich mehr so sauber getrennt, aber es scheint ja sowieso serverseitig schon nach Useragent unterschieden zu werden, der Mozilla-Code schien mir anders auszusehen.Der Doctype war denen gleich negativ aufgefallen...
Wo ist jetzt eigentlich der Nutzen von xhtml-transitional 1.0?
Zu guter letzt gibt es einen ausgiebigen alten Datenbestand, zu dem CSS-Angaben kompatibel gehalten werden müssen. Das war's für heute also mit der Unterstützung des NS4 - Ingo, bestelle bitte schöne Grüße an Deine Mutter! ;)
Hmm, da ist hart, muss ich da meinen Netscape 4 auch irgendwann ausrangieren?
Aber zumindest Heise hat seine Seiten in den letzen Monaten wieder zugänglicher gemacht, so geht es offenbar auch.
Grüsse
Cyx23
-
Hallo Cyx23,
- Wie auch immer, die NS4-Unterstützung fliegt wieder raus.
ja, der NC4-Frust.
Ja :(
Trotz allem, was ich erzählt habe - ich habe nur am Rande etwas beim neuen Layout mitgewirkt (bis Ende Mai - danach habe ich die zwei-Tage-Woche ohne Zeit für weiteres Design eingeführt). Um beurteilen zu können, welche Kompromisse eingehalten werden müssen und welche Spezialfälle es gibt, muß man einiges an Erfahrung mit den Datenbeständen mitbringen, die ich nicht habe. Es gibt immer irgend welche Seiten, die eine Sonderbehandlung erfordern.
ein Tag zusätzlicher Entwicklung [wäre] doch im Verhältnis zu den bis zu vielleicht 2% Besuchern (3.6 nach webhits.de) gerechtfertig
Ja - ich kann deswegen leider nicht weiter mit Dir diskutieren, weil ich mit Deinen Aussagen übereinstimme :)
Eben deswegen sollte Netscape 4 m.E. hier nicht per jss angesprochen werden, sondern ein "normales" CSS erhalten.
Danke für den Hinweis - das JSS war mir entgangen, ich weiß gar nicht, wann genau das eingeführt worden war!
ggf. eine CSS-Weiche, z.B. Caio/Kommentar weiterentwickelt wie hier http://www.lipfert-malik.de/webdesign/tutorial/bsp/kristof-lipfert-nc4-crossover.html
Danke, das ist interessant, dan Hack kannte ich noch nicht.
Der Doctype war denen gleich negativ aufgefallen...
Wo ist jetzt eigentlich der Nutzen von xhtml-transitional 1.0?
Im Verhältnis zu HTML 4.01? Oder zu XHTML 1.0 Strict?
Den Beurteilern war vor allem die Inkonsistenz negativ aufgefallen (vielleicht glauben sie auch, daß Barrierfreiheit nur mit XHTML zu erreichen wäre...). Ansonsten hat Transitional immer den Vorteil, daß man noch das Attribut name als Anker für NS4 und dergleichen ältere Browser verwenden kann.
Ingo, bestelle bitte schöne Grüße an Deine Mutter! ;)
Hmm, da ist hart, muss ich da meinen Netscape 4 auch irgendwann ausrangieren?
Ich werde ihn weiterhin auf die eine oder andere Art unterstützen. Wie der Stern das handhaben wird, kann ich Dir leider nicht sagen, meine Zeit ist abgelaufen. Zu meiner Abschiedsfeier nächste Woche kann ich ja noch ein gutes Wort für ihn einlegen ;)
Aber zumindest Heise hat seine Seiten in den letzen Monaten wieder zugänglicher gemacht, so geht es offenbar auch.
Schön, so etwas zu hören. Außerdem würde mich ein leicht erhöhter Anstieg der NS4-Nutzung bei den andauernden Sicherheitsproblemen mit dem IE nicht verwundern.
Viele Grüße,
Bubax
-
Hi,
Viele Probleme entstanden wegen eingebundener Werbung (deren Code von uns nicht beeinflußt werden konnte bzw. durfte).
Ich erinnere mich - In der Style-losen Zeit sorgten die trotzdem positionierten Skyscraper für sehr üble Überlagerungen und entsprechend reduzierter Nutzbarkeit. Wenn das allerdings nicht zu verhindern ist, sollte doch zumindest der Inhaltsbereich für den NN4 entsprechend reduziert werden, damit sowas nicht mehr passiert.
Das war's für heute also mit der Unterstützung des NS4 - Ingo, bestelle bitte schöne Grüße an Deine Mutter! ;)
mach ich..;-)
Übrigens zum HTML-Doctype: warum nicht XHTML mit xml-Prolog für den Quirks-mode?
freundliche Grüße
Ingo-
Hallo Ingo,
Übrigens zum HTML-Doctype: warum nicht XHTML mit xml-Prolog für den Quirks-mode?
Nun - das versetzt ja (zum Glück) nicht alle Browser in den quirks mode. Und auch Opera war nur kurzzeitig von dieser Bugimplementation betroffen.
Danke nochmal an Euch (Dich und Cyx23) für die Kommentare. Ob und welche Auswirkungen diese Kritik auf die Darstellung haben wird, könnt Ihr dann ja live verfolgen... Für mich als Privatperson war es auf jeden Fall wieder interessant.
Viele Grüße,
Bubax
-
-
-
-
-
-
Hallo.
dein Beispiel ist vielleicht ungeeignet weil es noch eine inhaltliche, strukturelle Unterstützung suggeriert (mag ja i.d. Praxis auch oft zutreffen).
M.E. sind solche Hilfscontainer dennoch lästiger als z.B. ein nicht valides allign=center Attribut.Mit der nächsten Version von XHTML werden diese "Hilfscontainer" endlich semantisch erfasst. Das war auch dringend notwendig, da ein <div> kaum ausreichend deutlich machen kann, das etwa zwei aufeinander folgende Absätze zu einer darüber stehenden Überschrift gehören, während ein darunter liegender dritter Absatz semantisch autark sein soll. Man kann aber natürlich auf den positiven Nebeneffekt eines gestalterisch geeigneten Containers verzichten und stattdessen ein semantisch mindestens ebenso fragwürdiges <br /> einfügen, aber meist wird eben leider einfach auf die Auszeichnung zusammenhängender Inahlte verzichtet.
Das grundlegende Problem bei CSS ist dessen geringe Leistungsfähigkeit bei reduziertem HTML (und üblichen Browsern), dein Beispiel-Div wird bei geringen Anforderungen an das Layout wie etwa Rahmen und bestimmte Hintergrundgestaltung mit bestimmten Abständen dringend benötigt.
Bei einer Tabelle habe ich ja auch hinreichend viele Elemente ineinander verschachtelt, so das hier gar nicht von "reduzierten HTML" zu sprechen wäre.
Eine Lösung wäre jedem Element vorsorglich immer zwei umgebende Container zu geben und diese dann immer im HTML-Code zu belassen und nach Bedarf per CSS zu gestalten, vorsorglich noch ein paar übergeordnete Container etc., dann muss nicht bei Layoutänderungen der HTML-Code geändert werden solange sich keine andere Verschachtelung ergibt...
Wenn ma die vorhandenen Elemente mittels ID kennzeichnet, kann man bei Bedarf auch mittels Javascript ein paar Container darum herum materialisieren lassen ...
Und bei der Grundsatzdiskussion Tabelle würde ich z.B. eine zweispaltige Layouttabelle durchaus auch als richtig eingesetzt betrachten können, denn bei einer Seitenteilung Navigation-Inhalt gibt es eigentlich kein richtiges Mittel, vielleicht noch Frames, ein Bezug der Navigation mit ausgewähltem Menupunkt zum daneben angezeigten Teil der Seite besteht ja auch, und per <link.. ist das Problem der Navigation auch noch nicht lösbar.
Ja, und wenn es kein geiignetes Mittel gibt, greifen wir uns au den zahlreichen fragwürdigen doch einfach irgendeins heraus. Warum integriert man dann den Inhalt nicht gleich in eine Definitionsliste, die man dann wieder in die Navigation verschachtelt?
MfG, at-
Hallo,
Mit der nächsten Version von XHTML werden diese "Hilfscontainer" endlich semantisch erfasst.
also womöglich etwas unübersichtlich a la Div-Typen mit semantischer Bedeutung und solchen ohne entspr. Bedeutung, oder etwas für den IE 8?
Bei einer Tabelle habe ich ja auch hinreichend viele Elemente ineinander verschachtelt, so das hier gar nicht von "reduzierten HTML" zu sprechen wäre.
Das hält sich beí genauem Hinschauen oft in erstaunlichen Grenzen. Auch die hier vor Jahren schon zu lesende Idee auf irgendwelchen promineten Seiten erheblich Code einsparen zu können wenn Tabellen ersetzt wuerden war m.E. ziemlich unrealistisch.
Wenn ma die vorhandenen Elemente mittels ID kennzeichnet, kann man bei Bedarf auch mittels Javascript ein paar Container darum herum materialisieren lassen ...
...oder Tabellen.
Und bei der Grundsatzdiskussion Tabelle würde ich z.B. eine zweispaltige Layouttabelle durchaus auch als richtig eingesetzt betrachten können, denn bei einer Seitenteilung Navigation-Inhalt gibt es eigentlich kein richtiges Mittel, vielleicht noch Frames, ein Bezug der Navigation mit ausgewähltem Menupunkt zum daneben angezeigten Teil der Seite besteht ja auch, und per <link.. ist das Problem der Navigation auch noch nicht lösbar.
Ja, und wenn es kein geiignetes Mittel gibt, greifen wir uns au den zahlreichen fragwürdigen doch einfach irgendeins heraus. Warum integriert man dann den Inhalt nicht gleich in eine Definitionsliste, die man dann wieder in die Navigation verschachtelt?
Es muß wohl wirklich nicht gleich per Frame getrennt werden, vielleicht wäre eine Definitionsliste tatsächlich richtiger als <ul>. Aber gibt es nicht noch <menu></menu>:-?
Grüsse
Cyx23
-
Hallo Cyx23
Es muß wohl wirklich nicht gleich per Frame getrennt werden, vielleicht wäre eine Definitionsliste tatsächlich richtiger als <ul>. Aber gibt es nicht noch <menu></menu>:-?
http://de.selfhtml.org/html/referenz/varianten.htm#strict_nicht_erlaubt
Auf Wiederlesen
Detlef--
- Wissen ist gut
- Können ist besser
- aber das Beste und Interessanteste ist der Weg dahin! -
Hallo.
Mit der nächsten Version von XHTML werden diese "Hilfscontainer" endlich semantisch erfasst.
also womöglich etwas unübersichtlich a la Div-Typen mit semantischer Bedeutung und solchen ohne entspr. Bedeutung, oder etwas für den IE 8?
http://www.w3.org/TR/xhtml2/mod-block-text.html#sec_8.9. gibt bereits einen guten Eindruck von den künftigen Möglichkeiten.
Bei einer Tabelle habe ich ja auch hinreichend viele Elemente ineinander verschachtelt, so das hier gar nicht von "reduzierten HTML" zu sprechen wäre.
Das hält sich beí genauem Hinschauen oft in erstaunlichen Grenzen. Auch die hier vor Jahren schon zu lesende Idee auf irgendwelchen promineten Seiten erheblich Code einsparen zu können wenn Tabellen ersetzt wuerden war m.E. ziemlich unrealistisch.
Allein das Ansinnen halte ich für Unsinn. Entweder der Code ist notwendig oder nicht. Aber sich über <div>-Suppe zu beschweren, während man gleichzeitig Tabellen verschachtelt, kann ich nicht nachvollziehen.
Wenn ma die vorhandenen Elemente mittels ID kennzeichnet, kann man bei Bedarf auch mittels Javascript ein paar Container darum herum materialisieren lassen ...
...oder Tabellen.
Meinetwegen alles mögliche. Die Möglichkeit war ohnehin kaum ernst gemeint -- wenn man nicht gerade server-seitiges Javascript einsetzt.
Es muß wohl wirklich nicht gleich per Frame getrennt werden, vielleicht wäre eine Definitionsliste tatsächlich richtiger als <ul>. Aber gibt es nicht noch <menu></menu>:-?
Das kommt auf die HTML-Version an. Aber vor allem stellst du einmal die richtige Frage: <ul> oder <dl>? Oder doch <menu>? Was ist sinnvoll? Und muss es eine allgemeingültige Antwort darauf geben? Legt der Standard bereits die Struktur fest? Nimmt er den Autoren bereits das Denken ab?
MfG, at-
Hallo,
http://www.w3.org/TR/xhtml2/mod-block-text.html#sec_8.9. gibt bereits einen guten Eindruck von den künftigen Möglichkeiten.
also voraussichtlich ein section-Tag. Unklar ist mir bei dem Artikel aber am Anfang die Bandbreite von "address" weil das Beispiel mit mailto zwar anschaulich aber auch sehr einschränkend interpretierbar ist, m.E. ein grundlegendes Problem solcher Artikel.
Allein das Ansinnen halte ich für Unsinn. Entweder der Code ist notwendig oder nicht. Aber sich über <div>-Suppe zu beschweren, während man gleichzeitig Tabellen verschachtelt, kann ich nicht nachvollziehen.
Soweit es die Quelltext-Ästhetik betrifft, magst du Recht haben, allerdings kann die Wartbarkeit einer <div>-Suppe schlechter werden als die von Tabellen, und da hat denn auch der "schöne" HTML-Code seine weitergehende Berechtigung.
Tabellenvermeidung nur wegen einer angeblich so wichtigen semantischen Bedeutung der Tabelle reicht mir nicht aus eine Div-Suppe vorzuziehen, zumal diese Bedeutung der Tabelle mit dem Einsatz einer Layouttabelle sehr weit überstimmt.
Zudem kann es so betrachtet werden dass bei der <div>-Suppe das CSS-Ideal einer Trennung der Formatierung aufgeben wird, oder dass bei anderer Betrachung deutlich wird wie unzulänglich das Konzept von CSS ist.Meinetwegen alles mögliche. Die Möglichkeit war ohnehin kaum ernst gemeint -- wenn man nicht gerade server-seitiges Javascript einsetzt.
Es gibt beim IE sinnvolle Einsatzmöglichkeiten einer solchen clientseitigen Tabellenerzeugung.
Das kommt auf die HTML-Version an. Aber vor allem stellst du einmal die richtige Frage: <ul> oder <dl>? Oder doch <menu>? Was ist sinnvoll? Und muss es eine allgemeingültige Antwort darauf geben? Legt der Standard bereits die Struktur fest? Nimmt er den Autoren bereits das Denken ab?
I.d.R. wird ja nach "allgemeingültigen" Regeln oder nach Trends vorgegangen, eine bis ins letzte differenzierte Wahl einer HTML-Version dürfte eher selten sein und interferiert dann noch mit der -sich auch noch verändernden- Frage der Zugänglichkeit.
Da zeigt der o.g. Artikel beim Thema "h" wie es vielleicht auch schwieriger werden kann einfach nachvollziehbare Strukturen (und passende Browser) zu finden.Bei <dl> scheint mir bislang der semantische Vorteil gegenüber anderen Lösungen noch fraglich, immerhin erfolgt wohl die Abgrenzung vom übrigen Dokument, aber sonst passt es eigentlich nicht für eine Navigation, unabhängig von der HTML-Version?
Bleibt also vielleicht noch als Ersatz einer "allgemeingültige(n)", gerne auch differenzierteren, Antwort mal zu schauen ob sich irgendeine Methode etabliert hat, auch wenn es dadurch nicht richtiger würde und mir z.B. ein <div id="navigation"> auch nicht ausreichend erscheint.Grüsse
Cyx23
-
Hi,
Bei <dl> scheint mir bislang der semantische Vorteil gegenüber anderen Lösungen noch fraglich,
Bei dl wird eine logische Beziehung der Elemente *innerhalb* der Liste (d.i. dt und dd) hergestellt, die bei anderen Listen fehlt. Eine Navigationsliste mit Unterpunkten läßt sich also sehr schön durch verschachtelte ul erzielen - oder durch eine dl mit dt als Hauptpunkt und dd als Unterpunkt. Der semantische Unterschied ist in diesem Beispiel relativ fein, aber immer noch vorhanden.
immerhin erfolgt wohl die Abgrenzung vom übrigen Dokument, aber sonst passt es eigentlich nicht für eine Navigation, unabhängig von der HTML-Version?
Warum nicht? Auch eine Definitionsliste ist nur eine Auflistung von Elementen - ob dies philosophische Aussprüche, Bilder oder Verweise sind, ist ziemlich egal.
Viele Grüße,
Bubax
-
-
-
-
-
-
-
-
-
-
Hi,
Sind dies nur einfach verschiedene Herangehensweisen
Ja.
oder haben diese unterschiedlichen Methoden auch Sinn?
Auch ja. beide haben spezifische Vor- und Nachteile.
Welche Methode könnt ihr empfehlen, vorallem um möglichst viele Browser anzusprechen?
Was heißt "viel"? Was heißt "Browser"? Was heißt "ansprechen"?
Andererseits können aber solche Bereiche auch absolut definiert werden, zB Menü (top:80px,left:0px,width:150px;height:auto) und Inhalt Inhalt (top:80px,left:120px,width:450px;height:auto), wenn man von einem fixen Layout mit 800*600 ausgeht.
Davon kann man nicht ausgehen. Außerdem wären Seitenabmessungen von 800*600 Pixel selbst für viele Monitore schon zu groß; wenn Du dann noch an die Browsergröße denkst, wirst Du sehen, daß das so nicht funktionieren kann.
Bei position:absolute entsteht leicht die falsche Vorstellung, daß *mein* Browserfenster *Dein* Blatt Papier wäre, das Du abmessen und auf Deine Bedürfnisse zuschneiden könntest. Das ist aber nicht der Fall.
Deswegen empfehle ich Dir, ein Layout mit float zu entwerfen, bei dem als Größenangaben (wie chlori sagte) ausschließlich relative Einheiten zu verwenden sind: em, ex und %. Das gibt eine sehr gute Einführung in die Möglichkeiten von CSS.
pt ist für den Ausdruck, auch cm usf. hat am Bildschirm nichts zu suchen. px ist in Verbindung mit Bildern manchmal sinnvoll einzusetzen - ist ansonsten aber ebenfalls zu vermeiden.
Wenn Du die Vorstellung fester Größen überwunden hast, kannst Du Dich an position:absolute heranwagen. Auch damit läßt sich sehr flexibles Layout bewerkstelligen, wie z.B. der Heilige Gral zeigt: http://glish.com/css/7.asp
Daß dort häufiger die Einheit px verwendet wird, soll Dich nicht stören (es ist dort nicht schädlich eingesetzt). Es ginge auch ohne.
Viele Grüße,
Bubax-
Hi,
sehr flexibles Layout bewerkstelligen, wie z.B. der Heilige Gral zeigt: http://glish.com/css/7.asp
Daß dort häufiger die Einheit px verwendet wird, soll Dich nicht stören (es ist dort nicht schädlich eingesetzt). Es ginge auch ohne.
Dann sieh' Dir diese Seite bitte mal genauer an und verkleinere Dein Fenster -> die rechte Box überdeckt den Inhaltsbereich. Noch ünler wird's, wenn Du die Schrift (was natürlich nicht im IE geht) vergrößerst: nichts paßt mehr. Und Du sagst, daß px hier nicht "schädlich" eingesetzt sind?
freundliche Grüße
Ingo-
Hi,
sehr flexibles Layout bewerkstelligen, wie z.B. der Heilige Gral zeigt: http://glish.com/css/7.asp
Daß dort häufiger die Einheit px verwendet wird, soll Dich nicht stören (es ist dort nicht schädlich eingesetzt). Es ginge auch ohne.
Dann sieh' Dir diese Seite bitte mal genauer an und verkleinere Dein Fenster -> die rechte Box überdeckt den Inhaltsbereich.
Stimmt - im IE hatte ich's mir zuletzt vor Monaten angeschaut.
Noch ünler wird's, wenn Du die Schrift (was natürlich nicht im IE geht) vergrößerst: nichts paßt mehr.
Früher oder später läuft alles aus dem Ruder - hier an dem Punkt, an dem ein Wort (oder <pre>) sich aufgrund seiner Größe nicht mehr umbrechen läßt. Das würde aber auch bei Verwendung von relativen Einheiten passieren. IMHO der entscheidende Konzeptionsfehler am "Heiligen Gral": Drei Spalten sind ungefähr exakt eine zu viel für den Bildschirm.
Und Du sagst, daß px hier nicht "schädlich" eingesetzt sind?
Hätte ich tiefer in den Quellcode geschaut, hätte ich font-size:10px und dergleichen Unfug gesehen. Mein Fehler. - Andererseits ging es mir bei dem Verweis nur darum, zu zeigen, daß sich mit position:absolute tolle Dinge erzielen lassen - die Spalten (d.h. die mittlere) passen sich wunderbar der Fenstergröße an.
Daß die von Dir erwähnten Katastrophen (die ich erst übersehen hatte) dennoch vorhanden sind, bestätigt immerhin unsere Aussage, daß relative Größen zu verwenden sind...
Viele Grüße,
Bubax-
Hi,
IMHO der entscheidende Konzeptionsfehler am "Heiligen Gral": Drei Spalten sind ungefähr exakt eine zu viel für den Bildschirm.
eher die absolute Positionierung auch der rechten Box. Mit float könnte sich diese nach unten schieben.
Daß die von Dir erwähnten Katastrophen (die ich erst übersehen hatte) dennoch vorhanden sind, bestätigt immerhin unsere Aussage, daß relative Größen zu verwenden sind...
das sowieso - aber vor allem auch, daß absolute Positionierung stets sehr gründlich getestet werden muß und nur dort eingesetzt werden sollte, wo es anders nicht geht oder Probleme bereitet-
freundliche Grüße
Ingo
-
-
-