Closed Bug 320875 Opened 16 years ago Closed 16 years ago
image/svg+xml object without explicit dimension specification has always 300x150px size
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
Required PNG and SVG files
Fixed URLs to the images in bugzila and cleaning some garbage.
Attachment #206328 - Attachment is obsolete: true
Assignee: nobody → general
Component: General → SVG
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → 1.8 Branch
Why is this wrong? This is dictated by the CSS spec last time I checked.
(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?)
<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.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
(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.
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.
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 :)
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.
Whiteboard: dupe of 321531
You need to log in before you can comment on or make changes to this bug.