320875 - image/svg+xml object without explicit dimension specification has always 300x150px size

Status: RESOLVED INVALID

(Core :: SVG, defect)

Description

[petr.pisar]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

If I use object element without width and height attributes and the data is SVG document, then it has always width 300px and height 150px. 

Reproducible: Always

Steps to Reproduce:
1.Use <object type="image/svg+xml" data="file.svg">
2.
3.

Actual Results:  
Size is always 300x150px

Expected Results:  
Size should be taken from SVG document (as is e.g. with image/png).

http://www.w3.org/TR/html4/struct/objects.html

Comment 1

[petr.pisar]

Attachment: XHTML code example

Required PNG and SVG files

Comment 2

[petr.pisar]

Attachment: SVG image

Comment 3

[petr.pisar]

Attachment: PNG image

Comment 4

[petr.pisar]

Attachment: XHTML object example

Fixed URLs to the images in bugzila and cleaning some garbage.

Comment 5

[Anne (:annevk)]

Why is this wrong? This is dictated by the CSS spec last time I checked.

Comment 6

[petr.pisar]

(In reply to comment #5)
> Why is this wrong? This is dictated by the CSS spec last time I checked.
> 
Can you point me the place in the spec? It would be very amazing if CSS said that size of object element is implicitly some-exact-number.

Are you sure we are talking about XHMLT "object" element (i.e. tag <object/>) and not about generic object how is used in CSS spec?

I think this concrete size is some Gecko's fallback size for object where it's not possible to get the right size. (But what about sound? Object containing audio/* is also visible?)

Comment 7

[Anne (:annevk)]

<http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-width>
<http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-height>

So no, it is not specific to Gecko. It is just some rule that applies to replaced elements of which the intrinsic size is not available. (This was already common practice for IFRAME for example.)

Resolving INVALID.

Comment 8

[petr.pisar]

(In reply to comment #7)
Ok, it's very suprising for me, but I agree.

In the light of this information, I tink, it is insufficiency of SVG subsystem to provide intrinsic dimensions. If you look at 
http://www.w3.org/TR/SVGMobile12/struct.html#SVGElementWidthAttribute (it's SVG-Tiny-1.2) you can see that SVG file can contain dimension definition (as is used in my example file). So I should open new feature request to support width and height attributes of svg element and export them outside the SVG subsystem.

Comment 9

[petr.pisar]

I found out older Bug 276431 which is about missing interface for exporting intrinsic dimenensions of SVG image. One impact is that it is not possible to use SVG image in <img> element.

Comment 10

[Chris Hubick]

Please see bug 70978 and bug 70976, which I filed in 2001.

Comment 11

[Chris Hubick]

With respect to comment 7 from Anne, I think the argument here is that intrinsic size *is* available - within the data file being included.  As part of understanding and supporting a given format within an object tag, the browser should be able to understand and utilize an intrinsic size specified by that format's data.  And like Petr, I would argue that SVG should work no differently than PNG in this regard, and indeed, *all* datatypes should follow the same rules with regards to intrinsic sizing.

And Petr, it's nice to know someone comes along every 5 years who actually cares about this :)

Comment 12

[Hixie (not reading bugmail)]

Anne is wrong. I just filed a duplicate, though, namely bug 321531, since I couldn't find any open bugs on this (since this one was marked invalid!), so I won't bother to reopen this bug.