- From: Cameron McCormack <cam@mcc.id.au>
- Date: Thu, 27 Feb 2014 15:57:25 +1100
- To: Nikos Andronikos <nikos.andronikos@cisra.canon.com.au>
- CC: Erik Dahlström <ed@opera.com>, www-svg@w3.org
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