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

[From right address]

On Thu, Apr 24, 2014 at 10:24 AM, Stephen Chenney <schenney@google.com>wrote:

> On Thu, Apr 24, 2014 at 8:31 AM, David Dailey <ddailey@zoominternet.net>wrote:
>
>>
>>
>> On Wednesday, April 23, 2014 9:53 PM
>> Nikos Andronikos wrote:
>>
>> >RESOLUTION: Bounding box for path/polygon/polyline with no data set
>> (empty
>> or zero valid commands) should not contribute to ancestor bounding box
>>
>> Hi Nikos,
>>
>> Everything else looks good to me, but I suppose that the above is to meant
>> to handle the case of unions of paths, as within a shared parent, like a
>> <g>, or, presumably (if ever implemented), a <veUnion>. I am wondering if
>> there might be filters in which, through some sequence of the chaining of
>> filter primitives as in <feBlend> or <feImage>, there might not be a
>> common
>> ancestor to two shapes, but where the net result would nevertheless be a
>> "union". We would still not want the bounding box to expand to include the
>> isolated empty point.
>>
>> In the case of a script which would perform such a union, perhaps without
>> the direct reconstruction in DOM of a common ancestor to the two
>> geometries,
>> we still would not want the isolated point to be considered. Might the
>> following rewording clarify the intent more clearly?
>>
>> modified RESOLUTION: Bounding box for path/polygon/polyline with no data
>> set
>> (empty or zero valid commands) should not contribute to bounding box of
>> its
>> union with  other shapes, e.g., as in a shared ancestor such a <g>.
>>
>> I'm not sure, actually, if this is needed, but might it help?
>>
>
> I think David's proposed text is better. When implemented, I expect it to
> be via a null bounding box that does not contribute to anything. We don't
> want an element to require a "null rect" at some times and "empty rect" at
> others.
>
> Stephen.
>
>
>>
>> Cheers
>> David
>>
>>