W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2009

Minutes, March 19 2009 telcon

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>
Message-ID: <20090319214316.GA16607@arc.mcc.id.au>


      [1] http://www.w3.org/

                               - DRAFT -

                   SVG Working Group Teleconference

19 Mar 2009


      [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


          ed_, Shepazu, anthony, [IPcaller], heycam


          shepazu, heycam


     * [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

   <heycam> ScribeNick: heycam

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

   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

   <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



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

   DS: this came up on the SVG IG list


     [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


     [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
   ... 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


     [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

   <shepazu> sa native /a native /


   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

   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

   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

   ED: how about <script defer>

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

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


     [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

   <scribe> ACTION: Doug to ask SYMM WG to clarify allowReorder
   processing in an erratum [recorded in

   <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
   [NEW] ACTION: Doug to ask SYMM WG to clarify allowReorder processing
   in an erratum [recorded in

   [End of minutes]

Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 19 March 2009 21:44:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:41 UTC