Abmessungen eingebetteter Objekte (object + width / height)

    In HTML 4.01 sind beim Object-Element die Attribute width und height erlaubt und sie funktionieren dort genau so wie bei Bildern. Sagt der Standard.
    Nach meinem Verständnis heißt das: Ich kann jedem beliebigen eingebetteten Objekt eine feste Höhe und Breite zuweisen. Da diese Festlegungen nichts mit der Verarbeitung des Objektes (etwa durch ein Plugin) zu tun haben, gelten sie auch dann, wenn der User-Agent das Objekt nicht darstellen kann. Stimmt das soweit?

    Wie erklärt es sich da, dass Firefox und viele andere Browser diese Angaben ignorieren, wenn das Flash-Plugin nicht installiert ist? Ich habe eine ältere Seite von mir kürzlich mit Firefox, IE, Opera, Konqueror und Safari getestet. Ergebnis: Fast alle Browser ignorieren die Höhen- und Breitenangabe, wenn das Flash-Plugin nicht verfügbar ist. Einzig Safari berüchtigt die Angaben und trotzdem glaube ich, dass nur dies das korrekte Verhalten ist.

    Habe ich jetzt einen Verständnisfehler was den Standard angeht, oder rendern in dieser Situation tatsächlich die meisten Browser falsch?

    Weil sicher nicht jeder einen Browser ohne Flash-Plugin verfügbar hat, hier zwei Screenshots. Der line zeigt die Ansicht der oben verlinkten Seite im Firefox, der rechte in Safari. Alle Objekte der Seite haben mit width und height festgelegte Abmessungen von 640 x 445 Pixel. Wenn das Flash-Plugin verfügbar ist, werden sie auch in der richtigen Größe angezeigt.
    [Blockierte Grafik: http://img174.imageshack.us/img174/2500/ffobj1vq1.th.jpg] [Blockierte Grafik: http://img181.imageshack.us/img181/1056/ffobj2yo1.th.jpg]

    Ich schätze das ist ein Problem der Standard-Vorgabewerte. Denn Firefox und Co rendern ein <object> standardgemäss als inline-Element, denen man keine Höhe/Breite mit auf den Weg geben kann. Ähnlich eines <img>.

    Wenn man dem <object> per CSS den Wert display:block; zuweist, werden Höhe und Breite akzeptiert (inline-Elemente dürfen keine weight/height Angaben haben).

    Vermutlich wäre ein inline-block als Vorgabe sinnvoller. Allerdings kenne ich Vorgaberegelungen im WebStandard nicht. Muss ich passen.

    Technisch wird vermutlich in das <img>-artige <object> ein neues Element geladen, wenn das Plugin installiert ist, welches die height/width-Angaben vom Elterelement ausliest und dann als block im <object> das element ausdehnt.

    Zitat von PIGSgrame

    Da diese Festlegungen nichts mit der Verarbeitung des Objektes (etwa durch ein Plugin) zu tun haben, gelten sie auch dann, wenn der User-Agent das Objekt nicht darstellen kann. Stimmt das soweit?

    Also ich lese da:

    Zitat

    When specified, the width and height attributes tell user agents to override the natural image or object size in favor of these values.


    Man kann mit der Angabe die natürlichen Größen überschreiben. Die natürliche Größe kann natürlich nur bekannt werden, wenn ein Plugin das Objekt tatsächlich rendert. Sonst gilt:

    Zitat

    The height and width attributes give user agents an idea of the size of an image or object so that they may reserve space for it and continue rendering the document while waiting for the image data.


    Der Browser reserviert zunächst den Platz. Erhält er dann keine Angaben zur realen Größe kollabiert er den Raum.

    Zitat

    Einzig Safari berüchtigt die Angaben und trotzdem glaube ich, dass nur dies das korrekte Verhalten ist.


    Da ist wohl Auslegungssache, je nach Interpretation ist das Verhalten zwar möglich aber nicht zwingend vorgeschrieben.

    Danke für eure Antworten.

    Das Zuweisen von display:block; an alle Objekte hilft leider nicht. Warum Firefox den einmal reservierten Raum wieder kolabiert, verstehe ich nicht ganz. Es stimmt tatsächlich, dass der Standard hier nichts explizit vorschreibt, aber muss man deswegen eine einmal gesetzte Größe wieder ändern? Etwas unlogisch erscheint mir dieses Verhalten schon und ich sehe auch nicht, inwiefern es unter dem Aspekt der Barriefreiheit oder Nutzerfreundlichkeit sinnvoll ist.

    Du hast doch in der default.css die Zeile

    Code
    object {display:block;width:640px;height:445px;}

    eingefügt und das Ergebnis schaut aus wie beim Safari. Da kollabiert doch nichts, oder habe ich Dich jetzt nicht verstanden ?

    Also bei mir kolabiert es weiterhin, es sieht auch mit der eingefügten Zeile genauso aus wie oben auf dem linken Screenshot. Sollte sich der Firefox unter Linux da etwa anders verhalten...? Den Cache habe zum Testen natürlich geleert.

    Ich war tatsächlich im Irrtum. Die Erweiterung Quick Preference Button bietet die Möglichkeit, das Flash-Plugin zu deaktivieren. Ich war der Meinung, dass sie dazu einfach einen about:config-Wert ändert, tatsächlich filtert sie die Flashinahlte aber ggf. selbst.

    Wenn ich von Windows aus die Flashplugin-DLL umbenenne, so dass sie dem Firefox wirklich nicht zur Verfügung steht, dann funktioniert es so, wie ich mir das gedacht habe (heißt: Die Höhe der Objekte bleibt erhalten, auch wenn sie nicht dargestellt werden können). Ich schließe daraus, dass QPB einfach den kompletten <object>-Tag filtert, anstatt (wie ich glaubte) den Zugriff auf das Flashplugin zu unterbinden.

    Danke für deine Hilfe!

    Zitat von boardraider

    Man kann mit der Angabe die natürlichen Größen überschreiben. Die natürliche Größe kann natürlich nur bekannt werden, wenn ein Plugin das Objekt tatsächlich rendert.

    so ist es leider nicht. der browser kennt die größe des vom plugin dargestellten objektes auf keinen fall. man muss deshalb immer breite und höhe dazu schreiben, sonst macht der browser einen fallback auf eine standardauflösung (300*200 oder so), egal wie groß der inhalt des engebetteten objekts tatsächlich ist. grund: plugins haben keine möglichkeit ihre maße dem browser mitzuteilen, das ist eine einschränkung der ziemlich alten netscape-plugin-api, die alle browser (außer der ie) verwenden. laut einem firefox-dev in bugzilla.

    wenn der inhalt des object-tags von browser selbst dargestellt wird, ist eigentlich keine größenangabe im object-tag mehr notwendig - sofern das objekt selbst eine größenangabe enthält. also wie bei bildern im img-tag.

    kleine abschweifung:
    ich schreibe oben "eigentlich", weil firefox bei eingebetteten svg-grafiken nicht die in selbigen enthaltene pixelgröße ausliest (falls vorhanden) und sie entsprechend darstellt. folge: man muss immer width und height angeben, sonst gibt es wieder eine (sehr kleine) fallback-auflösung. das ist so als ob man bei jeden jpeg die größe in den img-tag schreiben müsste...

    https://bugzilla.mozilla.org/show_bug.cgi?id=321531
    obwohl das imho ein ziemlich schwerwiegender bug ist, scheint das keinen dev zu interessieren. wer einen account hat: voten wär nett. :)

    http://devedge-temp.mozilla.org/library/manual…pi4.html#999189
    Demnach gäbe es zumindest theoretisch durchaus die Möglichkeit Informationen vom Plugin einzuholen. Allerdings wird die Realität wohl so aussehen, wie von dir beschrieben.

    http://devedge-temp.mozilla.org/library/manual…/pluginTOC.html

    Zitat von cubefox

    https://bugzilla.mozilla.org/show_bug.cgi?id=321531
    obwohl das imho ein ziemlich schwerwiegender bug ist, scheint das keinen dev zu interessieren. wer einen account hat: voten wär nett. :)

    So schnell kann's gehen: Ich wollte gerade dafür voten, aber seit gestern Nacht ist dieser Bug RESOLVED FIXED (in Firefox 3 zumindest). Dein Kommentar hat die Entwickler vermutlich auf diesen alten und lange brachliegenden Bug aufmerksam gemacht.

    Eine kleine Anmerkung allerdings noch:

    Zitat von cubefox@Bugzilla

    Its like you would have to tell every (!) single embeded jpg in <img> tag a width and height attribute! terrible.

    Das sollte man im Sinne der Zugänglichkeit eigentlich immer tun, in den Strict-Varianten der DTDs ist es sogar vorgeschrieben. Der Knackpunkt bei diesem Bug war aber, dass Firefox eine oft falsche Größe festgelegt hat und die vom Ersteller des SVG-Objektes festgelegte Größe ignoriert hat.

    Zitat von boardraider


    http://devedge-temp.mozilla.org/library/manual…pi4.html#999189
    Demnach gäbe es zumindest theoretisch durchaus die Möglichkeit Informationen vom Plugin einzuholen. Allerdings wird die Realität wohl so aussehen, wie von dir beschrieben.

    http://devedge-temp.mozilla.org/library/manual…/pluginTOC.html


    danke für die links, das war mir neu. ich hatte bisher nur die bugzilla-aussage des entwicklers (die ich leider nicht mehr finden kann) als grundlage.


    Zitat von PIGSgrame

    Das sollte man im Sinne der Zugänglichkeit eigentlich immer tun, in den Strict-Varianten der DTDs ist es sogar vorgeschrieben.


    das versteh ich nicht. was für einen einfluss hat die größenangabe im quelltext auf die zugänglichkeit?


    Zitat von PIGSgrame

    Der Knackpunkt bei diesem Bug war aber, dass Firefox eine oft falsche Größe festgelegt hat und die vom Ersteller des SVG-Objektes festgelegte Größe ignoriert hat.


    "aber"? wir haben doch nie von was anderem gesprochen, oder hab ich da jetzt was falsch verstanden? ^^

    Zitat von cubefox


    "aber"? wir haben doch nie von was anderem gesprochen, oder hab ich da jetzt was falsch verstanden? ^^

    Das bezog sich auf den Vergleich mit den Bildern: Wenn man eine Bildgröße nicht angibt, dann hüpft die Seite zwar hin und her, aber letztendlich wird das Bild doch in der richrigen Große dargestellt. Beim SVG-Bug war es aber so, dass der Firefox (fast) immer eine falsche Größe angezeigt hat, wenn man die richtige Größe nicht explizit angegeben hat. Bezogen auf den Thread-Titel handelt es sich um das gleiche Problem, bezogen auf den Bildervergelich aber nicht.

    Den Grund für die Wichtigkeit der width- und heigt-Attribute hat Dr. Evil ja genannt, ergänzend dazu noch folgende Anmerkung: Im Zeitalter von DSL, wo jede Seite innerhalb von Sekunden aufgebaut ist, ist das Problem nicht mehr so gravierend. Wenn man aber als Modemsurfer auf einer bilderreichen Seite landet, kann das Laden durchaus mehrere Minuten dauern. Meist fängt man dann natürlich schon an, den Text zu lesen, während man auf die Bilder wartet. Es ist wirklich unzumutbar, wenn einem da ständig mitten im Satz der Text aus dem Blickfeld hüpft.

    In einigen Fällen kann es vielleicht sinnvoll sein, auf die Größenangabe zu verzichten. Zum Beispiel bei einem Homepage-Template, bei dem man ein Standardlogo unkompliziert und undynamisch durch ein eigenes ersetzen können soll. Grundsätzlich sollte man die Größe aber angeben, man kann das ja bei Bedarf mit PHP & Co. automatisieren. Durchweg fehlende Bildgrößenangaben können jedenfalls eine echte Barriere sein, auch wenn sie für viele nicht offensichtlich wird.