Frage zu Height = 100% (wieder einmal, sorry :-))

[Coldplayer]

Hallo zusammen!

Ich habe ein sicher bekanntes Problem aber irgendwie kann ich nirgendwo eine sinnvolle Lösung finden, darum poste ich hier mal, vielleicht hat hier jemand einen Tipp. Es geht wieder mal um das lästige Thema Box-Modell.

Auch wenn ich dafür gleich Prügel bekomme muss ich sagen dass ich bis heute finde, dass das Box-Modell von IE sinnvoller und logischer ist als das Box-Modell des W3C *sofern* man HTML-GUIs für Ajax-Anwendungen baut, die Desktop-Anwendungen ähnlich sein sollen (für Websites ist sicher W3C sinnvoller).

Ich denke es ist ein Fehler und eine Verkennung der Realität, dass das W3C hier nicht logisch trennt, für mich liegt ein großer Unterschied darin, ob ich eine Website oder eine WebANWENDUNG entwickle, rein aus UI-Sicht, eine Website ist ein Dokument und eine Webanwendung ist eine GUI und die Anforderungen an Layouts sind imho deutlich unterschiedlich und gerade das führt zu Problemen. Ich hab an ein paar Dutzend teilweise sehr komplexen Ajax-Anwendungen seit 2000 (bevor es Ajax hieß) für große Unternehmen mitentwickelt, d.h. bin kein Anfänger oder so.

Aber ich treffe immer wieder auf das Problem, dass es im W3C-Boxmodell ohne häßlich-langsames JavaScript unmöglich ist, verschachtelte 100%-Höhe-DIVs zu bauen.

Folgendes Problem: ich habe ein Layout, welches mit der Größe des Browserfensters skalieren soll. Dabei kommt es immer wieder vor, dass ich eine DIV mit 100% Höhe habe, in der dann zwei scrollbare DIVs untereinander liegen, die sich den Platz der Parent-DIV teilen sollen, dafür setze ich die Height auf 50%. Nun sollen diese DIVs aber einen Border von 20 Pixel haben, um die Corporate Design-Anforderungen des Kunden sinnvoll abzubilden.

Ein einfaches Beispiel (natürlich nicht so im Code bei mir, aber soll nur das Problem verdeutlichen):

  
  
<div style="height:100%;">  
        <div style="height:50%;background-color:yellow;">  
        <div style="width:100%;height:100%;">  
            <div style="border:20px solid red;height:100%;">  
  
            </div>  
        </div>  
        </div>  
        <div style="height:50%;background-color:yellow;">  
        <div style="width:100%;height:100%;">  
            <div style="border:20px solid orange;height:100%;">  
  
            </div>  
        </div>  
        </div>  
    </div>  
  
  

Im Quirks-Modus des IE sieht das genau so aus wie ich es als GUI-Designer erwarten würde: Zwei DIVs mit Border, die sich die 100% (Browser-Fenster) teilen, aber im Standard-Modus stehen die DIVs über, da ja die Height den Border nicht enthält.

Den gewünschten Effekt erreiche ich also nur mit lästigen JavaScript-OnResize-Handlern, die lahm sind und einen schlechten Eindruck bei komplexen  GUIs hinterlassen. Oder geht das doch irgendwie anders? Ich weiss, über -moz-box-sizing gehts aber das ist auch irgendwie dirty finde ich.

Ich sehe das nur als Beispiel an, warum das W3C-Modell für Webanwendungen prinzipiell ungeeignet ist. Für Websites okay, da ist das Height-Verhalten okay, da man normalerweise die ganze Seite scrollt und nicht einzelne DIVs, aber für GUIs ist der Standard schlecht, falsch und geht an der Realität vorbei und macht nur Probleme. Ich denke, das W3C, das ja Jahrzehnte an eher kleinen Details feilt sollte speziell für GUIs neue Layout-Tags einfüren, z.B. BorderLayout, GridLayout, VBox, HBox etc. das wäre mal eine echte Innovation. Ich habe bereits eine JavaScript-Bibliothek hier intern entwickelt die genau das leistet, die ich demnächst veröffentlichen will, die aber v.a. im Firefox bei vielen Elementen (große Formulare) Performance-Probleme hat, wenn das nativ im Browser wäre, wäre es sicher 100mal schneller als in JavaScript und ich denke das wäre kein großer Act für die Browser-Entwickler und *sicherlich* mehr wert als abgerundete Ecken oder Animationseffekte.

