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

Nikos Andronikos wrote:
> 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.

Yes I don't think we should do this, for that reason; we should make 
markers suddenly render at (0,0) when you write <path d=""/> or <path/>.

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

I don't see any good reason to treat <path d=""/> and <path/> (i.e. 
empty d attribute and no d attribute) differently.

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

You're right the algorithm I added to 
https://svgwg.org/svg2-draft/coords.html#BoundingBoxes doesn't handle 
<path> with an invalid/empty d or no d.

I think options D and E are both OK.  But particularly I think we should 
make the "not rendered" elements not contribute to their ancestors' 
bounding boxes.

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

Normally the lacuna value is a valid value.  It helps us write prose 
defining elements' behaviour without having to explicitly handle invalid 
values.  So I don't think there's any benefit in defining a lacuna value 
for d.

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

I agree with returning [0,0,0,0] for these.

That the grammar allows an empty string sounds like an oversight.

> So the questions to the group are:
> What model should SVG 2 require?

D or E.

> Is the following acceptable?
> <path /> == <path d="" />
> <polygon /> == <polygon points="" />
> <polyline /> == <polyline points="" />
> Or alternatively
> Should <polyline />, <polygon /> and <path /> all be an error?

I think they should have equivalent behaviour, whatever that is.

I don't think I mind whether they are considered to be invalid in terms 
of authoring conformance.  I think they are currently.

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

Received on Thursday, 27 February 2014 04:58:09 UTC