- From: Leonard Rosenthol <lrosenth@adobe.com>
- Date: Mon, 23 Feb 2009 14:57:19 -0800
- To: Erik Dahlstrom <ed@opera.com>, "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Be aware that Adobe is in the process of publishing a correction to the algorithms for ColorDodge and ColorBurn, as we discovered that the published versions were incorrect for edge cases.
I can send you the revised info if you want.
Leonard
-----Original Message-----
From: public-svg-wg-request@w3.org [mailto:public-svg-wg-request@w3.org] On Behalf Of Erik Dahlstrom
Sent: Tuesday, February 17, 2009 2:11 AM
To: public-svg-wg@w3.org
Subject: Minutes Sydney 2009 F2F day 2
Minutes available here:
http://www.w3.org/2009/02/16-svg-minutes.html
or as text here:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
16 Feb 2009
See also: [2]IRC log
[2] http://www.w3.org/2009/02/16-svg-irc
Attendees
Present
Regrets
Chair
SV_MEETING_CHAIR
Scribe
jwatt, Cameron
Contents
* [3]Topics
1. [4]Transforms module
2. [5]CSS Animations spec
3. [6]Compositing spec
4. [7]Comments from roc
5. [8]SVG 1.1 errata
* [9]Summary of Action Items
_________________________________________________________
<trackbot> Date: 16 February 2009
<ed__> jwatt: [10]http://www.opera.com/company/jobs/
[10] http://www.opera.com/company/jobs/
<ed__> not keyboard navigable in FF
<jwatt> scribe: jwatt
<scribe> scribenick: jwatt
Transforms module
<ed__>
[11]http://dev.w3.org/SVG/modules/transforms/SVGTransforms.html
[11] 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>
[12]http://dev.w3.org/SVG/modules/transforms/SVGTransformsReqs.html
[12] 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>
[13]http://webkit.org/specs/CSSVisualEffects/CSSTransforms3D.html#tr
ansform-origin-property
[13] 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?
[14]http://webkit.org/specs/CSSVisualEffects/CSSTransforms3D.html#ba
ckface-visibility-property
[14] 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
[15]http://webkit.org/specs/CSSVisualEffects/CSSTransforms3D.html#tr
ansform-property
[15] 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
[16]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__> [17]http://dev.w3.org/csswg/css3-animations/
[17] 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>
[18]http://dev.w3.org/SVG/modules/compositing/master/SVGCompositingP
rimer.html
[18] http://dev.w3.org/SVG/modules/compositing/master/SVGCompositingPrimer.html
<anthony>
[19]http://dev.w3.org/SVG/modules/compositing/master/SVGCompositing.
html
[19] 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
[20]http://www.w3.org/mid/4994BF8F.1050302@cisra.canon.com.au
[20] 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
[21]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__> [22]http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml
[22] 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> [23]http://www.w3.org/Graphics/SVG/WG/track/actions/2362
[23] http://www.w3.org/Graphics/SVG/WG/track/actions/2362
<ed__>
[24]http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#bzwidth
[24] 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> [25]http://www.w3.org/Graphics/SVG/WG/track/actions/2370
[25] 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
[26]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
[27]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
[28]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__>
[29]http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#svgzoomev
ent-interface
[29] 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> [30]http://www.w3.org/Graphics/SVG/WG/track/actions/2386
[30] http://www.w3.org/Graphics/SVG/WG/track/actions/2386
ED: final erratum is "currentTranslate-currentScale on nested SVG"
[31]http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#currenttr
anslate-currentscale-nested-svg
[31] 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
[32]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> [33]http://www.w3.org/Graphics/SVG/WG/track/actions/2067
[33] 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> [34]http://www.w3.org/Graphics/SVG/WG/track/actions/2066
[34] 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> [35]http://www.w3.org/Graphics/SVG/WG/track/actions/2451
[35] 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> [36]http://www.w3.org/Graphics/SVG/WG/track/actions/2367
[36] 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> [37]http://www.w3.org/Graphics/SVG/WG/track/actions/2372
[37] 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> [38]http://www.w3.org/Graphics/SVG/WG/track/actions/2404
[38] 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> [39]http://www.w3.org/Graphics/SVG/WG/track/actions/2450
[39] 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> [40]http://www.w3.org/Graphics/SVG/WG/track/actions/2451
[40] 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> [41]http://www.w3.org/Graphics/SVG/WG/track/actions/2358
[41] http://www.w3.org/Graphics/SVG/WG/track/actions/2358
<ed__> ACTION-2367: Added testcase
[42]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/shapes-rect-03-t.s
vg as a starting point
[42] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/shapes-rect-03-t.svg
<trackbot> ACTION-2367 Propose an errata item for rx and ry notes
added
<ed__> ACTION-2451: Added draft testcase
[43]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/coords-dom-f-01.sv
g
[43] 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:
[44]http://lists.w3.org/Archives/Public/www-svg/2008Nov/0064.html
[44] 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:
[45]http://lists.w3.org/Archives/Member/member-svg-editors/
[45] 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
[46]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
[47]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
[48]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
[49]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
[50]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
[51]http://www.w3.org/2009/02/16-svg-minutes.html#action04]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [52]scribe.perl version 1.133
([53]CVS log)
$Date: 2009/02/17 07:05:54 $
_________________________________________________________
[52] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[53] http://dev.w3.org/cvsweb/2002/scribe/
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 [54]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[54] 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 s
ame for rotate/ think if we have rotate3D et. al, we'd probably want th
e same naming for translate and scale, that is having the suffix 3D the
re too/
FAILED: s/spec a rec already?//
Succeeded: s/whether it's possible to change our implementation/how fea
sible 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 wo
uld 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 scr
ibenick 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: [55]http://www.w3.org/2009/02/16-svg-minutes.html
People with action items: anthony doug erik jwatt
[55] http://www.w3.org/2009/02/16-svg-minutes.html
End of [56]scribe.perl diagnostic output]
[56] 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 Monday, 23 February 2009 22:58:25 UTC