Ich will hier niemand auf den Schlips treten aber ich habe schon mit vielen Leuten gesprochen, die sagen, IE macht alles falsch und schlecht und keiner konnte mir eine Lösung sagen, wie man am Browserfenster skalierbare Layouts ohne redundante, fixe Größenangaben per JavaScript hinbekommt (mit 100% Height und scrollbaren DIVs), was meiner Ansicht nach ein Beleg ist, dass viele Leute, die Websites programmieren etwas mangelnde Weitsicht für GUI-Layouts haben.

Dabei ist ja der Gag, dass es bei der Width mit "width: auto" genau richtig funktioniert ;-) warum dann nicht bei "height" irgendeinen Wert (eben nicht "auto" da anders belegt) der genau den gleichen Layoutalgorithmus wie bei "width:auto" anwendet?

Ich musste das einfach mal in den Raum werfen, wer schon mal echt komplexe GUIs gebaut hat wird sicher "mitfühlen" können, und Leute, die nur einfache Websites mit drei Spalten bauen können ggf. mal die Probleme der anderen besser nachvollziehen.

Vielleicht kennt ja jemand den einen Trick den ich nicht kenne? :-)

MFG Chris

[ChrisB]

Hi,

Ich denke es ist ein Fehler und eine Verkennung der Realität, dass das W3C hier nicht logisch trennt, für mich liegt ein großer Unterschied darin, ob ich eine Website oder eine WebANWENDUNG entwickle, rein aus UI-Sicht, eine Website ist ein Dokument und eine Webanwendung ist eine GUI und die Anforderungen an Layouts sind imho deutlich unterschiedlich und gerade das führt zu Problemen.

Dokumente und Anwendungen sind halt zwei komplett unterschiedliche Paradigmen.

HTML und CSS sind in Hinsicht auf ersteres entwickelt worden;
wer letzteres nach seinen Wünschen und Vorstellungen umsetzen will, sollte sich vielleicht fragen, ob er dazu die geeignete Technik gewählt hat.

Aber ich treffe immer wieder auf das Problem, dass es im W3C-Boxmodell ohne häßlich-langsames JavaScript unmöglich ist, verschachtelte 100%-Höhe-DIVs zu bauen.

Die komplette Philosophie von HTML und CSS aus W3C-Sicht ist nun mal, dass ein Dokument so groß ist, wie es ist - und wenig(er) Rücksicht darauf nimmt, ob irgend jemand nun exakt „einen Bildschirm“ füllen möchte.

Folgendes Problem: ich habe ein Layout, welches mit der Größe des Browserfensters skalieren soll. Dabei kommt es immer wieder vor, dass ich eine DIV mit 100% Höhe habe, in der dann zwei scrollbare DIVs untereinander liegen, die sich den Platz der Parent-DIV teilen sollen, dafür setze ich die Height auf 50%. Nun sollen diese DIVs aber einen Border von 20 Pixel haben, um die Corporate Design-Anforderungen des Kunden sinnvoll abzubilden.

Dann muss man beim CD vielleicht mal Abstriche machen, wenn die verwendete Technik dessen Umsetzung nicht 1:1 her gibt.

Sollte form follows function nicht auch gerade dann gelten, wenn man *Anwendungen* entwickeln will?

Den gewünschten Effekt erreiche ich also nur mit lästigen JavaScript-OnResize-Handlern, die lahm sind und einen schlechten Eindruck bei komplexen  GUIs hinterlassen. Oder geht das doch irgendwie anders? Ich weiss, über -moz-box-sizing gehts aber das ist auch irgendwie dirty finde ich.

Erst kritisierst du die Einstellung des W3C - und jetzt gefällt dir das, was zukünftige Versionen des CSS-Standards mitbringen werden, und was einige Browser bereits vorab als „eigene“ Eigenschaften implementiert haben, auch wieder nicht?

Ich sehe das nur als Beispiel an, warum das W3C-Modell für Webanwendungen prinzipiell ungeeignet ist.

Niemand hat behauptet, es wäre dafür geeignet oder auch nur dafür gedacht.

GUIs sind nun mal nicht das, wofür HTML und CSS entwickelt wurden.

