W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2011

RE: Some practical issues integrating the SVG transform attribute with CSS transform properties

From: Anthony Grasso <Anthony.Grasso@cisra.canon.com.au>
Date: Thu, 31 Mar 2011 00:32:34 +0000
To: Cameron McCormack <cam@mcc.id.au>, Patrick Dengler <patd@microsoft.com>
CC: Erik Dahlstrom <ed@opera.com>, "public-fx@w3.org" <public-fx@w3.org>, Jonathan Watt <jwatt@jwatt.org>, Robert O'Callahan <robert@ocallahan.org>
Message-ID: <923A4276C1903646BE5299CA8462B0A0174B0CF8@exm01-wvp.cisra.canon.com.au>
Hi Cameron,

> -----Original Message-----
> From: public-fx-request@w3.org [mailto:public-fx-request@w3.org] On
> Behalf Of Cameron McCormack
> Sent: Thursday, 31 March 2011 9:21 AM
> To: Patrick Dengler
> Cc: Erik Dahlstrom; public-fx@w3.org; Jonathan Watt; Robert O'Callahan
> Subject: Re: Some practical issues integrating the SVG transform
> attribute with CSS transform properties
> Patrick Dengler:
> > Is everyone on board for using the promotion of SVG Attributes to
> > properties as opposed to using the attr() notation? And, have we
> > landed on using -svg-r notation?
> I don’t know if everyone is on board yet, but so far it seems to have
> had the least pushback.  Tab mailed the CSS WG; I wonder if they have
> discussed it in the group yet.
> The -svg-r notation I’m not fond of.  It’s not pleasing to the eye, and
> if any of these properties are to be extended to apply to non-SVG
> elements in the future, the name will be a hindrance.
> I said I was going to write up a summary of attribute promotion like
> Tab’s one, but considering all of the animatable attributes in SVG.
> Here is is:
>   http://people.mozilla.org/~cmccormack/svg-properties.html

> Some things are similar to Tab’s analysis, others different.  Please
> don’t pay too much attention to the names, since I cringe at some of
> those I’ve chosen, and I am sure others will be able to come up with
> better ones.  I also don’t mention property value syntax, but I don’t
> think that’s going to be a problem.

As per our discussion on IRC, we should look into aligning the <feComposite> 'operator' attribute and the compositing 'comp-op' operator given that there was agreement over email [1] to backport compositing blend modes to filters.

Personally I don't care whether the filter property is changed to 'comp-op' or the compositing operator property is changed to 'composite-operator', either way is fine with me as long as it is consistent.



[1] http://lists.w3.org/Archives/Public/www-svg/2011Mar/0071.html

> > >>> Another option is to deprecate SVGAnimatedTransformList and
> > point people to CSSOM, or whatever way there is in CSS to get the
> > (animated or not) transform value as a higher level object (CSSMatrix
> > or equivalent, not DOMString).
> >
> > What we have been considering here is that if it is set with the
> > SVGAttribute, it is is stored in the SVG OM; if it is set with CSS it
> > is stored in the CSS OM.
> So that’s agreeing with 2 and choosing 3a from Rob’s initial mail?
> --
> Cameron McCormack ≝ http://mcc.id.au/

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Received on Thursday, 31 March 2011 00:33:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:38 UTC