See also: IRC log
<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
<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].
<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
<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
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]
<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
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]