Für Websites okay, da ist das Height-Verhalten okay, da man normalerweise die ganze Seite scrollt und nicht einzelne DIVs, aber für GUIs ist der Standard schlecht, falsch und geht an der Realität vorbei und macht nur Probleme.

Dann solltest du vielleicht eine Technik wählen, die deinen Anforderungen eher entgegen kommt.

Autos sind für Bootstouren auch eher schlecht geeignet. Bevor ich mich darüber echauffiere, passe ich aber entweder meine Ansprüche ans Gefährt der Realität und dem vorgesehenen Einsatzzweck an - oder ich wähle ein geeigneteres, möglichst schwimmfähiges Vehikel für meinen Ausflug :-)

[...] was meiner Ansicht nach ein Beleg ist, dass viele Leute, die Websites programmieren etwas mangelnde Weitsicht für GUI-Layouts haben.

Oder das manche Leute, die GUIs entwickeln wollen, zu weder ursprünglich dafür gedachten noch dafür sonderlich geeigneten Techniken greifen.

Dabei ist ja der Gag, dass es bei der Width mit "width: auto" genau richtig funktioniert ;-) warum dann nicht bei "height" irgendeinen Wert (eben nicht "auto" da anders belegt) der genau den gleichen Layoutalgorithmus wie bei "width:auto" anwendet?

Weil die Philosophie eben nicht zu dem passt, was du möchtest.

MfG ChrisB

[Coldplayer]

Hallo,

okay, mein Beitrag war etwas emotionsgeladen, sorry und danke für die Antworten.

Ich bin nur wieder einmal wie so oft zum Vermittler oder Spielball oder Trottel zwischen Betriebswirten und Designern geworden, das Ding an dem ich gerade bastle soll auf IE6, Firefox 3 und Konqueror laufen (IE6 wegen Admins etc aber der macht mir noch die wenigsten Probleme ;-)). Problem ist dass es ein Formulargenerator ist, d.h. die Lösung muss generisch/verschachtelbar sein, deshalb kann ich position:absolute knicken, das ist fast unmöglich generisch hinzubekommen. Ich machs jetzt mal über die box-sizing Eigenschaften, scheint ja gut zu tun.

Flash scheidet aus, da es m.E. für solche Projekte absolut ungeeignet ist, Rich Client scheidet auch aus (Kunde will unbedingt Browser-Lösung da Win, MacOS, Linux im Spiel sind), ebenso Silverlight, da alles mit Java gemacht werden soll und GWT/JavaFX sind einfach zu ugly. Also ein aussichtsloses Dilemma ;-).

Ihr habt Recht, HTML/CSS ist für so was nicht gedacht, ich wollte mit meinem Post nur mal darstellen wie einen sowas nerven kann wenn alle Leute sagen dass am IE alles übel ist. Ich hab nichts über für MS, weiss Gott, aber ich hab etliche Jahre lang nur für IE5/6 entwickelt (da v.a. Großkunden bzw deren Zahlenschubser sparen wollten und explizit nur das wollten) und hatte all heilig Zeit mal solche Probleme, auf die ich mit den anderen Engines dauernd treffe.

Ich fühle mich irgendwie als GUI-Programmierer nur im IE Quirksmodus wohl und irgendwie hab ich das Gefühl dass die IE-Programmierer vielleicht auch das im Sinn hatten als sie das Teil so entwickelt haben, wobei ich auf jeden Fall zustimme, dass für Webseiten W3C-Standards viel besser sind. Ich war nur tierisch genervt als ich gegoogelt habe und jeder sagt IE macht alles falsch.

Ich denke einfach, HTML sollte ggf. für GUIs ein paar Extensions bekommen, da der Bedarf einfach da ist, alle Kunden wollen HTML-Anwendungen, da Flash zu verspielt und Silverlight zu sehr MS ist usw usw.

Und Designer regen sich darüber auf, wenn nicht alles exakt CD ist, ihr kennt das ja vielleicht. Mein Problem ist, dass der Wettbewerbsdruck gerade so enorm ist dass wir es uns nicht erlauben können so (für BWLer) triviale Dinge wie Border etc. nicht aus dem CD zu übernehmen.

