Minutes, Raleigh F2F 2009 day 2

Minutes from day 2:

   http://www.w3.org/2009/06/09-svg-minutes.html	

or as text below:

    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

                    SVG Working Group Teleconference

09 Jun 2009

    See also: [2]IRC log

       [2] http://www.w3.org/2009/06/09-svg-irc

Attendees

    Present
           Cameron, Erik, Doug, Jonathan, Chris

    Regrets
    Chair
           Erik

    Scribe
           Cameron

Contents

      * [3]Topics
          1. [4]SVG2
          2. [5]making things properties
          3. [6]Fonts
          4. [7]Print / Color
          5. [8]Compositing
          6. [9]Transforms
          7. [10]WebCGM digression
          8. [11]back to transforms
          9. [12]SVG 1.1 Second Edition
      * [13]Summary of Action Items
      _________________________________________________________



    <trackbot> Sorry, heycam, I don't understand 'trackbot, hello'.
    Please refer to [14]http://www.w3.org/2005/06/tracker/irc for help

      [14] http://www.w3.org/2005/06/tracker/irc

    <trackbot> See [15]http://www.w3.org/2005/06/tracker/irc for help

      [15] http://www.w3.org/2005/06/tracker/irc

    <trackbot> Date: 09 June 2009

    <ChrisL> ScribeNick: ChrisL

