W3C

- DRAFT -

SVG Working Group Teleconference

16 Feb 2009

See also: IRC log

Attendees

Present
Regrets
Chair
SV_MEETING_CHAIR
Scribe
jwatt, Cameron

Contents


 

 

<trackbot> Date: 16 February 2009

<ed__> jwatt: http://www.opera.com/company/jobs/

<ed__> not keyboard navigable in FF

<jwatt> scribe: jwatt

<scribe> scribenick: jwatt

Transforms module

<ed__> http://dev.w3.org/SVG/modules/transforms/SVGTransforms.html

AG: I've been working on use cases and requirements
... as per concerns raised at the tech plenary last year

<anthony> http://dev.w3.org/SVG/modules/transforms/SVGTransformsReqs.html

AG: I kind of put some basic usage scenarios in there
... I'm not sure if anything more needs to be done
... want feedback

ED: there should be mention of and links to the CSS transforms proposal

CM: change that requirement 3.1 to mention supporting SVG DOM access to these transforms instead of a scripting feature set

DS: we should make sure to ask the CSS WG and browser vendors what their use cases and requirements are

AG: the scripting change should be easy
... I've done a bit more work on the transforms spec itself doing bits and pieces
... trimmed the specification down
... JF and I agreed to remove translateX/Y/Z and scaleX/Y/Z

JF: translateX/Y is part of the CSS specification but that's just syntactic suger

AG: we proposed a translate3D that takes three parameters

DS: why don't we just use 'translate' and extend it to allow it to take 3 parameters

AG: at the moment in our proposal translate3D has optional 2 parameters

CM: the syntax in the spec at the moment says it can have one or three

DS: rotate is different
... but scale and matrix...

AG: JF is right, it can be smaller
... to answer CM's question, the reason the the CSS specification is 4x4 is to allow perspective and 3D transformations
... in our proposal we've separated out the syntax to have a separate 3D and perspective transform
... in the spec you can specify one vanishing point per object

[AG draws on whiteboard to demonstrate separation]

CM: you're saying the 12 component version is more compatible with OpenVG?

<ChrisL> presumably opengl can also use the 3x3. i doubt openvg is an incompatible superset

AG: OpenVG uses 3x3, OpenGL uses 4x4

CM: is it because restricting the matrix to have all zeros in the third row of the perspective matrix means that when you multiply it by the 3D matrix it reduces down to a 3x3 which matches the OpenVG interface?
... and that's because you can't specify a general 4x4 matrix, and ...
... having general 3D effects isn't useful

AG: [yes]

DS: we can still do animations?

AG: yes

DS: are we going to cut ourselves off from future effects?

AG: not that I can think of

DS: are there two matrices or one, and what will getCTM return?

ED: we would extend the SVGMatrix interface to get at all the values of the matrix, so still the same object we're return, but with more accessors

AG: so, as a note, the reason we put SVGMatrix3D in there was to be compatible with SVG 1.1 matrices
... in answer to whether we'll miss out in stuff in future, the answer is still no, but currently the model we've got makes things a bit easier, because in CSS you can get | rotate perspective translate perspective |
... (repeated perspective)

DS: I thought theirs was separate

AG: they have both

DS: what's the use case

AG: I haven't seen any

DS: we should get them

ED: I think if we have rotate3D et. al, we'd probably want the same naming for translate and scale, that is having the suffix 3D there too

DS: but how would you do it, what would the syntax be?

AG: you need a rotation vector

CM: the restriction that you can't specify general 4x4 means that you are compatible with both OpenVG and OpenGL because 3x3 is just a subset of 4x4

DS: why do we need matrix3D?

ED: there is one reason: older user agents won't misinterpret it

CM: maybe we want to introduce forwards compatible parsing of transform lists so that individual transforms that are not recognized are ignored
... not sure if you can have useful results by ignoring them

AG: it's probably feasible, since the old matrix has 9 values

CM: I think that's a bit different from what I said
... still not sure if it's useful
... if the document needs to have perspective transforms to look right, is it useful?

ED: it will probably look incorrect either way

