nicht angemeldet
Browserweiche mit PHP? Wie?
Hi,
mit dem HTTP_REQUEST kann man doch eine Browserweiche machen oder? Wie genau mache ich denn das? Und wie zuverlässig ist die?
JavaScript ist für mich keine alternative, darauf möcht ich komplett verzichten.
Grüsse
Malte
-
hi
mit dem HTTP_REQUEST kann man doch eine Browserweiche machen oder? Wie genau mache ich denn das? Und wie zuverlässig ist die?
die ist genauso zuverlässig wie der HTTP_USER_AGENT, nämlich _garnicht_
man kann das versuchen, aber es geht IMO _nicht_ und ist absolut nicht zu empfehlen.JavaScript ist für mich keine alternative, darauf möcht ich komplett verzichten.
immerhin.
Grüsse
MalteFabian
-
Hi Malte,
mit dem HTTP_REQUEST kann man doch eine Browserweiche machen oder? Wie genau mache ich denn das? Und wie zuverlässig ist die?
Der String kann gefiltert und manipuliert werden.
JavaScript ist für mich keine alternative, darauf möcht ich komplett verzichten.
Das ist gut.
Aber wozu brauchst du eine Weiche? Es gibt nämlich auch zuverlässige Methoden.
LG Orlando
-
Hallo,
mit dem HTTP_REQUEST kann man doch eine Browserweiche machen oder? Wie genau mache ich denn das? Und wie zuverlässig ist die?
vorausgesetzt die Browserangaben sind bekannt und eindeutig,
was passiert schlimmstenfalls wenn jemand seinen Browser falsch
ausgibt, und wie oft mag so etwas vorkommen?
Daraus ergibt sich m.E. eine ausreichende bis hohe
Zuverlässigkeit, auch wenn die Idee einer Weiche erstmal nicht so
begeistert, aber schliesslich sind die ganzen CSS-Konstrukte
um IE5 bis Mozilla zu bedienen auch nicht so toll.JavaScript ist für mich keine alternative, darauf möcht ich komplett verzichten.
Eine Ausnahme kann eine CSS Korrektur für Netscape4 sein, da lässt
sich eine Weiche per PHP noch mit if(document.layers) kombinieren,
falls zu befürchten wäre dass auch andere Browser durchrutschen.
if(substr_count($HTTP_USER_AGENT,'Mozilla/4')>0)Grüsse
Cyx23
-
Hallo,
if(substr_count($HTTP_USER_AGENT,'Mozilla/4')>0)
Darunter fallen auch die IEs 4,5,6 und andere Browser-UAs ...
Ich habe mal eine Server-seitige Abfrage fuer eine Vote-Anwendung mit farbigen DIVs als %-Balken verwendet, wobei der Netscape 4.x eine Sonderbehandlung mit layer-background-color und clip: rect(...) bekam, weil sonst bekanntlich nicht viel zu sehen ist:
$ua=$HTTP_SERVER_VARS["HTTP_USER_AGENT"];
if(substr($ua,0,9)=="Mozilla/4" && strpos($ua,"MSIE")=="" && strpos($ua,"Opera")=="" && strpos($ua,"Konqueror")=="")
{
// Ausgabe fuer Netscape 4.x
}
else
{
// Ausgabe fuer andere Browser
}Wenn es nur um statisches CSS geht, sind Techniken wie @import sinnvoller.
MfG, Thomas
-
Hi Thomas,
if(substr_count($HTTP_USER_AGENT,'Mozilla/4')>0)
Darunter fallen auch die IEs 4,5,6 und andere Browser-UAs ...
deswegen hat Cyx23 ja auch if(document.layers) in's Spiel gebracht, weil es garantiert nur N4 trifft. Dass Javascript im Spiel ist, ist kein Problem - ohne gibt's ohnehin kein CSS, wie du weißt ;)
CSS serverseitig zu verteilen, ist IMHO ohnehin unsinnig...
LG Orlando
-
Hallo,
deswegen hat Cyx23 ja auch if(document.layers) in's Spiel gebracht, weil es garantiert nur N4 trifft. Dass Javascript im Spiel ist, ist kein Problem - ohne gibt's ohnehin kein CSS, wie du weißt ;)
CSS serverseitig zu verteilen, ist IMHO ohnehin unsinnig...
Nicht in dem von mir genannten Fall. Ich finde es durchaus praktikabel und akzeptabel, ein DIV zur Anzeige eines farbigen Balkens zu verwenden und dazu per vorheriger Berechnung die Breite via Inline-Style zuzuweisen, also etwa width auf den Wert $anteil/$gesamt*$maximale_breite zu setzen.
Mit per JS dynamisch generierten "Layern" unter Netscape 4.x zu operieren ist auch keine Freude, wie Du weißt ;-).
Die genannte Methode schickt sehr präzise alle IEs, Operas, Mozillas, Konquerors und sonstige Browser in den else-Zweig, sofern keine UA-Fakes vorliegen, die einen Netscape 4.x vortaeuschen und selbst dann ist das in meinem Beispiel kein Problem, weil layer-background-color ignoriert wird und der Rest gueltiges CSS ist.
Gefakte Netscape 4.x-Versionen bekommen vielleicht unverdauliches "Standard-CSS", aber das ist ja dann das ganz normale NN 4.x-Problem ...
MfG, Thomas
-
-
Hallo Thomas,
$ua=$HTTP_SERVER_VARS["HTTP_USER_AGENT"];
if(substr($ua,0,9)=="Mozilla/4" && strpos($ua,"MSIE")=="" && strpos($ua,"Opera")=="" && strpos($ua,"Konqueror")=="")da ist bei "Gecko" wohl "Mozilla/5" verlässlich genug sodass
der nicht nochmal abgefragt werden muss.Wenn es nur um statisches CSS geht, sind Techniken wie @import sinnvoller.
Es hat eigentlich Vorteile wenn die Netscape4 Workarounds klar
erkennbar sind, ist dann bei getrennten Blöcken aber oft nicht
mehr so übersichtlich.
Nur wenn man dann noch layer-background-color nicht immer drinnen
haben möchte (dann kann man die "normalen" CSS-Varianten noch
w3c validieren, für die ganz Peniblen) wird es auch mit der
CSS-weiche @import schwierig.Grüsse
Cyx23
-
Hallo,
$ua=$HTTP_SERVER_VARS["HTTP_USER_AGENT"];
if(substr($ua,0,9)=="Mozilla/4" && strpos($ua,"MSIE")=="" && strpos($ua,"Opera")=="" && strpos($ua,"Konqueror")=="")da ist bei "Gecko" wohl "Mozilla/5" verlässlich genug sodass
der nicht nochmal abgefragt werden muss.Kennungen mit "Mozilla/5" landen doch automatisch im else-Zweig.
Nur wenn man dann noch layer-background-color nicht immer drinnen
haben möchte (dann kann man die "normalen" CSS-Varianten noch
w3c validieren, für die ganz Peniblen) wird es auch mit der
CSS-weiche @import schwierig.In meinem Beispiel kommt layer-background-color praktisch nur bei NN 4.x-Browsern an.
MfG, Thomas
-
Hallo Thomas,
da ist bei "Gecko" wohl "Mozilla/5" verlässlich genug sodass
der nicht nochmal abgefragt werden muss.Kennungen mit "Mozilla/5" landen doch automatisch im else-Zweig.
eben.
Nur wenn man dann noch layer-background-color nicht immer drinnen
haben möchte (dann kann man die "normalen" CSS-Varianten noch
w3c validieren, für die ganz Peniblen) wird es auch mit der
CSS-weiche @import schwierig.In meinem Beispiel kommt layer-background-color praktisch nur bei NN 4.x-Browsern an.
Genau, so soll es ja hier auch sein (z.B. für die ganz Peniblen usw.),
aber du hattest gepostet "Wenn es nur um statisches CSS geht, sind
Techniken wie @import sinnvoller.".
'layer-backgroundcolor' ist doch erstmal statisch, zumindest stört es
andere Browser eigentlich nicht, z.Zt. höchstens das w3c?
Mit JavaScript kann über beispielsweise innerWidth CSS auch dynamisch
angepasst werden, flexible Anpassung von Objektabmessungen usw., kommt
mir jedenfals erstmal dynamischer vor als 'layer-backgroundcolor'.
Hier ist aber auch für eher statisches CSS nicht ' @import ', sondern
eine php-weiche benutzt worden, um 'layer-background-color' (doch
dynamisch?) vor anderen Browsern zu verstecken.Immerhin gibt es einige sinnvolle Möglichkeiten besonders bei
Netscape 4 noch etwas mehr anzupassen.
Für JavaScript geht z.B. <script type="text/javascript">,
oder ggf. nur <script> oder <script language...>, wobei
letzteres immerhin nach offizieller Syntax für den Netscape
richtig wäre, und die Variante <script> für NC4 m.E. noch besser
läuft. 'konform' ist inzwischen nur noch die erste Schreibweise,
zumindest solange NC4 berücksichtigt wird ist das wieder ein Argument
mehr für Differenzierungen per php-Browserweiche o.ä., damit
Netscape 4 ggf. nur <script> erhält, was denn auch per JavaScript
nur umständlich realisierbar wäre...Grüsse
Cyx23
-
Hallo,
'layer-backgroundcolor' ist doch erstmal statisch, zumindest stört es
andere Browser eigentlich nicht, z.Zt. höchstens das w3c?Nein, in dem genannten Vote-Beispiel sind die Farben dynamisch, also wird auch je nach Vorwahl layer-background-color mit einem Wert Server-seitig versehen.
MfG, Thomas
-
-
-
-
-
-
Hallo Malte,
mit dem HTTP_REQUEST kann man doch eine Browserweiche machen
oder? Wie genau mache ich denn das? Und wie zuverlässig ist die?JavaScript ist für mich keine alternative, darauf möcht ich
komplett verzichten.Wenn du dich mit den bereits eingebrachten einwaenden abfinden
kannst, hab ich einen Link fuer dich.
Die PHP Site phpbuilder setzt eine Browserweiche ein, und hat diese
in einem Artikel erklaert.
http://phpbuilder.com/columns/tim20000821.php3gruesse aus'm RuhrPott
jens mueller-
Moin!
Wenn du dich mit den bereits eingebrachten einwaenden abfinden
kannst, hab ich einen Link fuer dich.
Die PHP Site phpbuilder setzt eine Browserweiche ein, und hat diese
in einem Artikel erklaert.
http://phpbuilder.com/columns/tim20000821.php3Der Artikel ist über zwei Jahre alt! Das bedeutet: Seit dem haben sich die verfügbaren Browser wesentlich weiterentwickelt. Insbesondere die auf der ersten Seite aufgestellten Behauptungen sind entweder mittlerweile unzutreffend (Skalierungsmöglichkeiten in Browsern existieren heute), oder es existieren simple Abhilfen (nicht pt verwenden, sondern px - dann klappts auch mit dem Mac).
Die Font-Größen mit relativen Angaben (medium, small, x-small etc.) sind auch sehr zweifelhaft. Da ist man leider ziemlich den Browsern ausgeliefert, weil sich die CSS-Spezifikation für die Schriftgrößenunterschiede zwischen den einzelnen Stufen zwischen CSS1 und CSS2 geändert hat.
Und natürlich wiegt das grundsätzliche Problem schwer: Man liefert auf diese Weise nur basierend auf einer Textangabe, die beliebig fälschbar ist, für die Darstellung entscheidende Informationen aus. Es ist in meinen Augen viel sinnvoller, den Browser selbst entscheiden zu lassen, welche Informationen er (aufgrund der eigenen Unfähigkeit) akzeptiert. Die typischen CSS-Browserweichen sind dafür ideal.
- Sven Rautenberg
-
Hallo Sven,
... welche Informationen er (aufgrund der eigenen Unfähigkeit) akzeptiert. Die typischen CSS-Browserweichen sind dafür ideal.
nein, vor Allem es ist prinzipiell nicht zukunftsicher, es werden
doch isoliert Fähigkeiten abgefragt um ganz andere Eigenheiten zu
korrigieren, also ein totales Chaos.
Die Fähigkeit ein div per div[id] nicht zuordnen zu können wird mit
Verhaltensweisen wie der Nichtumsetzung von body{width:100%} korreliert,
da kann man doch gleich Kuchen backen und ans w3c schicken.Grüsse
Cyx23
-
Moin!
... welche Informationen er (aufgrund der eigenen Unfähigkeit) akzeptiert. Die typischen CSS-Browserweichen sind dafür ideal.
nein, vor Allem es ist prinzipiell nicht zukunftsicher, es werden
doch isoliert Fähigkeiten abgefragt um ganz andere Eigenheiten zu
korrigieren, also ein totales Chaos.Glaubst du, die serverseitige Abfrage des User-Agent ist besser? Sorry, aber da können so viele Enflüsse das Ergebnis versauen, dass es nicht mal _gegenwartssicher_ ist.
Abgesehen davon: Die Browserweiche, mit @import für alle anderen Browser außer Netscape 4 vernünftige und komplexere Stylesheets zu laden, funktioniert bestens und ist sowas von zukunftssicher - Netscape 4 wird @import garantiert niemals verstehen. Das ist also sicher.
Bei den anderen CSS-Hacks bin ich auch etwas kritisch. Insbesondere der Hack, um dem IE korrekte Breitenrechnung beizubringen, ist schrecklichst! Den wende ich nicht an - wenn es sich nicht ändern läßt, verschachtele ich lieber zwei DIVs, die die gewünschte Darstellung auf standardgemäße Weise hervorbringen.
Die Fähigkeit ein div per div[id] nicht zuordnen zu können wird mit
Verhaltensweisen wie der Nichtumsetzung von body{width:100%} korreliert,
da kann man doch gleich Kuchen backen und ans w3c schicken.Das ist solch ein Workaround, den ich kritisch sehe. Den braucht man nicht wirklich. Wenn man etwas Arbeit in die Entwicklung eines ordentlichen Stylesheets in Kombination mit einer ordentlichen HTML-Datei steckt, so dass das Ergebnis in allen Browsern gleich angezeigt wird (insbesondere Mozillas neueste Version und IE 5.0 als Vertreter extremer Gegensätze unter dem @import-Himmel), dann muß man die Seite niemals mehr anfassen.
Jede Unterscheidungstechnik basierend auf User-Agent-Angaben erfordert, dass man ständig am Ball bleibt und alle neuen Browserversionen hinzufügt, damit sie immer noch korrekt erkannt werden - insbesondere kommt höchstwahrscheinlich Arbeit hinzu, wenn der Internet Explorer immer standardkonformer wird und diverse Bugs rausfliegen. Sowas könnte man mit browserunabhängigem HTML+CSS vermeiden.
- Sven Rautenberg
-
Hi Sven,
Bei den anderen CSS-Hacks bin ich auch etwas kritisch. Insbesondere der Hack, um dem IE korrekte Breitenrechnung beizubringen, ist schrecklichst! Den wende ich nicht an - wenn es sich nicht ändern läßt, verschachtele ich lieber zwei DIVs, die die gewünschte Darstellung auf standardgemäße Weise hervorbringen.
das sehe ich etwas anders. Der M$IE6 hat den Box-Model-Bug nicht mehr (mit Doctype, ohne XML-Deklaration) und rechnet somit auch die Breite richtig. Wenn sich M$ schon bemühen sollte, ihm endlich mal vernünftig Selektoren beizubringen, wird es mit position:fixed und ähnlichen Dingen auch keine Probleme mehr geben. Sollte dies dennoch der Fall sein, man weiß ja nie, bleiben als Notlösung immer noch conditional comments. Und so viel Zeit nimmt so ein Umbau ja auch nicht in Anspruch.
Wenn man etwas Arbeit in die Entwicklung eines ordentlichen Stylesheets in Kombination mit einer ordentlichen HTML-Datei steckt, so dass das Ergebnis in allen Browsern gleich angezeigt wird (insbesondere Mozillas neueste Version und IE 5.0 als Vertreter extremer Gegensätze unter dem @import-Himmel), dann muß man die Seite niemals mehr anfassen.
FULL ACK. Selbst mit dem Box-Model-Bug hat man keine Probleme, wenn man die Seiten nicht bis auf's letzte Pixel ausreizt.
Jede Unterscheidungstechnik basierend auf User-Agent-Angaben erfordert, dass man ständig am Ball bleibt und alle neuen Browserversionen hinzufügt, damit sie immer noch korrekt erkannt werden - insbesondere kommt höchstwahrscheinlich Arbeit hinzu, wenn der Internet Explorer immer standardkonformer wird und diverse Bugs rausfliegen.
Je weniger Bugs er hat, desto besser kann er auch mit Selektoren und den Gründen, die diese erfordern umgehen. IMHO.
LG Orlando
-
Hallo Sven,
Abgesehen davon: Die Browserweiche, mit @import für alle anderen Browser außer Netscape 4 vernünftige und komplexere Stylesheets zu laden, funktioniert bestens und ist sowas von zukunftssicher - Netscape 4 wird @import garantiert niemals verstehen. Das ist also sicher.
wenn du einen Rausschmeisser brauchst, ist das die komfortabelste
Lösung. Eindeutig ist auch document.layers, und die php-weiche ist
besonders für NC4 sinnvoll um z.B. weniger valide Sachen
wie ein knappes <script> anderen Browsern gar nicht erst anzubieten.
CSS für Netscape4 ist oft besser realisierbar als z.B. hier im
Forum immer wieder behauptet wird, und es wird mit "ordentlichen
Stylesheets in Kombination mit einer ordentlichen HTML-Datei" noch
einfacher oder ist zumindest da nicht kontraproduktiv....- wenn es sich nicht ändern läßt, verschachtele ich lieber zwei DIVs, die die gewünschte Darstellung auf standardgemäße Weise hervorbringen.
»»...
Wenn man etwas Arbeit in die Entwicklung eines ordentlichen Stylesheets in Kombination mit einer ordentlichen HTML-Datei steckt, so dass das Ergebnis in allen Browsern gleich angezeigt wird (insbesondere Mozillas neueste Version und IE 5.0 als Vertreter extremer Gegensätze unter dem @import-Himmel), dann muß man die Seite niemals mehr anfassen.
... Sowas könnte man mit browserunabhängigem HTML+CSS vermeiden.Ich vermute dass der Doctype <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML
4.01 Transitional//EN"> am ehesten Voraussetzungen schafft, beim IE5
ähnliche Ergebnisse zu erzielen wie beim IE6, immerhin wird IE5 wohl
von rund 40% benutzt.Mir ist allerdings noch nicht klar, ob dann "für den Mozilla" alle
Grössen, margin usw. per verschachtelter divs realisiert werden
müssten oder könnten.
Auch für den body kann es schwierig werden, da benötige ich z.B. ein
grosses div für die ganze Seite um halbwegs einen body mit 100%
width/height zu simulieren, sehr lästig, und habe da auch eine
Unterscheidung für Mozilla reinschreiben müssen, wenn ich es
recht erinnere braucht es einmal {height:auto;} dann :100%}, und
beim Mozilla klappt es trotzdem noch nicht wie gewünscht.
Warum werden Angaben für, oder bezogen auf, den body nicht befolgt
wenn der body grösser ist als das Window, obwohl die ganze Seite
z.B. die Farben umsetzt? Sichtbarer Overflow ist es doch auch nicht?
Offenbar kann man mit CSS a la Mozilla 1.1 weder rechts noch unten
platzieren, obwohl doch body und nicht window Elternelement ist.
Das von dir erwähnte "browserunabhängige HTML+CSS" erfordert
entweder noch mehr Tricks - fällt dir da noch etwas ein um auch bei
Scrollbalken per absoluter Positionierung möglichst einfach
sowohl rechts als auch unten hinzukommen, idealerweise sogar ohne
Unterscheidungen wie #xy[id]{width:100%;}#xy{height:auto;}?
Oder kann mit CSS nicht rechts oder unten platziert werden, müssten
also letztendlich Tabellen oder spacer.gif verwendet werden?Grüsse
Cyx23
-
Moin!
Abgesehen davon: Die Browserweiche, mit @import für alle anderen Browser außer Netscape 4 vernünftige und komplexere Stylesheets zu laden, funktioniert bestens und ist sowas von zukunftssicher - Netscape 4 wird @import garantiert niemals verstehen. Das ist also sicher.
wenn du einen Rausschmeisser brauchst, ist das die komfortabelste
Lösung. Eindeutig ist auch document.layers, und die php-weiche ist
besonders für NC4 sinnvoll um z.B. weniger valide Sachen
wie ein knappes <script> anderen Browsern gar nicht erst anzubieten.Eine PHP-gesteuerte Browserweiche kann aber wunderbar versagen!
Alle Netscape 4 kennen kein @import - damit kriegt man _ganz sicher_ alle Netscape 4 aussortiert und gibt ihnen nur ein eingeschränktes, ggf. auch mit Netscape-Spezifika erweitertes CSS-Stylesheet. Wer es ganz besonder gut meinen will, der läßt in das <link>-CSS nur standardkonforme CSS-Angaben rein und regelt den Rest (layer-background-* etc) mit JSSS - also <style type="text/javascript">. Das ist dann nämlich auch valide, und trennt Netscape 4 von den restlichen Browsern auch 100% - vielleicht sogar noch besser, weil sich ja auch andere Browserhersteller überlegen könnten, @import nicht zu implementieren.
In Javascript kriegt man den Netscape 4 auch zu 100% korrekt mit document.layers erkannt. Das sollte man daher für irgendwelche DHTML-Layer-Geschichten auch nehmen.
Aber PHP kann sich ja nur auf irgendeine Information verlassen, die der Browser gleich beim ersten Seitenabruf sendet - Javascript kann da noch nicht wirksam geworden sein, um z.B. das Vorhandensein von document.layers zurückzumelden, es sei denn, man läßt vor jeder Seite eine Vor-Seite aufrufen, die prüft, welcher Browser denn vorliegt - ziemlich aufwendig und nervig für den Besucher.
Ach ja: Zum Validieren wird ja gerne der Valligator benutzt - der meldet sich auf der Site z.B. als "W3C_Validator/1.183 libwww-perl/5.64". Google sucht als "Googlebot/2.1 (+http://www.googlebot.com/bot.html)". Und es gibt darüber hinaus noch viele weitere User-Agents, die sinnvoll behandelt werden sollten. Die Versuchung liegt nahe, diesen Netzteilnehmern genau wie dem Netscape 4 speziell angepaßte Seiten anzubieten. Gerade für Suchmaschinen könnte es sich ja vielleicht lohnen - ich bin sicher, dass das auch gemacht wird. Spannende Frage ist: Was passiert, wenn der Spider die Seiten alle _zweimal_ abfragt, einmal offiziell als Bot, einmal als getarnter Browser - und sie dann nicht übereinstimmen? Ich bin mir sicher, dass auch das gemacht wird.
CSS für Netscape4 ist oft besser realisierbar als z.B. hier im
Forum immer wieder behauptet wird, und es wird mit "ordentlichen
Stylesheets in Kombination mit einer ordentlichen HTML-Datei" noch
einfacher oder ist zumindest da nicht kontraproduktiv.Mein Reden: Mit ordentlicher Arbeit spart man sich die fehlerträchtige Browserunterscheidung. Denn wie weit soll die gehen? Will man wirklich gegen _alle_ Browserbugs ein Mittelchen ausliefern - dann hat man mindestens genausoviel zu tun, wie man Zeit aufwenden müßte, um z.B. ein gemeinsames Stylesheet für alle Browser zu erstellen.
Ich vermute dass der Doctype <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML
4.01 Transitional//EN"> am ehesten Voraussetzungen schafft, beim IE5
ähnliche Ergebnisse zu erzielen wie beim IE6, immerhin wird IE5 wohl
von rund 40% benutzt.Nein, der IE5 hat den width-Bug - dagegen kann man nichts tun. Abgesehen davon ist noch die URL-Angabe im DOCTYPE erforderlich, damit sich der IE6 wie ein Mozilla verhält - naja, jedenfalls "fast". :->
Mir ist allerdings noch nicht klar, ob dann "für den Mozilla" alle
Grössen, margin usw. per verschachtelter divs realisiert werden
müssten oder könnten.Doch, das klappt:
#aussen { width:100px; }
#innen { border:3px solid black; padding:10px; }<div id="aussen"><div id="innen">Der Inhalt</div></div>
Mit diesem Trick wird das äußere DIV in jedem Browser 100 Pixel breit (border und padding sind nicht gesetzt), und das innere DIV wird so breit, wie Platz ist (eben 100px), wobei 3 Pixel Border und 10 Pixel padding eingefügt werden. Der IE-width-Bug tritt nicht auf, weil dort, wo width gesetzt wird, keine border und padding auftreten (die beim IE fälschlich als Bestandteil von width gerechnet werden, aber normalerweise _zusätzlich_ auf die Breite draufgerechnet werden).
Auch für den body kann es schwierig werden, da benötige ich z.B. ein
grosses div für die ganze Seite um halbwegs einen body mit 100%
width/height zu simulieren, sehr lästig, und habe da auch eine
Unterscheidung für Mozilla reinschreiben müssen, wenn ich es
recht erinnere braucht es einmal {height:auto;} dann :100%}, und
beim Mozilla klappt es trotzdem noch nicht wie gewünscht.Das Problem habe ich einfach deshalb nicht, weil ich akzeptiere, dass eine Seite oben links im Fenster beginnt und nach unten soweit reicht, wie Inhalt da ist. Alles andere ist Unsinn, wenn man dynamisch anpassbare Seiten schreibt. Zentrieren horizontal _und_ vertikal kommt nicht vor.
Das von dir erwähnte "browserunabhängige HTML+CSS" erfordert
entweder noch mehr Tricks - fällt dir da noch etwas ein um auch bei
Scrollbalken per absoluter Positionierung möglichst einfach
sowohl rechts als auch unten hinzukommen, idealerweise sogar ohne
Unterscheidungen wie #xy[id]{width:100%;}#xy{height:auto;}?Ähm, du meinst right und bottom? Funktioniert relativ gut in den besseren Browsern (zumindest right), versagt aber beim Netscape 4. Dem kann man leider dann kein dynamisch angepaßtes Layout verpassen, sondern muß die Breiten statisch festlegen und mit left positionieren.
Oder kann mit CSS nicht rechts oder unten platziert werden, müssten
also letztendlich Tabellen oder spacer.gif verwendet werden?Du willst position:fixed haben, weißt es nur noch nicht. Diese Positionierungsart bezieht sich nicht auf die Seite, sondern aufs Browserfenster. Damit könnte man relativ simpel feststehende Rahmen etc. erzeugen. Leider leider leider ist der IE noch zu doof dazu. Deshalb warte ich mit solcherart Layouts immer noch ab - und für den professionellen Einsatz auf Kundensites ist die Wartefrist vermutlich noch länger, weil erstmal alle alten IEs "absterben" müssen.
- Sven Rautenberg
-
Hallo nochmal,
... Das ist dann nämlich auch valide
dann wäre u.U. noch das beliebte <body marginwidth= ..>, das nicht
nicht durch CSS oder JavaScript ersetzt werden kann, zumindest nicht
für NC4 und rechten Rand; aber gut, wenn sonst alles stabil läuft,
ist es halt etwas weniger valide oder als saubere Lösung bleibt ein
grösserer Rand sichtbar.Nein, der IE5 hat den width-Bug - dagegen kann man nichts tun. Abgesehen davon ist noch die URL-Angabe im DOCTYPE erforderlich, damit sich der IE6 wie ein Mozilla verhält - naja, jedenfalls "fast". :->
Also mit 4.01 Transitional//EN"> ohne URL kommen doch IE6 und Moz1.1
gleichermassen in den "BackCompat"-modus? Und dann sollten doch
eigentlich IE5,5.5,6 untereinander am ähnlichsten sein?
Da muss ich wohl den IE5 installieren und mir das nochmals genauer
anschauen..Doch, das klappt:
#aussen { width:100px; }
#innen { border:3px solid black; padding:10px; }
<div id="aussen"><div id="innen">Der Inhalt</div></div>
Mit diesem Trick wird das äußere DIV in jedem Browser 100 Pixel breit (border und padding sind nicht gesetzt), und das innere DIV wird so breit, wie Platz ist (eben 100px), wobei 3 Pixel Border und 10 Pixel padding eingefügt werden. Der IE-width-Bug tritt nicht auf, weil dort, wo width gesetzt wird, keine border und padding auftreten (die beim IE fälschlich als Bestandteil von width gerechnet werden, aber normalerweise _zusätzlich_ auf die Breite draufgerechnet werden).Sieht als Lösung stimmiger aus als die CSS-Weichen.
Das Problem habe ich einfach deshalb nicht, weil ich akzeptiere, dass eine Seite oben links im Fenster beginnt und nach unten soweit reicht, wie Inhalt da ist. Alles andere ist Unsinn, wenn man dynamisch anpassbare Seiten schreibt. Zentrieren horizontal _und_ vertikal kommt nicht vor.
Bei vielen kürzeren Seiten mit gleichem Layout macht es schonmal
Sinn dass die Seiten gleich lang sind und unten noch etwas steht,
sind wir ja auch vom Printbereich gewohnt. Da kann es auch passen
wenn eine Abbildung oder ein Logo oder was auch immer in der Mitte
peppt oder unten rechts von der Seite.
Ausserdem sollte sowas generell mit einem Layoutwerkzeug möglich
sein.Ähm, du meinst right und bottom? Funktioniert relativ gut in den besseren Browsern ...
Bei IE6 gehts noch halbwegs, bei Mozilla lande ich mit right und
bottom in der Ecke vom window, ich will aber an die Seitenecke.Du willst position:fixed haben, weißt es nur noch nicht. Diese Positionierungsart bezieht sich nicht auf die Seite, sondern aufs Browserfenster.
Genau umgekehrt, da klappt es eben nicht so einfach:
<html><head><style>
body{margin:0;padding:0;
width:100%;height:100%}
#rbot{position:absolute;
bottom:0px;right:0px;
width:150px;height:80px;
margin:0;padding:0;background-color:#cccccc; }
</style></head>
<body>
<img src=xgif width=1800 height=1300>
<div id=rbot>rb</div>
</body></html>..und die Lösungsmöglichkeiten mit einem zusätzlich
div scheinen für IE6 und Moz1.1 unterschiedlich
auszufallen.Grüsse
Cyx23
-
-
-
-
-
-