SVG Working Group Teleconference -- 16 Sep 2008

<trackbot> Date: 16 September 2008

<scribe> scribe: erik

<scribe> scribeNick: ed

LC comments

AE: as of right now, there are no comments
... DS you'll be tracking them as they come in?

DS: yes, I'll put them in the LC tracking tool

Test fest update

AE: it's up in two weeks time
... not many responders
... three people coming
... want to remind everyone to respond

<shepazu> http://www.w3.org/Graphics/SVG/Group/wiki/OttawaF2F2008

<aemmons> http://www.w3.org/2002/09/wbs/19480/svgOttawaTestFest2008/

http://www.w3.org/Graphics/SVG/WG/wiki/Meetings

<shepazu> http://www.w3.org/2002/09/wbs/19480/svgOttawaTestFest2008/

AE: still negotiation to be able to go, but I think bitflash are sending someone
... do we have implementations to test except for the people that are coming?

DS: there's abbra, and I think chris contacted some people too

AE: so, at least one impl to gather results for there
... and julian from spinetix
... we want to have good coverage, but we need to have enough people to do the testing

DS: the more people we have the better

AE: bitflash said they could send additional people if we need more impls tested
... will send out an email about the testfest
... need to decide exactly where the meeting will be and so on

<scribe> ACTION: AE to move the ottawa testfest f2f page from the private to the public wiki, and add the location etc [recorded in http://www.w3.org/2008/09/16-svg-minutes.html#action01]

<trackbot> Created ACTION-2192 - Move the ottawa testfest f2f page from the private to the public wiki, and add the location etc [on Andrew Emmons - due 2008-09-23].

values of requiredExtensions to use XHTML/MathML

<aemmons> http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0291.html

AE: so in LC are we allowed to make any changes?

DS: got different answers
... the general consensus seem to be that it's ok to make changes in LC
... any change that affects an implementation that makes us reevaluate our test coverage isn't necessarily very good

AE: in this particular case, is this for SVG 1.1?

DS: i think it's for svg in general

AE: CL says adding an example might be a way forward

DS: i'm sceptical, it'd be non-normative
... we're making a spec for implementors
... we have an example that has xhtml in it, and it's using some bogus requiredExtension string
... it's a good idea to change the example, but I don't think it's enough

AE: should be raise it as an issue?
... and discuss it over the course of our last call, to wait for further feedback

DS: we've already got feedback
... question is if this is useful or if it harms anything

AE: what does everyone think of it?

ED: I'd be happy adding it

<shepazu> http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0299.html

ED: proposed wording looks ok

AE: makes sense to make it generic like that

<shepazu> http://www.w3.org/TR/SVGMobile12/struct.html#ExternalResourcesRequiredAttribute

AE: my only hesitation is to be careful with making changes to the spec

DS: we'd need to make tests for it too

<shepazu> http://www.w3.org/TR/SVGMobile12/struct.html#RequiredExtensionsAttribute

DS: how would you test it?
... abbra supports XHTML in foreignObject

AE: careful wording in the pass criteria would probably work

RESOLUTION: we'll clarify the wording in requiredextensions, adding the proposed wording from DS for XHTML and MathML

DS: do we want an errata item for 1.1 too?

<scribe> ACTION: DS to implement the resolution "we'll clarify the wording in requiredextensions, adding the proposed wording from DS for XHTML and MathML" and add a corresponding errata item for SVG 1.1 [recorded in http://www.w3.org/2008/09/16-svg-minutes.html#action02]

<trackbot> Created ACTION-2193 - Implement the resolution \"we'll clarify the wording in requiredextensions, adding the proposed wording from DS for XHTML and MathML\" and add a corresponding errata item for SVG 1.1 [on Doug Schepers - due 2008-09-23].

RATIONALE: it's a proven interop issue, and the wording is ambigous, and we want interop

<aemmons> http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0296.html

Fixing the Test Suite

AE: CL said he fixed the second part already
... in the online version (so, for the next version)
... should we update the released package?

DS: I'd rather wait until we have new content

AE/NH/ED: agree

AE: the first part, is that something that could be changed in the script

AG: file permissions don't get stored with the file do they?

DS: follow up with doh?

<scribe> ACTION: AG to follow up with DOH on http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0296.html regarding the first point [recorded in http://www.w3.org/2008/09/16-svg-minutes.html#action03]

<trackbot> Created ACTION-2194 - Follow up with DOH on http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0296.html regarding the first point [on Anthony Grasso - due 2008-09-23].

<aemmons> http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0298.html

Review of struct-discard-208-t.svg test

AG: tests a specific part of discard
... the original tests didn't quite test it properly

AE: we shouldn't approve any new tests until the f2f
... but assigning a reviewer is ok of course
... I'll review it

<scribe> ACTION: AE to review struct-discard-208-t.svg [recorded in http://www.w3.org/2008/09/16-svg-minutes.html#action04]

<trackbot> Created ACTION-2195 - Review struct-discard-208-t.svg [on Andrew Emmons - due 2008-09-23].

AG: opera passes

NH: ikivo passes

<aemmons> http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0305.html

SVG clip-path, mask and filter for non-SVG content

AG: quick question: are we still going to work on the testsuite after 1.2T goes to rec?

DS: yes

AE: agree, it'll probably be more tests added

DS: to push us over 500 approved tests, would be nice

AE: ok, back to the clip-paths

ED: haven't had time to look at the proposal in detail yet

DS: was trimmed down from what he had before

http://people.mozilla.com/~roc/SVG-CSS-Effects-Draft.html

<shepazu> http://people.mozilla.com/~roc/SVG-CSS-Effects-Draft.html

<shepazu> http://www.w3.org/TR/cssom-view/#elementview-getboundingclientrect

ED: would have to look at the CSS box model to see if that's the most appropriate way of defining exactly what's the size of the svg
... concerned about borders, margin, padding

DS: any objections to taking this on?

AE: it sounds very powerful

RESOLUTION: we'll take on this work, and liaison with the CSS WG to make sure this is ok

DS: what spec would it go in?
... filters? compositing?
... clipping and masking?

AE: do we want to raise an issue for this then?

DS: I'll add to tracker
... we could originate it in its own spec, like an svg-css spec
... might be more work though

AE: still some work to analyze this

DS: would prefer to put it in a spec now

<shepazu> http://dev.w3.org/SVG/modules/

AE: this is similar to the enableBackground (where wording is different in two modules)

AG: problem is that we'll have to push changes to everywhere

AE: we could have the spec scripts pull changes from a central location
... we need to solve how this is handled though

AG: yes, that's one way, I don't really mind how we solve this
... the other option is to make a small spec for things that overlap, and include that in the modules

AE: problem with that is if you need one little bit only
... and it's own testsuite etc
... 1) pull in wording for e.g enable-background from some central place for every module
... 2) have a small common module

DS: or 3) to have duplicated wording in each module
... problem is maintainability
... the second way is the profile way
... sounds like it would be better if it was specced out in one spec first, and then pulled into core

AE: but do we want everything in core?
... for the common things
... because when you look at this it'd be a collection of stuff that has little relation (except in context with the depending specs)

DS: so I think it makes sense to add roc's wording to the filters spec, even the clipping case

AE: so with enable-background, does it need to say anything about filters or clipping or can it be generic?

ED: it's pretty specific in filters, showing the algortihm for the background-image generation
... not sure how it looks like in clipping/compositing

AG: the way i've used in compositing is different from the filters spec
... describing attributes etc
... so if you want to pull in things how do we handle the fact that specs are written in different style?

AE/DS: we should strive to have the same style

AE: we might change the filters spec to be the same style
... how do we merge things between modules? and how do we make sure style is consistent?

<scribe> ACTION: ed to work with AG on integrating ROC's proposal into the filters spec [recorded in http://www.w3.org/2008/09/16-svg-minutes.html#action05]

<trackbot> Created ACTION-2196 - Work with AG on integrating ROC's proposal into the filters spec [on Erik Dahlström - due 2008-09-23].

<scribe> ACTION: AG to work with ED on integrating ROC's proposal into the compositing/clipping&masking spec [recorded in http://www.w3.org/2008/09/16-svg-minutes.html#action06]

<trackbot> Created ACTION-2197 - Work with ED on integrating ROC's proposal into the compositing/clipping&masking spec [on Anthony Grasso - due 2008-09-23].

RESOLUTION: we'll fold the clipping&masking into the compositing module

<shepazu> Rationale: the fewer modules, the easier the integration of features

AE: so how do we merge common elements and attributes in modules, and the stylistic things

<scribe> ACTION: AG to fold in the clipping&masking chapter into the compositing module [recorded in http://www.w3.org/2008/09/16-svg-minutes.html#action07]

<trackbot> Created ACTION-2198 - Fold in the clipping&masking chapter into the compositing module [on Anthony Grasso - due 2008-09-23].

DS: do we want to assign editors for the new modules?

AE: maybe we should first decide the priorities?
... need to keep focused, and we need to have the style ready first

AG: yes, we need to do that first
... so we don't waste time later on

DS: so with vector-effects, I'd just pull in the 1.2Full draft into the module

<shepazu> http://dev.w3.org/SVG/modules/template/

DS: we should probably reexamine this
... if this is the right approach
... for vector-effects

AG: yeah, there are a lot of problems with it as it stands

DS: ok

AE: so is there anywhere in the wiki we could have for stylistic rules, like what should go in the primer etc

AG: that'd be helpful

AE: maybe we could all work on that

DS: AE do you want to start it up?

AE: I was thinking AG

AG: one example is in print, all requirements are highlighted in red boxes

ED: i think i have an action to add that to filters too, but haven't had time to do it yet

AE: it makes sense to have that on the wiki

<scribe> ACTION: AG to add a wikipage for new modules, describing common styling etc [recorded in http://www.w3.org/2008/09/16-svg-minutes.html#action08]

<trackbot> Created ACTION-2199 - Add a wikipage for new modules, describing common styling etc [on Anthony Grasso - due 2008-09-23].

priorities

DS: my wishlist: vector-effects (cool, but will take awhile before implemented), the features that bitflash put in (the z-index) and the 2.5D stuff

AE: yes, we want to have the 2.5D soon to see what people have done so far
... and also from a market POV

DS: SCXML

- DRAFT -

SVG Working Group Teleconference

16 Sep 2008

Attendees

Contents