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

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=""/>. 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?

Btw, I created another testcase[1] for checking the x,y offsets and found  
some further browser inconsistencies. Firefox and Chrome seems to follow  
model C, and worth noting is that d="M10,20 10,20" produces a  
bbox=[10,20,0,0] which is propagated to its container element, same for a  
zero-length <line> element. I can't quite tell what IE11 is doing, it's  
not consistent with any of the given models, for path elements d="M10,20  
10,20" is the same as d="M10,20" and produces a bbox=[10,20,0,0] which  
isn't propagated to its container element, same with a zero-length <line>  
element.


[1] http://xn--dahlstrm-t4a.net/svg/dom/empty-elements.html
[2] https://svgwg.org/svg2-draft/paths.html#PathDataBNF
-- 
Erik Dahlstrom, Web Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group

Received on Wednesday, 19 February 2014 17:29:45 UTC