Re: Bildobjekt "onerror" Event-Handler Problem auf KHTML basierten Browsern
- From: Thomas 'PointedEars' Lahn <PointedEars@xxxxxx>
- Date: Mon, 28 Nov 2005 16:16:06 +0100
Daniel Kabs wrote:
> Thomas 'PointedEars' Lahn wrote:
> >> [Browser DOM]
>>> Letzteres sollte - dank der Bemühungen um eine Standardisierung - das
>>> W3C-DOM sein.
>> Nein.
>
> Verstehe, du bemängelst das Fehlen des Wörtchens "mindestens" vor "das
> W3C-DOM" in meinem Satz, schätze ich.
<kosh> Nein. </kosh>
>> Wenn Du Dich auf das W3C-DOM beschränktest, könntest Du viele Sachen
>> nicht machen, die bei Scripting von UAs ganz normal sind. Image() ist da
>> ein eher harmloses Beispiel:
>>
>> Wo im W3C-DOM ist `(window.)document' definiert? Siehste. Dort sind nur
>> Interfaces wie Document und HTMLDocument definiert, die zum Teil von den
>> realen, im Kern _natürlich_ proprietären DOMs implementiert werden.
>> Damit sind dann so schöne Dinge wie document.getElementById() möglich.
>
> Um bei deinem Beispiel `(window.)document' zu bleiben, ich verstehe das
> so:
>
> Wie du schreibst, das W3C-Dom definiert das Interface, hier also das
> "Interface Document: The Document interface represents the entire HTML
> or XML document. Conceptually, it is the root of the document tree,
> and provides the primary access to the document's data.", siehe:
>
> http://www.w3.org/TR/DOM-Level-2-Core/core.html#i-Document
>
> Und ein Browser implementiert es unter dem globalen Objekt window als
> Eigenschaft document.
Nein, es werden anscheinend Teile von W3C-DOM-Interfaces in Browser-DOMs
implementiert. Dass das nicht immer so ist, zeigt z.B. setAttribute().
> Damit hat man "window.document".
Aber z.B. document.all gibt es im Gecko- IE- und Opera-DOM.
> W3C konforme Browser zeichnen sich nun dadurch aus, dass window.document
> die Methode getElementById() kennt, ganz so wie man es aus der
> Spezifikation erwarten würde -> window.document.getElementById()
Es gibt genaugenommen keine 100% W3C-DOM-konformen Browser, da diese
nicht nutzbar wären. Darauf wollte ich (Dich) aufmerksam machen.
Die Argumentation "nicht W3C-DOM-konform = böse[tm]" ist unlogisch.
> Deine Frage "Wo im W3C-DOM ist `(window.)document' definiert?" ist also
> falsch gestellt, weil sie in der Spezifikation des Interfaces nach der
> Implementation sucht.
Nein, beachte den Kontext dieser rhetorischen Frage.
>>> Damit sollte man die Frage beantworten können, ob nach
>>> diesem Standard das Image Object einen onerror Event-Handler hat.
>>
>> Nein, da es dort gar kein Image-Objekt gibt. Es gibt dort nur ein
>> HTMLImageElement-Interface.
>
> Gut, "Image Object" ist kein Begriff aus der Spezifikation, aber um die
> Wörter will ich mich jetzt nicht schlagen. Na dann ersetze in meiner
> Aussage "Image Object" mit "HTMLImageElement".
Es gibt kein HTMLImageElement-Objekt im W3C-DOM. Es gibt ein
HTMLImageElement-Interface und dieses hat nicht die Attribute
`onload' oder `onerror'. Es hat aber auch nicht das Attribut
`onclick', dennoch haben Element-Objekte für img-Elemente
diese Eigenschaft in Browsern, die Du oben als W3C-DOM-konform
bezeichnest bzw. wird sie unterstützt. Das liegt daran, dass
Abwärtskompatibilität zu DOM Level 0 den Browserherstellern
wichtiger war.
>>>In letzterem steht:
>>>|1.6.5. HTML event types
>>>|
>>>| The HTML event module is composed of events listed in HTML 4.0 and
>>>| additional events which are supported in DOM Level 0 browsers.
>>>
>>>| und weiter zum Event-Typ "error" The error event occurs when an image
>>>| does not load properly or when an error occurs during script
>>>| execution. This event is valid for OBJECT elements, BODY elements,
>>>| and FRAMESET element.
>>>| >>>
>>>
>>> Schätze mal, das ist ein Nein. Super :-(
>>
>> Das "Nein" findest Du noch viel früher. Was aber nicht heisst, dass es
>> ein "Ja" bezüglich des DOMs nicht geben darf. "DOM" ist eben nicht
>> beschränkt auf "W3C-DOM", und das war es auch noch nie.
>
> Der frühe Vogel findet das "Nein" wo genau?
Siehe oben.
>>> Was bringt die ganze Standardisierung, wenn die grundlegenden Dinge vom
>>> "Quasi-Standard" DOM Level 0 nicht übernommen wurden?
>>
>> Wenn Du mal W3C-DOM Level 2 HTML genau liest, wirst Du feststellen,
>> dass dort viele Dinge von "DOM Level 0" übernommen wurden.
>
> Meiner Meinung nach ist vom "DOM Level 0" zu wenig übernommen worden,
> wie gerade das Beispiel der fehlenden onload und onerror Handler beim
> HTMLImageElement zeigen.
*** happens. Vielleicht gibt es ja nochmal ein W3C DOM Level 3 HTML.
> nur gibts keine Spezifikationen von "DOM Level 0", wohl weil Level 0
> noch vor der Zeit der Standardisierung war und damals jeder Browser sein
> eigens DOM-Süppchen gekocht hat.
Richtig. Die weitverbreitetsten DOM-Features der Browser, die sie
seit NN3 und IE3 haben, bilden den Quasi-Standard "DOM Level 0".
PointedEars
.
- Follow-Ups:
- References:
- Bildobjekt "onerror" Event-Handler Problem auf KHTML basierten Browsern
- From: Daniel Kabs
- Re: Bildobjekt "onerror" Event-Handler Problem auf KHTML basierten Browsern
- From: Thomas 'PointedEars' Lahn
- Re: Bildobjekt "onerror" Event-Handler Problem auf KHTML basierten Browsern
- From: Daniel Kabs
- Re: Bildobjekt "onerror" Event-Handler Problem auf KHTML basierten Browsern
- From: Thomas 'PointedEars' Lahn
- Re: Bildobjekt "onerror" Event-Handler Problem auf KHTML basierten Browsern
- From: Daniel Kabs
- Re: Bildobjekt "onerror" Event-Handler Problem auf KHTML basierten Browsern
- From: Thomas 'PointedEars' Lahn
- Re: Bildobjekt "onerror" Event-Handler Problem auf KHTML basierten Browsern
- From: Daniel Kabs
- Bildobjekt "onerror" Event-Handler Problem auf KHTML basierten Browsern
- Prev by Date: Re: Bildobjekt "onerror" Event-Handler Problem auf KHTML basierten Browsern
- Next by Date: Re: Bildobjekt "onerror" Event-Handler Problem auf KHTML basierten Browsern
- Previous by thread: Re: Bildobjekt "onerror" Event-Handler Problem auf KHTML basierten Browsern
- Next by thread: Re: Bildobjekt "onerror" Event-Handler Problem auf KHTML basierten Browsern
- Index(es):