Naja. Ich finds eben etwas ärgerlich, dass man praktisch die Schwächen der W3C-Standards und auch wirres verhalten von "guten" Browsern mit schmutzigen Tricks wie negativen Margins, Hintergrundbildern etc. ausgleichen muss, schlimmer sind Tabellen auch nicht glaub ich.

MFG Chris

[ChrisB]

Hi,

okay, mein Beitrag war etwas emotionsgeladen

Kann ich verstehen :-)

Ich bin nur wieder einmal wie so oft zum Vermittler oder Spielball oder Trottel zwischen Betriebswirten und Designern geworden, das Ding an dem ich gerade bastle soll auf IE6, Firefox 3 und Konqueror laufen (IE6 wegen Admins etc aber der macht mir noch die wenigsten Probleme ;-)).

Da kann dir das W3C *jetzt* aber auch mit bestem Willen und höchstem Eifer nicht mehr helfen - selbst wenn sie jetzt einen Standard verabschieden würden, der deinen Wünschen absolut entgegenkommt, wird der im IE 6 sicher keine Berücksichtigung mehr finden :-X

Problem ist dass es ein Formulargenerator ist, d.h. die Lösung muss generisch/verschachtelbar sein, deshalb kann ich position:absolute knicken, das ist fast unmöglich generisch hinzubekommen.

Damit bist du in der Tat stark limitiert; selbst wenn du die nötigen Positionierungen severseitig berechnest und schriftgrössenabhängig umsetzt, kann's dir das auf dem Client wieder zerhauen.

Ich machs jetzt mal über die box-sizing Eigenschaften, scheint ja gut zu tun.

Wenn du das mit dem Quirks Mode im IE kombinierst, dann hast du ja zumindest schon mal eine Lösung, die den und Firefox abdecken kann. (Kennt Konqueror die Eigenschaft box-sizing schon?)

Ihr habt Recht, HTML/CSS ist für so was nicht gedacht, ich wollte mit meinem Post nur mal darstellen wie einen sowas nerven kann wenn alle Leute sagen dass am IE alles übel ist.

Bei der normalen Webseitenerstellung ist der IE ja nur noch ein zusätzliches Übel, weil der selbst dann, wenn man sich mit den Übeln von CSS abgefunden hat, noch wieder Extrawürste erfordert.

Ich fühle mich irgendwie als GUI-Programmierer nur im IE Quirksmodus wohl

Bei der Entwicklung normaler Webseiten fühle ich mich in dem eben gar nicht wohl. Darum vermeide ich ihn immer - und muss dann für ältere IEs eben ein bisschen tricksen, wenn denn Rücksicht auf diese erforderlich ist; glücklicherweise ist das ja heute selten der Fall.
Wenn du firmeninterne Applikationen entwickelst, wo der IE 6 noch ein Muss ist, sieht das natürlich leider anders aus.

Ich war nur tierisch genervt als ich gegoogelt habe und jeder sagt IE macht alles falsch.

Die Aussage stimmt ja auch nach wie vor - wenn man sie auf den definierten Standard bezieht.

Naja. Ich finds eben etwas ärgerlich, dass man praktisch die Schwächen der W3C-Standards und auch wirres verhalten von "guten" Browsern mit schmutzigen Tricks wie negativen Margins, Hintergrundbildern etc. ausgleichen muss, schlimmer sind Tabellen auch nicht glaub ich.

An CSS gibt es sicher genug zu kritisieren - und Hoffnung auf Besserung ist, wenn überhaupt, nur langsam in Sicht.
Eine Umgebung wie das WWW erfordert nun mal in hohem Maße Abwärtskompabilität, deshalb kann man da den Murks der Vergangenheit nicht einfach komplett über Bord werfen und einen sinnvolleren Neuanfang machen - sondern an den vorhandenen Standards meist nur flickschusternde Nachbesserungen vornehmen.

Ich gebe dir vollkommen Recht, sowas wie box-sizing hätte eigentlich von Anfang an mit in den Standard gehört - dann hätten wir gleich die Möglichkeit gehabt, uns jeweils die Berechnungsmethode herauszusuchen, die im vorliegenden Fall günstiger ist.

