SVG Working Group Teleconference -- 19 Mar 2009

<trackbot> Date: 19 March 2009

<shepazu> the curse has been lifted!!

<shepazu> scribeNick: shepazu

We Are Robots

3d Transforms

heycam: I saw various emails about publication, what's the status?

shepazu: CSS is ready to publish
... we could be ready to publish as early as tomorrow
... the open question is, do we want to form a CSS-SVG Task Force about this?

heycam: there has been some pushback on that

shepazu: we really need to have a long-term collaboration

heycam: ideally, the HCG should do that

shepazu: yes, but there's too many groups there, and there's only 1-hour telcon every 2 weeks
... there's all sorts of cross-posting problems, and we have to set up a liaison each time there's an issue... a TF would make that easier

<heycam> ScribeNick: heycam

CM: how about us subscribing to www-style and doing coordination there?

DS: there are many other mails to www-style, would be distracting
... a taskforce with a dedicated mailing list is just a little bit more email for each group
... i'd like for the taskforce to be public

RESOLUTION: We are in favour of creating a taskforce for coordination on Transforms

DS: it might be too late for forming a TF mailing list for comments on transforms FPWD

CM: what are the open issues on Transforms?
... did dean's comments get put into the spec as issues?

AG: not all of them

DS: a couple of them are in there, i think
... first one was what to do about z-index/layeredG
... second one was the 4x4 matrix

AG: i have a note in there about transform-style

DS: both of those comments are in there already
... anthony, you should write up an analysis of why we choose 3x3 over 4x4
... like you described at the F2F

AG: you could render to an offscren buffer, then blit that using OpenVG's perspective transform

