Software Unterscheidung deaktiviertes JS/ kennt kein JS

[Dennis the Menace]

Moin Jungs und Mädels,

morgen darf ich eine hochspannende "Praxis der Softwareentwicklung II" Klausur schreiben und mein Prof war der Meinung, uns mit lustigen HTML/JS Fragen zu behelligen. So weit so einfach.

Eine Aufgabe hinterlässt bei mir aber noch nen Fragezeichen:
Wie kann erreicht werden, dass ein nicht Javascript-fähiger Browser - und nur ein solcher! - eine untenstehende (Ersatz-)Erläuterung ausgibt."

Darunter ist dann ein screenie zu sehn mit Text ala "Ihr Browser ist zu blöd...bla".

Klingt einfach, erstmal.

Genauer betrachtet wird hier aber eine Unterscheidung zwischen dem Fall, dass JS deaktiviert ist und dem Fall, dass der Browser JS garnicht kennt, verlangt. Das ist meines wissens nicht umsetzbar.

Jetzt die Frage...der ist blöder? Ich oder mein Prof.?

Bitte um Erleuchtung. :-)

Gruß Dennis

PS: und kommt mir nich mit <noscript> oder location.href = ...
Ersteres wird auch angezeigt, wenn der Browser JS garnicht kann.

[Harlequin]

Yerf!

Darunter ist dann ein screenie zu sehn mit Text ala "Ihr Browser ist zu blöd...bla".

<script type="text/javascript">//"Ihr Browser ist zu blöd...bla"</script>

Sollte eigentlich so ähnlich reagieren.

Gruß,

Harlequin

[Sven Rautenberg]

Moin!

Yerf!

Darunter ist dann ein screenie zu sehn mit Text ala "Ihr Browser ist zu blöd...bla".

<script type="text/javascript">//"Ihr Browser ist zu blöd...bla"</script>

Sollte eigentlich so ähnlich reagieren.

Nicht wirklich. Das Script-Element ist in HTML ja dazu da, Scriptcode zu enthalten. Und egal ob der Browser nun kein Javascript interpretiert, oder ob Javascript nur deaktiviert ist, ist das korrekte Parser-Ergebnis des Script-Elements nunmal kein sichtbarer Text.

Nur wirklich uralte Browser, die kein HTML 4 und kein HTML 3.2 können, kennen das Script-Element nicht und verhalten sich daher wie laut HTML-Standard bei unbekannten Elementen vorgeschrieben: Tags ignorieren, Inhalt anzeigen. Deshalb hat man früher den Elementinhalt in HTML-Kommentare eingeklammert, damit diese Browser keinen unerwünschten Text anzeigen.

- Sven Rautenberg

[Harlequin]

Yerf!

Nur wirklich uralte Browser, die kein HTML 4 und kein HTML 3.2 können, kennen das Script-Element nicht und verhalten sich daher wie laut HTML-Standard bei unbekannten Elementen vorgeschrieben: Tags ignorieren, Inhalt anzeigen. Deshalb hat man früher den Elementinhalt in HTML-Kommentare eingeklammert, damit diese Browser keinen unerwünschten Text anzeigen.

Jetzt stellt sich die Frage, ob es Browser gibt, die kein JS können, aber trotzdem den <script>-Tag verstehen... vermutlich schon. Aber irgendwie ist die Aufgabe eh komisch.

Gruß,

Harlequin

[Sven Rautenberg]

Moin!

Jetzt stellt sich die Frage, ob es Browser gibt, die kein JS können, aber trotzdem den <script>-Tag verstehen... vermutlich schon. Aber irgendwie ist die Aufgabe eh komisch.

Lynx beispielsweise.

- Sven Rautenberg

[Don P]

Hallo,

<script type="text/javascript">//"Ihr Browser ist zu blöd...bla"</script>

Sollte eigentlich so ähnlich reagieren.

