Closed Bug 1294966 Opened 8 years ago Closed 7 years ago

SVG getBBox should provide useful information for zero-width/height shapes

Categories

(Core :: SVG, defect, P3)

Product:
Core
Component:
SVG
Version:
50 Branch
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: amelia.bellamy.royds, Assigned: u459114)

Details

Attachments

(5 files)

Bug 1294966 - Part 1. Return correct x/y of bbox of an svg element even if the size of it is empty.
59 bytes, text/x-review-board-request
Details
Bug 1294966 - Part 2. Return correct width/height of bbox of an svg element even if the size of it is empty.
59 bytes, text/x-review-board-request
Details
Bug 1294966 - Part 3. Add test cases for get bbox of svg elements with empty size.
59 bytes, text/x-review-board-request
Details
Bug 1294966 - Part 4. Return bbox of an svg element even if the width or height is negative.
59 bytes, text/x-review-board-request
Details
Bug 1294966 - Part 5. Add test cases for get bbox of svg elements with negative width or height.
59 bytes, text/x-review-board-request
Details 
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

Steps to reproduce:

Define an SVG basic shape (e.g., rect, circle, ellipse) and set at least one of its sizing properties (width/height, r, rx/ry) to 0.  Use positioning attributes to put the element somewhere other than the 0,0 coordinates.

Call the getBBox method on the element.

Test case: http://jsbin.com/xakacesomu/4/edit?html,js,output


Actual results:

The BBox always returns an SVGRect object with x,y,width,height all set to 0.

IE/Edge do the same, bug status here: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8480723/

Blink/WebKit return the expected results


Expected results:

This was not well defined in SVG 1.1, but SVG 2 now clearly requires that as much information as possible be provided.  In other words, the x and y properties of the returned SVG/DOMRect object should match the cx/cy or x/y values on the shape, and height or width should be provided if not zero.

Spec: https://svgwg.org/svg2-draft/coords.html#BoundingBoxes
This would seem to conflict with the text in the specification that says such shapes are not rendered.
So if we're getting the bounding box of a g which contains such shapes, we ignore them, if we're getting the bounding box of the shape itself we don't. getBBox is already horribly complicated, making it more so would seem to make it even harder to get right.
Robert: I agree it's unfortunately complicated. If I could go back and change the rule about shapes not being rendered at all when one dimension is zero, I would.  (See this spec bug discussion about the inconsistencies between shapes and their equivalent paths: https://github.com/w3c/svgwg/issues/235 )

However, on the question of a shape with a valid bounding box not contributing to a container bounding box, that's actually a wider requirement, and may be another place where Firefox needs to update the algorithm.  Current spec text:

"Even if an element is not in the rendering tree – due to it being 'display: none', within a ‘defs’ element, not usually rendered like a ‘symbol’ element or not currently present in the document tree – it still has a bounding box. A call to getBBox on the element will return the same rectangle as if the element were rendered. However, an element that is not in the rendering tree does not contribute to the bounding box of any ancestor element."

There's also a detailed algorithm for getBBox in the spec, you might want to compare with Firefox's algorithms to see if there are any other discrepancies.  (And file an issue if you find the algorithm is inconsistent with the prose and/or otherwise un-implementable.)

These changes were made for web compatibility (FF & IE/Edge did one thing, Blink & WebKit did another, so we had to choose) but also because it is much more useful for authors to provide as much information as possible.  I started building these test cases because of a complaint that a Greensock utility was failing on Firefox; it was using bounding box to calculate a transformation origin on a shape before it was animated up to full size.
It's highly unlikely we'll ever be compliant on the display:none requirements. I'd much rather they'd been rewritten as they are hard to meet without regressing the efficiency of html and html will always win that war. 

I've asked for display:none on gradients, filters etc to basically disable them but it's never gone anywhere.
Component: Untriaged → SVG
Product: Firefox → Core
Priority: -- → P3
Assignee: nobody → cku
<rect x="40" y="20" width="0" height="10" fill="blue"/>

firefox reports       (x=0, y=0, w=0, h=0)
edge reports          (x=0, y=0, w=0, h=10)
chrome/safari reports (x=40, y=20, w=0, h=10)
In svg 2.0, I can not find a definition of how to handing negative width/height
https://svgwg.org/svg2-draft/geometry.html#Sizing

It's more clear in 1.0:
https://www.w3.org/TR/SVG/shapes.html#RectElement
width = "<length>"
    The width of the rectangle.
    A negative value is an error (see Error processing). A value of zero disables rendering of the element.
See comment 1. Since the w3c can't or won't fix the specification not to be self-contradictory we shouldn't jump though hoops to implement it.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
The current patches are invalid as far as I can tell per the parts of the specification that contradict the bounding box parts.
Robert: If you're going to resolve this as won't-fix because of an overly complicated spec, could you file an issue on the spec so that discussion can continue there? I can't find anything relevant in https://github.com/w3c/svgwg/issues
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: