var und const

[Hans]

Hallo.

In meiner Homepage habe ich eine properties.js
Darin stehen Werte wie z.B.:

var IE = ((document.all) && (navigator.appName != "Opera")) ? true : false;  
var screenWidth = screen.width;  
var screenHeight = screen.height;  
var serverProtocol = window.location.protocol;  
var serverName = window.location.hostname;

Diese Werte sind meiner Meinung nach Konstanten die nur einmal erstellt werden und dann "nie wieder" verändert werden.
Wenn ich nun das "var" durch "const" ersetze, kommt der IE damit nicht klar (Syntaxfehler und z.B. "IE ist undefiniert".
Warum?

Hans

[EKKi]

Mahlzeit Hans,

Diese Werte sind meiner Meinung nach Konstanten die nur einmal erstellt werden und dann "nie wieder" verändert werden.

Prinzipiell könnte das schon sein.

Wenn ich nun das "var" durch "const" ersetze, kommt der IE damit nicht klar (Syntaxfehler und z.B. "IE ist undefiniert".
Warum?

Vielleicht weil der verwendete IE (dessen Version Du verschwiegen hast) kein <http://de.selfhtml.org/javascript/sprache/reserviert.htm#uebersicht@title=Javascript >= Version 1.5> beherrscht?

MfG,
EKKi

[Hans]

Vielleicht weil der verwendete IE (dessen Version Du verschwiegen hast) kein <http://de.selfhtml.org/javascript/sprache/reserviert.htm#uebersicht@title=Javascript >= Version 1.5> beherrscht?

sorry.
 IE 7.0
 und
 IE 6.0

[Cybaer]

Hi,

IE 7.0
und
IE 6.0

const wird mom. nur alls proprietäres JavaScript 1.5 von Mozillas und Operas unterstützt. Aktuell ist ECMAScript 3 (ungefähr JS 1.5). Der IE hat, sofern man das bestimmen kann, ECMAScript 1 oder 2.

const kommt offiziell erst mit ECMAScript 4, ggf. aber schon mit ECMAScript 3.1. Vielleicht/vermutlich wird der IE 9 das unterstützen ...

Gruß, Cybaer

[molily]

Hallo,

Aktuell ist ECMAScript 3 (ungefähr JS 1.5). Der IE hat, sofern man das bestimmen kann, ECMAScript 1 oder 2.

JScript ist eine weitgehend konforme Implementierung von ECMAScript Edition 3. Oder welche neuen Features von Edition 3 im Vergleich zu Edition 1 und 2 kennt JScript nicht?

Mathias

[Cybaer]

Hi,

JScript ist eine weitgehend konforme Implementierung von ECMAScript Edition 3.

Hmm, du meinst nicht nur JS>=E3 sei wahr im Sinne von "entspricht ECMAScript 3", sondern auch JS<E3? Wie lautet denn der Bedingungsoperator für "weitgehend"? Wird der erst mit E4 eingeführt? ;)

Gruß, Cybaer

PS: Danke aber für das PDF. Mir war nicht bewußt, daß der IE (proprietäre Erweiterungen mal sowieso ausgelassen) an so vielen Stellen abweicht ...

[Cybaer]

Hi,

Vielleicht weil der verwendete IE (dessen Version Du verschwiegen hast) kein <http://de.selfhtml.org/javascript/sprache/reserviert.htm#uebersicht@title=Javascript >= Version 1.5> beherrscht?

Alle IEs liegen so bei JS 1.2.

Gruß, Cybaer

[molily]

Hallo,

Alle IEs liegen so bei JS 1.2.

Neue Objekte in JS 1.3 (Auszug):

Array: toSource
Boolean: toSource
Date: getFullYear, setFullYear, getMilliseconds, setMilliseconds, toSource, die UTC-Methoden
Function: apply, call
Number: toSource
Object: toSource
RegExp.toSource
String.replace erlaubt Funktion als Parameter
window.Infinity, window.isFinite, window.NaN, window.undefined
===, !==
plus diverse Änderungen im Verhalten.

Was kann IE davon jetzt nicht? toSource? Oder war deine Einschätzung eher so nach Gefühl?

Mathias

[Cybaer]

Hi,

Was kann IE davon jetzt nicht?

Ich hab's nicht ausprobiert.

toSource?

Das kann er zumindest wohl nicht.

Oder war deine Einschätzung eher so nach Gefühl?

Wie meiner Formulierung zu entnehmen sein sollte: Eher nach Gefühl.

Gruß, Cybaer

[molily]

Hallo,

var IE = ((document.all) && (navigator.appName != "Opera")) ? true : false;

Browsererkennung anhand von irgendwelchen Objekten ist Humbug. Und diese Umsetzung ist wenig zuverlässig.
Eigentlich muss man fast nie mit solchen Browsererkennungen arbeiten, sondern kann mit zielgenauen Fähigkeiten-Erkennungen arbeiten.

Warum?

Es gibt keine Konstanten in JavaScript (ECMAScript).
Wenn es in irgendeinem Browser zufällig funktioniert, ist es eine proprietäre Erweiterung.

Mathias

[Kai345]

[latex]Mae  govannen![/latex]

var IE = ((document.all) && (navigator.appName != "Opera")) ? true : false;

Browsererkennung anhand von irgendwelchen Objekten ist Humbug. Und diese Umsetzung ist wenig zuverlässig.
Eigentlich muss man fast nie mit solchen Browsererkennungen arbeiten, sondern kann mit zielgenauen Fähigkeiten-Erkennungen arbeiten.

ACK.

@hans:
Und wenn man eine Fähigkeit nutzen will, die zwar Browser-übergreifend vorhanden ist, aber nur im IE notwendig ist, sollte man ein per conditional comment eingebundenes Javascript nutzen oder die Unterscheidung per conditional compiling durchführen. ->Wikipedia

@all:
Das bringt mich zu der Frage, wie man am Besten vorgeht, wenn man einen der (seltenen) Fälle hat, wo man einen spezifischen Code ausschließlich in einen bestimmten anderen Browser ausführen möchte, aber nur Features nutzt, die auch andere Browser zur Verfügung stellen. Bisher habe ich mir dann ein browserspezifisches Feature aus dieser Liste gewählt und auf selbiges getestet. Wobei das IMO auch nicht ganz sauber ist, einmal, weil man nie weiß, was in der Zukunft in die Browser implementiert wird und auch weil ich das spezifische Feature überhaupt nicht nutze. Aber wie geht man sonst vor?

Cü,

Kai

[Timo "God's Boss" Reitz]

Das bringt mich zu der Frage, wie man am Besten vorgeht, wenn man einen der (seltenen) Fälle hat, wo man einen spezifischen Code ausschließlich in einen bestimmten anderen Browser ausführen möchte, aber nur Features nutzt, die auch andere Browser zur Verfügung stellen. Bisher habe ich mir dann ein browserspezifisches Feature aus dieser Liste gewählt und auf selbiges getestet. Wobei das IMO auch nicht ganz sauber ist, einmal, weil man nie weiß, was in der Zukunft in die Browser implementiert wird und auch weil ich das spezifische Feature überhaupt nicht nutze. Aber wie geht man sonst vor?

Eine saubere Vorgehensweise gibt es nicht, weil schon die Anforderung Quatsch ist.

[Kai345]

[latex]Mae  govannen![/latex]

Eine saubere Vorgehensweise gibt es nicht, weil schon die Anforderung Quatsch ist.

-v

Cü,

Kai

[molily]

Hallo,

der Frage, wie man am Besten vorgeht, wenn man einen der (seltenen) Fälle hat, wo man einen spezifischen Code ausschließlich in einen bestimmten anderen Browser ausführen möchte

Das kann man m.E. nur fallweise entscheiden.

Mathias

[Cybaer]

Hi,

Aber wie geht man sonst vor?

Indem man sich an den entsprechenden window- (opera) und navigator-Eigenschaften (appName, product, vendor, vendorSub) orientiert. Das ist von den jeweiligen Browserherstellern zur Browsererkennung auch explizit so definiert worden (nachzulesen in der jeweiligen Developers-FAQ oder Doku).

Z.B.:
 is_opera=window.opera;
 is_konqueror=(navigator.vendor && navigator.vendor=="KDE");
 is_chrome=(navigator.vendor && navigator.vendor.indexOf("Google")>=0);
 is_safari=(!is_chrome && navigator.product && navigator.product=="Gecko" && navigator.vendor && navigator.vendor.indexOf("Apple")>-1);

Gruß, Cybaer

[Kai345]

[latex]Mae  govannen![/latex]

Hi,

Aber wie geht man sonst vor?

Indem man sich an den entsprechenden window- (opera) und navigator-Eigenschaften (appName, product, vendor, vendorSub) orientiert. Das ist von den jeweiligen Browserherstellern zur Browsererkennung auch explizit so definiert worden (nachzulesen in der jeweiligen Developers-FAQ oder Doku).

Wenn man sie denn findet, für ältere Browser ist das nicht immer einfach. Und was nutzt mir eine neue Eigenschaft, wenn ich einen alten Browser ansprechen will.

Aber ich merke, daß ich mich nicht spezifisch genug ausgedrückt habe. Ich meinte eigentlich einen bestimmten Browser in einer ganz bestimmten Version, z.B um einen Browserbug zu umgehen...

is_opera=window.opera;

window.opera ist bekannt, aber wie erkenne ich z.B. sicher die Version Opera 7.54 [und kleiner] (jetzt mal abgesehen von der Sinnhaftigkeit) Bei neueren Operas habe ich window.opera.version(), aber das gab es damals noch nicht _> undefined. Überhaupt scheint das window.opera-Objekt damals noch keine (sichtbaren?) Methoden oder Eigenschaften besessen zu haben, jedenfalls hat eine for-in-Schleife über das Objekt nichts angezeigt, im Gegensatz zu neuen Operas. Solche Art der Browser-erkennung meinte ich. Und diese Probleme werden, so schätze ich, bei anderen Browsern ebenfalls vorhanden sein.

Cü,

Kai

[molily]

Hallo,

window.opera ist bekannt, aber wie erkenne ich z.B. sicher die Version Opera 7.54 [und kleiner] (jetzt mal abgesehen von der Sinnhaftigkeit) Bei neueren Operas habe ich window.opera.version(), aber das gab es damals noch nicht _> undefined.

Äh, appVersion vielleicht?

Mathias

[Kai345]

[latex]Mae  govannen![/latex]

window.opera ist bekannt, aber wie erkenne ich z.B. sicher die Version Opera 7.54 [und kleiner] (jetzt mal abgesehen von der Sinnhaftigkeit) Bei neueren Operas habe ich window.opera.version(), aber das gab es damals noch nicht _> undefined.

Äh, appVersion vielleicht?

Nein, eben nicht. Wenn ich den UA [1] ändere, dann ändert sich auch appVersion. Demzufolge kein verlässliches Erkennungszeichen.
Sieht so aus, als müßte ich bei der Methode "Featuretest irgendeiner spezifischen Eigenschaft/Methode aus besagter Liste" bleiben, alles andere scheint mindestens genauso unsicher. Und jetzt für jeden Browser stundenlang recherchieren, ob und was sich ändert, dürfte schwierig werden. Es bleibt die Erkenntnis, daß eine hundertprozentige Erkennung wohl nicht wirklich möglich ist, aber durch bestimmte Featuretest (evtl. noch in Kombination) kann man zumindest ziemlich sicher sein.

Und wenn man ehrlich ist, ist eine Abfrage-Kombination auf Methoden/Eigenschaften, die man zwar nicht nutzt, aber einen Browser und dessen Version ziemlich genau eingrenzen kann, zwar streng aus Programmiersicht schlechter Stil, aber gerade bei Javascript/Jscript muß man leider ohnehin viele Verrenkungen machen. Wenn man diese Featureabfrage entsprechend dokumentiert, sollte es auch kein wirkliches Problem sein. Zumal Fälle, die einer solchen spezifische Erkennung bedürfen, ohnehin sehr selten vorkommen werden.

Cü,

Kai

[1] gespenstisch, habe bis vor wenigen Minuten den Film über Flug UA93 am 11.September geschaut und jetzt das ...

[molily]

Hallo,

Wenn ich den UA [1] ändere, dann ändert sich auch appVersion.

Meinst du über die entsprechenden Opera-Menüs? Gut, dann bleibt aber noch die Versionsangabe im userAgent, wenn nicht »Mask as ...« einstellt ist.

Zumal Fälle, die einer solchen spezifische Erkennung bedürfen, ohnehin sehr selten vorkommen werden.

Ja, deswegen halte ich es für Unsinn, eine generische Browsererkennung zu programmieren. Wenn ich einem bestimmten (am besten vergangenen) Browser eine bestimmte Behandlung angedeihen will, so muss ggf. über adäquate Erkennung nachgedacht werden.

Mathias

[Cybaer]

Hi,

Wenn ich einem bestimmten (am besten vergangenen) Browser eine bestimmte Behandlung angedeihen will, so muss ggf. über adäquate Erkennung nachgedacht werden.

So ist es. Und wenn man das nicht kann, muß man das eben bedenken (und ggf. abwägen). Wenn man das kann, stellt sich das Problem nicht.

Bedenken muß man z.B. beim IE, daß die Scriptengine nichts über die Browserversion sagt. Wenn also HTML-Engine des IE x einen Fehler hat, dann ist die Abfrage auf JScript y zweifelhaft - selbst wenn x üblicherweise mit y verbunden war. IE x kann auch mal JScript z bekommen ...

Gruß, Cybaer

[Cybaer]

Hi,

Und jetzt für jeden Browser stundenlang recherchieren, ob und was sich ändert, dürfte schwierig werden.

Sicher. IMHO ist hier halt im Vorteil, wer schon länger Webseiten entwickelt.

Ein Neueinsteiger wird aber i.d.R. wohl nur die aktuell üblichen Browser berücksichtigen. Und wenn ihm da bei einem bestimmten, verbreiteten Browser ein nicht umgehbarer Bug aufstößt, dann wird er ggf. konkret zu diesem aktuellen Problem eine Lösung suchen - und eben auch finden (oder eben nicht).

Davon gänzlich unberührt bleibt natürlich die Nutzung der Browsererkennung für statistische Zwecke. Sie dient dann ja nur dem Zweck: Hauptsache besser als der UA ...

Es bleibt die Erkenntnis, daß eine hundertprozentige Erkennung wohl nicht wirklich möglich ist, aber durch bestimmte Featuretest (evtl. noch in Kombination) kann man zumindest ziemlich sicher sein.

Ja, in der Not frißt der Teufel Fliegen, und eine Browsererkennung wird ggf. zusätzliche auch auf Features zurückgreifen.

Zumal Fälle, die einer solchen spezifische Erkennung bedürfen, ohnehin sehr selten vorkommen werden.

Eben.

Gruß, Cybaer

[molily]

Hallo,

is_chrome=(navigator.vendor && navigator.vendor.indexOf("Google")>=0);
is_safari=(!is_chrome && navigator.product && navigator.product=="Gecko" && navigator.vendor && navigator.vendor.indexOf("Apple")>-1);

Hier scheint schon wieder der unsinnige Ansatz einer »Browsererkennung« durch, die von konkreten Problemen gänzlich abstrahiert. Den Fehler möchte ich sehen, der nur Chrome resp. Safari, aber sonst keinen anderen WebKit-Browser derselben Generation betrifft, und der nicht durch Fähigkeitenabfragen umgangen werden kann. Ich kann mich nur wiederholen.

Mathias

[Cybaer]

Hi,

Hier scheint schon wieder der unsinnige Ansatz einer »Browsererkennung« durch,

Sicher.

Aber ich predige ja selbst, wo ich gehe und stehe, daß man sich nicht vom (vermeintlichen) Browsertyp abhängig machen soll. Sowohl auf meiner Website, als auch in diesem Forum, als auch sonstwo, sondern daß man bei der "normalen" Programmierung sich nur nach den Fähigkeiten des jeweiligen Clients richten soll. Und das ziehe ich auch konsequenter durch, als so mancher andere (z.B. soll es hier auch User geben, die gar nicht mehr abfragen, ob es sich um einen DOM-fähigen/HTML-4-Browser handelt, sondern dies ungefragt voraussetzen - ich will ja keine Namen nennen ... >;-)).

