- From: Cameron McCormack <cam@mcc.id.au>
- Date: Wed, 22 Oct 2008 12:33:34 +1100
- To: SVG Working Group WG <public-svg-wg@w3.org>
Hi Doug. Doug Schepers: > I've added an illustrative example [1], which I hope will clarify how > the bbox results vary based on context. This is to maximize the utility > to authors. > > Please let us know if this satisfies your concern. > > [1] http://dev.w3.org/SVG/profiles/1.2T/publish/coords.html#ExampleBBoxCalc I have two small nits (are there ever big nits?). This added text is: Elements and document fragments which derive from SVGLocatable but are not in the rendering tree, such as those in a 'defs' element or those which have been been created but not yet inserted into the DOM, must still have a bounding box. The geometry of elements outside the rendering tree must take into account only those properties and values (such as 'font-size') which are specified within that element or document fragment, or which have a lacuna value or an implementation-defined value. I think this should say “implement SVGLocatable” (or “implement the SVGLocatable interface”), rather than “derive from SVGLocatable”, since interfaces can derive from other interfaces, but objects implement them. Also, I don’t think it is correct to say that document fragments can implement SVGLocatable; only elements can. In my mind, a document fragment is a sequence of disconnected nodes (i.e., something that can be represented by a DocumentFragment object in full DOMs (http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-B63ED1A3)). Here, it seems document fragment is being used to mean an element that has children. If that is the case, then I think it is safe to remove the “and document fragments”. Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Received on Wednesday, 22 October 2008 01:34:14 UTC