Re: JS Kontext und Einbettung in HTML



Gregor Kofler:
Jan Bruns:

nicht mehr zu rechnen wäre. Welcher Satz an Funktionalität unterstützt
wird, würfeln sich Browserentwickler zurecht

Sich an Standards zu orientieren ist mal kein Fehler. In JS gibt es
zudem die bewährte Methode der "feature detection".

An "Feature detection" denke ich, wenn es um neuartige
Funktionen geht.

(wie willkürlich das ist, zeigt sich z.B. daran, daß ausgerechnet
Firefox seit etlichen Versionen nicht mehr in der Lage ist, grosse
Bilder als einzigen Inhalt eines Frames darzustellen, was noch vor
wenigen Jahren eine absolut gängige, da de facto hochkompatible
Gestaltungsform war).

So? Hab ich wirklich noch *nie* gemacht. Was soll das bringen? Anstelle
von <img src="..." ... > ein <(i)frame src=".."></(i)frame> und im
aufrufenden Dokument ein Image Element? Wo ist da der tiefere Sinn? Kann
man da mal ein Beispiel sehen, wie es "nicht mehr funktioniert"? Wenn
dem so ist: Dann siehst du ja wie "de facto hochkompatibel" das ist/war.

Navigation. CSS funktioniert noch gar nicht so lange zuverlässig genug.
Das war lange Zeit wirklich der grösste gestaltungstechnische gemeinsame
Nenner von IE5.0 und NS4.7.

Hier ein Beispiel. Habe bei diesem anscheinend französischen Bilderhoster,
bei dem ich das Problem schonmal bemerkt habe, mal extra für Dich was
hochgeladen:

http://cjoint.com/?0Hlw2g3KeDx

Hier ein Screenshot davon (mit Iceweasel, die debian-Version von FireFox):

http://abnuto.de/jan/code/cjoint.png

Der bug ist wie gesagt seit etlichen FF-Versionen bekannt/gemeldet.

Was passiert genau beim Laden? Welche Teile des Quelltextes sind
zuverlässig schon funktionsbereit?

Welche Teile des Quelltextes? So der Quelltext sich nicht in externen
Skripten befindet, wird das Skript wohl beim Abarbeiten des Markups
interpretiert.

Ja, daß das wohl so sein wird denke ich auch immer wieder.
Das ist aber eben eine recht dünne begründung, wenn Fehler auftauchen.

Welche HTML-Elemente hat der Browser zuverlässig bereits erzeugt? Usw.

Zuverlässig? Keine. /Wahrscheinlich/ alle bereits wo er schon "drüber"
ist, weswegen Skripte gerne ganz am Ende des Markups eingefügt werden.

Mit der Wirkung, so schwieriger zu findendende, da seltener auftrende
Fehler zu provozieren.


Zu letzterem findet sich in

http://www.w3.org/TR/html4/interact/scripts.html

die schwammige Auskunft:

onload = script [CT]
The onload event occurs when the user agent finishes loading a
window or all frames within a FRAMESET. This attribute may be used
with BODY and FRAMESET elements.

Das ist nicht schwammig. Funktioniert stabil in praktisch allen
Browsern. Der bewährte Fallback, wenn der DOMContentReady event nicht
unterstützt wird.

Die Aussage ist schwammig. Was heisst "das Fenster ist geladen"?

Und selbst wenn es dort eine klarere Festlegung gäbe, ob die Browser
der User es letzlich auch genau so Handhaben, wie oben schon bzgl. des
Jahre alten FireFox-Bugs gesehen:

Das ist die falsche Richtung. Das W3C sagt nur "so soll es sein". Ob
bzw. was die Browser-Hersteller draus machen, ist nicht deren Sache. Für
die Implementierungen der großen Browser gibt es aber umfassende
Dokumentation:

https://developer.mozilla.org/en/
http://msdn.microsoft.com/en-us/library/hbxc2t98%28v=VS.85%29.aspx

Wer will denn heute noch für einzelne Browser schreiben?
Jemand der auch will, daß sein Werk nächstes Jahr nicht mehr eingesehen
werden kann, und somit wieder daran Geld verdienen kann, das ganze
nochmal aufzusetzten?

Auslöser meiner hier gestellten Frage war auch wieder so eine
Unsicherheit, die mich überkam, als etwas nicht ging (war aber letzlich
eine Fehlerkette meinerseits).

Womit wir wieder bei meiner Einleitungszeile wären: Was war denn die
Frage genau?

Das ist ein breiter Satz an Fragen, auf einige davon bist Du gerade
eingegangen mit Worten wie "ist unbekannt, browserspezifisch,
es wird whl so sein". Das beantwortet die Frage.

Gruss

Jan Bruns

--
Ein paar Fotos: http://abnuto.de/gal/
.

Relevant Pages

  • Re: Macro for table problems
    ... and so I'm been using this site from Firefox. ... But at least now I know how to from Safari. ... Yep: Frames are gone :-) Nearly 80 per cent of the site is now converted. ... Beth Rosengard wrote: ...
    (microsoft.public.mac.office.word)
  • Re: Macro for table problems
    ... Back when frames were state of the art, ... Beth Rosengard wrote: ... Paul and John have explained the Safari issue so I won't go into that. ... I can confirm the Firefox printing issue! ...
    (microsoft.public.mac.office.word)
  • Re: Macro for table problems
    ... And he says using frames is poor design to be avoided if possible. ... Paul and John have explained the Safari issue so I won't go into that. ... I can confirm the Firefox printing issue! ...
    (microsoft.public.mac.office.word)
  • Re: 406 Not Acceptable - The new frames!
    ... ....Recently seen a site that rejects Firefox simply for being Firefox. ... Browser racism must end. ... server doesn't have any idea that the browser doesn't support frames. ...
    (comp.infosystems.www.authoring.html)
  • Re: Javascript makes the current directory to change?
    ... All run as expected when I click 'Play' ... make it to not work - frames. ... I am 99% sure that the "joke" comes from Firefox 3. ... fact, I was 75% sure that the problem was in the JavaScript code, so I ...
    (comp.lang.javascript)