<scribe> ACTION: Anthony to write up the reasoning for using 3x3 matrix in SVG Transforms [recorded in http://www.w3.org/2009/03/19-svg-minutes.html#action01]

<trackbot> Created ACTION-2498 - Write up the reasoning for using 3x3 matrix in SVG Transforms [on Anthony Grasso - due 2009-03-26].

ACTION-2498: Put it in the wiki

<trackbot> ACTION-2498 Write up the reasoning for using 3x3 matrix in SVG Transforms notes added

DS: the css wg agreed to publish all four of the apple specs as fpwds, but they want to move more slowly on 3d transforms

SVG / ODF

http://lists.oasis-open.org/archives/tc-announce/200902/msg00007.html

DS: this came up on the SVG IG list

<shepazu> http://lists.oasis-open.org/archives/tc-announce/200902/msg00007.html

DS: AN noted that there was a proposal from the staff contact for the ODF TC saying:

<shepazu> [[

<shepazu> You are invited to help define the feature set of the next revision of OASIS

<shepazu> Open Document Format (ODF) to follow ODF 1.2. Help us take "ODF-Next" to a

<shepazu> higher stage of document evolution. Be creative. Push the envelope. Be

<shepazu> provocative. Change the paradigm. Start a revolution. The only limits on our

<shepazu> vision are our own.

<shepazu> ]]

<shepazu> http://wiki.oasis-open.org/office/Requirements

ED: they're looking for comments before the end of the month

DS: the earlier the better, since we might have some back and forth on this
... i've joined their mailing list

<shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_ODF#Proposed_Liaison_Prose

DS: i've been doing some research on this, going back through old issues
... i have some background, a summary of the current state [in this wiki page]
... they claim that they have svg support, but they don't
... they can import svg (in oo.org) into their Draw format, and they can export their Draw format to svg
... they use SVG attributes, but use them in a namespace (instead of the null namespace)
... and they don't use them on svg elements, they use them like <ns:rect svg:width='...'/>
... we need to convince them to actually use svg, as a native object
... so that you can generate it using whatever tools, and have it work in their document format

ED: it would be important to make sure they follow guidelines, if they need to extend svg in some way then they should do it in a way that is still compatible with svg
... e.g. putting extensions to svg in their own namespace

DS: i mention that in the wiki page

ED: there's a page/section in 1.2T, we should give a link to that

DS: i would also say that the SVG WG is interested in getting their feedback, and that we'd be willing to working with them on features that they would want from svg

<ed_> http://www.w3.org/TR/SVGMobile12/extend.html#ForeignNamespacesPrivateData

CM: should we just add things to the wiki page?

DS: i'd like a deadline
... i researched it pretty thoroughly
... i'd like to send it fairly soon
... so if you could check over it over the next couple of days, that would be good

ED: i'd like to see a requirement that if they do extensions, that they follow our guidelines
... i can add that to the wiki page

DS: missing at the moment is exact technicaly requirements on what we want to change
... i'll research how they do embedding in ODF

RESOLUTION: We will ask ODF TC to use SVG for the native graphics format

<shepazu> sa native /a native /

SVG in HTML

CM: started looking at the proposal pages briefly yesterday
... i'll commit some changes

ED: did you add all of the parse errors?

DS: i added them for nonquoted attributes

ED: we should discuss <script> and <style>

DS: what happens if you have an inline <svg> with an element that is outside the viewport and someone links to that outside-viewport element with a fragid

CM: in fact, what should that do even for a visible svg element. something more than just scrolling to the whole <svg> block?

DS: i want to be able to link to a particular time, too
... should that seek html things too (video, audio)?

ED: for <script> afaiui i'm fine with treating it just like the html <script> element
... with the exception of xlink:href instead of src

CM: or in addition to src?

ED: that's from the www-svg feedback

DS: so you wouldn't need to put cdata sections around the script content?

ED: you would have to comment those cdata things

DS: i thought people were saying something else

ED: if you want it to work both in svg+xml and svg+html

DS: i thought jonas was saying that it would automatically handle CDATA

CM: right, i think that was one of his proposals, to ignore the "<![CDATA[" at the front

ED: that's one of the proposals

DS: i think jonas was suggesting that CDATA blocks just work, and i think that's a better way forward

CM: i'm happiest with that proposal so far

DS: there aren't many incompatibilities

CM: there's the issue of entities in XML copied across to <script> in HTML and their being interpreted as actual "&" characters
... but i think that would be rare
... the issue about xml serialisers perhap generating content like that would be my biggest concern
... and that's a small concern

ED: what would need to change in our text to make this happen?
... would the CDATA model be able to handle this? or do we need to add a special mode for it?

DS: i think <style> should be treated in the same way as <script>

ed_work, we should check how <script></script> is treated

ED: how about <script defer>

CM: i'd like <script> and <style> to be the union of svg's and html's

ED: can you do <style src> in html?

<ed_> http://dev.w3.org/html5/spec/Overview.html#the-style-element

ED: i'd want the src attribute on <script> to work in svg

DS: i'm fine with adding all those attributes (in SVG 2)

<ed_> http://dev.w3.org/html5/spec/Overview.html#script

CM: type was accidentally animatable in SVG 1.1
... there's an erratum to make it not animatable

<shepazu> ISSUE-2239?

<trackbot> ISSUE-2239 -- Add HTML5 script-element attributes to SVG's script element -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2239

CM: but i think the attribute is still of type SVGAnimatedString
... no, that's xlink:href actually

<shepazu> ISSUE-2042?

<trackbot> ISSUE-2042 -- Consider adding adding non-NS linking syntax -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2042

RESOLUTION: We want SVG-in-HTML <script> and <style> to be of type CDATA but to treat "<![CDATA[" and "]]>" at start/end specially

<shepazu> ISSUE-2240?

<trackbot> ISSUE-2240 -- Add HTML5 style-element attributes to SVG's style element -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2240

allowReorder on <switch>

DS: can we add that to 1.2T at this point?

ED: i read the spec text for it, it seems it's all informative

DS: i think that's a mistake

ED: doesn't seem useful to do it like that
... the text says that the UA can pick any language it likes from the list, when allowReorder is true
... it doesn't mention the case when there are other required* attribute on the children
... it's fine as long as there's only systemLanguage

DS: systemLanguage is probably the primary use

ED: it would be better to state the exact order to pick the languages based on Accept header qualities

RESOLUTION: We want SYMM WG to clarify allowReorder processing in an erratum

<scribe> ACTION: Doug to ask SYMM WG to clarify allowReorder processing in an erratum [recorded in http://www.w3.org/2009/03/19-svg-minutes.html#action02]

<trackbot> Created ACTION-2499 - Ask SYMM WG to clarify allowReorder processing in an erratum [on Doug Schepers - due 2009-03-26].

ED: probably too late for 1.2T, we can add it to Core 2.0

DS: i think UAs could still implement it, practically

<shepazu> ISSUE-2238?

<trackbot> ISSUE-2238 -- Add @allowReorder to <switch> -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2238

<shepazu> ISSUE-2207?

<trackbot> ISSUE-2207 -- be happy ☻ -- CLOSED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2207

- DRAFT -

SVG Working Group Teleconference

19 Mar 2009

Attendees

Contents

We Are Robots

3d Transforms

SVG / ODF

SVG in HTML

allowReorder on <switch>

Summary of Action Items

Scribe.perl diagnostic output