Re: Developing CSSOM Value APIs for SVG / replacing SVGLength

On Tue, Sep 25, 2012 at 9:54 PM, Brian Birtles <bbirtles@mozilla.com> wrote:
> (2012/09/26 9:32), Tab Atkins Jr. wrote:
>> [Constructor,
>>   Constructor(float value, DOMString unitType),
>>   Constructor(DOMString value)]
>
> Those ctors are very similar to what Cameron has added to SVGLength with the
> exception of using a DOMString for the unitType instead of an optional
> unsigned short.[1]
>
> It seems like it would be good if SVGLength's ctors matched here (whilst
> possibly providing an additional typed ctor like we have now).

Ah, I wasn't aware that SVGLength was a pre-existing interface.  Yeah,
it makes sense to give it the missing constructor.


>> interface CSSLengthComponentValue {
>
> We brought this up at the F2F, but if the CSSOM is still in flux I'd
> *really* like if this was shortened since it is an interface name you
> actually do type out, e.g. var len = new CSSLengthComponentValue(...)
>
> (Even just typing out this email I've ended up copying and pasting that name
> everywhere!)

You shouldn't ever type it out - you should use the shorter-named
versions on the CSS object.  "CSS.px()", "CSS.length()", etc.

That said, I'm fine with shortening it.  "CSSLength" sounds fine, but
I'd want to do a bit of research to make sure that a similar naming
scheme for the rest of our types won't conflict anything.


>> Question: one of the motivations for doing this interface is to give
>> us a backdoor to reinvent the baseVal/animVal thing that authors tend
>> to hate.  I think we can do this cleanly by just making
>> SVGAnimatedLength inherit from CSSLengthComponentValue.
>
>
> I'm a little unsure about the inheritance. If you have a CSS length returned
> from an library of some sort, e.g. '5px', it seems it would be good if you
> could pass that straight into SVG's API wherever it takes an SVGLength.
>
> Perhaps we could (a) make the SVG API take a CSSLengthComponentValue
> everywhere it currently takes an SVGLength, (b) add
> CSSLengthComponentValue.toSVGLength(), (c) add a ctor to SVGLength to take a
> CSSLengthComponentValue, (d) make them the same interface and deprecate the
> stuff we don't like from SVGLength, (e) lots of other possibilities.
>
> I prefer (a) assuming we rename CSSLengthComponentValue to something
> reasonable.

Yes, (a) seems like a good option.

~TJ

Received on Wednesday, 26 September 2012 16:40:48 UTC