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

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].
> ...
>> My suggestion was:
>> Remove the restriction that a d attribute must have an initial moveto.
>> The lacuna value of the 'd' attribute will change from 'none' to an
>> empty string
>>
>> The following rules will apply if no initial moveto is given (and
>> will take effect if no d attribute is present on the element).
>>
>> If no initial moveto is given, then the position for the initial
>> moveto is based on the context of the 'd' attribute
>> if d is an attribute of the hatchPath element then the initial moveto
>> uses the position (x,0) as described in the hatches section of SVG 2 [5]
>> If d* is an attribute of a stop element (for a mesh gradient) then
>> the initial moveto uses the position of the last node of the previous
>> stop's path (See [4]). (but see note below)
>> otherwise, the initial moveto uses the position (0,0)
>>
>> * mesh gradients may not be relevant here. The plan currently is to
>> name the path data attribute for the stop element 'path' rather than
>> 'd' due to syntax differences (see [6]).
>> Those syntax differences being that only L,l,C and c are allowed. The
>> initial moveto is specified by the previous path and curves are
>> restricted to beziers because of underlying graphics library
>> requirements.
>> My thinking is that due to the many syntax differences, it's probably
>> best to leave the path attribute of mesh gradients as a separately
>> specified attribute.
>>
>> The basis for my suggestion:
>>
>>   *   brings more consistent behaviour to the various cases in which
>> we now use the d attribute or path commands
>>   *   allows for bounding box behaviour for elements with no user
>> specified data that is consistent with other basic shape elements
>>
>> So hopefully this will kick off further discussion. What do you all
>> think?
>
> It's unclear to me if you mean <path/> should render or not, and if
> there is any difference at all between <path d="M0,0"/> and <path d=""/>.

My suggestion would change the meaning of d="" to the equivalent of
d="M0,0", and d=none would no longer exist.
d="L100 100" would also be valid as the "M0,0" would be inserted
automatically.
In all these cases
* the path would render
* the path would contribute to ancestor's bounding box (unless rendering
disabled via display:none or something)

But I hadn't thought about the requirement that d="" disables rendering.
This means my suggestion would not be backwards compatible and so
probably needs to be discarded.

> Right now, the spec says <path d=""/> isn't rendered (last sentence of
> section 8.3.10[2]), if <path/> should render is undefined, and any 'd'
> attribute value that is valid according to the path grammar means the
> path is rendered (which includes <path d="M0,0"/> even if that doesn't
> produce any visual output).
> Let's call the proposal above model A.
> For the sake of the discussion, here's an alternative model B:
>
> * elements that don't render must return bbox=[0,0,0,0]
> * elements that don't render don't contribute to any (conceptual)
> ancestor's bbox (thinking of container elements, but also of <use>)
>
> Model C:
>
> * elements that don't render must return bbox=[0,0,0,0]
> * elements that don't render do contribute to any (conceptual)
> ancestor's bbox
>
> Model D:
>
> * elements that don't render must return bbox=[x,y,w,h] with the
> values for x,y,w,h taken from the lacuna values as defined for each
> relevant attribute on the given element, and if there's nothing to
> fall back on use zero for the missing value(s) instead
> * elements that don't render don't contribute to any (conceptual)
> ancestor's bbox
>
> Model E:
>
> * elements that don't render must always return bbox=[x,y,w,h] with
> the values for x,y,w,h taken from the lacuna values as defined for
> each relevant attribute on the given element, and if there's nothing
> to fall back on use zeros instead
> * elements that don't render do contribute to any (conceptual)
> ancestor's bbox
>
> In addition, we should clarify if an empty d attribute, an unspecified
> d attribute and a d attribute with a single moveto command and nothing
> else, all mean that the <path> isn't rendered. And similarly for
> polyline, but with the 'points' attribute instead. For polygon, since
> it auto-closes the path, one value is enough to define a line segment,
> so it would seem consistent to behave the same as a <line> with
> x1,y1,x2,y2 as the specified point, or as a path with d="Mx,yz". Note
> that zero-length lines (and path segments) do render, e.g <line
> stroke-linecap="round" stroke-width="10" stroke="black"/>.
>
> Model E is similar to what Presto was doing, apart from the
> specialcases where there the lacuna value was (none). It's not clear
> to me if model A is equivalent to any of the other models, but if I
> understand you correctly you want to define the lacuna values for
> path, polyline and polygon such that model E can be used?

It seems like this has become not just a question about what bounding
box a path with no d attribute should use.
But to define a consistent overall model for shape bounding boxes.
Currently there's not a lot of consistency, and no one really implements
the spec as written.

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].
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.
So let's assume that the bboxes given below only refer to when position
or dimensions are missing on the element

A       == E

B       elements that don't render must return bbox=[0,0,0,0]
         elements that don't render don't contribute to parent bounding box

C       elements that don't render must return bbox=[0,0,0,0]
         elements that don't render do contribute to ancestor's bounding box

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

E       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 do contribute to parent bounding box

F       elements that don't render must return bbox=[x,y,w,h]. x,y,w,h
are taken from lacuna values or an invalid rect is returned otherwise
         elements that don't render don't contribute to parent bounding box

G       elements that don't render must return bbox=[x,y,w,h]. x,y,w,h
are taken from lacuna values or an invalid rect is returned otherwise
         elements that don't render do contribute to parent bounding box
unless bbox is invalid rect

I've summarised Erik's tests for each browser in terms of the various
possible models (hope the formatting survives).
(X: result seems to be broken. In IE11's case the ancestor bounding box
becomes [0,0,0,0])

             IE11    WebKit  Chrome      FF      Opera Presto spec
rect        D       E       E           E G               D

circle      D       E       E           E G               D

ellipse     D       E       E           E G               D

line        D       E       E           E G               D

polygon     X       E       E           E G               D

polyline    X       E       E           E G               D

path        X       E       E           E G               D


nb: apparently FF is changing to D.

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 would suggest to keep model D as currently written in the spec.

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.

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).

<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.


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


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="" />
Or alternatively
Should <polyline />, <polygon /> and <path /> all be an error?

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]

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.

Received on Thursday, 27 February 2014 03:16:41 UTC