Davon abgesehen gibt es aber *mind.* 4 Dinge zu bedenken:

1. Es ist für statistische Zwecke durchaus interessant zu wissen, mit welchem Browser die eigene Zielgruppe wie unterwegs ist. (Nebenbei ist da vielleicht auch noch interessant, wieviele User ihre Browser via UA "tarnen".)

2. Auch Browser haben schlichtweg Bugs. Man kann sich auf den Standpunkt stellen: "Was interessieren mich die Bugs? Sollen die User doch updaten. Das ist nicht mein Problem!" Man kann sich aber auch auf den Standpunkt stellen: Wenn ich einen (zumindest wirklich ärgerlichen) Bug kenne, dann kann (nicht muß) ich auch ihn auch mal berücksichtigen. Denn man kann ja bekanntlich nicht davon ausgehen, daß alle User ihre Browser regelmäßig updaten wollen oder können.

Sowohl wg. 1) (hauptsächlich) als auch wg. 2) (gelegentlich) setze ich dieses Mittel ein.

3. Die Browserhersteller haben sich vermutlich was dabei gedacht. Sowohl, daß sie "allg. UAs" einbauen (bzw. dem User ermöglichen, eigene UAs zu definieren), als auch dabei, daß sie jenseits des UAs eine verläßliche Erkennungsmöglichkeit bieten. Die Abfrage dessen ist auch kein "Hack", sondern (zumindest im Fall von Konqueror und Opera) "offiziell garantiert" (bei Safari & Google habe ich leider noch nichts offizielles finden können - was auch der jeweils vergleichsweise schlechten Doku zugeschrieben werden mag).
*Was* sich die Browserprogrammierer dabei (sonst noch?) gedacht haben, kann ich vermuten (s.o.), wissen tue ich es nicht.

