- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 20 Mar 2009 08:43:17 +1100
- To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
http://www.w3.org/2009/03/19-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
19 Mar 2009
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0254.html
See also: [3]IRC log
[3] http://www.w3.org/2009/03/19-svg-irc
Attendees
Present
ed_, Shepazu, anthony, [IPcaller], heycam
Regrets
Chair
heycam
Scribe
shepazu, heycam
Contents
* [4]Topics
1. [5]We Are Robots
2. [6]3d Transforms
3. [7]SVG / ODF
4. [8]SVG in HTML
5. [9]allowReorder on <switch>
* [10]Summary of Action Items
_________________________________________________________
<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
[11]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
[12]http://lists.oasis-open.org/archives/tc-announce/200902/msg00007
.html
[12] http://lists.oasis-open.org/archives/tc-announce/200902/msg00007.html
DS: this came up on the SVG IG list
<shepazu>
[13]http://lists.oasis-open.org/archives/tc-announce/200902/msg00007
.html
[13] 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> [14]http://wiki.oasis-open.org/office/Requirements
[14] 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>
[15]http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_ODF#Proposed_Liais
on_Prose
[15] 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_>
[16]http://www.w3.org/TR/SVGMobile12/extend.html#ForeignNamespacesPr
ivateData
[16] 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_>
[17]http://dev.w3.org/html5/spec/Overview.html#the-style-element
[17] 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_> [18]http://dev.w3.org/html5/spec/Overview.html#script
[18] 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> [19]http://www.w3.org/Graphics/SVG/WG/track/issues/2239
[19] 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> [20]http://www.w3.org/Graphics/SVG/WG/track/issues/2042
[20] 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> [21]http://www.w3.org/Graphics/SVG/WG/track/issues/2240
[21] 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
[22]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> [23]http://www.w3.org/Graphics/SVG/WG/track/issues/2238
[23] http://www.w3.org/Graphics/SVG/WG/track/issues/2238
<shepazu> ISSUE-2207?
<trackbot> ISSUE-2207 -- be happy ☻ -- CLOSED
<trackbot> [24]http://www.w3.org/Graphics/SVG/WG/track/issues/2207
[24] http://www.w3.org/Graphics/SVG/WG/track/issues/2207
Summary of Action Items
[NEW] ACTION: Anthony to write up the reasoning for using 3x3 matrix
in SVG Transforms [recorded in
[25]http://www.w3.org/2009/03/19-svg-minutes.html#action01]
[NEW] ACTION: Doug to ask SYMM WG to clarify allowReorder processing
in an erratum [recorded in
[26]http://www.w3.org/2009/03/19-svg-minutes.html#action02]
[End of minutes]
_________________________________________________________
--
Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 19 March 2009 21:44:09 UTC