DS: if you use a matrix with 9 values in Firefox it throws away the entire transform

ED: Opera does the same probably

DS: [tests] actually Opera applies anything that comes before the matrix with 9 values, but not anything after
... Safari does the same as Firefox
... Batik pops up an alert
... if implementations all behaved like Opera, you could fake perspective with an initial skew and rotate, then undo the skew and rotate in the matrix that does the real perspective transform for newer user agents that support it
... extending 'matrix' or introducing matrix3D seems to make no difference in what implementations do

ED: if we extend, then rotate3D would be the only odd one out

<ChrisL> +1 to that

<ChrisL> assuming "that" gets minutes (hint)

DS: we could extend 'rotate' and make it depend on the number of parameters that are passed

<shepazu> rotate(<rotate-angle> <nx> <ny> <nz> [<cx> <cy> <cz>])

CM: CL, what were you +1'ing?

CL: what shepazu just said

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

JF: we introduced a transform-origin property

DS: is this in css as well?

JF: yes
... it's essential for 3d transforms
... without this property it's difficult to handle 3d transformations
... it's actually an extension and useful for 2d transforms

<anthony> http://webkit.org/specs/CSSVisualEffects/CSSTransforms3D.html#transform-origin-property

JW: a vanishing point?

JF: no

JW: how is this diferent from premultiplying a 3d translate?

JF: that's all it is

ED: it's also in the css proposal

JW: what's the advantage of having it separate?

ED: you have to write more if you do it in the transform list

AG: when you do translate, you need to work in that user space, but with transform-origin, you can put it in an object and say that it's the center of the object

DS: it's in the outer coordinate space

AG: it would allow percentages, too, object bounding box coordinates

ED: one question, is transform-origin in this spec exactly the same as in css transforms?

JF: very useful for transform origin, especially if we set the transform-origin as 50%,50%
... you can rotate or scale about the center point
... very convenient
... the initial value of this property is defined as 50%,50% in css transforms
... but we are thinking whether we should use this intiial value
... if we don't specify a transform-origin, it should rotate about the origin
... maybe it should be 0,0

JW: is css transforms spec

s/spec a rec already?/

CM: no they're about to publish a FPWD

DS: otherwise it changes how svg transforms work currently

AG: you can specify keywords, percentages and lengths in transform-origin
... but would the length be offsets from the origin or the bbox of the object?
... is that too overloaded?

CM: i think that would be confusing

<ChrisL> yes, thats too overloaded. just changing the unit should not change what parameter it is

AG: it seems a bit overloaded

DS: the 50%,50% initial value is at odds with existing percentage syntax in svg
... that would be viewport relative

ED: but in some cases they are relative to bboxes

DS: we could have something like transformUnits="objectBoundingBox"
... transformOriginUnits

AG: then you'd need to use both properties in pair

DS: the default is "userSpaceOnUse", for lengths

AG: relative to the origin

DS: and "objectBoundingBox" would make the lengths be relative to the bbox of the object
... the default should be userSpaceOnUse
... i don't mind this overloading

CM: why can't we have the transformOriginUnits value inside the transform-origin?

DS: it would be harder to parse, maybe more confusing for authors
... what if you want to animate the transform-origin?
... would you need to keep those transformOriginUnits keywords in the animation too?
... we should have these userSpaceOnUse/objectBoundingBox functionalities though

CM: you could have these keywords repeated in the transform-origin to use different references for the different axes

JW: css would have three values for this units attribute/keyword: the equivalent of objectBoundingBox, nearestContainingBlock and initialContainingBlock

CM: which one does userSpaceOnUse correspond to?

JW: probably nearestContainingBlock

ED: for transform-origin, if you had scale and rotate in the same transform, would the origin apply to both of them together? or each individually?

CM: it gives a pre and post translation for the whole transform
... in css transforms

ED: our one should say something about that

CM: be nice to have matrices and worked examples in the spec
... perspective-origin in the css spec

AG: in ours, we can just put the perspective origin in the 'perspective' property itself (giving three values)

