See also: IRC log
<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
<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 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 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> 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 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?
<trackbot> ISSUE-2213 -- Some issues in the definition of suspendRedraw/unsuspendRedraw/forceRedraw -- RAISED
<trackbot> 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__> 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__> http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml
<ed__> #remove_exception_on_unsuspendredraw
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__> http://www.w3.org/Graphics/SVG/WG/track/issues/2213
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> (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__> 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 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
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> 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> http://www.w3.org/TR/SVG11/images/coords/PreserveAspectRatio.svg
struct-image-06-t.svg has pAR on <image>
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 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 http://www.w3.org/2005/06/tracker/irc for help
trackbot, ACTION-2462?
<trackbot> Sorry, heycam, I don't understand 'trackbot, ACTION-2462?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
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> 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> 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?
<trackbot> ISSUE-2223 -- Consider Changing BBox Behavior of Filters -- RAISED
<trackbot> 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 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> 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> http://www.w3.org/Graphics/SVG/WG/track/actions/2463
<jwatt> scribe: jwatt
DS: SVG IG is doing:
<ed_sydney> 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] http://lists.w3.org/Archives/Public/public-svg-ig-jp/
JF: have Japanese mailing list
<jun> [Wiki] 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] 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 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 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 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].
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> 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
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 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 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 http://www.w3.org/2009/02/15-svg-minutes.html#action09]
<trackbot> Created ACTION-2466 - Update link 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].
AG: we should also communicate the plans to the community
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/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: http://www.w3.org/2009/02/15-svg-minutes.html People with action items: cameron chris doug ds erik jun jwatt shepazu[End of scribe.perl diagnostic output]