4. Ich bin ja kein Freund von Dogmen. Diese Methode geht, sie ist vorgesehen, und ich bin nicht Gott, der alles weiß, und anderen Wissen vorenthält, weil ich das selbst nicht nutzen möchte. Wenn Du dir (für dich oder allg.) keinen Anwendungsfall vorstellen möchtest oder kannst, bitte sehr. Ich lasse die Entscheidung darüber (durchaus nebst entsprechenden "Belehrungen" - s.o.) dem jeweiligen Programmierer, um dessen jeweiligen Problemfall ich konkret nicht weiß, und wo auch meine Phantasie nicht ausreicht, mir vorzustellen, was alles möglich ist. Ich sehe mich schlicht nicht im Stande, weise Ratschläge zu geben, für Dinge, die ich nicht kenne (aber die vielleicht andere bedrückt).

Ich kann mich nur wiederholen.

Was es nicht sinnvoller macht.

Gruß, Cybaer

[molily]

Hallo,

1. Es ist für statistische Zwecke durchaus interessant zu wissen, mit welchem Browser die eigene Zielgruppe wie unterwegs ist. (Nebenbei ist da vielleicht auch noch interessant, wieviele User ihre Browser via UA "tarnen".)

Ja, für solche Zwecke verwende ich u.a. vendor-Abfragen. (An so etwas habe ich erst in den letzten Tagen gearbeitet.) Der Unterschied ist eben, dass von Browsererkennung im Rahmen einer Statistik nichts abhängt. Wenn ich den Browser falsch erkenne, kann ich noch andere Heuristiken anwenden (HTTP-UA, navigator.userAgent, sonstige Objekte ...), und wenn letztlich alles schiefläuft, habe ich eine minimal fehlerhafte Statistik, aber mehr nicht. Von einer solchen Erkennung würde ich aber nur im Notfall eine Funktionalität einer Site abhängig machen.