SVG2

    CL: we have a bunch of open issues on svg2 now, things to discuss
    that wewre deferred

    ED: Start from a spec

    CM: Start from scratch, no grandfathering. More concise
    ... examples are fine, but crisper conformance statements

    JW: should not need the examples to understand the rest

    CM: Not as pseudocodey as HTML5

    ED: Goal is to pick parts from tiny 1.2 and full 1.1, merged into
    one spec

    CM: Also some things that are not the right thing that we could
    change

    CL: Is it possible to conform to both svg2 and svg 1.1/1.2T? Need to
    decide on expectetions for older user agents etc

    CM: Once svg2 is in the repo it will lead away from fixing up 1.1

    ED: merging does not exclude mobile, this is a spec for desktop and
    mobile. new iphone supports acid 3 as an example
    ... opera 9.7 on windows mobile also passes

    CM: Forwards/back compat like Tiny, not a complete break

    CL: So not a new mime type for example

    CM: Userr base is more adapatble

    <ed> s/also passes/gets a 100/100 score/

    cl: we bneed to not piss off existing adopters like inkscape, kde,
    xslfo+svg users

    <ed> s/scored 100 out of 100/gets a 100\/100 score/

    CL: perhaps we could list our hated or unuseful features

    JW: eRR needs better defined

    ED: vertical text needs better defined

    JW: Lets have a wiki page for this

    CL: two secions, one hitlist for dropping and one underdocumented
    list

    [16]http://dev.w3.org/SVG/modules/color/master/color-syntax.txt

      [16] http://dev.w3.org/SVG/modules/color/master/color-syntax.txt

    <heycam> ACTION-2550:
    [17]http://dev.w3.org/SVG/modules/color/master/color-syntax.txt

      [17] http://dev.w3.org/SVG/modules/color/master/color-syntax.txt

    <trackbot> Sorry... adding notes to ACTION-2550 failed, please let
    sysreq know about it

    [18]http://a.deveria.com/caniuse/#agents=All&eras=All&cats=SVG,Summa
    ry&alts=j&statuses=rec,cr,wd,ietf

      [18] http://a.deveria.com/caniuse/#agents=All&eras=All&cats=SVG

    CL: so i think that gradients which link to other gradients has
    turned out to be a misfeature
    ... Markers are an issue, in a new language i would not have
    markers, instead i would have a separate polymarker element
    ... painted bounding box

    JW: getting pbb is very expensive

    ed: yes, it can be. requires off screen painting in many cases

    (some yes it is, no it isn't ratholing)

    my it seems to be almost lunchtime

    [19]http://www.selenic.com/mercurial/wiki/CvsConcepts

      [19] http://www.selenic.com/mercurial/wiki/CvsConcepts

    <ed> break for lunch

    <ed> back from lunch

    DS: Like to lookat the polar element, and nurbs

    [20]http://en.wikipedia.org/wiki/Nurbs

      [20] http://en.wikipedia.org/wiki/Nurbs

making things properties

    ED: CSS wg seemed to think some of our attrs were suitable as
    properties, not all of them

    CL: So you want to make all attrs properties, doug?

    DS: Yes prtetty much

    CL, JW: Why?

    <ed> ACTION-2569?

    <trackbot> ACTION-2569 -- Erik Dahlström to draft a proposal to have
    width and height properties -- due 2009-05-27 -- OPEN

    <trackbot> [21]http://www.w3.org/Graphics/SVG/WG/track/actions/2569

      [21] http://www.w3.org/Graphics/SVG/WG/track/actions/2569

    DS: Want to use classes to affect other things than style. d== no,
    href, id, no....

    JW: Prefer to add on a case by case basis

    ED: yes

    DS: More a thought exercise

    CM: Could use stuff from css3 values and units, so calc()

    CL: Would rather have a calculation facility that would work on
    attrs and properties

    CM: My thinking was that if its easy to turn attr to prop to get
    that functionality then do that
    ... if we can ger a syntax that works on non-property attrs that is
    good

    ED: So see which of ourt attrs have an existing css property, width
    and height obvious ones

    CM; If they have the same meaning

    <heycam>
    [22]http://dev.w3.org/SVG/profiles/1.1F2/publish/attindex.html

      [22] http://dev.w3.org/SVG/profiles/1.1F2/publish/attindex.html

    s/outs/our/

    ED: Is there a global list of all css properties from all css3
    drafts?

    CL: Not as far as I know

    document.properties.iterate()

    (discussion on the difficulty of aggregating specs from multiple
    WGs)

    ED: transform is going into css, so there is anothetr one. need to
    define for 2dtx

    CM: Likely that animatable attes should be properties (as a first
    cut)
    ... transform, width, height

    ED: x1 y1 cx cy etc do not have a direct mapping, but could be more
    useful

    DS: rx ry has applicability, rounded corners

    CL: thats border-radius

    JW: Properties that inherit into stuff need to have consistent
    meanings from html and css. not so critical for non-inherited
    properties
    ... Concerned over making everything a property

    CL (amusing tale of xml:id becoming inherited in C12n)

    ED: Could get benefts by yusing transform together with width and
    height

    CM: Not with rounded corners
    ... rx has different meaning on rect and ellipse

    DS: Not terribly different
    ... Yesterday I mentioned wanting rx, ry and stroke on image, as a
    poor mans clippath
    ... Is there an optimisation hit for that ... not sure its worth it.
    But typically can see the thing you are clipping

    CM: Can use 'use' in clippath
    ... pointing to a graphical shape

    (brief discussion about ITU liaison as we remember they meet soon)

    ED: Some things that udom is good for and full dome does not cover,
    like pulling out a path from a glyph element
    ... missing from 1.1, should be added
    ... typed access is better for presentation properties, better than
    dom2 style

    CM: onclick, not a property

    (digression on JSRs)

    CM: things that have lengths

    DS: Things that don't have complex types

    cm: polyline - list of numbers, nt lengths

    ds: often wanted a percentage on a path.

    CM: Or H 2em

    ED: How does css transform integrate into svg, and what about
    gradient transform?
    ... why is it even called gradient-transform and not just transform
    ... and pattern-trandform

    CL: and svg:transform

    CM: Points is ok as a property value, but not things more complex
    than lists of simple types

    (digression on consistent list syntax in SVG2)

    ED: Mozilla has transforms in css. does it aply to svg, currently

    JW: No it does not, yet
    ... need to say the property is mapped , or that it takes precedence
    ... practicval difference if its made to inherit

    ED: Not difficult to make it inherit

    JW: what if therre is an animateTransform

    ED: Works on the eventual transform, after cascading

    <ed> CL: (explains CSS and XML animation)

    <heycam> CL: doing <animate attributeType="XML"
    attributeName="stroke"> animates the property, it's not possible to
    animate the presentation attribute separately

    ed: JW could you look into how svg transforms and css transforms
    interact on svg content?

    JW: sure

    <scribe> ACTION: jwatt to look into how svg transforms and css
    transforms interact on svg content? [recorded in
    [23]http://www.w3.org/2009/06/09-svg-minutes.html#action01]

    <trackbot> Created ACTION-2603 - Look into how svg transforms and
    css transforms interact on svg content? [on Jonathan Watt - due
    2009-06-16].

    [24]http://dev.w3.org/csswg/css3-values/

      [24] http://dev.w3.org/csswg/css3-values/

    [25]http://dev.w3.org/csswg/css3-values/#the-calc-function

      [25] http://dev.w3.org/csswg/css3-values/#the-calc-function

    so calc only does constant expressions on lengths

    which must have a unit

    <atomic-length> := <number><length-unit>

    Issue: At a later date new operators such as min/max, conditionals,
    new constants, division by length units etc. may be added.

    <trackbot> Created ISSUE-2278 - At a later date new operators such
    as min/max, conditionals, new constants, division by length units
    etc. may be added. ; please complete additional details at
    [26]http://www.w3.org/Graphics/SVG/WG/track/issues/2278/edit .

      [26] http://www.w3.org/Graphics/SVG/WG/track/issues/2278/edit

    <heycam> CM: it'd be a bit annoying to have to say <rect
    width="10px"> instead of <rect width="10">

    <heycam> CM: oh no, it's the scientific notation that is restricted

    <heycam> CM: so you couldn't say <rect width="1.23e5">

    <heycam> CM: and scientific notation is primarily useful for
    geometric attributes like width="" on <rect>

    <ed>
    [27]http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/presentationattr-s
    cientificnotation.svg

      [27]  
http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/presentationattr-scientificnotation.svg

    <ed> Opera, Firefox and Safari all behave slightly different on that
    testcase

    (we agree to try again to get sci.not accepted in css)

    CM: units optional in presentation attrs, but required in
    stylesheets

    <scribe> ACTION: jwatt rock the roc re sci.not [recorded in
    [28]http://www.w3.org/2009/06/09-svg-minutes.html#action02]

    <trackbot> Created ACTION-2604 - Rock the roc re sci.not [on
    Jonathan Watt - due 2009-06-16].

Fonts

    <ed> scribeNick: ed

    CL: we have a fonts module, but it's not checked in
    ... john daggett has done some of the work
    ... subsetting to the parts that are implemented
    ... extended fontmatching stuff dropped
    ... things that are missing: standalone spec for svgfonts with
    different conformance levels, for xsl
    ... though they might also want opentype fonts
    ... extensions of fonts, vertical text
    ... other things missing: xml syntax
    ... svgs xml syntax, other spec could cameleon it into another spec
    ... commenting on css3 fonts
    ... jdaggett is writing tests
    ... I'm converting them to svg syntax
    ... want to put them into the svg testsuite
    ... he's only testing HTML implementation

    CM: saw the mail you sent out about existing implementatioins
    ... among which are several svg impls

    CL: i feel we need more font tests
    ... good to see opera shipping with support for svgfonts and
    truetype fonts

    CM: what about hte module?

    CL: if it's useful to make a module then I can do the work

    CM: useful if we need to define something for xsl
    ... wopuld the module have @font-face equivalent, would it require
    svgfonts?

    CL: don't think so, they're more interested in opentype fonts
    ... downloadable fonts

    DS: they're doing print stuff right
    ... why wouldn't they want svgfonts?
    ... having a supplementatry spec to svgtiny12 would be good for JIS
    ... for vertical text

    CM/CL: good point

    CM: just wondering if it was worth having a module

    DS: for vertical text yes
    ... but does it belong in a font module?

    CL: font support for vertical text belongs in a font module

    (discussion of vertical text missing in tiny12)

    CL: easy to make fonts standalone with added support for vertical
    ... difficult if it ties into the rest of svg, gradients etc

    DS: (draws on whiteboard)
    ... want to annotate text
    ... and selectable

    CL: you could do one glyph with complex subshapes
    ... inkscape added some functionality for drawing svgfonts
    ... do you want an ALT tag?

    DS: just some way of saying something is text, and this is what it
    represents
    ... title with a role=text?
    ... talked to designers, making svg posters made more difficult
    because of lacking support

    CL: who in moz is working on that btw?

    JW: jdaggett I think

    CL: happy to help if it's needed

    JW: he started asking about svgfonts

    (discussion about blocked bugs)

    CL: making a module that does tiny fonts + vertical font
    ... we're not sure about the xml serialization of @font-face (for
    possible reuse by xsl)

    CM: if JIS is interested question is, what use is it without support
    for vertical text?

    CL: yeah, it's more useful when combined

    <scribe> ACTION: CL to commit the SVG Fonts module, removing the
    parts already covered by CSS3 Fonts [recorded in
    [29]http://www.w3.org/2009/06/09-svg-minutes.html#action03]

    <trackbot> Created ACTION-2605 - Commit the SVG Fonts module,
    removing the parts already covered by CSS3 Fonts [on Chris Lilley -
    due 2009-06-16].

    break for a moment, waiting for anthony to join for discussion on
    print/transform/color/compositing modules

Print / Color

    AG: CL you split out color right?

    CL: yes

    <heycam> Scribe: Cameron

    <heycam> ScribeNick: heycam

    CL: i was at csswg last week and they want to add cmyk support
    ... i objected on the grounds that they weren't clear on whether
    they wanted icc cmyk or device color
    ... implementors are demanding it
    ... hakon doesn't really understand the difference
    ... response he got back from implementors is that they want both
    ... so if you look at the current spec it still has the old stuff
    about device color
    ... it says device color is a name followed by a list of numbers
    ... and the name takes you to a device-color element, which olds an
    href that points out to who knows what
    ... and the example uses a numberOfComponents attribute that's not
    used anywhere, and extension namespaces
    ... the info about what the colours actually are are in a comment
    block
    ... for the common case where you want to say this is device cmyk,
    how do you do that?
    ... what uri should i use/mint to represent device cmyk? there isn't
    an easy way to do that.
    ... so i started changing the device-color element to make that work
    ... but the css folks just want a simple property value for that,
    not indirecting through an xml block

    <ChrisL> [30]http://dev.w3.org/SVG/modules/color/DoC/Tiny12DoC.html

      [30] http://dev.w3.org/SVG/modules/color/DoC/Tiny12DoC.html

    CL: looking at this DoC, all the comments on print
    ... so you can take a copy of this to make the DoC for the Page
    module, changing some bits
    ... there's a lot of green there, except for one purple item "we
    need to change this"
    ... i've got proposed text in there to accede to the commentor
    ... "device color would be better using pseudo profiles ...", and i
    said we disagree
    ... but i propose we change that to green/agree, since at the end of
    the day what you want is device cmyk (very important), device rgb
    perhaps, device grey, and device multi channel which is just as
    vague as the current spec
    ... hexachrome, you could probably do that with an icc profile
    ... and photo rgb printers like the epsons: cyan, light cyan,
    magenta light magenta.... 7 colour printers
    ... but that's no big deal they take sRGB input
    ... so i've change the device-color token to be one of device-grey,
    device-cmyk, ...
    ... device-grey takes one colour
    ... device-rgb takes three colours
    ... device-cmyk takes four colours
    ... unlike the current spec, it tells you what those colour
    parameters mean
    ... device-multichannel thing takes how many every colours it takes,
    and you don't know what they mean
    ... but that's by far the least useful case anyway

    AG: would you have a list of numbers that you don't know the length
    of?

    CL: yes
    ... that's the weak part of the proposal
    ... jeremias from fop wanted these
    ... so we're giving them exactly that
    ... csswg wanted something quite similar to this
    ... so the vendors who want this functionality get both of the
    things what they want
    ... and we keep inkscape/scribus happy, who also wanted device cmyk
    ... so i propose that we adopt this, then i add it, which is easy
    ... and i'll also add the syntax appendix part

    <ChrisL>
    [31]http://dev.w3.org/SVG/modules/color/master/SVGColor.html

      [31] http://dev.w3.org/SVG/modules/color/master/SVGColor.html

    AG: did we want to lift any content from my 2007 paper?

    CL: yes but that would mostly go in the primer
    ... another thing i've done is i've changed all the defs of the
    rendering intents
    ... so it uses HP's wording
    ... (from the DoC)
    ... at LGM they were happy about splitting the spec apart

    DS: people still do want a pagination model, though

    CL: they may have misunderstood split to mean throw out

    DS: right
    ... is canon still interested in pagination?

    AG: not at the moment
    ... they're more focussed on the UI stuff at the moment still
    ... can i get this master version of the spec reviewed by my guys
    yet?

    CL: i'd like to publish this, i need to do some responses to the
    commentors
    ... so 2 weeks response time for that
    ... it's public anyway, so you can point them to dev.w3.org

    AG: many more changes in the next 2 weeks?

    CL: not apart from folding in that syntax change
    ... i'm likely to beef up the primer
    ... add the stuff from your paper

    AG: we might take the language spec and review it then

    CL: sure
    ... i don't think is just ready for another LC yet
    ... but fairly shortly after this it should
    ... i do want to move it forward to CR, since there are implementors
    waiting for it
    ... one of the other things i've put in is a clear conformance
    requirement that UAs colour match embedded images
    ... firstly, the old spec assumed that but didn't mention it really
    ... it only told you how to override the colour profile with a
    different one, which is of less interest
    ... the reason that's important is that firefox and safari both do
    colour management of images now
    ... so they would conform to that part, and we can raise bugs if
    they colour manage images in html and not in svg, and they can reuse
    code and just hook it up

    AG: can we still add bits and pieces to the language spec?

    CL: yes, i'm not asking for a second LC yet, but it's getting close
    ... so i'll bring that to a telcon, but in a couple of weeks

    AG: i think it would be good to have something like "preserve black"
    in there, for text
    ... so if you have text that's black, and set a preserve black on
    it, so that it uses the black ink at the cmyk end

    CL: if you look at the rendering intents, i've change the language.
    one of the changes is that primarily you should be using
    relative-colorimetric
    ... and using that with black point compensation, so if the target
    device black is not 0, but some measured value of black, you'll map
    your blacks to that

    AG: yes but if you wanted to use a different rendering intent, or
    the one on the profile isn't there since not all profiles support
    it, then you might run in to problems
    ... i would like to see preserve black in there
    ... it's also useful for images

    CL: so that'd be a second attribute on the <color-profile> element?

    AG: yeah probably
    ... although i'll check with the guys here

    CL: i can add it in to the spec so it sounds reasonable

    AG: should i propose some wording?

    CL: yes please

    <scribe> ACTION: anthony to propose wording for "preserve black"
    attribute for color profiles [recorded in
    [32]http://www.w3.org/2009/06/09-svg-minutes.html#action04]

    <trackbot> Created ACTION-2606 - Propose wording for "preserve
    black" attribute for color profiles [on Anthony Grasso - due
    2009-06-16].

    CL: i'm going to start on test cases, tho it's a bit difficult
    without an implementation

    AG: does opera support colour management?

    ED: no

    CL: firefox 3.5 does, 3.1 did not
    ... unless you switched on specific prefs
    ... only on embedded images

    AG: we'll have to think up of some crafty colour values for the
    tests

    CL: for input i found documentation for the macbeth colour checker
    with measured colour values
    ... got those values converted to cielab
    ... from that i can produce srgb values etc., so i've done that here

    AG: are we going to allow... i know we have solid colour, viewport
    fill... what other things use colour? feFlood?

    CL: yes
    ... flood-color
    ... it's missing viewport-fill though
    ... there is an outstanding issue that many profiles don't have all
    four rendering intents specified, so what do you do if you ask for a
    rendering intent that's not supplied?

    AG: i think this was mentioned in the first round of comments from
    guys here
    ... they said something on the lines of using fallback, or ignoring
    it

    CL: if you allow it to use any rendering intent, you need it to
    definitely work if it has those rendering intents
    ... if it only has a single rendering intent, then allow it to use
    that

    AG: be good to say in the spec if the rendering intent is not in the
    profile, then just do colour conversion as normal
    ... there are also some minor editorial notes that unintentionally
    limit things, i'll send those in in the next week or so
    ... the sentence that begins "if icc based named colours are
    provided"
    ... in "icc named colour", in the first red box

    CL: it says it must use it in preference to the fallback

    AG: we should remove the "use profile connections other than ciexyz
    or ..."

    CL: why?
    ... are there profiles that use other connection spaces?

    AG: those are two common ones that i know of, don't know, but they
    could
    ... it's just limiting

    CL: i wanted to say that if you get a profile connection space that
    you don't know about, then you don't use it
    ... so you use fallback

    AG: ok i like your wording better

    <ChrisL> or uses an unsupported profile connection space

    <scribe> ACTION: Chris to follow up to all commentors on the colour
    module that haven't been responded to [recorded in
    [33]http://www.w3.org/2009/06/09-svg-minutes.html#action05]

    <trackbot> Created ACTION-2607 - Follow up to all commentors on the
    colour module that haven't been responded to [on Chris Lilley - due
    2009-06-16].

    <scribe> ACTION: Chris to fold in the edits to the colour module
    that were discussed at this meeting [recorded in
    [34]http://www.w3.org/2009/06/09-svg-minutes.html#action06]

    <trackbot> Created ACTION-2608 - Fold in the edits to the colour
    module that were discussed at this meeting [on Chris Lilley - due
    2009-06-16].

Compositing

    AG: haven't done much on that, just letting it sit
    ... still have to fold in cameron's and erik's comments in
    ... we haven't worked out any common wording for enable-background

    ED: we did publish a first draft of compositing right?

    AG: yes

    DS: there are a few things that would be good to get done by svg
    open, that you are working on
    ... compositing e.g., what needs to be done for that?

    AG: just folding in erik's and cameron's comments

Transforms

    DS: did you respond back to dino about the openvg stuff?

    AG: openvg is a bit higher level than opengl
    ... haven't responded back to him about that
    ... i did ping him and ask him if we can sit down and work out some
    common ground for the specs, but he seems to be a bit busy at the
    moment
    ... he'll get in touch with me some time soon
    ... i did some reading up on perspective transformations in 3d and
    looked a number of different ways of doing it
    ... from what i can tell, and other guys here tell, the way that
    canon's proposed matches what's currently known and done out there
    ... we don't understand the use case & reqs that css have
    ... e.g. for stringing along multiple perspective transformations in
    the one transform property
    ... so that's the first thing i need to talk to dino about
    ... i've played around with webkit for a bit, since they implement
    the transform stuff
    ... the results it produces when you apply a perspective transform
    seem a bit odd
    ... it's as if it doesn't implement it at all
    ... so not sure what's going on there

    CM: it might just be the iphone build of safari

    AG: i did some testing between the css proposal and ours
    ... with both you can get the same effects
    ... but i would like to understand why they want the chainable
    perspective transformations
    ... a lot of the other things are similar, and we could use the same
    syntax/spec for

    DS: might be useful to still write up why the matrices are the way
    they are, and the openvg reasons

    AG: using openvg, you need to render all your graphics to a buffer,
    flatten it, then apply a 3x3 perspective transform
    ... the maths is in the spec
    ... what sort of write up are you looking for?

    DS: a rationale about why it doesn't hinder the spec to do it this
    way

    AG: compared to what css proposes, it doesn't really change anything

    DS: but we need to justify it

    AG: another thing we'll need in the transforms spec is, and i'd like
    the group's opinion on, is an xml syntax for transforms, like we've
    discussed with paths

    <anthony> <svg>

    AG: it's similar to the stuff CRF in EXI have done

    <anthony> <defs>

    <anthony> <transform id="rotateX_rotateY">

    <anthony> <rotateX angle="45" />

    <anthony> <rotateY angle="45" />

    <anthony> </transform>

    <anthony> </defs>

    <anthony> <rect ... transform="#rotateX_rotateY" />

    <anthony> <circle ... transform="#rotateX_rotateY" />

    <anthony> <svg>

    AG: one of the advantages i can see is that you don't need to supply
    a group around objects to apply a transform, have them referenceable

    DS: i can see this useful for grouping logically and according to
    appearance

    ED: if you have the css transform, it's quite easy to reuse
    transforms with that

    DS: so yes i see a use case for it. if it's handled by making
    transform a property, ...
    ... probably it's better if we duplicate that functionality [with
    the xml syntax]

    AG: with css can you animate a component of the transform? say, the
    x component?

    ED: i don't know exactly if it's easy to do that. you'd have to
    split the transfrom property into several parts.

    AG: that was one of the other ideas i was thinking of. with the
    above example, you can animate individual components of a transform.

    CM: that's the same reasoning for separating out the path commands

    DS: true
    ... it reminds me of some things dino wanted to do with scaleX,
    scaleY, breaking them out into separate commands
    ... if they are going to be css properties, aren't the going to be
    svg properties as well?

    ED: [nods]

    <ed> [35]http://dev.w3.org/csswg/css3-3d-transforms/#animation

      [35] http://dev.w3.org/csswg/css3-3d-transforms/#animation

    CL: if the properties are mapped, you get that for free

    CM: i think the css proposal doesn't have separate properties for
    scaleX, scaleY, just separate commands in the one property

    ED: with css, you can animate individual items

    CM: and we have weirdo transform animations

    DS: but as separate attributes, then you don't have the ordering any
    more
    ... so it wouldn't work

    ED: so it doesn't sound like the broken-up xml syntax is what we
    want

    CM: will we adopt the css transform animation, or stick with what we
    have?

    ED: the decomposition?

    CM: yes

    DS: it'd break backwards compat

    ED: other things break tho, such as center point rotation

    DS: we should work with css to make sure we all have what we want

WebCGM digression

    CL: their transforms now have a center point for rotations

    <scribe> ACTION: Chris to mail comments about WebCGM [recorded in
    [36]http://www.w3.org/2009/06/09-svg-minutes.html#action07]

    <trackbot> Created ACTION-2609 - Mail comments about WebCGM [on
    Chris Lilley - due 2009-06-16].

back to transforms

    AG: so how do we want to handle animations
    ... the same as tiny?

    <ed>
    [37]http://www.w3.org/TR/SVGMobile12/animate.html#AnimateTransformEl
    ement

      [37]  
http://www.w3.org/TR/SVGMobile12/animate.html#AnimateTransformElement

    <ed>
    [38]http://www.w3.org/TR/SVGMobile12/animate.html#complexDistances

      [38] http://www.w3.org/TR/SVGMobile12/animate.html#complexDistances

    CM: we just do single component animations

    ED: makes less sense to interpolate individual components in a 3d
    matrix

    AG: yeah i guess so
    ... wondering if there's a use case for it though
    ... interpolating the whole matrix is definitely useful, individual
    ones not sure
    ... e.g. you might translate something then only animate a rotation

    CM: we could add an <animateTransform type="list">

    ED: we could keep the current behaviour, then add this to align with
    css

    CM: i like that, maybe it could even be the default if no type="" is
    specified
    ... though decomposing the matrix and doing linear interpolation on
    the components won't give you the same result as linearly
    interpolating a rotate() parameter

    ED: so would this go in the 3d transforms spec?

    AG: i think it belongs in animations chapter of svg 2

    ED: yeah

    <scribe> ACTION: Anthony to raise an issue on SVG 2 about
    animateTransform with matrix-decomposed interpolation like css
    [recorded in
    [39]http://www.w3.org/2009/06/09-svg-minutes.html#action08]

    <trackbot> Created ACTION-2610 - Raise an issue on SVG 2 about
    animateTransform with matrix-decomposed interpolation like css [on
    Anthony Grasso - due 2009-06-16].

    AG: other than that, nothing else to discuss on transforms

    ED: nothing to say on print?

    AG: no

SVG 1.1 Second Edition

    AG: i'm writing up the script at the moment to run through the xslt
    to transform the tests
    ... that should be done tonight

    CL: make sure you copy across any attributes on the root <svg>
    element, since some tests put some there

    AG: ok i'll change the xslt to do that

    <xsl:copy-of select='@*[local-name() != "id" and local-name() !=
    "width" and local-name() != "height" and local-name() != "viewBox"/>

    <anthony> <svg id="svg-root" width="100%" height="100%"

    <anthony> viewBox="0 0 480 360"
    xmlns="[40]http://www.w3.org/2000/svg"

      [40] http://www.w3.org/2000/svg

    put that as the first child of your <svg id="svgroot" width=".."
    ...> result element

    <anthony> xmlns:xlink="[41]http://www.w3.org/1999/xlink">

      [41] http://www.w3.org/1999/xlink

    AG: cdata sections will get stripped out

    [42]http://www.w3.org/TR/xslt#output

      [42] http://www.w3.org/TR/xslt#output

    <karl> hi ChrisL

Summary of Action Items

    [NEW] ACTION: anthony to propose wording for "preserve black"
    attribute for color profiles [recorded in
    [43]http://www.w3.org/2009/06/09-svg-minutes.html#action04]
    [NEW] ACTION: Anthony to raise an issue on SVG 2 about
    animateTransform with matrix-decomposed interpolation like css
    [recorded in
    [44]http://www.w3.org/2009/06/09-svg-minutes.html#action08]
    [NEW] ACTION: Chris to fold in the edits to the colour module that
    were discussed at this meeting [recorded in
    [45]http://www.w3.org/2009/06/09-svg-minutes.html#action06]
    [NEW] ACTION: Chris to follow up to all commentors on the colour
    module that haven't been responded to [recorded in
    [46]http://www.w3.org/2009/06/09-svg-minutes.html#action05]
    [NEW] ACTION: Chris to mail comments about WebCGM [recorded in
    [47]http://www.w3.org/2009/06/09-svg-minutes.html#action07]
    [NEW] ACTION: CL to commit the SVG Fonts module, removing the parts
    already covered by CSS3 Fonts [recorded in
    [48]http://www.w3.org/2009/06/09-svg-minutes.html#action03]
    [NEW] ACTION: jwatt rock the roc re sci.not [recorded in
    [49]http://www.w3.org/2009/06/09-svg-minutes.html#action02]
    [NEW] ACTION: jwatt to look into how svg transforms and css
    transforms interact on svg content? [recorded in
    [50]http://www.w3.org/2009/06/09-svg-minutes.html#action01]

    [End of minutes]
      _________________________________________________________


     Minutes formatted by David Booth's [51]scribe.perl version 1.135
     ([52]CVS log)
     $Date: 2009/06/09 23:29:25 $
      _________________________________________________________

      [51] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [52] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20
Check for newer version at [53]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

      [53] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

WARNING: Bad s/// command: s/also passes/gets a 100/100 score/
WARNING: Bad s/// command: s/also passes/gets a 100\/100 score/
Succeeded: s/also passes/scored 100 out of 100/
FAILED: s/outs/our/
Succeeded: s/cs/cx/
Succeeded: s/different/difference/
Succeeded: s/of/me of/
Succeeded: s/note/not/
WARNING: No scribe lines found matching ScribeNick pattern: <Cameron> .
..
Found ScribeNick: ChrisL
Found ScribeNick: ed
Found Scribe: Cameron
Found ScribeNick: heycam
ScribeNicks: ChrisL, ed, heycam
Present: Cameron Erik Doug Jonathan Chris
Found Date: 09 Jun 2009
Guessing minutes URL: [54]http://www.w3.org/2009/06/09-svg-minutes.html
People with action items: anthony chris cl jwatt

      [54] http://www.w3.org/2009/06/09-svg-minutes.html

    End of [55]scribe.perl diagnostic output]

      [55] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm


-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Tuesday, 9 June 2009 23:39:25 UTC