Float ist so ein weiterer Kandidat, über den man eigentlich nur regelmäßig fluchen kann. Um Floats einzuschliessen overflow verwenden? Ganz tolle Idee, das hat manchmal wieder Nebenwirkungen, die man an der Stelle absolut nicht gebrauchen kann. Statt hier solche, manchmal geradezu absurd anmutenden Wechselwirkungen zu definieren, hätte man doch gleich eine weitere Eigenschaft definieren können, die explizit und einzig und allein die Aufgabe hat, anzugeben, wie sich ein Element in Bezug auf seine gefloateten Nachfahren verhalten soll - soll es sie einschliessen, oder sie rausfliessen lassen.
Ja, wenn man so vorgegangen wäre, dann hätten wir ein paar zusätzliche Eigenschaften mehr gehabt, die wir kennen müssen. Das wäre aber vermutlich doch immer noch die praktischere Lösung gewesen. Stattdessen hat man aber wohl versucht, den Standard in Hinsicht auf die Anzahl der Eigenschaften „schlank“ zu halten - und dafür aber sich gegenseitig bedingende Abhängigkeiten geschaffen, die a) erst mal nur schwer zu verstehen bzw. zu erlernen sind, und b) in manchen Situationen gewünschte Effekte unmöglich machen, weil die Nebenwirkungen einem dann einen Strich durch die Rechnung machen.

CSS kann man m.E. in seiner derzeitigen Form nur lieben und gleichzeitig hassen.

MfG ChrisB

[stewe]

»»Problem ist dass es ein Formulargenerator ist, d.h. die Lösung muss generisch/verschachtelbar sein, deshalb kann ich position:absolute knicken, das ist fast unmöglich generisch hinzubekommen.

Oha, da gehts offensichtlich um Dinge, die mir nichts sagen. Aus reinem Interesse: Würde mir einer von euch beiden erklären, wie "generisch" hier gemeint ist und warum das Ganze mit position:absolute kaum hinzukriegen wäre?

Freundliche Grüsse und Vielen Dank

Der Immer-begierig-etwas-Neues-zu-erfahren-Seiende :)

[Peter Pan]

Hi Admins!

Ich hatte in diesem Thread die erste Antwort geschrieben, die ich nicht wiederfinde - bei zwei Beiträgen bleibt das überschaubar;)

Nach dem Absenden las ich das übliche 'Diese Nachricht ist nun ...' und  habe das Abendessen zubereitet und nun nach der Speise schaue ich wieder hier herein und wundere mich - wo ist mein Beitrag geblieben?

Es geht mir jetzt weniger um meinen Beitrag, als viel mehr um die Frage: ist das ein Bug, oder hat man das gelöscht - ich bin mir keiner Schuld bewußt gegen die Forumsregeln verstossen zu haben.

off:PP

[Der Martin]

Hallo,

Es geht mir jetzt weniger um meinen Beitrag, als viel mehr um die Frage: ist das ein Bug, oder hat man das gelöscht - ich bin mir keiner Schuld bewußt gegen die Forumsregeln verstossen zu haben.

das einzige, was ich dir davon mit Sicherheit sagen kann: In diesem Thread ist nichts gelöscht worden. Kein Beitrag von dir, und keiner von jemand anderem.
Es wird sich also eher um einen Bug handeln - sei es bei der Forumssoftware, in deinem Browser oder in deinem Erinnerungsvermögen. ;-)

Ciao,
 Martin

[Peter Pan]

Hi Martin!

das einzige, was ich dir davon mit Sicherheit sagen kann: In diesem Thread ist nichts gelöscht worden.

Gut, denn ich hätte keinen Grund dafür finden können.

Kein Beitrag von dir, und keiner von jemand anderem.
Es wird sich also eher um einen Bug handeln - sei es bei der Forumssoftware, in deinem Browser oder in deinem Erinnerungsvermögen. ;-)

Ok! Letzteres kann niemand zu 100% ausschließen, mein Browser schielt unschuldig wie immer.

off:PP

[stewe]

Wie abwärts kompatibel muss es denn sein?

Denn: mit "position:absolute" kannst du doch GENAU das machen, was du willst. Du nimmst n'div (oder gleich den body) als 100% und setzt ein neues div mit position absolute dort hinein. dann kannst du mit top:/left:/right:/bottom: all die Abstände eingeben, die du für deinen Border brauchst... und den border brauchst du noch nicht einmal, falls du dem body schon die entsprechende farbe zuweist...

gruss

stewe