SVG Working Group Teleconference -- 30 Mar 2009

<trackbot> Date: 30 March 2009

<shepazu> ChrisL: remember, we set it an hour back?

<ChrisL> huh?

<shepazu> it's not for another hour

<shepazu> has the EU DST kicked in?

<ChrisL> I thought we were waiting for australia to change, next week

<ChrisL> yes, it kicked in on Sunday

<shepazu> that explains it

<ChrisL> zakim believes its now

<shepazu> here, it's still just 2:40, the telcon is scheduled for 3:30 boston time

<shepazu> yes, zakim has been confused for weeks

<shepazu> I put in the request a while back, but it doesn't seem to have taken

<shepazu> er

<shepazu> freudian slip?

<shepazu> well, I got a response, but it didn't seem to work

<shepazu> sure, you know my #?

<shepazu> 1-919-932-9872

<shepazu> btw, I've rethought the new telcon times

<shepazu> I can try to get up at 6:30 for a 7:00 call, if it works better for you

<shepazu> trackbot, start telcon

<trackbot> Meeting: SVG Working Group Teleconference

<trackbot> Date: 30 March 2009

<ChrisL> zakim +00 is me

<scribe> scribe: erik

<scribe> scribeNick: ed_

CSS/SVG coordination list

DS: we've got this list now, for future transforms specs we should point to this list

<shepazu> public-fx@w3.org

Trait accessors for animation

<heycam> http://www.w3.org/mid/A13D0B44629697468E9C6AE200CFD39A61A231FB1C@mailkeeper.mdigitalm.com

http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0327.html

CM: yeah, it should be the fill for the animation elements, not the <animation> element only
... create an erratum for this?