Genau. Wenn Der Browser kein Javascript kann, dann zeigt er den Text zwischen den script-Tags trotzdem an. Wenn er Javascript kann, dieses aber nur deaktiviert ist, dann zeigt er Text natürlich nicht an, weil alles zwischen den script-Tags als Script angesehen und ignoriert wird. Wenn JavaScript aktiviert ist, wird trotzdem nichts angezeigt, weil gar kein Code vorhanden ist, nur der Kommentar //Ihr Browser...

Das wäre doch genau das gewünschte Verhalten, oder?

Gruß, Don P

[Sven Rautenberg]

Moin!

<script type="text/javascript">//"Ihr Browser ist zu blöd...bla"</script>

Sollte eigentlich so ähnlich reagieren.

Genau. Wenn Der Browser kein Javascript kann, dann zeigt er den Text zwischen den script-Tags trotzdem an.

Nein, eben nicht. Auch javascriptunfähige Browser kennen trotzdem das <script>-Tag und wissen, dass sie alles dazwischen komplett ignorieren müssen, es auch nicht dem Benutzer anzeigen. Soviel Javascript können sie dann doch - wobei <script> ja nicht nur Javascript enthalten kann, sondern grundsätzlich jede denkbare Skriptsprache.

Denk dir nur mal einen Browser, der kein Visual Basic Script kann - der zeigt ja den Inhalt eines <script>-Elements auch nicht einfach an, nur weil er zufällig Javascript doch beherrscht.

- Sven Rautenberg

[Sven Rautenberg]

Moin!

PS: und kommt mir nich mit <noscript> oder location.href = ...
Ersteres wird auch angezeigt, wenn der Browser JS garnicht kann.

Es muß also ein Unterscheidungsfall getroffen werden für
a) Browser kann gar kein Javascript, man kann es auch nicht einschalten
b) Browser könnte zwar Javascript, es ist aber deaktiviert.

Da in beiden Fällen das Ausführen von Skripten nicht funktioniert, kann man mit Javascript nichts erreichen.

In beiden Fällen werden auch, wie du richtig erkannt hast, <noscript>-Bereiche aktiv werden.

Die wirklich einzige denkbare Möglichkeit wäre, serverseitig den User-Agent auszuwerten und durch Wissen aus anderen Quellen zu extrapolieren, dass der gerade anfragende Browser wohl grundsätzlich Javascript könnte, oder eben nicht - und dann die Meldung im <noscript> entsprechend formulieren.

Ansonsten bin ich auf die Lösung deines Lehrers gespannt... :)

- Sven Rautenberg

[Cybaer]

Hi,

Die wirklich einzige denkbare Möglichkeit wäre, serverseitig den User-Agent auszuwerten

IIRC laden Browser die JS (ab 1.1) beherrschen auf jeden Fall externe Scripte - sie werden ggf. nur nicht ausgeführt. Darüber könnte man eine Fallunterscheidung machen, ähnlich wie ich sie mal in einem PHP-Script für HTTP-1.1-Clients benutzt habe, bei der PHP innerhalb eines einzigen User-Requests feststellen kann, ob der Browser JS beherrscht, oder nicht beherrscht, oder beherrscht, aber JS deaktiviert ist: Kann mein Browser JS? (Main-Source & Sub-Source zur Anschauung - bei den *nicht veröffentlichten* Funktionen sollte anhand des Namens klar sein, was sie tun).

Zuerst hatte ich die Fallunterscheidung über eine externe JS-Datei festmachen wollen, aber das scheiterte, da sie immer geladen wurde, auch wenn JS abgeschaltet war. Trotzdem kann man das nutzen.

Ich fand es dann aber sinnvoller, mit OBJECT bzw. auch noch EMBED zu testen - davon ausgehend, das ein Multimedia-Browser üblicherweise auch JS können wird.

Mein PHP-Script unterscheidet also nach den Stati

• Uralt-Browser bzw. Bot ohne JS
• Moderner Browser mit deaktiviertem JS
• Moderner Browser mit aktiviertem JS

wobei das Script auch explizit wartet, bis der Benutzer ggf. das Scripting erlaubt oder ablehnt (zumindest der IE bietet ja optional die Möglichkeit, den Benutzer jedesmal entscheiden zu lassen, ob er ein JS/ActiveX/... zulassen möchte oder nicht).

