Re: ISSUE-2129 (definition clarifications): Definition section is too long and needs clarifications (bbox, canvas, etc.) [Last Call: SVG 1.2 Tiny ]

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