<scribe> ACTION: AG to create an erratum for SVGT12, clarifying 'fill' in traitaccess, see http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0327.html [recorded in http://www.w3.org/2009/03/30-svg-minutes.html#action01]

<trackbot> Created ACTION-2505 - Create an erratum for SVGT12, clarifying 'fill' in traitaccess, see http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0327.html [on Anthony Grasso - due 2009-04-06].

SVG integration module

DS: we could make a spec that would be the lists of all elements in all svg specs
... it would have method names, attribute names, and it would be normative
... and point to definitions of the relevant specs
... and also how svg integrates with other web techs, e.g svg in html:img... need not be html, could be docbook, odf etc
... have different usage scenarios
... that way the html5 spec wouldn't have to a list of elements/attributes
... for svg

CL: right, we could produce such a list

CM: you mention this table, and security issues etc
... it'd be good to have somewhere to write it down
... i think it warrants a spec, this is a common theme

DS: yes, these are all integration issues
... this would be good for ODF, if they decide to use svg as a native image format

CM: we could bring it back into svg 2.0 when it's ready

DS: should we do this?

CL: don't see a down side for doing this

DS: how hard would it be to change the scripts to generate tables of elements/attributes?

CM: probably not that hard
... the tiny12 has an rng, and that would be easy
... hsivonen is using a slightly modified version of the full 1.1 RNG, so it can't be that far off
... it'd be easier if 1.1 had an RNG, there's one

<ChrisL> look into trang

CM: we'd like to have all elements from 1.1 and 1.2T, right?

CL/DS: yes

DS: it'd still be a good idea to rewrite the RNG into functional modules

CL: maybe start with the SVG 1.2 and then delete stuff

DS: we could get rberjon to help us
... our rng was flawed in a few places for 1.2T

RESOLUTION: we will make an SVG integration module

DS: it would be nice because we could get a diff between 1.1 and 1.2T, for elements etc

CM: probably one reason to get a such a table would be to get HTML5 to reference it

CL: producing it will still help other people/specs

<scribe> ACTION: heycam to create an SVG integration module and setup scripts for it [recorded in http://www.w3.org/2009/03/30-svg-minutes.html#action02]

<trackbot> Created ACTION-2506 - Create an SVG integration module and setup scripts for it [on Cameron McCormack - due 2009-04-06].

<scribe> ACTION: DS to contact robin berjon to ask for help with converting the 1.1 DTD to RNG and related issues [recorded in http://www.w3.org/2009/03/30-svg-minutes.html#action03]

<trackbot> Created ACTION-2507 - Contact robin berjon to ask for help with converting the 1.1 DTD to RNG and related issues [on Doug Schepers - due 2009-04-06].

SVG in HTML

CM: we sent off our proposal document, which didn't address all of the points
... little of which actually resulted in changes in the html5 spec

<ChrisL> So this document was produced as an action in the HTML WG, then rejected out of hand?

CM: it seems ian doesn't really want to get proposed working, so wording on that document itself seems a waste of time

<ChrisL> Suggest contacting the chair to ensure our document is reviewed

CL: suggest to talk to the HTMLWG chair and put it on their agenda

CM: there discussions ongoing on www-svg, and public-html

<heycam> CM: perhaps for now the best venue for these discussions is on those mailing lists, then

<shepazu> y'all calling back?

<jwatt> gah!

<jwatt> conf restricted

<heycam> jwatt, use 26631 as the code

<jwatt> when?

<heycam> when you dial back in?

<jwatt> thought you meant as a passcode :/

<jwatt> ta

CM: I have an action to collate the remaining issues we hadn't got consensus on yet
... and to integrate them into the document
... but maybe it would be better to crosspost them to the mailinglist instead?

DS: can we change the SVG 1.1 so radically (to convert the 1.1 DTD to RNG)?

CL: we should talk to philippe about that

<scribe> ACTION: CL to check if we can replace the SVG 1.1 DTD with an RNG [recorded in http://www.w3.org/2009/03/30-svg-minutes.html#action04]

<trackbot> Created ACTION-2508 - Check if we can replace the SVG 1.1 DTD with an RNG [on Chris Lilley - due 2009-04-06].

CM: so, what about discussing the HTML issues on the lists?

CL: sounds good

DS: yeah

CM: there are some constructive discussions going on there
... ok, I'll post the things we don't have consensus on
... and suggest that everyone join in on the discussions

Thoughts on cleaning up SVG 1.1 for Second Edition

CM: i'm looking at remaking the build scripts
... and also how to make 1.1 look a bit better
... to build the 1.1 spec and get the second edition published
... in the old cvs there's no master copy, so the source is rather bad

<heycam> http://mcc.id.au/temp/struct.html

<ChrisL> the code seems to have autogenerated markup but we don't have the sources or the scripts from which it was built

CM: here's an example of how it could look, main change is replacing the DTD fragments with something more readable

DS: an author reading the spec will understand this more easily

CM: the IDL will get generated definitions also
... I've written an IDL parser, and use that for generating the interface definitions

CM: another advantage is that in the master version you can write <a>'svg'</a> and have it transformed into something useful

<heycam> <a>container element</a>

DS: and for definitions?

CM: yes

<ChrisL> for elements, attributes, properties and definitions

CL: what about types? strings, iri?

<ChrisL> cool

CM: could use the same, not done yet though

CL: would be useful to have them

CM: the intro chapter defs would be nice, and where elements are in the spec etc
... parsing of
... if people are happy with this style then I can commit the scripts

CL: would like to use it for new modules

CM: could help with cross spec references too
... will check it into cvs even though it's not fully ready
... will let ppl know when it's ready for use
... links to interfaces would be nice

Raising the issue of multi-threading

CM: AA was asking about getBBox, and multithreading

http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0321.html

JW: it's contrary to how you use the DOM, and it wouldn't stop it from getting svg bbox

CL: multithreading is fine, if you can get advantages from it
... but you have to deal with making the implementation behave a certain predictable way

<ChrisL> but you have to sync up the threads

CM: right, to have getBBox block until you can get a valid result
... it took a while until Firefox returned proper values from getBBox, and to break that would be a step backwards
... there's content that relies on this already

ED: http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0324.html has some suggestions for clarifying getBBox
... 1.1 doesn't have the 1.2T wording about implementation-dependent bboxes for elements outside the document tree

JW: values can sometimes be resolved in a meaningful way, eg. <svg><rect></svg>

<scribe> ACTION: ed to create an errata item for SVG 1.1 and the getBBox method, as described in http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0321.html [recorded in http://www.w3.org/2009/03/30-svg-minutes.html#action05]

<trackbot> Created ACTION-2509 - Create an errata item for SVG 1.1 and the getBBox method, as described in http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0321.html [on Erik Dahlström - due 2009-04-06].

<ChrisL> http://www.codedread.com/svg-support.php

<ChrisL> in the link above there is also a Firefox pre3.6+SMIL

ICC color

[CL explains @color-profile]

JW: would be nice to have a way to specify the profile for the document
... if you wanted to resuse some profile from someone, you might want to set on a subtree only

CL: in terms of minimizing the syntax it won't give you much
... you'd still have to do the rgb fallbacks
... reasonable to make some changes but might be incompatible with 1.1

AG: I've got some ppl here to review the color spec
... underspecified for printing, overspecified for web authoring

CL: i'd like to know the details of those

AG: what group do we want to target?

CL: I'd think both

<ChrisL> its for repurposing content, screen+print, with an eye on screen improving

CL: we haven't covered colormatched raster images
... if you mix raster and vectors you want to fit colors together

AG: agree that the web needs more than sRGB