ED: so you're changing all the matrix3d() to just matrix() with 12 values?

JF: i think we should consider this, examining the current implementation
... if it's ok, we're happy to change

ED: but for the other ones, we're dropping the "3d" suffix to them?

JF: i think we should carefully examine that

AG: we'd need to investigate how feasible these changes are

CM: how about backface-visibility which is in the css spec?

http://webkit.org/specs/CSSVisualEffects/CSSTransforms3D.html#backface-visibility-property

JF: i think that property is useful for some use cases
... currently we have no strong opinion about this

CM: without it, you would need to animate and compute at what times to hide the two faces

ED: i agree it would be useful in some places to have this property
... i don't think there's anything unsuitable for it being used in svg too

AG: should we have layeredGroup?
... it's like a restricted form of z-index

DS: what about 3d models, like rotating a cube?

AG: layeredGroup would handle this case, as well as the backface-visibility case

ED: backface-visibility is a css property, but layeredGroup wouldn't be

<ChrisL> backface culling is common on real 3d systems, as the amount of data to be sent down the pipe can often be halved. but where is the back geometry coming from, in 2D?

DS: so we may as well have backface-visibility, since we'll already have it in css

CM: should we be adding these as properties or attributes?

DS: well if we're having these css ones, then we may as well have these as properties too
... and make 'transform' a property

JW: then we really need to make the two (the svg and css 'transform') compatible

http://webkit.org/specs/CSSVisualEffects/CSSTransforms3D.html#transform-property

they don't have TransformRef values

DS: maybe it just wouldn't work with css boxes
... so we really need separate rotateX, rotateY, rotateZ?

AG: the regular rotate() in svg rotates around the z axis

CM: so rotateZ() is just the same as rotate()

ED: so it would make it slightly simpler than the one we're proposing, since we need to specify the vector to rotate around?

JF: if you have individual rotates, it's easier to do animation on these rotateX, rotateY
... you could do animateTransform type="rotateX"

CM: so it's a similar sugar as having both matrix() and translate(), e.g.
... and the css spec has these too

DS: i don't mind rotateX, Y, etc.

AG: in our spec, rotateX, rotateY and rotateZ can all take two optional center point coordinates
... in the css spec they don't have that

DS: their 'transform-style' property allows you to do the cube rotation example

CM: would we then prefer layeredGroup over transform-style and backface-visibility, or vice versa?

DS: we could have both, and talk about how they interacts with layeredGroup

AG: layeredGroup would allow you to specify the z-indexes of each child

CM: so that seems to be less usable than transform-style, which will work out the right z-order itself

JF: i agree
... but i'm not sure if this 'transform-style' with preserve-3d works or not
... it will choose which to display based on the z coordinate
... but sometimes objects are not parallel to the x/y plane
... so it's difficult to define one specific z position of the objects
... the objects might intersect

CM: maybe it would take the center of the bounding box (bounding cube?) to determine the z coordinate
... so layeredGroup would allow you to specify the exact ordering of the objects in the z axis

JF: i think we need further investigation of this

ED: should we try to publish what we have?
... or should we coordinate more?

CM: we'll do that mail on friday in that coordination session