Ansonsten bin ich auf die Lösung deines Lehrers gespannt... :)

Ich also weniger. ;-)

Eher gespannt, ob er es anders löst, und wenn ja: wie.

Gruß, Cybaer

[Sven Rautenberg]

Moin!

Mein PHP-Script unterscheidet also nach den Stati

• Uralt-Browser bzw. Bot ohne JS
• Moderner Browser mit deaktiviertem JS
• Moderner Browser mit aktiviertem JS

Dein PHP-Skript weiß zu dem Zeitpunkt, an dem es die Seite generiert, noch nicht, ob ein im HTML-Quellcode referenziertes Javascript evtl. geladen wird, oder nicht.

- Sven Rautenberg

[Cybaer]

Hi,

Dein PHP-Skript weiß zu dem Zeitpunkt, an dem es die Seite generiert, noch nicht, ob ein im HTML-Quellcode referenziertes Javascript evtl. geladen wird, oder nicht.

Natürlich nicht. Das soll ja auch herausgefunden werden. >;->

Im Ernst: Wie bitte? Es "weiß" es zu Beginn (also im ersten Teil) nicht. Im Zweiten Teil, dann, wenn der eigentliche Content generiert ist, weiß das Script das schon (udn teilt das Ergebnis ja auch mit) - oder eben nicht, wenn es kein Multimedia-Client (der also EMBED odr OBJECT "normal" nutzt) ist.

Was Du also wolle sagen? :-o

Gruß, Cybaer

[Sven Rautenberg]

Moin!

Dein PHP-Skript weiß zu dem Zeitpunkt, an dem es die Seite generiert, noch nicht, ob ein im HTML-Quellcode referenziertes Javascript evtl. geladen wird, oder nicht.

Natürlich nicht. Das soll ja auch herausgefunden werden. >;->

Das kann es aber in diesem Request nicht herausfinden, weil es ja für die Generierung des HTMLs zuständig ist, nicht für die Generierung des Javascripts. Das wird erst viel später vom Browser abgerufen.

- Sven Rautenberg

[Cybaer]

Hi,

Das kann es aber in diesem Request nicht herausfinden, weil es ja für die Generierung des HTMLs zuständig ist, nicht für die Generierung des Javascripts.

(seufz) OK, hast mich erwischt! Das Script errät nur *zufällig* den aktuellen Status! (Hmm, das klingt ja noch genialer: Artificial Hokuspokus ;-))

Im Ernst: Ich schrieb ja nicht "innerhalb eines einzigen Requests", sondern "innerhalb eines einzigen *User*-Requests"! Nun mag man darüber streiten, was ein "User-Request" denn überhaupt ist. Ich wollte damit nur verdeutlichen, daß der User einen (üblichen) Request absetzt und *innerhalb* dieses Requests wird die Frage beantwortet - mithilfe von vom Script via ausgegebenem HTML-Code generierten Sub-Requests (deswegen auch Main-Script und Sub-Script).

Das wird erst viel später vom Browser abgerufen.

Jojo. =%-) "viel später" bedeutet hier "noch vor Beendigung des User-Requests bereits beendet" (oder auch Initial-Request, falls Du dich mit dem Begriff eher anfreunden kannst). Das ist ja echt mächtig "viel später" ... (kopfschüttel)

Also: Die Sub-Requests starten (natürlich) später, sind aber eher fertig als der Initial-Request. Da finde ich die Formulierung "viel später" etwas unpassend. %-)
Zumal das ganze in weniger als einer halben Sekunde erledigt ist. Leidest Du unter Zeit-Dilatation? ;-)

Gruß, Cybaer

[Sven Rautenberg]

Moin!

Das kann es aber in diesem Request nicht herausfinden, weil es ja für die Generierung des HTMLs zuständig ist, nicht für die Generierung des Javascripts.

(seufz) OK, hast mich erwischt! Das Script errät nur *zufällig* den aktuellen Status! (Hmm, das klingt ja noch genialer: Artificial Hokuspokus ;-))