2. Auch Browser haben schlichtweg Bugs. Man kann sich auf den Standpunkt stellen: "Was interessieren mich die Bugs? Sollen die User doch updaten. Das ist nicht mein Problem!"

Ältere Versionen anzusprechen finde ich »safe« - sie sind abgeschlossen und da tut sich nichts mehr. Man kann daher Kriterien suchen, anhand derer eine recht zuverlässige Erkennung möglich ist.

Schwierig wird es, wenn zum Zeitpunkt des Schreiben des Scriptes noch kein Fix existiert, aber auch keine Fähigkeitenabfrage möglich ist. Dann bleibt einem nichts anderes übrig, als »Zeitbomben« im Script unterzubringen.

Wenn man mal die Arbeit z.B. von Opera verfolgt, dann zeigen sich große Probleme dabei, mit den Betreiber großer Sites zusammenzuarbeiten. Die haben nämlich irgendwann, als sie einen Fehler in einer aktuellen Opera-Version festgestellt haben, ein if (window.opera) eingebaut. (Und leider war das manchmal nötig - die Betreiber haben nicht einfach gepfuscht.) Der Fehler ist längst behoben, aber die Site funktioniert im korrigierten Opera immer noch nicht. Das nervt Opera-Anwender und Opera Software bricht sich einen ab, die Betreiber dazu zu bringen, die Browserabfragen herauszuwerfen.

