W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2009

Minutes Sydney 2009 F2F day 1

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>
Message-ID: <op.upfn6my9geuyw5@macbooked>
Minutes available here:


or as text here:


      [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


          DS, JF, CMC, ED, CL, jwatt, AG


          Cameron, jwatt, ed_sydney


     * [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
   ... 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

   <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

   <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

   <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

   <trackbot> Created ACTION-2460 - Come up with topics of interest to
   Inkscape so we can approach Josh Andler [on Chris Lilley - due



   <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

   CM: summary of boris' comment is that these methods should just be

   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
   ... 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

   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.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

   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,
   ... 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

   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>


     [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
   ... 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

   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

   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


     [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

   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

   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

   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
   ... 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

   <scribe> ACTION: Cameron to suggest some rewritten text for these
   suspend methods [recorded in

   <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
   ... 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


     [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

   those reference PNGs, though

   <scribe> ACTION: Erik to play with preserveAspectRatio="something
   slice" to achieve something like crop but without using crop
   [recorded in

   <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


   <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?


   <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



   <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
   ... 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
   ... that would apply only when you have objectBoundingBox on the

   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
   ... but if the filter still paints outside that area it doesn't get

   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

   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

   ED: given that the content already exists, auto would have to be the

   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

   <scribe> ACTION: jwatt to propose some text for filter region
   clipping [recorded in

   <trackbot> Created ACTION-2463 - Propose some text for filter region
   clipping [on Jonathan Watt - due 2009-02-23].


     [35] http://lists.w3.org/Archives/Public/www-svg/2009Feb/0017.html


   <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

   ... 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
   ... 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

   JF: working on SVG map specification, based on proposal by
   ... 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

   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

   <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

   <trackbot> Created ACTION-2464 - Look into how SVG IG JP can submit
   Layering and Tiling Module to W3C/SVG WG [on Doug Schepers - due

<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

   <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

   (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

   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

   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
   ... 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

   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
   ... 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

   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

   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

   CM: might waste efforts dealing with integration points

   DS: progressing documents to LC or CR, finding out if there are any
   ... 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

   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

   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

   <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
   ... and what stays a module

   DS: we decide on what's a good set of features for svg and go with

   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

     [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

     [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
   [NEW] ACTION: Chris to come up with topics of interest to Inkscape
   so we can approach Josh Andler [recorded in
   [NEW] ACTION: Doug to do the paperwork for berjon's IE application
   [recorded in
   [NEW] ACTION: Doug to follow Zack Rusin's interest in being an
   invited expert [recorded in
   [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
   [NEW] ACTION: Erik to play with preserveAspectRatio="something
   slice" to achieve something like crop but without using crop
   [recorded in
   [NEW] ACTION: jun to follow up with SVG IG JP on the svg wg roadmap
   [recorded in
   [NEW] ACTION: jwatt to propose some text for filter region clipping
   [recorded in
   [NEW] ACTION: shepazu to look into how SVG IG JP can submit Layering
   and Tiling Module to W3C/SVG WG [recorded in

     [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

     [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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:10 UTC