Im Ernst: Ich schrieb ja nicht "innerhalb eines einzigen Requests", sondern "innerhalb eines einzigen *User*-Requests"! Nun mag man darüber streiten, was ein "User-Request" denn überhaupt ist. Ich wollte damit nur verdeutlichen, daß der User einen (üblichen) Request absetzt und *innerhalb* dieses Requests wird die Frage beantwortet - mithilfe von vom Script via ausgegebenem HTML-Code generierten Sub-Requests (deswegen auch Main-Script und Sub-Script).

Nur nochmal zur Klarstellung: Gefordert ist, dass der Browser anzeigt, ob er selbst gerade Javascript aktiviert hat oder nicht, und falls nicht, ob er Javascript grundsätzlich könnte, oder nicht.

Über das Thema "Javascript aktiviert oder nicht" streiten wir uns ja nicht, das geht prima Oldschool mit document.write() und <noscript>.

Und die Frage "könnte er Javascript oder nicht" ist noch offen. Wie willst du das hinkriegen? Die Option "nachgucken, ob er ein eingebundenes externes Javascript vielleicht doch lädt" besteht nicht, weil Browser das nicht tun (von eventuellen Ausnahmen abgesehen), damit ist also keine zuverlässige Ausgabe möglich. Und selbst wenn das für die Ausnahmefälle doch ginge, mußt du ja innerhalb des Servers zwischen zwei zu bearbeitenden Requests kommunizieren können, was aber keinesfalls garantiert werden kann, denn die Zahl paralleler Requests ist browserseitig ebenfalls begrenzt, der Browser kann genausogut alle Requests seriell abarbeiten. Damit bekämst du keinerlei Einflußmöglichkeit mehr auf die HTML-Seite, solltest du einen JS-Abruf feststellen. Das gilt übrigens auch für jegliche Art von Sessionmechanik, die man für diesen Zweck einsetzen könnte.

Also: Die Sub-Requests starten (natürlich) später, sind aber eher fertig als der Initial-Request. Da finde ich die Formulierung "viel später" etwas unpassend. %-)

Nein, das ist keinesfalls garantiert - im Gegenteil sogar sehr unwahrscheinlich. Guck dir einfach mal zur Illustration die Ladezeit-Darstellung in Firebug an.

Zumal das ganze in weniger als einer halben Sekunde erledigt ist. Leidest Du unter Zeit-Dilatation? ;-)

Der absolute Verbrauch an menschlicher Lebenszeit ist für die Betrachtung der Vorgänge nicht relevant.

- Sven Rautenberg

[Cybaer]

Hi,

Über das Thema "Javascript aktiviert oder nicht" streiten wir uns ja nicht, das geht prima Oldschool mit document.write() und <noscript>.

Wobei hier, ganz Oldschool, sogar noch strenggenommen zu bedenken wäre, daß NS2 kein NOSCRIPT kennt. %-)

Und die Frage "könnte er Javascript oder nicht" ist noch offen.

Ja. Und ich denke, daß das "üblicherweise" in "davon ausgehend, daß ein Multimedia-Browser üblicherweise auch JS können wird" auch schon deutlich zum Ausdruck bringt, daß man keine 100%-ige Gewissheit bekommt.

Es könnte z.B. auch ein HTTP-1.0-Client sein, der keine chunked data beherrscht. Und theroretisch könnte dieser Client sogar JS beherrschen.

Nur: Für die Praxis reicht's IMHO - üblicherweise. ;->

was aber keinesfalls garantiert werden kann, denn die Zahl paralleler Requests ist browserseitig ebenfalls begrenzt,

Aber üblicherweise nicht auf 1 sondern eher nach oben begrenzt.

Nein, das ist keinesfalls garantiert - im Gegenteil sogar sehr unwahrscheinlich. Guck dir einfach mal zur Illustration die Ladezeit-Darstellung in Firebug an.

Ich kenne niemanden, der mit dem Firebug surft. Ich kenne nur z.B. Firefox-Surfer.

Der absolute Verbrauch an menschlicher Lebenszeit ist für die Betrachtung der Vorgänge nicht relevant.

