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

This email is my follow up for action 3590 [1] which relates to Issue 2454 [2].

A quick summary of the problem:

The lacuna value for the d attribute of the path element, is 'none'.

It is not clear from the specification what the bounding box for a path with no 'd' attribute is, or how it contributes to parent bounding boxes.

Implementations aren't that consistent in their behaviour, as shown by Erik's tests (See Issue 2454 [2]).
Firefox and Chrome: bounding box (0,0,0,0) and contributes to parent bounding box.
Opera Presto: empty path doesn't contribute to parent bounding boxes. Bounding box is <DBL_MAX>, <DBL_MAX>, -Inf, -Inf.
IE11: is just a bit whacko. Invalidates parent bounding box? (I don't have IE11)

There were two viewpoints put forward during the discussion at the telcon, and they were along the following lines...
a path with no d element :
1. is invalid and should have no geometry, bounding box, or contribution to the parent bounding box
or
2. should take some sort of default value (e.g. x=y=w=h=0) and contribute in the same was as other drawing elements (rect, circle, etc)

Note that polygon and polyline also use a lacuna value of 'none' for their path data and so follow the behaviour of path. They should be made consistent with whatever is decided for path.

After a fairly long discussion, consensus couldn't be reached on what the preferable behaviour is.

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?

Cheers,
Nikos

1. http://www.w3.org/Graphics/SVG/WG/track/actions/3590
2. https://www.w3.org/Graphics/SVG/WG/track/issues/2454
4. http://tavmjong.free.fr/SVG/MESH/Mesh.html
5. http://www.w3.org/TR/SVG2/pservers.html#HatchPathElement
6. http://www.w3.org/2011/07/29-svg-minutes.html#item04

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.