- From: Erik Dahlstrom <ed@opera.com>
- Date: Mon, 16 Feb 2009 18:24:12 +1100
- To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Minutes available here:
http://www.w3.org/2009/02/15-svg-minutes.html
or as text here:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
15 Feb 2009
See also: [2]IRC log
[2] http://www.w3.org/2009/02/15-svg-irc
Attendees
Present
DS, JF, CMC, ED, CL, jwatt, AG
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Cameron, jwatt, ed_sydney
Contents
* [3]Topics
1. [4]Invited experts
2. [5]ISSUE-2213
3. [6]Image view box cropping
4. [7]ISSUE-2223
5. [8]SVG Interest Group
6. [9]<animation> element with regards to mapping
7. [10]svg bucket module
* [11]Summary of Action Items
_________________________________________________________
<trackbot> Date: 15 February 2009
<ChrisL> come on, you slackers, get into work already :)
<ChrisL> hi erik
<ed__> hello
<ed__> do you want to call in every day or just some of the days?
<ed__> we have a polycom here, but we need to set it up
<ChrisL> i'm willing to call in every day
<ed__> ok, we're just missing a phoneline now :)
<shepazu> ChrisL: I sent the phone number to the SVG WG list
<shepazu> ChrisL: +61 299768755
<ChrisL> thanks doug
trackbot, start telcon
<trackbot> Meeting: SVG Working Group Teleconference
<trackbot> Date: 15 February 2009
Invited experts
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
DS: Robin Berjon has asked if we'd be interested in having him as an
IE
... any objections?
[none heard]
RESOLUTION: We will invite Robin Berjon as an invited expert
<scribe> ACTION: Doug to do the paperwork for berjon's IE
application [recorded in
[12]http://www.w3.org/2009/02/15-svg-minutes.html#action01]
<trackbot> Created ACTION-2458 - Do the paperwork for berjon's IE
application [on Doug Schepers - due 2009-02-22].
DS: Zack Rusin from KDE expressed interest when discussing it with
him at SVG Open
<scribe> ACTION: Doug to follow Zack Rusin's interest in being an
invited expert [recorded in
[13]http://www.w3.org/2009/02/15-svg-minutes.html#action02]
<trackbot> Created ACTION-2459 - Follow Zack Rusin's interest in
being an invited expert [on Doug Schepers - due 2009-02-22].
DS: Rob Buis, also
... he's from WebKit
... I contacted Zack a while back and I said that we're in the
middle of 1.2T, so we don't have time to work on diffusion curves
right now (the gradient stuff)
... but that when we're finished with it we'd follow it up again
... I have permission from plh to invited him, and it should be
approved
<ChrisL> Joshua Andler
DS: I chatted with Josh Andler (from Inkscape) a few months ago
<ChrisL> [14]http://www.w3.org/2000/09/dbwg/details?group=19480
[14] http://www.w3.org/2000/09/dbwg/details?group=19480
DS: and his impression that we'd get back to him when we were done
with 1.2T
... if we can make it clear to him to get him involved with stuff
going forward, we could find features that Inkscape would be
interested in
<scribe> ACTION: Chris to come up with topics of interest to
Inkscape so we can approach Josh Andler [recorded in
[15]http://www.w3.org/2009/02/15-svg-minutes.html#action03]
<trackbot> Created ACTION-2460 - Come up with topics of interest to
Inkscape so we can approach Josh Andler [on Chris Lilley - due
2009-02-22].
ISSUE-2213
ISSUE-2213?
<trackbot> ISSUE-2213 -- Some issues in the definition of
suspendRedraw/unsuspendRedraw/forceRedraw -- RAISED
<trackbot> [16]http://www.w3.org/Graphics/SVG/WG/track/issues/2213
[16] http://www.w3.org/Graphics/SVG/WG/track/issues/2213
ED: do we need to address every weak spot in the 1.1 spec or whether
we can live with how it is and focus on 1.2
MON AM1 - Issues
MON PM1 - SVG IG Japan report
MON PM2 - Core 2.0 and plans
<ed__> [17]http://dev.w3.org/SVG/profiles/1.2T/errata/errata.xml
[17] http://dev.w3.org/SVG/profiles/1.2T/errata/errata.xml
CM: nothing in the errata yet related to this (just ed's issue
removing the exception for unsuspend*)
<ed__> sorry, wrong errata
<ed__> [18]http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml
[18] http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml
<ed__> #remove_exception_on_unsuspendredraw
[19]http://www.w3.org/TR/SVG/struct.html#InterfaceSVGSVGElement
[19] http://www.w3.org/TR/SVG/struct.html#InterfaceSVGSVGElement
CM: summary of boris' comment is that these methods should just be
hints
ED: i think that would be fine, it's just for the author to tell the
UA to lay off updates for a while
... just to help optimisation
... it doesn't hurt if it redraws too much, performance would be
worse, you might see things you shouldn't (half an updated tree for
example)
... but that's what you'd see anyway if the feature wasn't supported
at all
... so it's sort of a hint already
CM: does mozilla implement these?
JW: not really
... if you were doing drag and drop, user implements script that
moves the x/y position across, and it would flicker with
intermediate steps
... but now script changes are grouped together, so you don't get
this flickering
... so there's not much use for it now
ED: there are other ways of avoiding redraws, e.g. building trees
outside the document, then inserting that into the document
JW: a lot more performant to do it that way
ED: agreed
... in my experience it's more predictable to do it that way
JW: but if there is a lot of stuff in the document that you're
manipulating, you wouldn't want to remove it to just do the
modificaitons
ED: so there is still some use
... it's pretty common on svg-developers to ask "i have to update
all these coordinates on all these <path> objects, and i don't want
to have updates between"
JW: so what's the errata?
ED: this is suggesting that suspendRedraw is a hint
<ed__> [20]http://www.w3.org/Graphics/SVG/WG/track/issues/2213
[20] http://www.w3.org/Graphics/SVG/WG/track/issues/2213
[21]http://lists.w3.org/Archives/Member/w3c-svg-wg/2005JanMar/0439.h
tml
[21] http://lists.w3.org/Archives/Member/w3c-svg-wg/2005JanMar/0439.html
ED: i would agree with jonf about suspendRedraw only working on the
outermost svg
... although i guess in some cases it might be useful to do that as
well
CM: would that scope the limiting of rendering to that subtree?
ED: yeah
JW: i don't see how we can reasonably do that
... limit it to subtrees
... if people make a tonne of changes under a subtree...
... all the drawing logic is global for the window
... you'd need to store it, it'd be a nightmare
... i think suspendRedraw should be document wide
... what's the use case for having it work on a subtree?
ED: that's the question
... i suppose you could have a mapping application with a view that
modifications are prevented only in that part
CL: if you have a subtree that you know will have sporadic updates
... but in other cases, you might want every single change visible
... so they're constructing something, then when they're done,
redraw
... you could give them something else to look at it, hide the
subtree being modified
JW: switch off, you mean the user could? or the implementations?
CL: the author could. they'd clone that subtree, set display none,
twiddle it, then add it back to the document
ED: you want to keep the old image in place while you do the updates
CL: right, it's a workaround
ED: there'd be other ways of getting the same effect
DS: i'm not convinced there's a pressing need for it on a subtree
ED: haven't checked the code, but i don't think we support
suspendRedraw on subtrees
DS: you could be constructing something in a DOM, outside of the
document, then just insert it into the document when you want it to
render
ED: we should have some examples like that somewhere
... or the IG could make such examples to show that that's how you
do that
DS: a best practice
... it might not be intuitive to some people
CM: what if there is HTML around the SVG? and you call suspendRedraw
on the <svg>
<shepazu>
([22]http://www.w3.org/Graphics/SVG/WG/wiki/SydneyF2F2009#Agenda)
[22] http://www.w3.org/Graphics/SVG/WG/wiki/SydneyF2F2009#Agenda)
CM: would that be difficult to prevent working on the HTML?
JW: i think so, yes
ED: for us it is not difficult to limit it to an SVG view
... you can suspendRedraw on multiple SVG fragments in an HTML
document separately
... in our implementations, each SVG fragment is sort of a separate
document
... so it's possible to do that
JW: when suspendRedraw happens, you could take a snapshot image?
... what happens if you have an SVG fragment in some HTML, and then
the HTML changes causing the SVG fragment to translate or change
size, what happens then?
ED: you have to buffer content
DS: it has to be interactive though
ED: so it's a static rendering, but the tree/events are different
underneath
DS: so it shouldn't stop timelines, interactivity etc.
... for me suspendRedraw is just like that best practice... so the
implementation effectively works on a cloned DOM (the unsuspended
one) and then renders it all at once at the end
... would events still fire?
ED: you might get unintuitive results because the tree could be
different from how it looks
JW: say i suspendRedaw, and i move a circle from the left to the
right of the screen, and it takes a really long time for some reason
... if the user clicks on the circle on the left, as it appears, is
that targetted to the circle?
... suspendRedraw shouldn't be used across really long times
DS: it should be used for complex DOM operation but you don't want
it to all go the screen at once
ED: practically in every case i've seen, it's much better to build
the changed tree outside the document since it's more predictable
what behaviour you get
... so suspendRedraw is more of a hint to optimise content, not as
predictable
JW: does it matter what the implementations does, if it's only meant
to be used over a short time period?
DS: it should matter, we need to say what occurs
<ed__>
[23]http://www.w3.org/TR/SVG11/struct.html#InterfaceSVGSVGElement
[23] http://www.w3.org/TR/SVG11/struct.html#InterfaceSVGSVGElement
JW: the spec doesn't explicitly say that animation timelines,
interaction, events, hit testing, etc. continue
DS: when there's something moving, when you click it, what is most
intuitive/predictable/useful to the user/author for hit testing?
ED: you could still do workarounds like have some rectangle on the
top that always catches events, for example
DS: i can see good arguments for using the apparent location or the
real location
CM: i think using the real location would be easier
ED: we have no chance of knowing where the element was before
JW: i think the implementation should be doing optimisations, not
having the author specify it
ED: when is a good time to redraw? it's a hint to say when the
author would want a redraw.
... the spec doesn't say when to do redraws
... i agree that implementations should do optimisations
JW: it could be used as a hint to say you don't need to render
between these points
... but that's different from it being a requirement that the user
doesn't want to show these particular states
DS: i wouldn't want the implementation to render when i don't want
it to
ED: there is a timeout, so you still might get a rendering
... the spec caps the timeout at 60 seconds
DS: should it throw an event when it unsuspends?
ED: or something that says when you render, in general
DS: suspendRedraw should only affect the rendering, nothing else
... should we have an event for when the suspend timeout occurred?
... i think it would be useful to have it whenever unsuspend
happened
JW: before or after the paint?
DS: most usefully before the paint
CM: i'd think after the paint
ED: we could split it into two events...
DS: after paint would be ok
... so are we agreed that it isn't a hint but it's a demand?
... for me it's a question of allowing the author to control,
definitely that painting doesn't happen
ED: i would say that it's possible for authors to prevent it working
well, e.g. a long timeout
... anyone that implements it will look "worse" than those that
don't
DS: permance yes, it's possible to misuse it
... at the same time, it's more predictable if it always works
... as an author, it's really good to have predictabilty
JW: i think 60 seconds is a bad maximum, it's very long
... so you've messed things up for the user
AG: the default values are normally something sensible
JW: lots of things could have changed in 60 seconds
... the user's interactions with it could be completely confused
... if 60 seconds, why have a limit at all?
CM: i agree
... what would be a reasonable limit?
CL: 60 seconds sound arbitrary to me
DS: not sure what it gives us if we change it
JW: 60 seconds gives the author something to shoot themselves in the
foot with
ED: having no limit at all...
JW: 60 seconds is effectively no limit
DS: more sensible would be to have no cap
CM: 500ms or 1sec?
CL: if there's a huge amount of churn in the DOM, and you have
redraw on, there might be lots of needless redraw
DS: you could set a longer timeout then
CL: sometimes the intent is to improve response times
DS: i'm concerned about changing something
ED: i think we shouldn't change it for 1.1
... better to try to find better solutions for core 2.0
JW: certain clarifications could happen
... could we put in the spec that suspendRedraw may be implemented
by creating a snapshot of the element, and therefore ancestor
elements that cause scaling might show pixellation?
... if there's a reasonable default, like 1s, the user probably
wouldn't notice
ED: i'm not sure that in such a case, opera wouldn't show an image
at all, maybe white or whatever the background was
... because there was no rendering at that size (if you change size)
DS: so should we allow this on svg fragment in html?
JW: in terms of whether it's an erratum, or a 1.2 thing, certain
things can go in an erratum
... e.g. suggesting that you could implement it by buffering the
rendering, then if it scales it might pixellate, or it might not
render at all
... that and what happens with event handling
... it might be good to know that if you click you're going to be
clicking on somewhere that might not be where the element is any
more
ED: it can be used sometimes for optimising
... but i do prefer doing changes outside the document
... we could recommend using it only in certain situations
... in the most common case it's faster to update outside the
document
... we could say that it's useful for when you have stuff in the
document that you don't want to take out just to update
... we'd recommend the alternatives
JW: just an informative section?
ED: yes
... could you run in to the same problem with canvas?
DS: i guess you could have something that takes a long time to
render
<scribe> ACTION: Cameron to suggest some rewritten text for these
suspend methods [recorded in
[24]http://www.w3.org/2009/02/15-svg-minutes.html#action04]
<trackbot> Created ACTION-2461 - Suggest some rewritten text for
these suspend methods [on Cameron McCormack - due 2009-02-23].
open ISSUE-2213
reopen ISSUE-2213
<trackbot> ISSUE-2213 Some issues in the definition of
suspendRedraw/unsuspendRedraw/forceRedraw re-opened
Image view box cropping
DS: here's an argument to using viewBox in addition to crop
<ed__> ISSUE-2002
<ed__> ISSUE-2002?
<trackbot> ISSUE-2002 -- Controlling the implicit viewBox of raster
images used in the <image> element -- RAISED
<trackbot> [25]http://www.w3.org/Graphics/SVG/WG/track/issues/2002
[25] http://www.w3.org/Graphics/SVG/WG/track/issues/2002
DS: in general, css does the simplest thing
... a lot of their approaches is satisfying 80% of use cases
... svg is good for handling 20% cases
... e.g. smil animation in svg versus css animations
... crop would handle a large number of use cases
... but it's slightly different from the way we do viewBox
... do people really want to do aspect ratio preservation on cropped
parts of an image?
ED: i think it would be useful in some cases
... it does give more control
... if we reuse viewBox for cropping, then we would be able to
address fewer use cases
... if we say that viewBox could override the intrinsic one, we
wouldn't be able to control with preserveAspectRatio
AG: you might want to use crop in conjunction with viewBox
ED: the crop would be cutting out the image before doing a viewBox
on it
DS: i'm thinking of width/height in combination of viewBox
CM: is this just for raster?
ED: crop is new, so it could apply to SVG content too
... it'd need more thought in that case
... an svg could have no width/height attributes and no viewBox,
what happens?
JW: do you allow 100% to be intrinsic?
... if you have width/height set to 100% being displayed in an
<img>, you fit it to the size of the <img>
ED: for an svg, do you want to control the viewBox or would you like
to control the width/height/x/y on the root <svg>?
JW: viewBox can essentially let you give an x/y
DS: would it be worth saying in addition to width/height in
SVG.next, be able to say defaultWidth/defaultHeight?
... so width/height=100%, and defaultWidth/defaultHeight would be
suggested dimensions
JW: replaced element SVG stuff, the whole way we managed to solve
svg embedded in html was with css replaced element rules
... the rule is width/height on the svg element are the intrinsic
dimensions
... if the implementation can't resolve the percentages, then you
fall back to the css 300x150 default
... the defaultWidth/defaultHeight fell by the wayside in lieu of
the css replaced element handling
ED: i was suggesting that i take another look at the crop property
and come up with a proposal for using that with svg
... clip is user space coordinates, only affects what gets drawn
... crop changes what the image is that is being rendered
... crop effectively changes what the input image is
[doug draws on a flip chart]
JW: we don't support viewBox on <image>, only preserveAspectRatio
... i think in the DTD it doesn't allow viewBox
CM: same for the viewBox IDL attribute, it's not on SVGImageElement
<anthony>
[26]http://www.w3.org/TR/SVG11/images/coords/PreserveAspectRatio.svg
[26] http://www.w3.org/TR/SVG11/images/coords/PreserveAspectRatio.svg
struct-image-06-t.svg has pAR on <image>
[27]http://dev.w3.org/SVG/profiles/1.1F2/test/svg/struct-image-06-t.
svg
[27] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/struct-image-06-t.svg
those reference PNGs, though
<scribe> ACTION: Erik to play with preserveAspectRatio="something
slice" to achieve something like crop but without using crop
[recorded in
[28]http://www.w3.org/2009/02/15-svg-minutes.html#action05]
<trackbot> Created ACTION-2462 - Play with
preserveAspectRatio=\"something slice\" to achieve something like
crop but without using crop [on Erik Dahlström - due 2009-02-23].
CM: crop can also do inset
trackbot, action-2462?
<trackbot> Sorry, heycam, I don't understand 'trackbot,
action-2462?'. Please refer to
[29]http://www.w3.org/2005/06/tracker/irc for help
[29] http://www.w3.org/2005/06/tracker/irc
trackbot, ACTION-2462?
<trackbot> Sorry, heycam, I don't understand 'trackbot,
ACTION-2462?'. Please refer to
[30]http://www.w3.org/2005/06/tracker/irc for help
[30] http://www.w3.org/2005/06/tracker/irc
ACTION-2462?
<trackbot> ACTION-2462 -- Erik Dahlström to play with
preserveAspectRatio=\"something slice\" to achieve something like
crop but without using crop -- due 2009-02-23 -- OPEN
<trackbot> [31]http://www.w3.org/Graphics/SVG/WG/track/actions/2462
[31] http://www.w3.org/Graphics/SVG/WG/track/actions/2462
JF: have you thought about rotating when cropping the image?
issue-2002?
<trackbot> ISSUE-2002 -- Controlling the implicit viewBox of raster
images used in the <image> element -- RAISED
<trackbot> [32]http://www.w3.org/Graphics/SVG/WG/track/issues/2002
[32] http://www.w3.org/Graphics/SVG/WG/track/issues/2002
[discussions on flip chart]
ED: for these more complex transformed cropping, the author could
just use clip-path in conjunction with transforming to get the same
effect
ISSUE-2223
ISSUE-2223?
<trackbot> ISSUE-2223 -- Consider Changing BBox Behavior of Filters
-- RAISED
<trackbot> [33]http://www.w3.org/Graphics/SVG/WG/track/issues/2223
[33] http://www.w3.org/Graphics/SVG/WG/track/issues/2223
JW: there are very few svg bugs that are repeated
... one is that we're clipping incorrectly on filtered elements
... it all comes down to x/y/width/height of the <filter> element
... defaulting to -10%,-10%,120%,120%
... this probably came from wanting to limit the size of the filter
so that it doesn't work over the whole canvas
... it's not very hard to make a quick filter graph to work out what
area you need
ED: i misunderstood your concerns then
... i agree it would be if the defaults would be what you want
... does it just apply to blur, or other filters too?
... blur is the most commonly wanted filter, and that extends beyond
the bbox
JW: ignoring primitives for the moment
... so this area is causing clipping when you have filter primitives
that extend outside of that box
... authors are blurring a lot, and it's going outside that default
bbox
... the implementation can figure out the optimal area to apply the
filter to
... to us it seems that it's causing more problems
... it's cuaisng confusion for authors, by resulting in clipping
... i don't see it as a use case for clipping, just use a clip path
ED: as a default, it might be easier if the implementation worked it
out
... that would apply only when you have objectBoundingBox on the
filter?
JW: No
ED: which cases then? what would be the default?
... you might have content that relies on this default area that the
filter applies to
JW: when would you need that?
ED: for anything that inside a filter fills that area
... e.g. feFlood
CM: flood defaults to filling an infinite area
JW: you could still say that it floods the filter primitive
subregion, but that subregion does not clip
... you could still have a region, the region is whatever
(-10%,-10%,etc.)
... but if the filter still paints outside that area it doesn't get
clipped
CM: so instead of having feFlood being clipped, change it so that it
floods a particular area
JW: we're getting bugs where inkscape is calculating an optimal
size, but it's getting it wrong, so now there is lots of SVG out
there with incorrect width/height on <filter>
... omnigraffle gives the whole canvas as the filter region
ED: so that never clips
DS: in inkscape you have the opposite, they're trying to optimise
... but if it's a bit wrong, then you get weird clipping
AG: you could offset the feFlood
CM: but that would be a separate primitive?
DS: gaussian blur is the most commonly used primitive
ED: it's one that draws outside the bbox
JW: does it matter that blur is the only one that is important?
ED: well we could make a targetted fix just for blur
JW: and then if we add another one later that is commonly used?
... feOffset too
DS: it will be hard to get the tools to changed
... there's content out there that looks funky because of this
filter clipping
[discussion about having x/y/width/height defining the filter
region, so that primitives align to it, but allow painting outside
it]
ED: if you have a subregion outside the filter region it would clip,
but that's not common for authors to use
AG: would it be difficult in the filters module to have keywords for
x/y/width/height?
ED: given that the content already exists, auto would have to be the
default
DS: the only reason you want clipping is for optimisation, really
ED: sometimes you want to filter some parts of what you're filtering
CM: you could use the primitive subregions for that?
ED: probably
... i think feFlood, feOffset and feTurbulence generate images
... and they rely on a defined filter region
... all three of those extend outside
... maybe not feTurbulence
JW: if we decided that it wouldn't clip, then mozilla would put that
in 3.1
... but as long as not too much content breaks, and that's what the
WG wants
DS: so some people might be using the filter region for specific
effects, rather than just for optimisation
ED: you can also clip out regions with a clip path that you want to
filter
<scribe> ACTION: jwatt to propose some text for filter region
clipping [recorded in
[34]http://www.w3.org/2009/02/15-svg-minutes.html#action06]
<trackbot> Created ACTION-2463 - Propose some text for filter region
clipping [on Jonathan Watt - due 2009-02-23].
<shepazu>
[35]http://lists.w3.org/Archives/Public/www-svg/2009Feb/0017.html
[35] http://lists.w3.org/Archives/Public/www-svg/2009Feb/0017.html
action-2463?
<trackbot> ACTION-2463 -- Jonathan Watt to propose some text for
filter region clipping -- due 2009-02-23 -- OPEN
<trackbot> [36]http://www.w3.org/Graphics/SVG/WG/track/actions/2463
[36] http://www.w3.org/Graphics/SVG/WG/track/actions/2463
SVG Interest Group
<jwatt> scribe: jwatt
DS: SVG IG is doing:
<ed_sydney> [37]http://www.planetsvg.com/
[37] http://www.planetsvg.com/
DS: community site (work going slowly, but progressing)
... SVG Open - trying to pull resources
... probably 1st weekend in October, hosted by Google, hopefully
also sponsored by Mozilla too
... going to launch planetsvg soon
... basically a community site: tutorials, news, developer/designer
forums (basically the thing that's not set up yet)
... we'd like to start making torture tests
... find points where browsers don't align. edge cases
... whereas acid tests are more theoretical, we'd focus on problems
that users are actually running into frequently
... Jeff Schiller is running the IG
... Brad Neuburg considering joining the IG
JF: SVG IG JP
... started activity last oct
... no conference, but had f2f meetings in oct, nov, jan
<jun> [ML] [38]http://lists.w3.org/Archives/Public/public-svg-ig-jp/
[38] http://lists.w3.org/Archives/Public/public-svg-ig-jp/
JF: have Japanese mailing list
<jun> [Wiki] [39]http://www.w3.org/Graphics/SVG/IG/wiki/Japan
[39] http://www.w3.org/Graphics/SVG/IG/wiki/Japan
JF: and wiki page
... page has pointers to meeting minutes
... group consists of the members:
... Takagi-san (KDDI)
... Yakuna-san (HTML WG)
... Goho-san (MS Japan)
... several other people related to JIPDEC (Japanese industrial
standards)
... SVG IG JP has currently two areas of focus
... standardization and mapping
... translating SVG 1.2 Tiny to Japanese
<jun> [SVG Map]
[40]http://blog.svg-map.com/2008/07/the-index-of-sv.html
[40] http://blog.svg-map.com/2008/07/the-index-of-sv.html
JF: working on SVG map specification, based on proposal by
Takagi-san
... originally an independent specification, using different
namespace, but IG JP agreed to work on new module
... currently contains layering, tilling and support for
geo-coordinates, and special metadata useful for mapping
... IG JP originally saw this as a profile, but now think it should
be a module because mapping may want to use other modules
... so the module would contain features useful to mapping, and not
be a different svg
DS: tiling is a prefetching strategy as well as a region of interest
issue
JF: Level of Detail is also useful for mapping, but thinking to
exclude it from the layering and tiling module
... all client side - not specifying anything server side
... question to the WG: does the WG want so split out Level of
Detail and z-index from Layering and Tiling?
... or keep them together in a single module?
CM: I'd like to see more details to see if it's general enough to go
in SVG instead of mapping
DS: it's not just mapping - anything where you have very different
level of detail
... circuit diagrams for example
JF: plan to come up with first draft in April
... will submit to W3C and JIS
... the original map profile [link above] has z-index and LoD too
RESOLUTION: SVG WG recommends that SVG IG JP work on separate tiling
and layering module, and the SVG WG will consider the case of
z-index and LoD
ISSUE: Investigate the use cases and requirements for z-index
<trackbot> Created ISSUE-2226 - Investigate the use cases and
requirements for z-index ; please complete additional details at
[41]http://www.w3.org/Graphics/SVG/WG/track/issues/2226/edit .
[41] http://www.w3.org/Graphics/SVG/WG/track/issues/2226/edit
ISSUE: Investigate the use cases and requirements for Level of
Detail
<trackbot> Created ISSUE-2227 - Investigate the use cases and
requirements for Level of Detail ; please complete additional
details at
[42]http://www.w3.org/Graphics/SVG/WG/track/issues/2227/edit .
[42] http://www.w3.org/Graphics/SVG/WG/track/issues/2227/edit
<shepazu> ACTON: shepazu to look into how SVG IG JP can submit
Layering and Tiling Module to W3C/SVG WG
<shepazu> ACTION: shepazu to look into how SVG IG JP can submit
Layering and Tiling Module to W3C/SVG WG [recorded in
[43]http://www.w3.org/2009/02/15-svg-minutes.html#action07]
<trackbot> Created ACTION-2464 - Look into how SVG IG JP can submit
Layering and Tiling Module to W3C/SVG WG [on Doug Schepers - due
2009-02-23].
<animation> element with regards to mapping
JF: a member of SVG WG IG would like to know if the <animation>
element will definitely be supported in future SVG specifications or
not
<ed_sydney> concern raised from SVG IG is that <image> in SVG 1.1
supports referencing svg, but it's forbidden in 1.2T
<ed_sydney> and not supported in 1.1 tiny
ED: I would expect the next major version of Tiny to allow <image>
to reference SVG, but whether or not it runs animations or scripts,
should be defined properly
DS: In the bucket module I'm writing about the different usage
scenarios for SVG
... there are a bunch of issues
<shepazu> [44]http://www.schepers.cc/svg/blendups/embedding.html
[44] http://www.schepers.cc/svg/blendups/embedding.html
DS: if you look at this document in Opera, CSS backgrounds should
display, but they should not have animation
... when they are used for <image> in HTML they should display and
have animation, but no script
... well, look at the page
ED: we should have the table for SVG referencing elements
<ed_sydney> DS: I would expect <svg:image> to behave just like
<html:img> wrt to scripting/animation etc (look at the above url)
ED: I would recommend either <image> or <animation> for tiles
<ed_sydney> ...image for static tiles where you don't need to know
exactly what element inside the tile document was clicked
<ed_sydney> ...animation for the ones where you need to know
<ed_sydney> scribe: ed_sydney
svg bucket module
CM: there are various things we need to have somewhere
DS: bigger issues in svg need some coordination
... for reuse and so on
... there's a bit of talk about it in 1.1 and 1.2T, but there's not
something you can actually reference
... spec doesn't talk about some common rpoblems and how to solve
them
... WHOOOOAAA!
(the room next door also wooooes)
scribe: i don't think we've decided if it's going to be a module or
a profile
CM: would you also want to have an integrattion stpec?
DS: not appropriate to have every spec split into tiny pieces
... a spec has to have a certain length or content to make it useful
... we're breaking down the spec into modules, but i think there
should be one larger spec that covers all of svg
CM: so for common infrastructure, and for solving things that we
haven't resolved on yet
DS: for addressing common usage scenarios
CM: so not for random things only
DS: i'm thinking core of the language
... so common infrastructure etc
CM: still feels a bit abstract
... and for modules we've already started on
... we might need to have some hooks in tiny that we could put in,
but we can't change everything in tiny (though we can errata some
things)
AG: we should first finish the errata for 1.1, before starting on
1.2T errata
DS: part of me wants to make this a short spec, for usage scenario
stuff, but part want to make it a core type spec, but it's a bit
early to decide
AG: right
... there's no place for it now, but the wording we put it in we can
reuse later
... sometimes we can lose track of the problem in issues, if left
alone for a long time
... fleshing the wording out makes more sense, and sticking it into
the bucket spec
CM: i'm happy for this to be a place we put things for now
... but i'd like to know what's our plan with it
... at the moment mozilla says they're targetting 1.1, and not
really targetting 1.2T...how do you (JW) think things should
progress? we can't keep doing 1.1 errata forever
JW: I assume 1.2 full or core 2.0 or whatever the next iteration
happens to be
... a few years away
DS: what if we put things into a spec, and plan to go with that in a
couple of years?
JW: i'm guessing there might still be some incompatibilties 1.2T <->
1.1 that we need to look at
AG: full 1.2 started sort of like a bucket, and then was split into
modules
DS: wrt to inconsistencies, 1.1 had alot of problems, so if the next
version addressed those, and tried to keep compatibility, but i
don't mind if we clean up the 1.1 spec
... especially if it helps with html integration
JW: what's the reason for having modules?
DS: smaller easy to write, easy to review
JW: why would a module be shorter than a chapter?
DS: it's not, but it's 400page spec vs 40 page chapter/module
... we do get complaints about the length of the spec
JW: but that would be the same for a profile consisting of modules
DS: but the moduels would have got some review before then
... a module can go on top of another module
... it's standalone, and some other specs can reference that part
only
... like CSS
CM: the infrastructure isn't there yet
... liek override this sentence, and then do this other thing
... in tiny
DS: integration is one part of the bucket spec
CM: modularizing is a tradeoff
... ease of review vs how things fit together
DS: there are benefits of both ways
... we're almost done with some of the modules already
... but there are integration issues
JW: the problem with module is that you might need to change the
modules after they've gone through review, unless you sync with a
profile or integration spec
... in which case the mdoules aren't very different from chapters
anyway
DS: modules are easier to work on in a way
JW: maybe for very independent modules
DS: tiling and layering would be quite different
CM: some things might be easy to separate, but some other things
like compositing and filters change some base things, like how stuff
renders
... and you might need to reference other modules
JW: for some things it's useful to have one spec, so you can search
in it, and to define interaction etc
... calling it a module doesn't do away with that
CM: does our charter define our roadmap wrt to modules vs monolithic
spec?
JW/DS: don't think so
JW: many things interact, so I'm leaning on favoring the monolithic
way of doing things
... I know TOR was concerned about modules, and which ones to
support
CM: so advancing at different rates, and the reason that you may
need to change integration points as it goes aliong is a concern
DS: it's also a concern not to obsolete 1.2T too early
... JIS needs it to be stable
AG: that's the reason for having the modules, so that we could build
them on top of 1.2T
... we could fold the modules into a monolithic spec at a later
point
CM: might waste efforts dealing with integration points
DS: progressing documents to LC or CR, finding out if there are any
problems....
... we could advance all the modules up to CR individually, and then
work on integration issues, then decide if we go with separate
modules or a monolithic spec
JW: sounds like a good idea
DS: i'm not suggesting that integration issues are done late, but
that they're done as an ongoing task
... but with extra focus at the end
... we don't want to lose track of the features of the language
JW: so we stick things into the bucket spec we don't know yet where
they should go
... are we aiming for the moduels to result in a tiny spec or a full
spec?
DS: there's only one spec going forward, for both mobile and desktop
RESOLUTION: we'll continue making modules (with ongoing integration
work) and we'll park each of them in CR until they're all in CR and
then we'll do a final integration pass before publishing modules for
reuse with older specs and a single monolithic spec defining the
full language. We will only publish modules to REC if they're needed
for reuse by others, otherwise just leave it as chapters in the full
spec
DS: JF will you check with JIPDEC/JIS to see if this works for them?
<scribe> ACTION: jun to follow up with SVG IG JP on the svg wg
roadmap [recorded in
[45]http://www.w3.org/2009/02/15-svg-minutes.html#action08]
<trackbot> Created ACTION-2465 - Follow up with SVG IG JP on the svg
wg roadmap [on Jun Fujisawa - due 2009-02-23].
JF: as new modules are proposed, how do we decide what goes into svg
2.0?
... and what stays a module
DS: we decide on what's a good set of features for svg and go with
that
JF: maybe a message on the 1.2 full spec page to say that it's not
going to REC?
JW: seems like a good idea
... and say what we are going to do
<scribe> ACTION: DS to update link [46]http://www.w3.org/TR/SVG12 to
point at 1.2T and to change the dated link to say that work is
aborted on 1.2 full, svg 2.0 will be the next version, the latest
rec is 1.2T [recorded in
[47]http://www.w3.org/2009/02/15-svg-minutes.html#action09]
[46] http://www.w3.org/TR/SVG12
<trackbot> Created ACTION-2466 - Update link
[48]http://www.w3.org/TR/SVG12 to point at 1.2T and to change the
dated link to say that work is aborted on 1.2 full, svg 2.0 will be
the next version, the latest rec is 1.2T [on Doug Schepers - due
2009-02-23].
[48] http://www.w3.org/TR/SVG12
AG: we should also communicate the plans to the community
Summary of Action Items
[NEW] ACTION: Cameron to suggest some rewritten text for these
suspend methods [recorded in
[49]http://www.w3.org/2009/02/15-svg-minutes.html#action04]
[NEW] ACTION: Chris to come up with topics of interest to Inkscape
so we can approach Josh Andler [recorded in
[50]http://www.w3.org/2009/02/15-svg-minutes.html#action03]
[NEW] ACTION: Doug to do the paperwork for berjon's IE application
[recorded in
[51]http://www.w3.org/2009/02/15-svg-minutes.html#action01]
[NEW] ACTION: Doug to follow Zack Rusin's interest in being an
invited expert [recorded in
[52]http://www.w3.org/2009/02/15-svg-minutes.html#action02]
[NEW] ACTION: DS to update link [53]http://www.w3.org/TR/SVG12 to
point at 1.2T and to change the dated link to say that work is
aborted on 1.2 full, svg 2.0 will be the next version, the latest
rec is 1.2T [recorded in
[54]http://www.w3.org/2009/02/15-svg-minutes.html#action09]
[NEW] ACTION: Erik to play with preserveAspectRatio="something
slice" to achieve something like crop but without using crop
[recorded in
[55]http://www.w3.org/2009/02/15-svg-minutes.html#action05]
[NEW] ACTION: jun to follow up with SVG IG JP on the svg wg roadmap
[recorded in
[56]http://www.w3.org/2009/02/15-svg-minutes.html#action08]
[NEW] ACTION: jwatt to propose some text for filter region clipping
[recorded in
[57]http://www.w3.org/2009/02/15-svg-minutes.html#action06]
[NEW] ACTION: shepazu to look into how SVG IG JP can submit Layering
and Tiling Module to W3C/SVG WG [recorded in
[58]http://www.w3.org/2009/02/15-svg-minutes.html#action07]
[53] http://www.w3.org/TR/SVG12
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [59]scribe.perl version 1.133
([60]CVS log)
$Date: 2009/02/16 07:16:18 $
_________________________________________________________
[59] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[60] 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 [61]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[61] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/documenbt/document/
Succeeded: s/sometimes/something/
Succeeded: s/changes effectively/effectively/
Succeeded: s/1st/probably 1st/
Succeeded: s/no/on/
Succeeded: s/I don't know/should be defined properly/
Succeeded: s/<use>/<image>/
Succeeded: s/there should/they should/
Found Scribe: Cameron
Found ScribeNick: heycam
Found Scribe: jwatt
Inferring ScribeNick: jwatt
Found Scribe: ed_sydney
Inferring ScribeNick: ed_sydney
Scribes: Cameron, jwatt, ed_sydney
ScribeNicks: heycam, jwatt, ed_sydney
Present: DS JF CMC ED CL jwatt AG
WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth
Found Date: 15 Feb 2009
Guessing minutes URL: [62]http://www.w3.org/2009/02/15-svg-minutes.html
People with action items: cameron chris doug ds erik jun jwatt shepazu
[62] http://www.w3.org/2009/02/15-svg-minutes.html
End of [63]scribe.perl diagnostic output]
[63] 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, 16 February 2009 07:25:35 UTC