nicht angemeldet
JürgenB
Matthias Apsel
Der Martin
Matthias Apsel
Der Martin
Der Martin
Matthias Apsel
Gunnar Bittersmann
Gunnar Bittersmann
Auge
JürgenB
Hallo miteinander!
Ich habe in der Mittagspause mal angefangen, mir meinen eigenen kleinen browserbasierenden WebGL-Editor zu programmieren, scheitere im Moment jedoch schon an der ersten Hürde! ;)
Anzuordnen seien folgende Elemente ohne einen window.overflow zu erzeugen:
<header id = "header" >
</header>
<main id = "main"
role = "main" >
<section id = "tools" >
</section>
<canvas id = "scene" >
</canvas>
</main>
Die Elemente <header> und <main> sollen immer 90 Prozent der Breite des Fensters haben und mittig zentriert sein:
header {
position: relative;
margin: 0 auto 0;
width: 90%;
height: 200px;
}
main {
position: relative;
margin: 15px auto 0;
width: 90%;
/* ... */
}
Das funktioniert auch bestens! Was aber _nicht_ funktioniert ist das Hinzufügen einer variablen Höhenangabe für das Element <main> und dessen Kindelement <section>.
Das Ziel insgesamt sollte sein, dass <header> eine Breite von 90 Prozent des Fensters hat und eine minimale Breite von, sagen wir mal 800px, immer horizontal zentriert ist, und eine feste Höhe hat von, sagen wir 200px.
Das Element <main> soll ebenfalls eine Breite von 90 Prozent des Fensters haben und eine minimale Breite von 800px, immer horizontal zentriert sein, - dann aber statt einer festen Höhe, soll es eine variable Höhe haben, die der window.height minus der header.height minus je 15px oben und unten entspricht, allerdings begrenzt durch eine minimale Höhe von sagen wir 500px.
Das Element <section> soll innerhalb von <main> die Eigenschaft float: left; haben, eine feste Breite von, sagen wir 200px, eine minimale Höhe von 500px, und bei allem was darüber hinausgeht, eine variable Höhe, die der variablen Höhe des Elternelementes <main> entspricht.
Das Element <canvas> soll ebenfalls die Eigenschaft float: left; haben, eine minimale Höhe und eine minimale Breite haben, die sich mit den als Beispiel genannten minimalen 800px( -200px ) x 500px deckt, sowie darüber hinaus in Breite und Höhe variabel an die Fenstergröße bzw. die sich daran orientierende Größe des Elternelmentes <main> angepasst sein.
|<--5%--><---------90%--------><--5%-->|
______________________________________
| .--------------------------------. |
| | |min | <--- h: 200px / w: variabel / min-w: 800px
| '--------------------------------' |
| .-----. .------------------------. |
| | | | | | |
| | | | | | |
| |_____| |___________|min | <--- h: variabel / min-h: 500px /
| | min | | | | <section> w: 200px /
| '-----' '------------------------' | <canvas> w: variabel / min-w: 600px
|______________________________________|
Aber irgendwie bekomme ich das nicht gebacken!
Ich nehme an, die Vermischung von Prozentangaben mit Pixelangaben in einer Axialebene wird vom Browser nur ungern gesehen. ;)
Falls jemand den Knoten entwirren oder durchschlagen kann und mich an seinem Wissen teilhaben lässt, sei ihm oder ihr mein Dank sicher!
Gruß,
Roadster.
Hallo Roadster,
css kann rechnen: http://wiki.selfhtml.org/wiki/Calc#Berechnungen_-_Die_calc-Funktion
Gruß, Jürgen
Hallo Roadster
Hallo Jürgen
css kann rechnen: http://wiki.selfhtml.org/wiki/Calc#Berechnungen_-_Die_calc-Funktion
CSS vielleicht, aber ich wohl nicht! ;)
header {
position: relative;
margin: 0 auto 0;
width: 90%;
min-width: 800px;
height: 200px;
}
Die Kombination von width: 90%; und min-width: 800px; funktioniert tadellos, genauso wie es sein soll. Auch kann ich auf der X-Achse ohne weiteres Angaben wie width: calc( 100% - 200px ); und min-width: 500px; machen und es wird genauso umgesetzt...
Aber wenn ich mich dann an die Höhenangabe der Elemente <main> und <section> mache, funktioniert das selbe Prinzip eben überhaupt nicht!
main {
position: relative;
margin: 15px auto 15px;
width: 90%;
min-width: 800px;
height: calc( 100% - 230px ); /* ...oder jede beliebige Prozentangabe... */
min-height: 500px;
}
#tools {
position: relative;
float: left;
width: 200px;
height: inherit;
min-height: inherit;
}
Völlig egal, ob ich hier bei height einfach eine Prozentangabe mache oder ob ich noch ein paar Pixel davon abziehe, das Element <main> oder auch <section> haben immer nur die min-height, - und wenn ich die wegnehme, sind sie flat...
Eine dynamische Anpassung über Prozentangaben findet also nur auf der X-Achse statt, nicht jedoch auf der Y-Achse, und die Frage ist, warum das selbe Prinzip einmal funktioniert und einmal nicht! ;)
Gruß,
Roadster.
Om nah hoo pez nyeetz, Roadster!
Eine dynamische Anpassung über Prozentangaben findet also nur auf der X-Achse statt, nicht jedoch auf der Y-Achse, und die Frage ist, warum das selbe Prinzip einmal funktioniert und einmal nicht! ;)
90% von "auto"?
Ansonsten - online-Beispiel bitte.
Matthias
Om nah hoo pez nyeetz, Roadster!
Hallo Matthias!
Eine dynamische Anpassung über Prozentangaben findet also nur auf der X-Achse statt, nicht jedoch auf der Y-Achse, und die Frage ist, warum das selbe Prinzip einmal funktioniert und einmal nicht! ;)
90% von "auto"?
DAS funktioniert ja! ;)
Klartext:
Die Breite beträgt 90% des Elternelementes ( im Falle des headers also body/window ) und der Abstand links und rechts ( shorthand margin bei Angabe von 3 Werten: oben links/rechts unten ) auf auto, so dass das Element immer zentriert ist. Kein Ding. Warum soll das nicht laufen? ;)
Was NICHT funktioniert, ist das selbe Spiel auf der Y-Achse, also bei height statt width ( obwohl wie du bei Ansicht meines Beispiels sicher feststellst, die Werte für margin-top und margin-bottom nicht auf auto stehen ;)
Was soll ich da ein Live-Beispiel Posten? Versuch doch mal, ob mit oder ohne margin bei einem beliebigen Element den Wert für height in Prozent anzugeben! :D
Gruß,
Roadster.
Hallo,
Was NICHT funktioniert, ist das selbe Spiel auf der Y-Achse, also bei
heightstattwidth( obwohl wie du bei Ansicht meines Beispiels sicher feststellst, die Werte fürmargin-topundmargin-bottomnicht auf auto stehen ;)
aber die Höhe des Elternelements (bzw. aller Vorfahrenelemente) hast du vermutlich nicht explizit festgelegt. Ergo gilt der Defaultwert "auto", das Element ist genau so hoch, wie es sein Inhalt erfordert.
Was soll ich da ein Live-Beispiel Posten? Versuch doch mal, ob mit oder ohne
marginbei einem beliebigen Element den Wert fürheightin Prozent anzugeben! :D
Kein Problem, wenn die Vorfahrenelemente alle eine definierte Höhe haben.
Ciao,
Martin
Hallo,
aber die Höhe des Elternelements (bzw. aller Vorfahrenelemente) hast du vermutlich nicht explizit festgelegt. Ergo gilt der Defaultwert "auto", das Element ist genau so hoch, wie es sein Inhalt erfordert.
Ah, so war das gemeint! Ok, mea culpa!
Kein Problem, wenn die Vorfahrenelemente alle eine definierte Höhe haben.
Dennoch, ich habe ja auch nicht den Wert für width des body explizit definiert und trotzdem funktioniert das in DEM Fall ohne Probleme!
Also warum erkennt der Browser ohne weiters die 90% der Fensterbreite, aber nicht die 70% der Fensterhöhe?
Das schöne an der Prozentangabe ist ja, dass man das Browserfenster skalieren kann und die Elemente sich dynamisch anpassen. So wie es mit 'width' auch problemlos funktioniert. Aber wenn ich bei der Höhe keine automatische Erkennung des Wertes habe, so dass es immer auf 'auto' steht, wie du sagtest, läuft dieses Feature natürlich leer.
Was soll man da machen? Request für die Fensterhöhe mit setInterval alle 5ms + Neuladen des Elementes? lol :(
Gruß,
Roadster.
Om nah hoo pez nyeetz, Roadster!
Dennoch, ich habe ja auch nicht den Wert für width des body explizit definiert und trotzdem funktioniert das in DEM Fall ohne Probleme!
Block-Elemente nehmen immer die gesamte Breite ein, aber nur soviel Höhe, wie der Inhalt es erfordert.
Matthias
Hallo.
Was soll man da machen? Request für die Fensterhöhe mit setInterval alle 5ms + Neuladen des Elementes? lol :(
Ok. Man könnte vielleicht noch ganz tricky rangehen und in JS die Höhe über eine Umrechnung an die Breite anknüpfen, aber das funktioniert natürlich auch nur soweit, wie das Seitenverhältnis beim Skalieren nicht verändert wird...
Mmmmhhh... :/
Gruß,
Roadster.
Om nah hoo pez nyeetz, Roadster!
Ok. Man könnte vielleicht noch ganz tricky rangehen und in JS die Höhe über eine Umrechnung an die Breite anknüpfen, aber das funktioniert natürlich auch nur soweit, wie das Seitenverhältnis beim Skalieren nicht verändert wird...
Du musst nur html und body eine Höhe geben. etwa 100% oder 100vh.
Matthias
Om nah hoo pez nyeetz, Roadster!
Hallo Matthias!
Ok. Man könnte vielleicht noch ganz tricky rangehen und in JS die Höhe über eine Umrechnung an die Breite anknüpfen, aber das funktioniert natürlich auch nur soweit, wie das Seitenverhältnis beim Skalieren nicht verändert wird...
Du musst nur html und body eine Höhe geben. etwa 100% oder 100vh.
Ja. Warum einfach, wenn's auch kompliziert geht! ;)
Danke für den Tip. / Thread closed. :)
Gruß,
Roadster.
Hi,
Kein Problem, wenn die Vorfahrenelemente alle eine definierte Höhe haben.
Dennoch, ich habe ja auch nicht den Wert für width des body explizit definiert und trotzdem funktioniert das in DEM Fall ohne Probleme!
Also warum erkennt der Browser ohne weiters die 90% der Fensterbreite, aber nicht die 70% der Fensterhöhe?
weil "auto" für width und height unterschiedlich funktioniert. In der Breite heißt "auto" tatsächlich, dass das Element einschließlich seiner Abstände (margin, border, padding) die gesamte verfügbare Breite seines Elternelements bzw. im Fall des html-Elements die gesamte Fensterbreite einnehmen soll. In der Höhe orientiert sich "auto" aber am Platzbedarf des Elementinhalts.
Das ist auch sinnvoll, denn sonst wäre ja jeder Absatz, jede Überschrift, jede Liste so hoch wie das Browserfenster.
Das schöne an der Prozentangabe ist ja, dass man das Browserfenster skalieren kann und die Elemente sich dynamisch anpassen. So wie es mit 'width' auch problemlos funktioniert. Aber wenn ich bei der Höhe keine automatische Erkennung des Wertes habe, so dass es immer auf 'auto' steht, wie du sagtest, läuft dieses Feature natürlich leer.
Nein. Wie schon gesagt: Definiere für alle Vorfahrenelemente bis hinauf zum html-Element eine Höhe. Typisch ist etwa, dem body- und dem html-Element height:100% zu geben. Dann ist die Welt in Ordnung, weil sich eine Prozentangabe beim html-Element dann tatsächlich auf die Fenstergröße bezieht (was auch sonst, html hat ja kein Elternelement mehr).
So long,
Martin
Hi
Hi
weil "auto" für width und height unterschiedlich funktioniert. In der Breite heißt "auto" tatsächlich, dass das Element einschließlich seiner Abstände (margin, border, padding) die gesamte verfügbare Breite seines Elternelements bzw. im Fall des html-Elements die gesamte Fensterbreite einnehmen soll. In der Höhe orientiert sich "auto" aber am Platzbedarf des Elementinhalts.
Das ist auch sinnvoll, denn sonst wäre ja jeder Absatz, jede Überschrift, jede Liste so hoch wie das Browserfenster.
Leuchtet ein.
Nein. Wie schon gesagt: Definiere für alle Vorfahrenelemente bis hinauf zum html-Element eine Höhe. Typisch ist etwa, dem body- und dem html-Element height:100% zu geben. Dann ist die Welt in Ordnung, weil sich eine Prozentangabe beim html-Element dann tatsächlich auf die Fenstergröße bezieht (was auch sonst, html hat ja kein Elternelement mehr).
Dir auch nochmal danke für den Hinweis! ;)
Wobei noch anzumerken sei, dass mir dabei noch eine (eigentlich nicht) lustige Sache aufgefallen ist:
Wenn man für html/body '100%' angibt, erscheinen bei mir im Firefox Scrollbars...
... und mir ist auch schon bei anderer Gelegenheit aufgefallen, dass (zumindest im Firefox) immer dann, wenn man ein Element auf die ganze window.height/width skaliert, man immer noch ein margin: -8px 0 0 -8px; nachschieben muss, da das Element oben und links immer um ein paar Pixel eingerückt dargestellt wird.
:/
Gruß,
Roadster.
Hallo,
Wobei noch anzumerken sei, dass mir dabei noch eine (eigentlich nicht) lustige Sache aufgefallen ist:
Wenn man für html/body '100%' angibt, erscheinen bei mir im Firefox Scrollbars...
ist mir noch nicht aufgefallen, aber ich habe auch noch nicht darauf geachtet.
... und mir ist auch schon bei anderer Gelegenheit aufgefallen, dass (zumindest im Firefox) immer dann, wenn man ein Element auf die ganze window.height/width skaliert, man immer noch ein
margin: -8px 0 0 -8px;nachschieben muss, da das Element oben und links immer um ein paar Pixel eingerückt dargestellt wird.
Dann schau doch spaßeshalber mal nach, ob html und/oder body nicht per Browser-Default schon ein padding und/oder margin haben, das man eigentlich nur auf 0 setzen müsste. Das könnte dann auch die Scrollbalken erklären, die du nicht haben willst.
Ciao,
Martin
Hallo
Hallo
Dann schau doch spaßeshalber mal nach, ob html und/oder body nicht per Browser-Default schon ein padding und/oder margin haben, das man eigentlich nur auf 0 setzen müsste. Das könnte dann auch die Scrollbalken erklären, die du nicht haben willst.
So ist es natürlich. Die Liste der zu normalisierenden Elemente wird stets länger...
Frage mich echt, was die Leute reitet, so einen Quatsch zu implementieren. Wenn sowas Schule macht, können wir in ein paar Jahren jedes Stylesheet erstmal mit einer ewig langen Liste beginnen, in der wir jedes einzelne Element auf den eigentlichen Defaultwert zurücksetzen, bevor wir mit irgendwas anfangen...
Wirklich ein Ärgernis.
Gruß,
Roadster.
Om nah hoo pez nyeetz, Roadster!
So ist es natürlich. Die Liste der zu normalisierenden Elemente wird stets länger...
Das halte ich nicht für gut. Seiten müssen nicht in jedem Browser gleich aussehen und die Defaultstyles sind meist sinnvoll.
Beschränke dich beim Normalisieren auf Sachen, die Browser bekanntermaßen deutlich unterschiedlich machen. Lies: Spare dir die Normalisierung.
Wirklich ein Ärgernis.
Nein. box-sizing existiert. Sieh dies als Normalisierung.
Matthias
Om nah hoo pez nyeetz, Roadster!
Hallo Matthias!
Das halte ich nicht für gut. Seiten müssen nicht in jedem Browser gleich aussehen und die Defaultstyles sind meist sinnvoll.
Äh, naja, eigentlich bin ich schon der Ansicht, dass die Seiten nach Möglichkeit in jedem Ausgabemedium gleich aussehen sollten (zumal dieses in der Regel doch immer aus einem mehr oder minder großen Rechteck besteht ;) Man will schließlich akkurate Arbeit abliefern und keine groben Schätzungen. Ich denke, es sollte da schon verbindliche Vorgaben geben, an die sich alle Browserhersteller gleichermaßen halten.
Aber das ist natürlich nur meine unbedeutende Meinung... ;)
Gruß,
Roadster.
@@Roadster:
nuqneH
Äh, naja, eigentlich bin ich schon der Ansicht, dass die Seiten nach Möglichkeit in jedem Ausgabemedium gleich aussehen sollten
Qapla'
nuqneH
Hallo
Ok. In der ersten und hernach wieder verworfenen Version des Posts auf den du dich beziehst, hatte ich noch den Relativsatz eingebaut "..., abgesehen natürlich von der Unterscheidung zwischen Desktop- und Smartphonebrowsern..."
Dass eine Seite auf einem Smartphone idealerweise nicht so aussieht wie auf einem Desktop-PC würde ich als Selbstverständlichkeit ansehen, weshalb ich es schließlich auch für unnötig erachtet habe dies explizit zu erwähnen.
Aber mit welcher Begründung bitte soll eine Seite auf einem Desktop-Browser anders aussehen als auf einem anderen? Sagen wir auf einem IE anders als auf einem FF?
Sorry, aber das ist doch unsinnig! Die einzige sinnvolle Unterscheidung in der Darstellung auf der selben Geräteklasse die mir nachvollziehbar erscheint, ist wenn der User motorisch oder visuell beeinträchtigt ist und deswegen spezielle Programme / Plug-Ins für seinen Zugang verwendet. Aber gerade in diesem Fall erscheint es mir umso gebotener, einheitliche Vorgaben zu haben, um den Einsatz solcher Hilfsprogramme gegebenenfalls nicht noch zu erschweren!
Oder welche Gründe fallen dir noch ein, abgesehen von 'Desktop != Smartphone'?
Gruß,
Roadster.
@@Roadster:
nuqneH
Aber mit welcher Begründung bitte soll eine Seite auf einem Desktop-Browser anders aussehen als auf einem anderen? Sagen wir auf einem IE anders als auf einem FF?
Andersrum: Mit welcher Begründung bitte soll eine Seite auf einem Desktop-Browser gleich aussehen wie auf einem anderen?
Kein normaler Nutzer vergleicht das Aussehen einer Webseite in verschiedenen Browsern auf Gleichheit. Solange die Seite in seinem Browser gut aussieht und gut bedienbar ist, ist alles in Ordnung.
Es gibt keine gute Begründung, warum Webseiten in verschiedenen Browsern gleich aussehen sollten.
Aber es gibt tatsächlich eine gute Begründung, warum Webseiten in verschiedenen Browsern nicht gleich aussehen müssen. Jeremy Keith gibt sie in seinem Artikel Responsive Enhancement: Es wäre reine Zeitverschwendung.
“Instead of spending your time trying to make websites look the same in wildly varying browsers, you can spend your time making sure that the core functionality of what you’re building works everywhere, while providing the best possible experience for more capable browsers.”
Qapla'
nuqneH
Hallo.
Ich denke wir reden ein wenig aneinander vorbei.
Du bist längst desillusioniert und gehst (womöglich zurecht) von der Prämisse aus, dass die Browserhersteller ohnehin alle ihr eigenes Süppchen kochen und jedweder Versuch, einheitliche Standards für die Verwendung von Defaultstyles zu etablieren, ohnehin zum Scheitern verurteilt ist.
Ich hingegen bin noch naiv genug zu glauben, hier könnte ein einheitlicher (sinnvoller) Standard etabliert werden. ;)
Insofern sprach ich lediglich davon, was grundsätzlich wünschenswert wäre, aber die Unmöglichkeit dieses Ansinnens vorausgesetzt, kann ich mich deiner Einschätzung freilich nur anschließen.
Gruß,
Roadster.
Hallo
Du bist längst desillusioniert und gehst (womöglich zurecht) von der Prämisse aus, dass die Browserhersteller ohnehin alle ihr eigenes Süppchen kochen und jedweder Versuch, einheitliche Standards für die Verwendung von Defaultstyles zu etablieren, ohnehin zum Scheitern verurteilt ist.
unabhängig, ob dieses Ansinnen tatsächlich zum scheitern verurteilt ist, mach mal bitte aus „desillusioniert“ ein „realistisch“.
Ich hingegen bin noch naiv genug zu glauben, hier könnte ein einheitlicher (sinnvoller) Standard etabliert werden. ;)
Kannst du, Glaube versetzt ja angeblich Berge. Ich gehe aber davon aus, dass *das* nicht Gunnars Ansinnen war.
Gehe bitte davon aus, dass wir™ die Einzigen sind, die sich die von uns oder anderen erstellten Seiten mit allen möglichen Browsern anschauen und etwaige Unterschiede bemerken. Der normale™ Benutzer benutzt auf seinem heimrechner einen browser, auf dem Arbeitsrechner evtl. einen anderen und dann noch den einen auf dem Smartphone und/oder dem Tablet (typischerweise jeweils „dem einen“). Dieser nämliche Benutzer wird von etwaigen Unterschieden selten etwas mitbekommen. Am ehesten wird auffallen, wenn sich das Layout, durch Mediaqueries bestimmt, auf einem Gerät wegen Hoch- vs. Querformat ändert.
Auf der anderen Seite steht der Wunsch nach einem für jeden an jedem Gerät/Browser nachvollziehbaren Aussehen der eigenen Seite. Das Stichwort lautet „Corporate Identity“. Das heißt aber eben nicht, dass man sich deswegen an jedem Pixel aufhängen soll.
Ist die Schrift in einem bestimmten Browser in einem bestimmten Betriebssystem (ja, das kommt auch noch dazu!) einen Pixel höher? Who cares? Außer dir weiß das niemand!
Ist der Balken in einem Browser einen Pixel schmaler als in einem anderen? Who Cares? Außer dir weiß das niemand! Geschweige denn, dass die Welt davon unterginge.
Warum sollte man nun dafür seine Zeit verschwenden?
Stimmen die farben? Sieht die Seite in vergleichbaren Programmen bei vergleichbarer Auflösung weitgehend gleich aus? So, dass man sich als erneuter Besucher nicht fragt, ob man eventuell falsch gelandet ist? Ja? Dann ist's gut so.
Tschö, Auge
PS:
Nur so als Beispiel für echt 'sinnvolle' Defaultstyles: margin(-top) bei p-Elementen!
Was glaubst du, wie lange ich damals als komplettes Greenhorn gerätselt habe, warum meine Angaben zu line-height nicht den gewünschten Effekt gebracht haben? ;)
...und dann all die lustigen Experimente die ich veranstaltet habe, um meinen paragraph doch noch an die richtige Stelle zu bugsieren... :D
;)
Gruß,
Roadster.
Hallo Roadster,
height: calc( 100% - 230px ); /* ...oder jede beliebige Prozentangabe... */
wie die anderen schon schrieben, sind 100% hier die Höhe des umgebenden Elements, dessen Höhe, wenn nicht explizit gesetzt, vom Inhalt abhängt.
Ich würde hier mit "vh" arbeiten, das ist die prozentuale Höhe des Browserfensters:
height: calc( 100vh - 230px );
Und älteren Browsern (IE8?) bekommen als Fallback eine gut geratene feste Höhe, also
height:800px; height: calc( 100% - 230px );
So wird bei Browsern die calc oder vh nicht kennen, die zweite Angabe ignoriert, die anderen überschreiben mit der zweiten Angabe die erste.
Gruß, Jürgen
Hallo Roadster
Hallo Jürgen
Und ältere Browser (IE8?) bekommen als Fallback eine gut geratene feste Höhe, also
height:800px; height: calc( 100% - 230px );So wird bei Browsern die calc oder vh nicht kennen, die zweite Angabe ignoriert, die anderen überschreiben mit der zweiten Angabe die erste.
Danke für den Hinweis. Ist echt nicht einfach, bei allen verwendeten Eigenschaften und Methoden den Überblick zu behalten, wann und wo sie implementiert wurden. Bin immer wieder erstaunt, wenn ich lese wie verbreitet prähistorische Browser- und OS-Versionen auch heute noch sind. ;)
Gruß,
Roadster.
Hallo miteinander!
Habe ich mich doch schon so gefreut, dass die hier empfohlene Lösung so tadellos funktioniert, aber dabei ganz übersehen, dass ich hier ja noch mit einem <canvas> Element zu tun habe, dass nach einer direkten Angabe für height und width in Form einer reinen Zahl verlangt!
Wenn ich die width & height des Elternelementes in Prozent berechne, wie soll ich das dann in px oder direkt in eine Zahl umrechnen, um den entsprechenden Wert des CANVAS daran zu knüpfen?
Gibt es eine Methode, beim Auslesen des Wertes für height/width zu bestimmen, in welcher Einheit dieser dargestellt werden soll???
:/
Gruß,
Roadster.
Ahoi.
Ok, ich glaube mein Vorhaben, das <canvas id = "scene"> so wie die anderen Elemente frei zu skalieren ist ohnehin zwecklos. ;)
Gegeben gl = webGLContextObject und gl.viewportWidth = scene.width; sowie gl.viewportHeight = scene.height; lege ich fest gl.viewport( 0, 0, gl.viewportWidth, gl.viewportHeight ); wenn ich die drawScene( ); Funktion für das <canvas> aufrufe...
Sofern ich den renderingContext nicht über setInterval( ); oder requestAnimationFrame( ); stetig neu beschreiben will (was kompletter Unsinn wäre), ist die Darstellung also eh an eine feste Höhe und Breite gebunden.
Denke, am sinnvollsten wäre es daher, einen angemessenen Defaultwert zu nehmen und dann für x- und y-Achse range-slider einzubauen, um die Szene bei Bedarf manuell zu skalieren.
Alternativ könnte man wohl höchstens über window.innerWidth und window.innerHeight 'ne zweite Schiene aufmachen, die Höhe und Breite des parentElement <main> berechnen und dann die drawScene( ); Funktion über eine while-Schleife aufrufen, wenn sich der entsprechende Wert verändert, i.e. wenn das Browserfenster skaliert wird.
Mmmmhh... naja, mal sehen. ;)
Gruß,
Roadster.
Ahoi. ;)
Also, nur für's Archiv und den Fall, dass jemand vor der gleichen Problemstellung steht, und zwar ein <canvas> Element, dass als Wert für width und height keine Prozentangaben sondern nur Angaben in px als absolute Zahl annimmt, trotzdem relativ zum Browserfenster frei skalieren zu können:
Hierzu muss man zunächst mit...
var innerWidth = window.innerWidth ||
document.documentElement.clientWidth ||
document.body.clientWidth;
var innerHeight = window.innerHeight ||
document.documentElement.clientHeight ||
document.body.clientHeight;
...äquivalente Werte zu...
html {
width: 100%;
height: 100%;
}
body {
width: 100%;
height: 100%;
}
...in px als absolute Zahl in einer Variablen speichern und diese Werte dann für eine beliebige window.size [ n ] an die anderen (aufgrund prozentualer Breiten- und Höhenangaben) frei skalierbaren Elemente anpassen, so dass das <canvas> relativ zu diesen die richtige Größe hat, was recht einfach zu bewerkstelligen ist, indem man einfach step by step die Höhen- und Breitenangaben der parentElements nachvollzieht, z.B.:
innerWidth == html/body
parent_1 = 90% von html/body ---> p1width == calc(( innerWidth / 100 ) * 90 )
parent_2 = calc( 70% + 12px ) ---> p2width == calc(( p1width / 100 ) * 70 ) + 12 usw...
canvasWidth == p2width - 10; ...plus ein wenig Feinjustierung. ;)
Alles was man dann noch tun muss, ist einen Event-Listener zu schalten...
window.addEventListener( 'resize', function ( ) {
/* ...in dessen Zielfunktion die Variablen der Werte für canvas.width und canvas.height
aktualisiert (oder neu angelegt) werden... */
/* ...und dann die entsprechende DRAW_Funktion für das canvas neu aufgerufen wird... */
});
...and that's it!
Eigentlich easy, aber wer kennt schon das Event resize ? ;)
Gruß,
Roadster.