Relevant ist, wie schnell die Seite kommt, damit der Surfer sie zur Betrachtung hat. ;-)

Gruß, Cybaer

[Blaubart]

Tach.

IIRC laden Browser die JS (ab 1.1) beherrschen auf jeden Fall externe Scripte - sie werden ggf. nur nicht ausgeführt.

Das trifft auf Opera definitiv nicht zu. Wenn JS deaktiviert ist, werden externe Skripte nicht geladen, was ich auch sehr vernünftig finde. Beim Firefox bin ich mir nicht ganz sicher, glaube aber, daß der das genauso handhabt ...

[Alexander (HH)]

Moin Moin!

IIRC laden Browser die JS (ab 1.1) beherrschen auf jeden Fall externe Scripte - sie werden ggf. nur nicht ausgeführt.

Das trifft auf Opera definitiv nicht zu. Wenn JS deaktiviert ist, werden externe Skripte nicht geladen, was ich auch sehr vernünftig finde. Beim Firefox bin ich mir nicht ganz sicher, glaube aber, daß der das genauso handhabt ...

Alles andere wäre auch ziemlich blöd. Warum sollte der Browser eine Resource anfordern, die er gar nicht benutzen darf?

Mein Firefox 2.0.0.11 unter Windows lädt bei abgeschaltetem Javascript definitiv die externen Scripte NICHT nach. Mein IE 6.0.28000.1106 ebenfalls nicht. Genauso wenig mein Opera 9.24.

Alexander

[Cybaer]

Hi,

Mein Firefox 2.0.0.11 unter Windows lädt bei abgeschaltetem Javascript definitiv die externen Scripte NICHT nach. Mein IE 6.0.28000.1106 ebenfalls nicht. Genauso wenig mein Opera 9.24.

Wie hast Du das festgestellt? Denn ich mag mich nicht für alle Browser festlegen, aber ausprobiert habe ich es ja (mit einem PHP-generiertem JS, wobei das PHP-Script beim Aufruf eine Datei beschrieben hat - halt wie im endgültigen Script die EMBED- & OBJECT-Resourcen). Und mindestens bei einem der drei hat er trotz deaktiviertem Script geladen. Getestet hatte ich das mindestens mit dem IE 6, da der IE IMHO am "verzwickelsten" war. Er läßt ja JS auch "on demand" zu.

Oder war das bereits bei "on demand"? Ach, das Alter ... >;->

Gruß, Cybaer

[Alexander (HH)]

Moin Moin!

Hi,

Mein Firefox 2.0.0.11 unter Windows lädt bei abgeschaltetem Javascript definitiv die externen Scripte NICHT nach. Mein IE 6.0.28000.1106 ebenfalls nicht. Genauso wenig mein Opera 9.24.

Wie hast Du das festgestellt?

HTML-Seite mit <script src="script.js" type="text/javascript">, Javascript im Browser abgeschaltet, tail -f /opt/apache2/logs/access.log, Zugriff auf die HTML-Seite. Und siehe da, script.js wird nicht geladen.

Alexander

[Glory]

Interpretieren denn Browser, die kein Javascript kenne, die <noscript> Tags? Wenn nicht, könnte man zumindest zwischen "kann kein Javascript, kenne kein Javascript(, erlaube kein Javascript)" und "kann Javascript, kenne Javascriptm, erlaube kein Javascript" unterscheiden.

Dafür fügst du irgendwo im Quelltext den "Du kannst kein Javascript" Hinweis ein und lässt ihn durch ein <noscript> (div, welches über den Satz gelegt wird) </noscript> ausblenden.

[Don P]

Hallo,

Genauer betrachtet wird hier aber eine Unterscheidung zwischen dem Fall, dass JS deaktiviert ist und dem Fall, dass der Browser JS garnicht kennt, verlangt. Das ist meines wissens nicht umsetzbar.

In ASP geht das angeblich doch. Habe mal folgendes ergoogelt:

Zitat:
----------------
In ASP gibt es für die Erkennung, ob der Browser Javascript-fähig ist, eine Funktion:

  
Dim objBrowser  
Set objBrowser = Server.CreateOBject("MSWC.BrowserType")  
Response.Write("<br>Javascript:" & objBrowser.Javascript)  
Set objBrowser = Nothing  

----------------
Zitat Ende

Und weiter heißt es: "das Ergebnis von einem Javascript fähigen Browser lautet immer true, unabhängig davon ob Javascript aktiviert ist."

Nun, wenn das stimmt, dann müsste es prinzipiell auch möglich sein, mit anderen als ASP-Servern an diese Information zu kommen, weil es eine rein serverseitige Abfrage ist. Wie die das wohl machen?

Gruß, Don P

[Der Martin]

Hi,

In ASP geht das angeblich doch. [...]
Und weiter heißt es: "das Ergebnis von einem Javascript fähigen Browser lautet immer true, unabhängig davon ob Javascript aktiviert ist."

damit sind wir bei serverseitigen Lösungsansätzen - und die können immer nur soviel Information auswerten, wie der Client ihnen überhaupt liefert. Du wärst mit deinem Lösungsvorschlag also (wie alle serverseitigen Lösungen) darauf angewiesen, dass der Client einen User-Agent-Header sendet und darin auch noch eine Kennung übermittelt, die in deiner "Datenbank" vorkommt.
Fehlt dieser Header, der ja im HTTP-Protokoll nicht vorgeschrieben ist, oder enthält er etwas, das du nicht erwartest, kannst du keine Aussage treffen.

Ergo: Dieser Lösungsansatz ist ein Holzweg.

So long,
 Martin

[molily]

Hallo,

Nun, wenn das stimmt, dann müsste es prinzipiell auch möglich sein, mit anderen als ASP-Servern an diese Information zu kommen, weil es eine rein serverseitige Abfrage ist. Wie die das wohl machen?

Wie gesagt, HTTP-User-Agent-Header. Das Stichwort ist übrigens browscap.ini und »Implementationen« gibts in dutzenden Sprachen, darunter PHP.

Mathias

[Don P]

Hallo,

Es gibt anscheinend tatsächlich Möglichkeiten, serverseitig mehr oder weniger sicher festzustellen, ob ein Browser prinzipiell JavaScript unterstützt, auch wenn es deaktiviert ist. Das geht aber über reines HTML und JavaScript hinaus und braucht spezielle serverseitige Implementierungen:

Im Prinzip müssen Informationen über die Fähigkeiten der versch. Browser gesammelt und gepflegt werden, dann kann der Server z.B. durch Zugriff auf eine Datei "browscap.ini" anhand der HTTP-Informationen über der user_agent feststellen, mit wem genau er es zu tun hat und was der im Prinzip alles kann. Für Server mit PHP siehe z.B. hier. ASP habe ich ja schon angesprochen.

Gruß, Don P

[Sven Rautenberg]

Moin!

Es gibt anscheinend tatsächlich Möglichkeiten, serverseitig mehr oder weniger sicher festzustellen, ob ein Browser prinzipiell JavaScript unterstützt, auch wenn es deaktiviert ist.

Der Knackpunkt ist das "mehr oder weniger sicher" deiner Aussage.

Wie brauchbar ist ein Mechanismus, der das "weniger sicher" feststellen kann?

Alle entsprechenden Mechanismen nutzen genau ein Indiz: Den User-Agent-String. Und der ist grundsätzlich als unzuverlässig anzusehen.

- Sven Rautenberg

[Alexander (HH)]

Moin Moin!

Im Prinzip müssen Informationen über die Fähigkeiten der versch. Browser gesammelt und gepflegt werden, dann kann der Server z.B. durch Zugriff auf eine Datei "browscap.ini" anhand der HTTP-Informationen über der user_agent feststellen, mit wem genau er es zu tun hat und was der im Prinzip alles kann. Für Server mit PHP siehe z.B. hier. ASP habe ich ja schon angesprochen.

Spätestens mit wget --user-agent="Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727)" http://www.example.com/javascript-test.php wird mir die Funktion attestieren, dass wget Javascript interpretieren kann.

Alexander