<scribe> ACTION: Anthony to draft an email to send to the CSS WG summarising our thoughts about transforms [recorded in http://www.w3.org/2009/02/16-svg-minutes.html#action01]

<trackbot> Created ACTION-2467 - Draft an email to send to the CSS WG summarising our thoughts about transforms [on Anthony Grasso - due 2009-02-24].

CSS Animations spec

<ed__> http://dev.w3.org/csswg/css3-animations/

DS: we'll discuss these later in the week, give us a chance to read them

ED: on thursday

CM: so we should read both animations and transitions

DS: also please read the vector effects, filters, layout reqs documents for thursday

Compositing spec

<anthony> http://dev.w3.org/SVG/modules/compositing/master/SVGCompositingPrimer.html

<anthony> http://dev.w3.org/SVG/modules/compositing/master/SVGCompositing.html

AG: i think we need to put clipping and masking in the spec, since that's what we resolved
... but we could add it later, and publish this now
... it is publishable as it is
... the other day i sent an email out to benjamin who had posted that question about the soft-light equations
... i went to the pdf spec and got the new equations for color-dodge and color-burn, and soft-light
... but i didn't quite agree with his equation for soft-light, how he derived it from the pdf spec (for the alpha case)
... so i sent my derivations of the equations
... i think we are ok to publish what we've got
... the compositing spec follows the adobe compositing model

http://www.w3.org/mid/4994BF8F.1050302@cisra.canon.com.au

AG: benjamin's and my equations come up with slightly different numbers

CM: could you create a pdf file and check the colours to determine which is correct?
... did asv6 support these compositing features?

CL: don't know, i think it did but i'm not sure

CM: but you're ok with publishing with the equations as they are at the moment?

AG: yes

ED: the equations are in the primer. does that mean they're not normative?

DS: i think the primer should be a shorter document that gives the examples

ED: especially in the case of the equations, then they should go in the language spec

CL: you can have non normative stuff in the language spec, but no normative text in the primer
... it should purely be expository, pretty examples, etc.

AG: maybe about an hour or two's work

<scribe> ACTION: Anthony to move the equations over to the language spec [recorded in http://www.w3.org/2009/02/16-svg-minutes.html#action02]

<trackbot> Created ACTION-2468 - Move the equations over to the language spec [on Anthony Grasso - due 2009-02-24].

ACTION-2468: For the compositing spec, that is.

<trackbot> ACTION-2468 Move the equations over to the language spec notes added

DS: explain what is compositing, what you'd use it for
... almost like use cases and requirements

CL: it's a good place to explain why certain decisions were made, so that implementors don't think "oh that's stupid, i'll do it this more logical way" without realising why it was done that

JW: definitely rationale should be recorded

JF: is it useful to have the version number "1.2" in the specification?

AG: just call it "Compositing"

DS: same with "Filters"

RESOLUTION: Pending moving the equations, we will publish the Compositing spec and primer
... Add clipping and masking at some later point to the Compositing spec

Comments from roc

JW: regarding suspendRedraw, what we've said sounds reasonable
... he's still not sure why it is needed in browsers though
... html+css says that nothing is rendered in the middle of a script block

DS: what about when doing scripted animation?

JW: you'd use setTimeout(), when each invocation of the timer handler is finished, you'd get a rendering
... so suspendRedraw and unsuspendRedraw in the same script block isn't useful

ED: what happens in firefox if you have say a mouse event triggers a listener, and the function takes a long time to execute, would you have any updates?

JW: currently not

ED: not 100% sure if that's what we did before, in opera

JW: you might interrupt the script for a repaint?

ED: i'm pretty sure that in opera 9.2 or so we would do a repaint if the script is taking too long
... i think the newer strategy is to do what firefox is doing
... i don't want to say for sure, but i think we're doing something like that now

JW: so roc is wondering what the use cases are for, to have suspend/unsuspend in a different script invocations
... he doesn't see why svg should be different from html+css in this regard
... re clipping of filters, we'll go ahead and make that change

ED: i think we still need to discuss the actual solution
... i'd rather wait for the WG to make a decision on it

AG: so that's calculating their own values for clipping filters?

JW: so the width/height attributes wouldn't determine the size of the offscreen buffer, but they would still define the coordinate system for the filters to work within
... also we would need to alter feFlood to fill only the filter region

ED: i'd like to review JW's proposed text before going ahead with it

JW: he also had questions about LOD functionality

DS: the idea is that LOD has no effect on transform, it only responds to the currentScale DOM attribute

JW: what about a foreignObject with an SVG inside that? the currentScale in the inner document didn't change, but the outer one did?

DS: if you zoom in the outer one, i would not expect to change the LOD of the inner one

ED: i think that would make most sense for authoring

DS: i don't think it's reasonable to expect complex document fragments like that to behave in some complicated way
... i could see always looking at the outermost currentScale, don't think it's the most useful way though

[doug draws on the board]

SVG 1.1 errata

<ed__> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml

ED: we have actions for all of the draft errata
... nothing to report on the tangents one, but it's not defined well enough in 1.2T either, so there's no wording to backport
... i think we discussed a bit in the telcon about changing the implementation requirements chapter for animateMotion with zero length path segments
... currently the text is specific to things that render, paths
... i still don't think we have a conclusion on ACTION-2362

ACTION-2362?

<trackbot> ACTION-2362 -- Erik Dahlström to backport the zero length path wording from 1.2T to this "Reword F.5 Tangents" erratum -- due 2008-12-04 -- CLOSED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2362

<ed__> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#bzwidth

ED: next on the list is sizing of the outermost svg

ACTION-2370?

<trackbot> ACTION-2370 -- Erik Dahlström to go through the e-mailing thread for errata item "Sizing of the outermost svg" and update the item discussion -- due 2008-12-08 -- CLOSED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2370

ED: so i added those discussion/comment links
... i think tiny 1.2 defines all that boris wanted
... do we need to port that back to 1.1 in an erratum?
... so the issue about intrinsic sizing and use of svg in css
... so we have a whole section on intrinsic sizing in 1.2T

JW: are we publishing a 2ed soon?

CM: yes
... incorporating just the errata

<scribe> ACTION: jwatt to flesh out the intrinsic sizing erratum with text backported from 1.2T [recorded in http://www.w3.org/2009/02/16-svg-minutes.html#action03]

<trackbot> Created ACTION-2469 - Flesh out the intrinsic sizing erratum with text backported from 1.2T [on Jonathan Watt - due 2009-02-24].

<scribe> ACTION: jwatt to Review the spec for the consisten use of glyph and em square/cell, and get rid of character cell [recorded in http://www.w3.org/2009/02/16-svg-minutes.html#action04]

<trackbot> Created ACTION-2470 - Review the spec for the consisten use of glyph and em square/cell, and get rid of character cell [on Jonathan Watt - due 2009-02-24].

[discussion about perhaps postponing this erratum]

ED: after this F2F we could mail the list to point out the errata that we have at "proposed", and that we will fold these in to SVG 1.1 second edition
... and that we're not planning to fix other things with the second edition
... but still get comments on those errata

[we decide to postpone that one, reassigned the action to SVG Core 2.0]

<scribe> ACTION: Erik to send the mail announcing the errata and 1.1 second edition publication plans [recorded in http://www.w3.org/2009/02/16-svg-minutes.html#action05]

<trackbot> Created ACTION-2471 - Send the mail announcing the errata and 1.1 second edition publication plans [on Erik Dahlström - due 2009-02-24].

<ed__> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#svgzoomevent-interface

JW: seems like the right thing to me to drop zoomrectscreen
... it assumes that you implement zooming in the way that ASV did it

DS: i think zooming still needs more discussion with implementors

JW: it's quite underspecified at the moment

DS: taking out, to me, gives the impression that we don't want that feature at all

ED: we don't implement the rectangular selection zooming. we could, but not all UAs will want to do that.

JW: i think it should be the rectangle where x and y is the position of the top-left coordinate of the viewport in user space
... established by the target of that zoom.
... so you can position an element relative to what is the new viewport

ED: when you do this kind of zooming, what does it change? the viewBox? the currentScale/currentTranslate?
... is it possible to get the same information some other way?

JW: the viewport DOM attribute

ED: there's currentView as well

CM: maybe that's something different, what the currently linked to <view> element is?

JW: you want the zoom event to be dispatched just after the currentScale etc. attributes change, but just before a repaint
... does opera implement previousScale/previousTranslate?

ED: i don't think so

JW: i think all of the context information is redundant, be would would keep the zoom event
... i think mozilla's is the most complete implementation of SVGZoomEvent
... adobe didn't implement those properties
... we just do {previous,new}{Scale,Translate}
... maybe we shouldn't remove it all just now
... but in SVG.next, it seems like it would simplify implementations and the spec to remove them
... so remove zoomRectScreen?

ED: yes

JW: you can use viewport instead

DS: i don't mind removing it. i think how zooming is handled in svg needs more work, though.

JW: we could add a note to say that we will deprecate {previous,new}{Scale,Translate}

CM: i think we should remove rather than deprecate

ED: we could say in the erratum how to do this (caching those values)

RESOLUTION: Dropping all context info and attributes from SVGZoomEvent, and explain how you can get {previous,new}{Scale,Translate} by other means, but still having the event

ED: so those three errata could be combined

ACTION-2386: join these three errata and drop the context info and other attributes from SVGZoomEvent

<trackbot> ACTION-2386 Investigate the "SVGZoomEvent - Interface" errata item further notes added

ACTION-2386?

<trackbot> ACTION-2386 -- Jonathan Watt to investigate the "SVGZoomEvent - Interface" errata item further -- due 2008-12-25 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2386

ED: final erratum is "currentTranslate-currentScale on nested SVG"

http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#currenttranslate-currentscale-nested-svg

DS: being able to zoom in on individual <svg> elements ...

[doug draws]

JW: i don't think currentScale/currentTransform are good anyway
... you might want to keep the center centered, then zoom
... or maybe zoom to a rectangle

ED: you can use predefined <view> elements

JW: if you click on the plus button in doug's example, you don't want to just make currentScale larger, you need to also mess with currentTranslate

DS: right, but having both of them, plus a zoomToRect() method would be handy

AG: could add that to 2.0 Core

ED: would it have to use currentTranslate/currentScale? could it use viewBox instead?
... you can modify viewBox with script already

DS: so how does a viewBox work with regards to transforms and regards to LOD?

JW: it's part of the stack of transformation matrices

DS: related is when linking to a #fragment, when the element is too big to fit in the viewport

ED: should we address that now, or later?

DS: later. what do we do with this issue?

<scribe> ACTION: Doug to fill in the currentTranslate/currentScale erratum to explicitly make using those attributes on inner <svg> elements undefined [recorded in http://www.w3.org/2009/02/16-svg-minutes.html#action06]

<trackbot> Created ACTION-2472 - Fill in the currentTranslate/currentScale erratum to explicitly make using those attributes on inner <svg> elements undefined [on Doug Schepers - due 2009-02-24].

close action-2368

<trackbot> ACTION-2368 Propose wording for the change that addresses the errata item Current Translate Current Scale on nested SVG closed

CM: there are seven other actions for errata stuff
... we'll go through them to decide whether to handle them now or not

ACTION-2067?

<trackbot> ACTION-2067 -- Anthony Grasso to add Eriks proposed wording to the Errata. Link to ACTION-2066 -- due 2008-06-19 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2067

ED: this is about extending the background image outside the viewport
... this is about if you have filter content outside the viewport, whether that is clipped
... you specify in enable-background a rectangle
... or you can just say "new". opera is clipping to the viewport.

ACTION-2066?

<trackbot> ACTION-2066 -- Erik Dahlström to propose wording that clarifies the use of background image outside of the viewPort bounds -- due 2008-06-19 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2066

ED: i would be ok with postponing this for a bit
... and just put it into the filter spec
... the question is how often do you need to use enable-background for content outside the viewport

ACTION-2358?

ACTION-2367?

ACTION-2372?

ACTION-2404?

ACTION-2450?

ACTION-2451?

<trackbot> ACTION-2451 -- Erik Dahlström to modify the current errata item on SVGTransform.matrix that addresses ISSUE-2210 -- due 2009-02-16 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2451

ACTION-2367?

<trackbot> ACTION-2367 -- Erik Dahlström to propose an errata item for rx and ry -- due 2008-12-08 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2367

ACTION-2372?

ACTION-2372?

<trackbot> ACTION-2372 -- Doug Schepers to propose revised wording for the errata item "Capturing pointer-events with a zero opacity mask" to clarify it with clip-path -- due 2008-12-11 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2372

ACTION-2404?

<trackbot> ACTION-2404 -- Doug Schepers to add errata item for root overflow -- due 2009-01-22 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2404

ACTION-2450?

<trackbot> ACTION-2450 -- Cameron McCormack to make an errata item that aligns the pace animation in 1.1 Full with that in 1.2 Tiny -- due 2009-02-16 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2450

ACTION-2451?

<trackbot> ACTION-2451 -- Erik Dahlström to modify the current errata item on SVGTransform.matrix that addresses ISSUE-2210 -- due 2009-02-16 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2451

ACTION-2358?

<trackbot> ACTION-2358 -- Doug Schepers to propose wording for the clip path pointer-events erratum and masking/compositing module change -- due 2008-12-04 -- OPEN

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/2358

<ed__> ACTION-2367: Added testcase http://dev.w3.org/SVG/profiles/1.1F2/test/svg/shapes-rect-03-t.svg as a starting point

<trackbot> ACTION-2367 Propose an errata item for rx and ry notes added

<ed__> ACTION-2451: Added draft testcase http://dev.w3.org/SVG/profiles/1.1F2/test/svg/coords-dom-f-01.svg

<trackbot> ACTION-2451 Modify the current errata item on SVGTransform.matrix that addresses ISSUE-2210 notes added

<shepazu> jwatt: http://lists.w3.org/Archives/Public/www-svg/2008Nov/0064.html

close ACTION-2450

<trackbot> ACTION-2450 Make an errata item that aligns the pace animation in 1.1 Full with that in 1.2 Tiny closed

<shepazu> jwatt: http://lists.w3.org/Archives/Member/member-svg-editors/

<ed__> trackbot, close ACTION-2451

<trackbot> ACTION-2451 Modify the current errata item on SVGTransform.matrix that addresses ISSUE-2210 closed

Summary of Action Items

[NEW] ACTION: Anthony to draft an email to send to the CSS WG summarising our thoughts about transforms [recorded in http://www.w3.org/2009/02/16-svg-minutes.html#action01]
[NEW] ACTION: Anthony to move the equations over to the language spec [recorded in http://www.w3.org/2009/02/16-svg-minutes.html#action02]
[NEW] ACTION: Doug to fill in the currentTranslate/currentScale erratum to explicitly make using those attributes on inner <svg> elements undefined [recorded in http://www.w3.org/2009/02/16-svg-minutes.html#action06]
[NEW] ACTION: Erik to send the mail announcing the errata and 1.1 second edition publication plans [recorded in http://www.w3.org/2009/02/16-svg-minutes.html#action05]
[NEW] ACTION: jwatt to flesh out the intrinsic sizing erratum with text backported from 1.2T [recorded in http://www.w3.org/2009/02/16-svg-minutes.html#action03]
[NEW] ACTION: jwatt to Review the spec for the consisten use of glyph and em square/cell, and get rid of character cell [recorded in http://www.w3.org/2009/02/16-svg-minutes.html#action04]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2009/02/17 07:05:54 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/we're saying//
Succeeded: s/ think if we have scale3D et. al, we'd probably want the same for rotate/ think if we have rotate3D et. al, we'd probably want the same naming for translate and scale, that is having the suffix 3D there too/
FAILED: s/spec a rec already?//
Succeeded: s/whether it's possible to change our implementation/how feasible these changes are/
Succeeded: s/AG/JF/
Succeeded: s/the own value/their own values/
Succeeded: s/ED: i think that would make most sense/ED: i think that would make most sense for authoring/
Found Scribe: jwatt
Inferring ScribeNick: jwatt
Found ScribeNick: jwatt
Found Scribe: Cameron
Found ScribeNick: heycam
Scribes: jwatt, Cameron
ScribeNicks: jwatt, heycam

WARNING: No "Present: ... " found!
Possibly Present: ACTION-2367 ACTION-2386 ACTION-2451 ACTION-2468 AG CL CM ChrisL DS ED JF JW anthony chuckle ed__ heycam joined jun jwatt scribenick shepazu svg trackbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 16 Feb 2009
Guessing minutes URL: http://www.w3.org/2009/02/16-svg-minutes.html
People with action items: anthony doug erik jwatt

[End of scribe.perl diagnostic output]