nicht angemeldet
über div, float und CSS-Interpretationen...
Tach zusammen!
Knobele jetzt schon eine Weile, aber irgendwie wills nicht so recht. Unter http://www.leipold-net.de/images/selfHTML/Floatproblem.html habe ich mein Problem mal online gestellt.
Bild und Bilduntertitel liegen innerhalb eines div, was alle Browser auch korrekt anzeigen. Der daneben stehende Text sollte um das div herumfließen, was ja auch klappt. Das Bild-div und der danebenstehende Text liegen zusammen in einem weiteren div, welches sich wiederum im body befindet.
Jetzt das Problem: In der jetzigen Form funktioniert im Mozilla/Firefox alles so, wie ich es mir dachte: ist das Browserfenster hinreichend schmal, fließt der Text rechts neben dem Bild-div und auch darunter noch weiter. Ist das Browserfenster entsprechend breit, bleibt der komplette Text neben dem Bild-div, das äußere div umfaßt auch noch das Bild-div, es bleibt also noch eine weiße Fläche übrig.
Nicht jedoch bei IE: das äußere div ist immer nur so groß, wie der Text lang ist - das Bild-div ragt darüber hinaus. Opera gar schneidet das bild-div am Ende des äußeren div ab :-(
Ändere ich in die CSS
#Inhalt{ overflow: auto; }
zu
#Inhalt{ overflow: visible; }
agieren Mozilla/Firefox und Opera wie der IE (sprich: das äußere div ist so lange wie der Text, das bild-div ragt über das äußere div hinaus), bei selbigem (IE) ändert sich nichts.
Hat jemand evtl. einen Gedanken dazu? Woran könnts liegen?
Fragen über Fragen... und hoffentlich bald ein paar hilfreiche Antworten :-)
Danke, Ulli
-
Hallo,
mit der Ergänzung scheint es gleich auszusehen:
* html body #Inhalt{float:left}
Grüsse
Cyx23
-
mit der Ergänzung scheint es gleich auszusehen:
* html body #Inhalt{float:left}Habe ich gestern abend (bzw. sehr früh heute morgen ;) ausprobiert... klappt nicht ganz, jedenfalls nicht bei mir, IE verbreitert dadurch den body auf mehr als Fensterbreite (danke, MS, für dieses begnadete boxmodell... :-( )
Opera schneidet immer noch ab. Aber wahsaga hat mir mittlerweile weiterhelfen können.
Danke, Ulli
-
Hallo,
mit der Ergänzung scheint es gleich auszusehen:
* html body #Inhalt{float:left}
Habe ich gestern abend (bzw. sehr früh heute morgen ;) ausprobiert... klappt nicht ganz, jedenfalls nicht bei mir, IE verbreitert dadurch den body auf mehr als Fensterbreite (danke, MS, für dieses begnadete boxmodell... :-( )das liesse sich bei deinem Beispiel vmtl. durch padding:10px; für den body und den Verzicht auf margin:10px; bei #inhalt korrigieren.
Opera schneidet immer noch ab.
Ich hatte es so verstanden dass das Ergebnis erstmal für den IE nachgebessert werden müsste.
Ohne Weiche, also per #Inhalt{float:left}, passt es auch beim Opera, ggf. müsste noch overflow:auto bedacht oder um Höhenangaben ergänzt werden (Mozilla).Aber wahsaga hat mir mittlerweile weiterhelfen können.
Wenn es so funktioniert ist es ja gut, mit zusätzlichen Elementen kann einiges gerichtet werden, z.B. auch über zusätzliche container der box-bug, aber ein stimmiges und aufgeräumtes HTML hat auch einige Vorteile.
Grüsse
Cyx23
-
Hallo!
klappt nicht ganz, jedenfalls nicht bei mir, IE verbreitert dadurch den body auf mehr als Fensterbreite
das liesse sich bei deinem Beispiel vmtl. durch padding:10px; für den body und den Verzicht auf margin:10px; bei #inhalt korrigieren.Möglicherweise... da wahsagas Hinweis Abhilfe schaffte, verzichte ich aber auf einen Test.
Ich hatte es so verstanden dass das Ergebnis erstmal für den IE nachgebessert werden müsste.
Muß es das nicht immer :-D
Ohne Weiche (...)
Genau! Ohne Weiche möchte ich alle meine Seiten erstellen... nur unnötige Arbeit.
(...) aber ein stimmiges und aufgeräumtes HTML hat auch einige Vorteile.
Nur zu wahr... Genau das ist mein Ansinnen, je aufgeräumter das HTML, um so besser sollten die Brauser damit zurechtkommen (und ich natürlich auch, wenn ich irgendwann mal wann was ändern muß).
MfG, Ulli
-
Hallo,
Ohne Weiche (...)
Genau! Ohne Weiche möchte ich alle meine Seiten erstellen... nur unnötige Arbeit.
(...) aber ein stimmiges und aufgeräumtes HTML hat auch einige Vorteile.
Nur zu wahr... Genau das ist mein Ansinnen, je aufgeräumter das HTML, um so besser sollten die Brauser damit zurechtkommen (und ich natürlich auch, wenn ich irgendwann mal wann was ändern muß).da will ich mal das "stimmige und aufgeräumte HTML" etwas zuspitzen :-)
"Ohne Weiche" bietet sich ja erstmal Tabellenlayout an, das läuft unter fast allen Browsern ohne Weichen o.ä.
Wenn ich nun aber die Ansätze von CSS wie Trennung der Formatierung vom HTML, und ähnlich Vorstellungen eines sematic Web mit stimmigen bzw. inhaltsstimmigen HTML und "Inhalt" im HTML sowie "Layout" im CSS weiterverfolge, sind die Klimmzüge besser im CSS untergebracht, schon weil es sich ja um Layoutprobleme handelt.
Da widerspricht eine Überlegung welche als Korrektur missbrauchten HTML-Elementen keine "Bedeutung" zubilligt und diese doch als Hilfsmittel einsetzt bereits grundsätzlich den vorher postulierten Anforderungen.
Es gibt also eigentlich nur die Möglichkeit im CSS, und notfalls per CSS-Weichen, anzupassen um ordentliches HTML zu erhalten.
Wo nun davon aus gutem Grund abgewichen wird dürfte es -vollkommen richtig- um die vorrangige Funktion eine Website im Browser, also Darstellbarkeit, gehen, allerdings kann ich hier dann irgendwann auch wieder bei der äusserst zuverlässigen Tabelle ankommen.Grüsse
Cyx23
-
(...) sind die Klimmzüge besser im CSS untergebracht, schon weil es sich ja um Layoutprobleme handelt.
Da widerspricht eine Überlegung welche als Korrektur missbrauchten HTML-Elementen keine "Bedeutung" zubilligt und diese doch als Hilfsmittel einsetzt bereits grundsätzlich den vorher postulierten Anforderungen.Hmmm... natürlich ist ein div, welches den einzigen Zweck hat, eine zuvor eingestellte CSS-Formatierung (in diesem speziellen Fall das float:left eines divs davor) aufzuheben, die "reine Lehre" betrachtend, falsch. Schließlich steht im HTML Inhalt und sämtilche Formatierungen im CSS - insofern stimme ich Dir zu.
In diesem besonderen Falle jedoch handelt es sich um ein inhaltsleeres div, das außer im Quelltext nicht zu sehen ist. Und da es mir um gute Lesbarkeit meines Codes (und damit gute Wartbarkeit) ging, kann ich mit diesem kleinen Umstand recht gut leben, da es auf allen Browsern (zumindest die, die ich teste) läuft, die Anzeige nicht stört (im Gegenteil) und das CSS nicht allzusehr aufbläht (je mehr CSS, desto größer die Wahrscheinlichkeit, daß man mal sich widersprechende Anweisungen eingibt - und sich dann wundert, warums grade wieder nicht klappt)).
Wo nun davon aus gutem Grund abgewichen wird dürfte es -vollkommen richtig- um die vorrangige Funktion eine Website im Browser, also Darstellbarkeit, gehen, allerdings kann ich hier dann irgendwann auch wieder bei der äusserst zuverlässigen Tabelle ankommen.
Jein - Für einen Sehenden mag es egal sein, ob er auf eine Tabellen- oder eine div-Konstruktion schaut. Ein Blinder jedoch muß sich per Braille-Zeile oder Screenreader die Seite "ansehen". Und ebenjene Medien kommen bei Tabellenkonstruktionen in Schwierigkeiten: von links nach rechts vorlesen? Oder doch besser von oben nach unten?
Bei Einsatz von divs ergibt sich im Idealfall (der, wenn man sich nicht völlig bescheuert anstellt, der Normallfall ist) immer eine linear zu lesende Seite, die völlig problemlos zu lesen ist - egal, ob mit den Augen, Fingern oder Ohren.
Ein gutes Beispiel, wie man es nicht macht, ist zum Beispiel meine eigene Seite: http://www.leipold-net.de/index.htm. Betrachte diese Seite mit Opera, wähle dabei als Benutzermodus Textbrowser (und, zur Verschärfung, evtl. noch "disable tables"). Ziemlich unübersichtlich, oder? (Zur Entschuldigung: ist ja schon vier Jahre her... und war so ziemlich das erste, was ich gemacht habe, und dafür isses einigermaßen in Ordnung).
Besser ist da eine meiner Arbeiten vom letzten Jahr: http://www.bildundbohne.de/V01/Content.php?show=home&style=std
Abgesehen von den Seiten mit den Bildern (ich weiß, eigentlich inkonsequent... aber die Bilder könnte ein Blinder ohnehin nicht sehen...) sind alle Seiten komplett ohne Frames und stets gleich angeordneten Elementen: Titel, Menü, Inhalt._Das_ ist für mich der größte Vorteil von tabellenfreiem Layout. Ich mache daraus allerdings auch keine Glaubensfrage, wenn ich etwas per div partout nicht hinbekomme, nehme ich auch ganz pragmatisch eine Tabelle - ist halt auch eine Frage des Zielpublikums. Einen schönen bunten Bilderkatalog auf Teufel-komm-raus auf div zu trimmen, obwohl es außer Bildern nichts zu sehen gibt, empfände ich als vergebliche Liebesmühe. Denn mit einem Bild kann ein blinder Besucher ohnehin nichts anfangen - egal, ob das Bild in einem <table> oder in einem <div> ist.
Puh, viel Text
MfG Ulli-
Hallo,
Wo nun davon aus gutem Grund abgewichen wird dürfte es -vollkommen richtig- um die vorrangige Funktion eine Website im Browser, also Darstellbarkeit, gehen, allerdings kann ich hier dann irgendwann auch wieder bei der äusserst zuverlässigen Tabelle ankommen.
Jein - Für einen Sehenden mag es egal sein, ob er auf eine Tabellen- oder eine div-Konstruktion schaut. Ein Blinder jedoch muß sich per Braille-Zeile oder Screenreader die Seite "ansehen". Und ebenjene Medien kommen bei Tabellenkonstruktionen in Schwierigkeiten: von links nach rechts vorlesen? Oder doch besser von oben nach unten?
Im Forumsarchiv findest du eine Menge über die Zugänglichkeit von Tabellenlayouts (z.B. </archiv/2004/1/70365/#m405352> folgende und Links darin). Ebenjene Medien linearisieren Tabellen ganz einfach Zeile für Zeile von links nach rechts Spalte für Spalte. Sofern die Layouttabelle entsprechend aufgebaut ist, sodass die Inhaltsreihenfolge bei dieser Linearisierung noch Sinn ergibt, besteht (diesbezüglich) kein Problem für assistive Techniken.
Ein gutes Beispiel, wie man es nicht macht, ist zum Beispiel meine eigene Seite: http://www.leipold-net.de/index.htm. Betrachte diese Seite mit Opera, wähle dabei als Benutzermodus Textbrowser (und, zur Verschärfung, evtl. noch "disable tables"). Ziemlich unübersichtlich, oder?
Ich finde dort keine Beispiele für unzugängliches Tabellenlayout und die Frames sind umständlich gelöst, sodass sie unnötig kompliziert mit Textbrowsern/Screenreadern bedienbar sind. Das sind keine prinzipiellen Probleme von Frames.
Besser ist da eine meiner Arbeiten vom letzten Jahr: http://www.bildundbohne.de/V01/Content.php?show=home&style=std
Solche Adressen ignoriert Google übrigens.
Abgesehen von den Seiten mit den Bildern (ich weiß, eigentlich inkonsequent... aber die Bilder könnte ein Blinder ohnehin nicht sehen...) sind alle Seiten komplett ohne Frames und stets gleich angeordneten Elementen: Titel, Menü, Inhalt.
_Das_ ist für mich der größte Vorteil von tabellenfreiem Layout.
Wieso ist das bei Tabellenlayout nicht möglich?
Mathias
-
-
-
-
-
-
-
hi,
Jetzt das Problem: In der jetzigen Form funktioniert im Mozilla/Firefox alles so, wie ich es mir dachte
das wundert mich aber.
gefloatete elemente fallen bekanntlich aus dem dokumentfluss heraus, beeinflussen also auch die höhe ihres elternelementes nicht mehr.
lösung hierfür ist allgemein, vor dem schliessen des elternelementes noch ein (leeres) element (br oder div bspw.) einzufügen, welches über clear das floaten wieder aufhebt. ein solche clear vermisse ich aber in deinem beispiel.
http://selfhtml.teamone.de/css/eigenschaften/positionierung.htm#clear
gruss,
wahsaga-
Moin!
gefloatete elemente fallen bekanntlich aus dem dokumentfluss heraus, beeinflussen also auch die höhe ihres elternelementes nicht mehr.
Irgendwie komisch - jetzt, wo ich es so lese, denke ich mir: "Ja, klar, natürlich". Aber selbst drauf gekommen bin ich nicht. Mist :-)
lösung hierfür ist allgemein, vor dem schliessen des elternelementes noch ein (leeres) element (br oder div bspw.) einzufügen, welches über clear das floaten wieder aufhebt. ein solche clear vermisse ich aber in deinem beispiel.
s.o. Leeres div rein, Problem raus. Wie gesagt, hätte ich eigentlich selbst drauf kommen können, aber irgendwie war das wohl nix. Muß wohl doch noch ein bißchen üben ;-)
Ein herzliches Danke,
Ulli
-