Re: What should the bbox of a path without a d attribute be?

On Thu, 27 Feb 2014 04:16:08 +0100, Nikos Andronikos  
<nikos.andronikos@cisra.canon.com.au> wrote:

> On 20/02/2014 4:29 AM, Erik Dahlström wrote:
>> On Wed, 19 Feb 2014 03:59:50 +0100, Nikos Andronikos
>> <nikos.andronikos@cisra.canon.com.au> wrote:
>>
>>> This email is my follow up for action 3590 [1] which relates to Issue
>>> 2454 [2].
...
> Models:
> I'm not totally sure if in model B and C, Erik means that any shape,
> even one with dimensions and position set to a value other than 0 will
> return a bbox of [0,0,0,0].

The models I described weren't concerned at all with elements that render,  
since the spec wasn't unclear in that area. There might be some variations  
between browsers wrt to elements that render too, but hopefully not (or at  
least less so). Do raise issues if that's the case.

> I think that in all cases, when a shape has author defined dimensions,
> then the returned bbox will be in that position and of those dimensions.

Yes, that sounds reasonable to me, and should already be what the spec  
requires IINM.

...
> D       elements that don't render must return bbox=[x,y,w,h]. x,y,w,h
> are taken from lacuna values or zero
>          elements that don't render don't contribute to parent bounding  
> box
...
> SVG 2 is currently listed as D, but this isn't quite correct because the
> specification doesn't define to use zero when dimensions not available
> (i.e. value is none)
>
>  From 9.2
> "The width and height of the rectangle. A negative value for either
> attribute is an error (see Error processing). A value of zero for either
> attribute disables rendering of the element. "
>
>  From 7.11
> "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."

I think the spec should be made a bit more clear regarding what "elements  
not in the rendering tree" actually means. When the spec says "disables  
rendering of the <foo> element" then that means the element should not be  
in the rendering tree. Other things that might be unclear are elements  
that are invisible, e.g opacity=0, but which should be part of the  
rendering tree.

> I would suggest to keep model D as currently written in the spec.

That's ok with me, but it needs to say to use zero when one or both of the  
dimension values aren't available (i.e. value is none, or e.g <path  
d="M1,2"/>). Perhaps it needs to be made clear also that if some value is  
invalid but has a lacuna value other than 0 then that lacuna value should  
be used instead of 0.

> Separately from the above models, we still need to determine what <path
> /> means.
> I propose <path /> is equivalent to <path d="" />. Why not just make the
> lacuna value for d an empty string?
> Then, neither <path /> nor <path d="" /> would render, or contribute to
> ancestor bbox.

Sounds good to me. What about invalid paths? Perhaps we should mention  
that case too, like if the path is broken halfway through, the bbox should  
represent the valid part of the path, right? That is what should render,  
but is unlike all other lacuna values which are either valid or invalid,  
but never somewhere in between.

> The bbox returned by getBBox() for the path isn't obvious. But [0,0,0,0]
> seems reasonable as with no moveto given, the point would be at the  
> origin.
> This makes sense to me, because a relative initial moveto is equivalent
> to a move from (0,0).

I think [0,0,0,0] makes more sense than any other alternative so far.

> <polyline points="" />, <polyline />, <polygon points="" /> and <polygon
> /> should follow the behaviour of <path d="" />
> - Does not render.
> - Does not contribute to ancestor bbox.
> - Returns a bbox of [0,0,0,0]
>
> Note that <polyline points="" /> and <polygon points="" /> are currently
> valid as far as the grammar goes, but no behaviour is specified.

Similar note as for <path d="z"/>, when a polygon/polyline has an odd  
number of points that should behave the same as the <path> case, render up  
to the point of error in the attribute,  
http://www.w3.org/TR/SVG11/implnote.html#ErrorProcessing.

So, e.g <polygon points="1"/>, according to spec this should render up to  
the point of error, but there's not really anything to render for this  
case.

> An alternative model is:
> <polyline />, <polygon /> and <path /> are all in error.

Hmm, for validation purposes of static files perhaps... but even so,  
animating the d attribute would still be possible, so it's not clear that  
an empty such element should be an error. I don't think we should make  
them be errors, especially since they were not "in error" in SVG 1.1.

> So the questions to the group are:
> What model should SVG 2 require?
>
> Is the following acceptable?
> <path /> == <path d="" />
> <polygon /> == <polygon points="" />
> <polyline /> == <polyline points="" />

Yes.

> Or alternatively
> Should <polyline />, <polygon /> and <path /> all be an error?

No.

> And for <path d="" />, <polygon points="" /> and <polyline points="" />,
> are the following behaviours acceptable?
> Does not render.
> Does not contribute to ancestor bbox.
> Returns a bbox of [0,0,0,0]

Yes.

We should resolve on how to deal with the "in error" conditions for  
<path>, <polyline> and <polygon>. I propose that when the element in  
question does render something the bbox must represent that, and if the  
data is malformed before an initial moveto then the bbox should be  
[0,0,0,0], and if the point where the data is malformed is right after the  
initial moveto (x,y) the bbox should be [x,y,0,0].


-- 
Erik Dahlstrom, Web Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group

Received on Wednesday, 5 March 2014 13:38:54 UTC