3. Die Browserhersteller haben sich vermutlich was dabei gedacht. Sowohl, daß sie "allg. UAs" einbauen (bzw. dem User ermöglichen, eigene UAs zu definieren), als auch dabei, daß sie jenseits des UAs eine verläßliche Erkennungsmöglichkeit bieten.

Nunja, da gilt eben nur für Opera mit dem window.opera-Objekt. In den anderen Fällen ist es letztlich Heuristik: Chrome ist in der Erkennung definiert als Browser von Google Inc. (okay, das scheint recht eindeutig, solange Google keinen weiteren veröffentlicht) und Safari ist definiert als Gecko von Apple (das geht nicht wirklich auf).

Die Abfrage dessen ist auch kein "Hack", sondern (zumindest im Fall von Konqueror und Opera) "offiziell garantiert" (bei Safari & Google habe ich leider noch nichts offizielles finden können - was auch der jeweils vergleichsweise schlechten Doku zugeschrieben werden mag).

Es gibt einfach nichts entsprechendes, das ist auch deren Politik.

Ich lasse die Entscheidung darüber (durchaus nebst entsprechenden "Belehrungen" - s.o.) dem jeweiligen Programmierer, um dessen jeweiligen Problemfall ich konkret nicht weiß, und wo auch meine Phantasie nicht ausreicht, mir vorzustellen, was alles möglich ist. Ich sehe mich schlicht nicht im Stande, weise Ratschläge zu geben, für Dinge, die ich nicht kenne (aber die vielleicht andere bedrückt).

Die Logik geht nicht auf. Indem man allgemeine Browsererkennungsscripte publiziert, ohne die Problemfälle zu betrachten, gibt man doch weise Ratschläge. Man publiziert eine Lösung für Probleme, die man gar nicht kennt, verspricht aber implizit, es sei irgendwie eine adäquate Lösung (»die Erkennung ist zuverlässig«). Gerade weil ich mir nicht vorstellen kann, »was alles möglich ist«, gaukle ich niemandem vor, ich könne eine Landkarte von Terra Incognita zeichnen.

Seit z.B. Bibliotheken eine solche Infrastruktur zur Verfügung stellen, wird sie auch allerorten benutzt. Da kann man siebenunddreißig Disclaimer in die Doku schreiben - das Know-How hinsichtlich browserübergreifende JavaScript-Programmierung ist einfach zu spärlich gesät, als dass die Disclaimer fruchten könnten.

Mathias

[Cybaer]

Hi,

Wenn man mal die Arbeit z.B. von Opera verfolgt, dann zeigen sich große Probleme dabei, mit den Betreiber großer Sites zusammenzuarbeiten.

Ja, ist gibt sehr viel schlechten Code im Netz. Keine neue Erkenntnis.

Nunja, da gilt eben nur für Opera mit dem window.opera-Objekt. In den anderen Fällen ist es letztlich Heuristik:

Du irrst. In der Konqueror-Doku steht z.B., daß, egal was kommt, der vendor immer "KDE" sein wird.

Die Logik geht nicht auf. Indem man allgemeine Browsererkennungsscripte publiziert, ohne die Problemfälle zu betrachten, gibt man doch weise Ratschläge. Man publiziert eine Lösung für Probleme, die man gar nicht kennt, verspricht aber implizit, es sei irgendwie eine adäquate Lösung (»die Erkennung ist zuverlässig«).

Nein, man publiziert ein Werkzeug. Und jeder Webautor steht nach wie vor in der Pflicht, ihm zur Verfügung stehende Werkzeuge mit Sinn & Verstand zu nutzen (was eben auch heißt, ggf. nicht zu nutzen).

