nicht angemeldet
Browser-Identifikation auch bei Opera - ABER WIE ???
Bitte um Hilfe:
Mit navigator.appName läßt sich der Browser des Besuchers auslesen. Allerdings macht der Opera da ja nicht mit, da der Opera-Nutzer selbst angibt, als welcher Browser der Opera sich ausgibt.
Wie also programmiere ich die Browser-Identifikation.
Der Idee nach sollte es etwa so aussehen:
<script type="text/javascript">
<!--
if (navigator.userAgent == /.pera/);
document.write("Opera");
else document.write(navigator.appName);
//-->
</script>
Wie gesagt: der Idee nach. Wie aber mache ich es richtig???
Weiß jemand Rat?
Danke für Hilfe!
-
Hallo,
Mit navigator.appName läßt sich der Browser des Besuchers auslesen. Allerdings macht der Opera da ja nicht mit, da der Opera-Nutzer selbst angibt, als welcher Browser der Opera sich ausgibt.
if(window.opera || navigator.userAgent.indexOf("Opera")!=-1)
{
// Code fuer Opera
}MfG, Thomas
-
Aloha!
Mit navigator.appName läßt sich der Browser des Besuchers auslesen. Allerdings macht der Opera da ja nicht mit, da der Opera-Nutzer selbst angibt, als welcher Browser der Opera sich ausgibt.
Erstmal: Wozu muss der Browser identifiziert werden? Es ist in 90% der Fälle nicht sinnvoll, die Angabe "User-Agent" auszuwerten, denn die hat viel zuviele Varianten, die gar nicht alle abzudecken sind.
Was Sinn macht, ist die Auswertung, ob der Browser document.getElementById (alle neuen), document.all (IE4) oder document.layers (NS4) kennt - sofern man diese Methoden in seinem Skript verwenden will.
Für statistische Zwecke ist die User-Agent-Angabe vielleicht sinnvoll auszuwerten.
if(window.opera || navigator.userAgent.indexOf("Opera")!=-1)
{
// Code fuer Opera
}if (window.opera)...
reicht vollkommen - denn dieses Objekt kennt nur Opera (solange es nicht in einem anderen Browser eingebaut wird). Der User-Agent kann aber (wieder mal) zu Fehlerkennungen führen, denn der kann benutzerdefinierbar sein - wenn dann ein Benutzer seinen Browser als Opera ausgibt, ohne wirklich einen zu haben, könnte das problematisch werden.- Sven Rautenberg
-
Hallo,
Erstmal: Wozu muss der Browser identifiziert werden? Es ist in 90% der Fälle nicht sinnvoll, die Angabe "User-Agent" auszuwerten, denn die hat viel zuviele Varianten, die gar nicht alle abzudecken sind.
Was Sinn macht, ist die Auswertung, ob der Browser document.getElementById (alle neuen), document.all (IE4) oder document.layers (NS4) kennt - sofern man diese Methoden in seinem Skript verwenden will.
haut oft nicht ganz hin.
Nicht alle Besonderheiten von Opera lassen sich defensiv berücksichtigen.
Besonders problematisch dass Opera auch behaupten kann document.all zu beherrschen.
Grüsse
Cyx23
-
Hallo Sven,
ich habe gar nichts weiter vor, als daß dem Besucher angezeigt wird, mit welchem Browser er unterwegs ist. Und zwar deswegen, weil ich Seiten baue, die auch von ganz blutigen Anfängern besucht werden, die gelegentlich nicht wissen, mit welchem Browser sie unterwegs sind. (Doch, das gibt's.) Und wenn man meint, seinen Besuchern über den einen oder anderen Browser das eine oder andere sagen zu sollen, ist's für jene Anfänger vielleicht gut zu wissen, mit welchem Browser sie überhaupt arbeiten.
Gruß
SebastianAloha!
Mit navigator.appName läßt sich der Browser des Besuchers auslesen. Allerdings macht der Opera da ja nicht mit, da der Opera-Nutzer selbst angibt, als welcher Browser der Opera sich ausgibt.
Erstmal: Wozu muss der Browser identifiziert werden? Es ist in 90% der Fälle nicht sinnvoll, die Angabe "User-Agent" auszuwerten, denn die hat viel zuviele Varianten, die gar nicht alle abzudecken sind.
Was Sinn macht, ist die Auswertung, ob der Browser document.getElementById (alle neuen), document.all (IE4) oder document.layers (NS4) kennt - sofern man diese Methoden in seinem Skript verwenden will.
Für statistische Zwecke ist die User-Agent-Angabe vielleicht sinnvoll auszuwerten.
if(window.opera || navigator.userAgent.indexOf("Opera")!=-1)
{
// Code fuer Opera
}if (window.opera)...
reicht vollkommen - denn dieses Objekt kennt nur Opera (solange es nicht in einem anderen Browser eingebaut wird). Der User-Agent kann aber (wieder mal) zu Fehlerkennungen führen, denn der kann benutzerdefinierbar sein - wenn dann ein Benutzer seinen Browser als Opera ausgibt, ohne wirklich einen zu haben, könnte das problematisch werden.- Sven Rautenberg
-
Hallo, Sebastian!
ich habe gar nichts weiter vor, als daß dem Besucher angezeigt wird, mit welchem Browser er unterwegs ist. Und zwar deswegen, weil ich Seiten baue, die auch von ganz blutigen Anfängern besucht werden, die gelegentlich nicht wissen, mit welchem Browser sie unterwegs sind. (Doch, das gibt's.) Und wenn man meint, seinen Besuchern über den einen oder anderen Browser das eine oder andere sagen zu sollen, ist's für jene Anfänger vielleicht gut zu wissen, mit welchem Browser sie überhaupt arbeiten.
Ok, dann wirfst du dem Benutzer einfach den User-Agent an den Kopf (in netter Form natürlich) und schreibst bitte dazu, dass deine nähere Auswertung (MSIE, Opera, Netscape) eine gewisse Wahrscheinlichkeit hat, aber nicht stimmen muss.
Hm, mir fällt gerade ein: Warum hat der Browser eigentlich eine Titelzeile? Was steht dort immer drin? Ja, der Browsername! Also hast du eine ganz simple Möglichkeit, den Benutzer zu informieren: "Schauen Sie in die Titelzeile, dort steht der verwendete Browser drin." Außerdem hat jedes Programm die Möglichkeit, die Programmversion anzuzeigen: "Hilfe -> Über BROWSERNAME" zum Beispiel.
- Sven Rautenberg
-
Erstmal: Wozu muss der Browser identifiziert werden? Es ist in 90% der Fälle nicht sinnvoll, die Angabe "User-Agent" auszuwerten, denn die hat viel zuviele Varianten, die gar nicht alle abzudecken sind.
Außer der Variante "ich verkaufe den Macher einer Seite für dumm und behaupte, mein Browser sei XY" wüsste ich jetzt keine.
Würden alle Browser mit den W3C-Normen perfekt klar kommen, würde diese Problematik für mich nicht existieren. Fakt ist aber, dass selbst Gecko unter anderem CSS2 noch nicht vollständig implementiert hat, von XHTML1.1 Ruby noch nicht kann, von HTML 2.0 <link> in neueren Builds aus Performance-Gründen nicht sinnvoll auswertet, uswusf. Ganz zu schweigen von IE, der noch nicht mal ansatzweise an diese Qualität herankommt.
Eine umfangreichere Site mit komplexen Layout (so etwas wird mir nunmal vorgegeben) kann ich daher nur realisieren, wenn ich den UA-String auswerte. Server-seitig, über Perl oder PHP; nicht client-seitig mittels JavaScript.
Was Sinn macht, ist die Auswertung, ob der Browser document.getElementById (alle neuen), document.all (IE4) oder document.layers (NS4) kennt - sofern man diese Methoden in seinem Skript verwenden will.
Leider nein. Abgesehen davon, dass derartiges server-seitig nicht auswertbar ist (was nötig ist, um jede menge Traffic zu sparen - oder soll ich z.B. Stylesheets übertragen, aber die letztlich nicht vom Browser benutzen lassen?), ist diese Methode allmählich auch veraltet, denn
- Opera kann inzwischen leider teilweise document.all
- bei Mozilla bahnt sich leider, leider eine document.all-Implementation an, und evtl. auch eine document.layers-Implementation. Natürlich versuchen viele, das zu verhindern.
- afaik kann auch Konqueror teilweise document.all
- mit "alle neuen" weisst du nicht, ob es IE 5 oder IE 6 ist. Ersterer hat bekanntlich große box-model-Macken.
Wer seinen UA-String abfälscht, ist letztlich selbst schuld: trifft man auf eine Site, die kategorisch nach UA-String den Browser, den man benutzt, aussperrt, so sollte man diese nach Möglichkeit demonstrativ links liegen lassen. Ist das nicht möglich, so kann man von mir aus für diese Site den UA-String kurzzeitig umstellen, sollte das aber keineswegs dauerhaft tun.
Ferner gibt es solche, die das aus Spaß machen, mit UA-Strings wie "Kitchen/1.0 (modern)" etc. - damit ist der Sinn des Headers ad absudrum geführt, und da gilt wirklich "selbst schuld".
Wenn es dich interessieren sollte, so sieht mein PHP-Code dafür aus:
//-------------------------------------------
// query UA string
//-------------------------------------------/**
* $detectedUA will contain one of the following values:
* 'opera6' : Opera 6
* 'operaold' : Opera old version
* 'ie5mac' : IE 5 Mac
* 'ieoldmac' : IE Mac old version
* 'ie6win' : IE 6 Win32
* 'ie5win' : IE 5 Win32
* 'ieoldwin' : IE Win32 old version
* 'gecko' : any Gecko browser
* 'other' : other UA string
*/function inUAString($UAString) {
global $HTTP_USER_AGENT;
$notUAString = strpos($HTTP_USER_AGENT,$UAString) === false;
return !$notUAString;
}function detectUA() {
if ( inUAString('Opera') )
$detectedUA = inUAString('6.0') ? 'opera6' : 'operaold';
elseif ( inUAString('MSIE') ) {
if ( inUAString('Mac') )
$detectedUA = inUAString('MSIE 5') ? 'ie5mac' : 'ieoldmac';
elseif ( inUAString('Win') ) {
if ( inUAString('MSIE 6') )
$detectedUA = 'ie6win';
elseif ( inUAString('MSIE 5') )
$detectedUA = 'ie5win';
else $detectedUA = 'ieoldwin';
}
}
elseif ( inUAString('Gecko') )
$detectedUA = 'gecko';
else $detectedUA = 'other'; // triggered by konqueror, ns4 and others
return $detectedUA;
}Ich selbst bin kein PHP-Experte, und es mag effizienter gehen.
-
Erstmal: Wozu muss der Browser identifiziert werden? Es ist in 90% der Fälle nicht sinnvoll, die Angabe "User-Agent" auszuwerten, denn die hat viel zuviele Varianten, die gar nicht alle abzudecken sind.
Außer der Variante "ich verkaufe den Macher einer Seite für dumm und behaupte, mein Browser sei XY" wüsste ich jetzt keine.
Ähm, du weißt, wie viele Browser es auf der Welt gibt? Wieviele verschiedene User-Agent-Strings es gibt?
Mein Kernpunkt ist: Browsererkennung, die gerne in Browserweichen mündet, um je nach Browser gewisse Javascriptteile auszuführen, sollten sich ausschließlich anhand der vorhandenen DOM-Objekte orientieren, nicht an irgendwelchen User-Agent-Angaben.
Der klassische Reinfall: Mit der Veröffentlichung von Netscape 6.0 funktionierten nicht nur viele Webseiten nicht, sondern produzierten Javascriptfehler in Massen. Grund: Es wurde anhand des User-Agent-Strings entschieden: Ist "MSIE" enthalten, dann nimm document.all, und ansonsten document.layers.
Das klappt natürlich nicht, wie wir alle wissen. Besser wäre: Wenn document.all existiert, dann nimm das. Wenn document.layers existiert, dann nimm das. Dadurch würde die Webseite zwar noch nicht funktionieren, aber die Fehler wären schon mal weg - und außerdem läßt sich solch ein Konstrukt eben relativ leicht um "Wenn document.getElementById, dann nimm dieses" erweitern.
Würden alle Browser mit den W3C-Normen perfekt klar kommen, würde diese Problematik für mich nicht existieren. Fakt ist aber, dass selbst Gecko unter anderem CSS2 noch nicht vollständig implementiert hat, von XHTML1.1 Ruby noch nicht kann, von HTML 2.0 <link> in neueren Builds aus Performance-Gründen nicht sinnvoll auswertet, uswusf. Ganz zu schweigen von IE, der noch nicht mal ansatzweise an diese Qualität herankommt.
Ja, und? Das sind alles Dinge, die in Supersonderfällen vielleicht mal interessant sind. Also für Bastler. Sie verbieten sich von selbst, wenn man kommerzielle Webseiten produzieren will, die auf einer breiten Browserbasis funktionieren müssen.
Man kann das bedauern - aber es ist eben auch Fakt, dass gewisse Webseiten sich eher am kleinsten gemeinsamen Nenner orientieren müssen. Dabei sind die Möglichkeiten der Gestaltung schon recht groß, wenn man Netscape 4 einfach außer acht läßt. Und auch dieser Browser kann mit abgespeckten CSS-Dateien zur Mitarbeit überredet werden.
Eine umfangreichere Site mit komplexen Layout (so etwas wird mir nunmal vorgegeben) kann ich daher nur realisieren, wenn ich den UA-String auswerte. Server-seitig, über Perl oder PHP; nicht client-seitig mittels JavaScript.
Das kannst du natürlich machen - die Frage ist: Was passiert, wenn dir unbekannte Browser die Site besuchen? Kriegen die dann die volle Feature-Ladung geboten, oder bist du arg konservativ und lieferst HTML 2.0 aus (um es mal extrem auszudrücken ;) )? Was ist, wenn der unbekannte Browser alles komplett beherrschen würde, was du brauchst, es aber nicht kriegt?
Ich halte das Auswerten des User-Agent-Strings _serverseitig_ für groben Unfug - diese Angabe kann viel zu leicht verändert werden oder ungewollt verlorengehen (ja, manche uneinsichtige Admins filtern die Angabe aus Sicherheitsgründen am Firmenproxy heraus - was dann?). Auch clientseitig ist es nicht viel besser - wegen der gleichen Problematik. Allerdings ist es unwahrscheinlicher, gar keine Angabe zu erhalten, aber genauso wahrscheinlich, unerwartete Angaben zu erhalten.
Was Sinn macht, ist die Auswertung, ob der Browser document.getElementById (alle neuen), document.all (IE4) oder document.layers (NS4) kennt - sofern man diese Methoden in seinem Skript verwenden will.
Leider nein. Abgesehen davon, dass derartiges server-seitig nicht auswertbar ist (was nötig ist, um jede menge Traffic zu sparen - oder soll ich z.B. Stylesheets übertragen, aber die letztlich nicht vom Browser benutzen lassen?), ist diese Methode allmählich auch veraltet, denn
- Opera kann inzwischen leider teilweise document.all
Nur, wenn er als Internet Explorer getarnt ist.
- bei Mozilla bahnt sich leider, leider eine document.all-Implementation an, und evtl. auch eine document.layers-Implementation. Natürlich versuchen viele, das zu verhindern.
Ist auch unproblematisch, siehe unten...
- afaik kann auch Konqueror teilweise document.all
Dito.
- mit "alle neuen" weisst du nicht, ob es IE 5 oder IE 6 ist. Ersterer hat bekanntlich große box-model-Macken.
Auch dagegen ist ein Kraut gewachsen.
Die Javascript-Lösung ist eigentlich ganz einfach.
Ausgangspunkt: Die primär zu benutzende Lösung ist das W3C-DOM. Das können alle neuen Browser mehr oder weniger (die derzeit bestehenden Einschränkungen des Opera-Browsers, gewisse Inhalte und CSS-Werte nachträglich zu verändern, sind bekannt - sowas macht man dann einfach nicht ;) ).
Wenn document.getElementById nicht vorhanden ist, wird als Ausweichlösung mit document.all gearbeitet (das sollte im Prinzip nur für IE 4 zutreffen). Wenn das nicht vorhanden ist, wird mit document.layers gearbeitet (was nur für den NS 4 zutrifft).
Wenn neue Browser auftauchen, dann werden die hoffentlich das W3C-DOM verstehen und durch diese Abfrage ganz automatisch mit berücksichtigt. Und auch wenn sie stattdessen eines der alternativen DOM-Modelle kennen, werden sie immer noch berücksichtigt (wenngleich die Wahrscheinlichkeit dafür gegen Null geht).
Was den Traffic angeht: Nach meinen Erfahrungen blähen sich lediglich die Javascript-Dateien ein wenig auf. Und ggf. laden die besseren Browser (also alles außer Netscape 4) zwei statt nur einer CSS-Datei, damit dieses alte, aber verbreitete Modell zumindest etwas anzeigt, die anderen Browser aber bessere grafische Darstellungen bringen können.
Und server-seitig sollte man den UA-String ohnehin nicht auswerten. Was ein Browser macht und kann, dass weiß der Browser selbst am besten. Es ist Aufgabe des Programmierers, für die häufigsten Browser funktionierende Lösungen zu erstellen - und dabei keinesfalls andere, unberücksichtigte Browser auszuschließen. Er soll sich an die W3C-Standards halten. Die Browser werden dies auch tun - und schon funktioniert die Seite.
Wer seinen UA-String abfälscht, ist letztlich selbst schuld: trifft man auf eine Site, die kategorisch nach UA-String den Browser, den man benutzt, aussperrt, so sollte man diese nach Möglichkeit demonstrativ links liegen lassen. Ist das nicht möglich, so kann man von mir aus für diese Site den UA-String kurzzeitig umstellen, sollte das aber keineswegs dauerhaft tun.
Wer für die Fälschung des UA-Strings nichts kann, hat der dann Pech gehabt? Er erhält ja schlimmstenfalls keinerlei Hinweis darauf, was sein Browser falsch macht. Er sieht nur eine kaum existente, unbenutzbare oder grausam designte Seite. Und mit welcher Angabe hätte er denn mehr Erfolg? Weiß er, wie er diesen UA-String setzen kann? Was ist, wenn er einen W3C-DOM-Browser hat, sich aber als IE ausgibt - und dann mit document.all beworfen wird?
Ferner gibt es solche, die das aus Spaß machen, mit UA-Strings wie "Kitchen/1.0 (modern)" etc. - damit ist der Sinn des Headers ad absudrum geführt, und da gilt wirklich "selbst schuld".
Selbst schuld ist der Programmierer der Seite, der nicht begriffen hat, dass die UA-Angabe infomativen Charakter hat, aber keinesfalls genormt ist oder in irgendeiner Weise verläßlich ist. Die Angabe des UA-Strings ist optional!
Und das steht unter anderem auch in der RFC 2616 (HTTP/1.1) im Kapitel 12.1.
<quote>
12.1 Server-driven NegotiationIf the selection of the best representation for a response is made by an algorithm located at the server, it is called server-driven negotiation. [...]
Server-driven negotiation is advantageous when the algorithm for selecting from among the available representations is difficult to describe to the user agent, or when the server desires to send its "best guess" to the client along with the first response (hoping to avoid the round-trip delay of a subsequent request if the "best guess" is good enough for the user). In order to improve the server's guess, the user agent MAY include request header fields (Accept, Accept-Language, Accept-Encoding, etc.) which describe its preferences for such a response.
Server-driven negotiation has disadvantages:
1. It is impossible for the server to accurately determine what might be "best" for any given user, since that would require complete knowledge of both the capabilities of the user agent and the intended use for the response (e.g., does the user want to view it on screen or print it on paper?).
2. Having the user agent describe its capabilities in every request can be both very inefficient (given that only a small percentage of responses have multiple representations) and a potential violation of the user's privacy.
3. It complicates the implementation of an origin server and the algorithms for generating responses to a request.
4. It may limit a public cache's ability to use the same response for multiple user's requests.
</quote>Dem ist IMO nichts mehr hinzuzufügen.
- Sven Rautenberg
-
Hi Sven,
- It may limit a public cache's ability to use the same response for multiple user's requests.
</quote>
Dem ist IMO nichts mehr hinzuzufügen.
weil es gerade so gut paßt:
Der verbreitete Proxy-Cache Squid ist _jetzt_ gerade dabei, Caching
für negotiated content einzubauen (in der kommenden Version 2.5).Das Problem ist allerdings, daß er dafür zuverlässige Informationen
von den beteiligten Partnern braucht, um zu verstehen, was er da vor
sich hat, und daß die Partner ihm diese momentan noch nicht liefern -
beispielsweise mod_gzip 1.3.19.1a (noch) nicht ... (1b schon eher ...)Viele Grüße
Michael - It may limit a public cache's ability to use the same response for multiple user's requests.
-
Hallo,
if (window.opera)...
reicht vollkommen - denn dieses Objekt kennt nur Opera (solange es nicht in einem anderen Browser eingebaut wird).Fragt sich nur, ob kommende Versionen das auch noch kennen.
Der User-Agent kann aber (wieder mal) zu Fehlerkennungen führen, denn der kann benutzerdefinierbar sein - wenn dann ein Benutzer seinen Browser als Opera ausgibt, ohne wirklich einen zu haben, könnte das problematisch werden.
Nun, die einstellbaren "Standard-Fake-User-Agents" von Opera enthalten eben alle die Zeichenkette "Opera" und wer einen anderen Browser als Opera ausgibt, ist selbst schuld.
Außerdem habe ich eine ODER-Verknuepfung gewaehlt ...
Davon abgesehen halte von diesen Abfragen eher wenig, außer wenn man Opera bis 6.0x von DOM-Aktionen fernhalten moechte.
MfG, Thomas
-
Hallo,
Außerdem habe ich eine ODER-Verknuepfung gewaehlt ...
Hm, UND waere natuerlich noch konsequenter ...
MfG, Thomas
-
-
Hallo Sven und Rest der Gang,
darf ich mich mal dazwischenwerfen...
Habe ein aehnliches Problem - mein Kunde hat sich jetzt einen Nokia-Communicator 9210 zugelegt und beschwert sich, dass er damit seine neue Website nicht sehen kann - das Teil kann naemlich kein JavaScript (und vielleicht auch keine Frames darstellen?). Soll eine abgespeckte Version des Opera-Browsers drauf laufen.
Hast Du - oder sonstwer - eine Idee wie ich diesen Communicator abfangen kann?
TIA Wilfried :-)
-
Hi Wilfried,
Habe ein aehnliches Problem - mein Kunde hat sich jetzt einen Nokia-
Communicator 9210 zugelegt und beschwert sich, dass er damit seine
neue Website nicht sehen kann - das Teil kann naemlich kein
JavaScriptreicht dann nicht bereits ein <noscript>-Bereich, während der normale
Inhalt der Seite komplett im <script>-Bereich via document.write
erzeugt wird?
(Oder eventuell auch nur alle Links auf den Teilbereich, der ohne
JavaScript nicht funktioniert?)(und vielleicht auch keine Frames darstellen?).
Dasselbe gilt für <noframes>.
Tip: Nimm Opera, schalte die Interpretation von von Frames ab (!)
und surfe durch Deine Seiten. Dann siehst Du recht gut, was jemand
sehen wird, dessen Browser keine Frames kennt.Hast Du - oder sonstwer - eine Idee wie ich diesen Communicator
abfangen kann?Schau Dir seinen UserAgent-String an - beispielsweise, indem Dein
Kunde die Seite
http://www.schroepl.net/cgi-bin/http_trace.pl
besucht und Dir die Ausgabe davon schickt.Aber <noscript> und <noframes> sind die robustere Lösung, denn es
kann ja täglich neue UserAgents geben, die irgendwas nicht können,
und deren Namen Du nicht ständig in Deine Liste einpflegen willst.Viele Grüße
Michael-
Hallo Michael,
ja, eine einfache und gute Loesung - vielen Dank !
Wilfried :-)
-
-
-
-
-
Hallo,
mal wieder eine ungebetene Überlegung von mir: Opera-benutzer in Ehren (in großen Ehren sogar), aber: wer mit einem opera auf (m)eine Seite surft, und wissentlich behauptet, einen anderen Browser zu nutzen, der darf sich auch nicht wundern, wenn ich seinen Browser dann auch "wie einen anderen "behandel".
Opera-benutzer sind (positiv gemeint) Ausnahme-Konsumenten. Die wissen, was sie benutzen. Und wenn sie dann noch an der "Duftmarke" des Produktes rumschrauben, sollten die erst recht wissen, was sie machen. Warum also nun auch noch Klimmzüge machen? Wenn sie gerne wie "ein IE-Benutzer" behandelt werden wollen... na, dann behandeln wir sie eben doch einfach so....
Chräcker
-
Hallo,
Moin!
mal wieder eine ungebetene Überlegung von mir: Opera-benutzer in Ehren (in großen Ehren sogar), aber: wer mit einem opera auf (m)eine Seite surft, und wissentlich behauptet, einen anderen Browser zu nutzen, der darf sich auch nicht wundern, wenn ich seinen Browser dann auch "wie einen anderen "behandel".
das ist wohl wahr, allerdings gibt es sicher auch ein paar leutz die sich dann freuen das das eine oder andere div verrutscht ist.
*g*Opera-benutzer sind (positiv gemeint) Ausnahme-Konsumenten. Die wissen, was sie benutzen. Und wenn sie dann noch an der "Duftmarke" des Produktes rumschrauben, sollten die erst recht wissen, was sie machen. Warum also nun auch noch Klimmzüge machen? Wenn sie gerne wie "ein IE-Benutzer" behandelt werden wollen... na, dann behandeln wir sie eben doch einfach so....
Ich surfe standart mässig mit Opera. ( Javascript aus, mit Opera Odent )
Mit dem IE hatte ich beim surfen einfach eine zu voll gestopfte task leiste ( nein ich benutz kein XP )
Ausserdem ist er IMHO schneller als IE und mozilla ( als netscape sowieso )Ich würde sicher mozilla benutzen aber ich habe mich bei Meiner MS Intellieye maus so an die 4+5 taste gewöhnt, die man im IE und Opera als vor und zurück taste nutzen kann. Im Mozilla geht das leider net :(.
Chräcker
Mfg AnalphaBestie
schöne seite übrigens, hat echt spass gemacht ;)
-
Hallo,
Ich surfe standart mässig mit Opera. ( Javascript aus, mit Opera
Odent )sicherlich bei bestimmten "surfgebieten" nicht die dümmste Konstelation.
Ich würde sicher mozilla benutzen aber ich habe mich bei Meiner MS
Intellieye maus so an die 4+5 taste gewöhnt, die man im IE und
Opera als vor und zurück taste nutzen kann. Im Mozilla geht das
leider netso ähnlich gehts mir mit dieser Mauswedelfunktion bei meinem mozilla. Mittlere Maustaste gedrückt, nach rechts oder links zucken, und schon gehts vor oder rückwärts durch die Geschichte. Habe ich immer für eine nette Speilerei gehalten, bis ich den 1.1er instalierte und erst einmal die Mausweselfunktion nicht mehr funktionierte. Da habe ich erst mal gemerkt, wie oft ich die benutzte ;-))))
schöne seite übrigens, hat echt spass gemacht ;)
mit opera? ;-))))))))))
(danke natürlich fürs Lob ,-))
Chräcker
-
Hi Chräcker,
Ich surfe standart mässig mit Opera. ( Javascript aus, [...]
sicherlich bei bestimmten "surfgebieten" nicht die dümmste Konstelation.
bei allen, wo es nicht gerade um's Stempeln geht ;)
so ähnlich gehts mir mit dieser Mauswedelfunktion bei meinem mozilla. Mittlere Maustaste gedrückt, nach rechts oder links zucken, und schon gehts vor oder rückwärts durch die Geschichte.
Für alle, die das noch nicht können: http://optimoz.mozdev.org/gestures/
BTW, deine Opera-Abfrage (window.opera) könnte sich demnächst als äußerst unangenehm entpuppen, wenn Opera 7 erscheint. Der wird nämlich der beste Browser aller Zeiten werden und am Stempelgeheimnis verkraften nicht mehr scheitern (hoffe ich). Vielleicht solltest du so arbeiten, wie es Jürgen in </?m=122083&t=21945> vorgeschlagen hat und mit
var kannDOM=document.getElementsByTagName('body')[0].replaceChild;
prüfen. Dann kann ich mich endlich auch im Gästebuch eintragen <ansporn /> ;)
LG Orlando
-
Ups,
das war zuviel.
am Stempelgeheimnis verkraften nicht mehr scheitern
Entweder das "verkraften" bezieht sich auf die Bewunderung durch die Besucher, oder wir streichen es aus dem Protokoll... ;)
LG Orlando
-
Hallo,
wichtiger guter Hinweis, werde diese DOM-Erkennungsmethode dann ja auch brauchen, um die 7er opera von den anderen zu trennen.
Wirklich wahr, ich hatte angefangen, die Seiten operafest zu machen, aber ich muß gestehen, als ich merkte, woran es scheiterte, war ein Wochenende gerettet: die "Opera-muß-draussen-bleiben"-Seite war letztendlich schon schneller geschrieben als meinen Spaghetti-Javascript-code glatt zu bügeln....... beim 7er werde ich dann keine Ausrede mehr haben, fürchte ich ,-)))
(wird er dann "nur" DOM2-Methoden unterstützen und/oder gehört dann innerhtml noch zu den zu erhoffenden Funktionen? die Stempelseite ist halt noch etwas rustikaler ,-))))
Chräcker
-
Hi Chräcker,
wichtiger guter Hinweis, werde diese DOM-Erkennungsmethode dann ja auch brauchen, um die 7er opera von den anderen zu trennen.
beim 7er werde ich dann keine Ausrede mehr haben, fürchte ich ,-)))
so ist es ;)
(wird er dann "nur" DOM2-Methoden unterstützen und/oder gehört dann innerhtml noch zu den zu erhoffenden Funktionen? die Stempelseite ist halt noch etwas rustikaler ,-))))
Keine Ahnung. Ich glaube es aber eher nicht. Zwar wurde im 6er mit document.all etwas, sagen wir "experimentiert", aber bei innerhtml zweifle ich. Aber du kannst dir ja mit den Möglichkeiten des DOM ein eigenes innerhtml basteln ;)
Eine interessante Aussage zu diesem Thema:
"If it is crucial that there will *full* DOM support, Opera 7
will not satisfy your need, and you would better have to wait
for Opera 8. If your goal is less absolutist than that, my hope
is that you will not be disappointed with what you will get.
When? It may soon be time to dust off that "RSN" abbreviation
again."([http://groups.google.com/groups?hl=de&lr=&ie=UTF-8&frame=right&th=cd076b875a2efc9f&seekm=ak5smn%24i0%241%40mail.opera.no#link9])
LG Orlando
-
Hallo,
"If it is crucial that there will *full* DOM support, Opera 7
will not satisfy your need, and you would better have to wait
for Opera 8.na, dann habe ich ja vielleicht doch noch etwas Zeit ,-)))
Chräcker (jaja, ich wrde mir aber den 7er anschauen, jaja....)
-
-
-
-
-
-
mal wieder eine ungebetene Überlegung von mir: Opera-benutzer in Ehren (in großen Ehren sogar), aber: wer mit einem opera auf (m)eine Seite surft, und wissentlich behauptet, einen anderen Browser zu nutzen, der darf sich auch nicht wundern, wenn ich seinen Browser dann auch "wie einen anderen "behandel".
Bis hin zur aktuellen Version 6.05 gibt sich Opera direkt nach der Installation standardmäßig als MSIE 5.0 aus. Damit dürfte Deine These "Den sie wissen, was sie tun." gehörig auf den Kopf gestellt werden ;-)
Im User-Agent-String steht allerdings immer die "Opera" mit drin.
-
Hallo,
normalerweise wollte ich auf annonyme Poster gar nicht mehr reagieren, ich mag mich eben nur gerne mit Menschen unterhalten, so wirkt es immer, als ob man nur mit dem computer spricht, das ist dann das dämlichste. (Da fällt mir vollkommen o.T. ein. gibts eigendlich noch Parkuhren? (von wegem: sich mit ner Parkuhr unterhalten....)....)
Aber wie dem auch sei, hier "muß" ich doch mal reagieren:
Bis hin zur aktuellen Version 6.05 gibt sich Opera direkt nach der
Installation standardmäßig als MSIE 5.0 aus. Damit dürfte Deine
These "Den sie wissen, was sie tun." gehörig auf den Kopf gestellt »» werden ;-)Stimmt ;-) (kann man ja mal ruhig zugeben).... komische Entwickler, aber sie werden ihre Gründe haben. Dann nehme ich natürlich diesbezüglich etwas "Schärfe" zurück....
Chräcker
-
Hallo,
normalerweise wollte ich auf annonyme Poster gar nicht mehr reagieren, ich mag mich eben nur gerne mit Menschen unterhalten,
kann ich verstehen, aber ich z.B. habe verschiedene Gründe, die erstmal mit Anonymität weniger als vielmehr mit "Interferenzen" z.B. bei Suchmschinen zu tun haben.
Stimmt ;-) (kann man ja mal ruhig zugeben).... komische Entwickler, aber sie werden ihre Gründe haben. Dann nehme ich natürlich diesbezüglich etwas "Schärfe" zurück....
Allerdings ist es default so, das führt peinlicherweise auch dazu dass Opera document.all bejaht. Die Gründe sind vmtl. ein bescheidenes workaround um bei einigen Websites überhaupt etwas zu sehen.
Es sind ja auch genug User am Opera verzweifelt, die Operanewsgroups waren, und sind vmtl. noch, bis zum Abwinken voll davon.Grüsse
Cyx23
-
-
-