Re: [CSSOM] Revisiting transforms and getBoundingClientRect()

On Sat, Sep 10, 2011 at 12:17 PM, Simon Fraser <smfr@me.com> wrote:

> On Sep 8, 2011, at 10:29 PM, Robert O'Callahan wrote:
>
> On Fri, Sep 9, 2011 at 7:01 AM, Simon Fraser <smfr@me.com> wrote:
>
>> Sure. With all these new point/quad methods, maybe we should bite the
>> bullet and have a WebPoint class with x, y members. Then WebQuad can have 4
>> WebPoints.
>>
>> The poorly-named ClientRect should become WebRect.
>>
>
> I don't think we should have "Web" prefixes on Web APIs. If we need a
> prefix, maybe CSSRect.
>
>
> Even when the same APIs should work for SVG elements, which have a non
> pixel-based coordinate system?
>

SVG elements don't really have CSS boxes so these APIs don't apply naturally
to SVG elements. We basically have to make up a definition for what the
various CSS boxes mean for SVG elements. Given we're making e.g.
element.contentBoxes return something for an SVG element, naming the result
type with a "CSS" prefix isn't doing any more violence to the platform.

In SVG, we'd also have to think about mapping between the SVG coordinate
> space and that of the enclosing HTML (if any), and vice-versa with
> <foreignobject>.
>

Yes. The mapping functions should definitely do that. The tricky bit is
defining the coordinate system used for source and destination SVG elements.
Probably the SVG bounding-box top-left.

Rob
--
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]