Die alte "Messerdiskussion": Bin ich als Messerhersteller verantwortlich dafür, daß damit jemand abgestochen wird? Soll ich keine Messer herstellen, weil damit nicht nur Leben gerettet oder Zwiebeln geschält, sondern auch Menschen umgebracht werden?

Seit z.B. Bibliotheken eine solche Infrastruktur zur Verfügung stellen, wird sie auch allerorten benutzt. Da kann man siebenunddreißig Disclaimer in die Doku schreiben - das Know-How hinsichtlich browserübergreifende JavaScript-Programmierung ist einfach zu spärlich gesät, als dass die Disclaimer fruchten könnten.

Wer schlecht programmieren "will", der wird das immer können. Und wer es tut, der wird seine Scripte nicht dadurch verbessern, wenn er an einer Stelle etwas richtig macht, aber den Rest immer noch falsch ...

Gruß, Cybaer

PS: Dein Hinweis liest sich ein bißchen so wie: Manche Informationen muß man "verheimlichen", weil die Leute einfach zu doof sind. Das mag zwar sein, aber ich überlasse die Entscheidung dann doch prinzipiell lieber dem jeweiligen Coder. Zumal es nicht um die Steuerung von Atomkraftwerken geht ... =;->

[molily]

Hallo,

Dein Hinweis liest sich ein bißchen so wie: Manche Informationen muß man "verheimlichen", weil die Leute einfach zu doof sind.

Was heißt zu doof - ich sage nur, dass das das Thema Browserweichen vs. Fähigkeitenweichen nicht im Bewusstsein der Webentwickler ist. Und damit liege ich glaube ich nicht falsch.
In den meisten Fällen wird derzeit zur unangemessenen Browserweiche gegriffen. Es ist nicht meine Baustelle, Wissen für den einen Sonderfall unter 100 zu produzieren, in dem eine Browserweiche tatsächlich nötig ist. Und überall, wo ich dieses Thema beackert sehe, kommt in der Regel Unerfreuliches und technisch Fehlerhaftes heraus. In Krisengebiete werden keine Dual-User-Güter geliefert, wenn ich deinen Vergleich mal aufnehmen darf.

Mathias

[Cybaer]

Hi,

Was heißt zu doof - ich sage nur, dass das das Thema Browserweichen vs. Fähigkeitenweichen nicht im Bewusstsein der Webentwickler ist. Und damit liege ich glaube ich nicht falsch.

Sicherlich nicht. Kann nur, wie immer, an mangelhaften Quellen liegen, die es falsch vormachen.

In den meisten Fällen wird derzeit zur unangemessenen Browserweiche gegriffen. Es ist nicht meine Baustelle, Wissen für den einen Sonderfall unter 100 zu produzieren, in dem eine Browserweiche tatsächlich nötig ist.

Ich brauche es, das Wissen existiert bei mir, also kann ich es auch veröffentlichen. Und falls es dazu führt, daß stattdessen ein User eine bessere Browserweiche statt einer schlechteren verwendet, dann ist das zwar nicht Ziel der Sache, aber letztlich auch ein Fortschritt - selbst wenn ihm immer noch nicht bewußt sein sollte, daß er eigentlich gar keine Browserweiche braucht.

In Krisengebiete werden keine Dual-User-Güter geliefert, wenn ich deinen Vergleich mal aufnehmen darf.

Ja, aber dort geht es auch um Menschenleben. Wir reden hier von Websites, die offensichtlich auch so in hoher Zahl fehlerhaft sind.

Ich surfe jedenfalls nicht mit Standardeinstellungen durchs Web, und wundere mich doch immer wieder aufs neue, daß man selbst auf Websites IT-affiner Firmen (z.B. www.chip.de) massiv über JS-Fehler stolpert (die der Normaluser sich halt nicht anzeigen läßt - und der Webentwickler, bzw. der Verantwortliche für die Abnhame, anscheinend auch nicht). Browser-"Erkennung" aufgrund des UAs ist auch ein gern verwendetes Mittel - wie man sehen kann, wenn man mit einem unüblichen UA surft. Bei IT-affinen Firmen wundert mich das umso mehr, da solche Vorgehensweisen duchaus Zweifel an ihrer generellen IT-Kompetenz aufkommen läßt. Die anderen haben halt "nur" "komische" Seiten ...

Gruß, Cybaer