W3C home > Mailing lists > Public > public-svg-wg@w3.org > October to December 2008

Minutes, 23 Oct SVG WG f2f

From: Chris Lilley <chris@w3.org>
Date: Fri, 24 Oct 2008 09:27:13 +0200
Message-ID: <1171625369.20081024092713@w3.org>
To: public-svg-wg@w3.org


Minutes for Thursday 23 Oct TPAC session are at

and below as text for bots. Notice that the list of 'Present' seems to have been overwritten during the day.

                   SVG Working Group Teleconference

23 Oct 2008

   See also: [2]IRC log

      [2] http://www.w3.org/2008/10/23-svg-irc


          Ori_Idan, Fons_Kui, jk, Jun_Fujisawa, Doug_Schepers, Erik_Dahlstrom, Anthony_Grasso, Al_gilman, Chris_Lilley, dino


          anthony, Erik, Chris


     * [3]Topics
         1. [4]LC comments
         2. [5]ISSUE-2085
         3. [6]ISSUE-2094
         4. [7]ISSUE-2107
         5. [8]ISSUE-2110
         6. [9]ISSUE-2130
         7. [10]ISSUE-2139
         8. [11]ISSUE-2145
         9. [12]SVG IG Japan
        10. [13]SVG JIS Standard
        11. [14]svg transformations module
        12. [15]next F2F meeting(s)
        13. [16]More Last Call Comments
        14. [17]Testing
     * [18]Summary of Action Items

   <trackbot> Date: 23 October 2008

LC comments


     [19] http://lists.w3.org/Archives/Member/member-svg-editors/2008Oct/0322.html

   <anthony> scribe: anthony

   <ed> [20]http://www.w3.org/Graphics/SVG/WG/track/products/11

     [20] http://www.w3.org/Graphics/SVG/WG/track/products/11



   <trackbot> ISSUE-2085 -- Spec unclear where focus should initially
   go when a document is loaded -- OPEN

   <trackbot> [21]http://www.w3.org/Graphics/SVG/WG/track/issues/2085

     [21] http://www.w3.org/Graphics/SVG/WG/track/issues/2085

   ED: Issue raised by Ikivo
   ... NH has an action to propose new wording

   DS: Perhaps we should make a proposal to him

   <fat_tony> scribeNick: fat_tony


     [22] http://dev.w3.org/SVG/profiles/1.2T/publish/interact.html#navigationbehaviour

   ED: The thing he is complaining about is the steps for how focus
   navigation behaves
   ... You can interpreter this in a few ways
   ... that's not necessarily a bad thing

   DS: Do we talk about document focus vs UA focus

   <scribe> ACTION: Doug to Propose wording for document focus vs user
   agent focus that addresses ISSUE-2085 [recorded in

   <trackbot> Created ACTION-2324 - Propose wording for document focus
   vs user agent focus that addresses ISSUE-2085 [on Doug Schepers -
   due 2008-10-30].



   <trackbot> ISSUE-2094 -- accessing rules for traitAccess -- OPEN

   <trackbot> [24]http://www.w3.org/Graphics/SVG/WG/track/issues/2094

     [24] http://www.w3.org/Graphics/SVG/WG/track/issues/2094

   ED: We have two open actions there
   ... one is on me
   ... the other on A Emmons
   ... and A Emmons had the action to respond to the commenter

   DS: Who was this for?

   ED: Julien R
   ... I'll just check the public mailing list

   AG: Did you make the change?

   ED: No he's just asking for an answer
   ... it's not clear that he wants anything changed

   DS: What's the justification for the ones we chose not to change?

   ED: I really hoped A Emmons would take care of this
   ... he seemed to have a good grasp on it

   AG: Can we ping him at lunchtime?

   DS: We can always send him an email



   <trackbot> ISSUE-2107 -- i18n comment 6: Direction and bidi-override
   attributes -- RAISED

   <trackbot> [25]http://www.w3.org/Graphics/SVG/WG/track/issues/2107

     [25] http://www.w3.org/Graphics/SVG/WG/track/issues/2107

   ED: Is this done?

   DS: We really need Chris here for this
   ... and the next one 2110
   ... these are both internationalisation issues

   OI: Bidi direction is important to the I18N
   ... I think there are issues with Right-to-Left and Tob-to-Bottom

   DS: We do not cover vertical text in Tiny
   ... but we do in full

   AG: The wording in the specification allows for support for
   Top-to-Bottom text
   ... but doesn't mandate it

   DS: Tiny 1.1 is just subset of features in full

   ED: We do have tests for Right-to-Left and Top-to-Bottom
   ... but they are simple tests
   ... we don't test all the tricky cases
   ... so with the issue here I do agree with it
   ... the last comment I believe is a miss understanding

   OI: [Reads Issue]

   ED: There is nothing preventing you from doing that
   ... [Explains feature]

   OI: Is inherited like CSS?

   ED: Yes it is

   OI: If it is inherited like CSS that is ok

   ED: We took the direction property from CSS
   ... so it should be the same

   OI: The default is Left-to-Right

   DS: Would it be worth noting that in the spec

   OI: Could say that the property of RtL is inherited from the top
   ... then it will be inherited to the terms inside it
   ... that's in CSS
   ... what is it in your terms

   ED: text content element is the term for it

   DS: I think this is just an authoring note
   ... if you put direction in the root of the document
   ... it will apply only to text elements
   ... it could confuse people because it's not like "text-direction"

   ED: It does map to the CSS property

   OI: You should note that it only applies to text blocks
   ... if I have a text block with direction RtL and a nested text
   block is also RtL

   DS: And of course override-able

   ED: That's one of his requests
   ... to have examples
   ... I think it would be useful to have the inheriting thing

   OI: So people know that there is inheritance?
   ... may not be necessary

   DS: More so for authors rather than implementers
   ... I think I'm going to put in a note
   ... because it's not really clear that direction applies to text

   OI: The direction property only applies to text
   ... not to graphics

   ED: Another comment he makes here in this issue
   ... that we say in the spec that authors are discouraged from using
   direction and unicode-bidi

   DS: [Reads out issue]
   ... so what this sentence means for people using western languages
   don't mess with this

   OI: Do you understand the issue if you place a dot after it
   ... the unicode algorithm doesn't know about the dot if it's LtR or
   ... That's a problem with 'weak directionality'
   ... they don't have a directionality

   ED: Just need to clean up the wording on this issue and make an
   example or two

   OI: I can review the wording now if you want

   ED: So in this issue there was not suggested text (wording)
   ... there's no concrete proposal on this issue

   OI: I can review this issue, propose wording and make an example

   ED: If you can make an example sure, that'd be great
   ... so he's example for the example of using RtL on the top and
   unicode-bidi embed

   DS: Did we decide about the in most cases?

   ED: Ori said he's happy to review any text proposal we have
   ... if you can propose some new wording that would be great

   OI: I'm not on the mailing list but I will send you an email
   ... Here's a small HTML example
   ... [shows example]

   <scribe> ACTION: Doug to Propose wording and examples for ISSUE-2017
   [recorded in

   <trackbot> Created ACTION-2325 - Propose wording and examples for
   ISSUE-2107 [on Doug Schepers - due 2008-10-30].



   <trackbot> ISSUE-2110 -- i18n comment 8: Text rendering order --

   <trackbot> [27]http://www.w3.org/Graphics/SVG/WG/track/issues/2110

     [27] http://www.w3.org/Graphics/SVG/WG/track/issues/2110

   OI: I think this is very similar
   ... oh wait, this is different
   ... that would be great if the direction of RtL that right glyph
   would be rendered first
   ... I think it would be nice
   ... but it is not a must
   ... that the right most glyph would be rendered first
   ... would be good from slow implementations so you can read the
   glyphs as they're being rendered

   ED: I'm not sure that the sentence is saying that

   OI: That's how I read it
   ... [reads sentence out]

   DS: So when it says rendering, I don't think the rendering would be
   ... if they're overlapping then the order matters

   OI: If they're not overlapping and the rendering order is not fast
   ... then you'll notice it
   ... do you think there'll be any slow implementation?
   ... do you think there'll be a slow application in a hand held
   device with a slow processor
   ... it only matters if this is a slow rendering device

   DS: Honestly I'd be very surprised
   ... because the text is processed as a block
   ... and put in order for placing on the canvas

   ED: I mean rendering part of text content block would be very

   OI: If the user agent that does the rendering to a canvas is it
   ... there is actually know mean for the rendering order of blocks

   DS: Individual characters in the block may over lap due to kerning


     [28] http://lists.w3.org/Archives/Public/www-svg/2008Oct/0117.html

   ED: Chris has suggested new wording there


     [29] http://lists.w3.org/Archives/Public/www-svg/2008Oct/0179.html

   DS: Here is my reply
   ... if the glyphs are reordered in the byte stream what happens?

   OI: Why would that happen?

   DS: Richard says it could; for example South East Asian characters
   ... we need Richard for this

   ED: We may need some tests

   OI: We need a Hebreu for this
   ... or Arabic
   ... and for South East Asian languages
   ... maybe Richard can supply us an example today

   DS: There is nothing stopping us for making examples today
   ... but it needs to be done in two days

   ED: How is this handled in HTML again?
   ... is this already addressed

   OI: Yes, it works fine
   ... I'm not sure about the rendering order
   ... in HTML it doesn't matter

   DS: Yes you can
   ... because of CSS
   ... they are adding Opacity in CSS
   ... so they will run into the same issues
   ... with letter spacing
   ... so HTML and CSS has the same problem

   ED: For consistency we use the same algorithm

   OI: For consistency can we say it's defined in HTML

   DS: Probably not

   OI: The issue is the running order just as Richard sent in

   ED: I mentioned reasons for reordering
   ... so I agree to that one
   ... the one that Chris sent

   OI: The reason we need to discuss rendering order is for when we
   have overlap
   ... I agree with Chris

   ED: So essentially this is rendering the first character you'd read

   OI: I agree with Chris
   ... not to sure about what Doug is saying
   ... we need a clarification from Richard

   ED: Does this address the whole issue

   <scribe> ACTION: Erik to Add the proposed wording for ISSUE-2110
   [recorded in

   <trackbot> Created ACTION-2326 - Add the proposed wording for
   ISSUE-2110 [on Erik Dahlström - due 2008-10-30].



   <trackbot> ISSUE-2130 -- Basic Data Types section needs
   clarifications -- OPEN

   <trackbot> [31]http://www.w3.org/Graphics/SVG/WG/track/issues/2130

     [31] http://www.w3.org/Graphics/SVG/WG/track/issues/2130

   <ChrisL> RIM states that they use SVG Tiny 1.2


     [32] http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=211600037

   <ChrisL> RIM engineers are looking at supporting 3-D graphics,
   probably through adopting the Java specification for OpenGL ES (JSR
   239). The company is also broadly adopting 2-D scalable vector
   graphics such as SVG Tiny 1.2. It first used SVG in version 4.6 for
   the Blackberry Bold phone.

   <ChrisL> "We are looking at doing fairly complete support for SVG in
   all the places an image needs support in a device," said Liam Quinn,
   who heads browser development at RIM.

   <ChrisL> issue-2130?

   <trackbot> ISSUE-2130 -- Basic Data Types section needs
   clarifications -- OPEN

   <trackbot> [33]http://www.w3.org/Graphics/SVG/WG/track/issues/2130

     [33] http://www.w3.org/Graphics/SVG/WG/track/issues/2130

   CL: We had a related issue which was about xml:id and the XML Schema
   ... and we resolved to fix the schema
   ... which fixes the first part of the issue
   ... for the second one
   ... we are asked to supply an example
   ... this is related to XML namespacing

   DS: He may simply not understand what QNames are
   ... I guess we could add a quick example

   <ChrisL> XML namespaces has two methods, one for elements
   (unprefixed ones use the default namespace) and one for attributes
   (where unprefixed ones do not).

   <ChrisL> Following the tag finding on qnames in attribute values,
   and common practice, qnames in attribute values also do not use
   default namespaces

   <ChrisL> [34]http://www.w3.org/2001/tag/doc/qnameids.html

     [34] http://www.w3.org/2001/tag/doc/qnameids.html

   <ChrisL> This wording needs to be clarified

   <ChrisL> "If the <QName> has a prefix, then the prefix is expanded
   into an IRI reference using the namespace declarations in effect
   where the name occurs, and the default namespace is not used for
   unprefixed names. "

   <ChrisL> ACTION: Chris to clarify QName expansion to tuples
   [recorded in

   <trackbot> Created ACTION-2327 - Clarify QName expansion to tuples
   [on Chris Lilley - due 2008-10-30].

   <ChrisL> "If the <QName> has a prefix, then the prefix is expanded
   into a tuple of an IRI reference and a local name, using the
   namespace declarations in effect where the name occurs. Note that,
   as with unprefixed attributes, the default namespace is not used for
   unprefixed names. "

   CL: Proposed sentence in IRC

   <ChrisL> The relevant part of the tag finding, that we follow, is
   "Specifications that use QNames to represent {URI, local-name} pairs
   MUST describe the algorithm that is used to map between them."

   CL: So an example would be if you're animating an attribute name is
   ... you'd be animating "stroke" and not "svg:stroke"
   ... [reads out rest of issue]
   ... so his third one is because in the schema we haven't defined
   anything as frame target
   ... do we want to patch up the schema to define something called
   "frame name"

   DS: Do we define what a frame target is?
   ... we can add a definition

   CL: Where is frame target used

   ED: Linking, I think the <a> element


     [36] http://dev.w3.org/SVG/profiles/1.2T/publish/linking.html#AElementTargetAttribute

   <ChrisL> [37]http://www.w3.org/TR/SVGMobile12/linking.html#AElement

     [37] http://www.w3.org/TR/SVGMobile12/linking.html#AElement

   CL: [Reads part out in spec]

   <ChrisL> "<frame-target>"

   <ChrisL> Specifies the name of the frame, pane, or other relevant
   presentation context for display of the linked content. If this
   already exists, it is re-used, replacing the existing content. if it
   does not exist, it is created (the same as _blank, except that it
   now has a name). Note that frame-target must be an XML Name [XML11].

   <ChrisL> we could link XML Name to the types chapter

   <ChrisL> basically frame-target is of type XML Name. So there is no
   error in the spec

   CL: The next one handler, string
   ... XML doesn't call string "strings"

   ED: What does XML Events say?

   <ChrisL> for the next two, XML-NMTOKEN is a subset of string

   ED: is it just an XML token?

   CL: And we have a link to the types which say NMToken

   <ChrisL> NMTOKEN is correct, and links to

     [38] http://www.w3.org/TR/SVGMobile12/types.html#DataTypeXML-NMTOKEN

   <ChrisL> 'string' is too loose and should be corrected

   CL: Which chapter is handler in?

   ED: Scripting

   <ChrisL> we can edit the spec where it says string

   ED: Do we just have XML-NMToken as a basic type?

   CL: Yes

   ED: We do us XML name
   ... on listener
   ... but not on handler

   CL: I've corrected handler
   ... I don't see it on listener

   ED: It's using XMLName, it should be using NMToken in that case

   CL: So this is in the scripting chapter?

   ED: Yes

   <ed> heycam: I have an up-to-date tools directory

   <ed> note that someone might have changed the example, we did
   discuss it



   <trackbot> ISSUE-2139 -- Add note regarding eRR attribute and
   prefetch element -- RAISED

   <trackbot> [39]http://www.w3.org/Graphics/SVG/WG/track/issues/2139

     [39] http://www.w3.org/Graphics/SVG/WG/track/issues/2139

   ED: A Emmons did send proposed text
   ... and Cyril responded to say if the text is added then he'll be
   fine with that

   <scribe> ACTION: Anthony to Add the text from the wording proposed
   by A Emmons to the specification regarding ISSUE2139 [recorded in

   <trackbot> Created ACTION-2328 - Add the text from the wording
   proposed by A Emmons to the specification regarding ISSUE2139 [on
   Anthony Grasso - due 2008-10-30].



   <trackbot> ISSUE-2145 -- Clarify media timeline and document
   timeline -- RAISED

   <trackbot> [41]http://www.w3.org/Graphics/SVG/WG/track/issues/2145

     [41] http://www.w3.org/Graphics/SVG/WG/track/issues/2145

   DS: He hasn't offered anything helpful regarding the issue

   ED: Do we want to postpone this

   DS: We will look at this one in a bit

   <ed> png?

   <scribe> scribe: Anthony

   <scribe> scribeNick: fat_tony

SVG IG Japan

   JF: Just started the activity in Japan
   ... for SVG IG
   ... created a mailing list
   ... had first f2f meeting on Friday
   ... the second is on 12th Nov
   ... and we invited Doug to talk to the group
   ... the group includes Takagi-san from KDDI and Takahashi-san fromm
   Indigo and Mori-san from Osaka City Uni

   CL: Where is the mailing list?

   JF: Yes it is in W3C
   ... there are several people from JIPDEC

   <ChrisL> [42]http://lists.w3.org/Archives/Public/public-svg-ig-jp/

     [42] http://lists.w3.org/Archives/Public/public-svg-ig-jp/

   JF: JIPDEC is a Japanese standards body

   <ChrisL> JIPDEC - Japan Information Processing Development

   JF: that is managing the standarisation of SVG in Japan

   <ChrisL> [43]http://www.jipdec.or.jp/eng/

     [43] http://www.jipdec.or.jp/eng/

   DS: JIPDEC sells copies of the JIS standard

   <shepazu> s/11th Nov/12th Nov/

   JF: Keio W3C will have JPC meeting on the 6th November
   ... so we can expect more traffic on SVG IG JP

   DS: If Kaz can translate the description on the public mailing list
   page in English to Japanese

   <scribe> ACTION: Doug to Coordinate on Kaz on JP IG list description
   [recorded in

   <trackbot> Created ACTION-2329 - Coordinate on Kaz on JP IG list
   description [on Doug Schepers - due 2008-10-30].

   <ChrisL> list description is in english currently

   <ChrisL> [45]http://lists.w3.org/Archives/Public/public-svg-ig-jp/

     [45] http://lists.w3.org/Archives/Public/public-svg-ig-jp/

   JF: Currently our main activity in SVG IG JP is to support the SVG
   JIS standardisation
   ... and coordinate with other people. Another activity is to promote
   the usage of SVG for
   ... web mapping in Japan
   ... we will working on a new module called SVG Map module

   CL: This is related to the existing JIS standard?

   JF: No this is a different module and and email to promote it has
   been sent out
   ... we will work on a complete module
   ... so we can make a complete proposal to SVG WG
   ... we also considering on gathering SVG map data in Japan
   ... and publish the map data on the SVG community site
   ... possibly on planet SVG

   CL: Are there minutes of the F2F meeting?

   JF: Yes minutes were scribed but they are in Japanese
   ... by Kaz

   DS: I want to thank you for all your effort you have put into this

   <ChrisL> thats good. hope to see them on the mailing list

   DS: The fact that you are the chair of the SVG IG is really good. I
   appreciate that

SVG JIS Standard

   JF: On the same date we had the first SVG JIS committee meeting
   ... Hagino-san of W3C Keio is the manager
   ... and the goal is to create a JIS Standard for the SVG based
   format for mapping
   ... and that includes a complete translated specification of SVG
   Tiny 1.2

   DS: When will they begin translation?

   JF: As soon as PR is available
   ... in the first committee meeting we discussed the possible
   category of the JIS standard
   ... and also the structure of the standard has been discussed
   ... there are two possible categories, one is mapping
   ... and networking category

   DS: Can it be in both?

   JF: That is an important point
   ... as for the structure four possibilities was suggested
   ... the first is the one just for SVG
   ... and one for SVG map module
   ... the second is to have just one standard just for SVG map module
   and that will be different from the SVG Tiny 1.2 spec
   ... and the third possibility is to have a single JIS standard to
   have branch of map module
   ... and the last possibility is to have a single combined
   specification which has SVG map and SVG Tiny all in one

   CL: There are advantages of each

   JF: There are some people who think that it is not useful out side
   of the use case of mapping
   ... we had the conclusion that there will be a map module and a
   network module
   ... in the last committee meeting they decided to have a separate
   standard for SVG Tiny and a separate for SVG Map module

   <ChrisL> Its my preference also, to have one standard which is
   SVGT1.2 in Japanese, and a second one which is SVG Mapping and could
   be submitted to W3C so we can have it as an W#C spec in English as

   JF: so we hope that we can bring the Map module to the working group

   DS: I know Andreas will be interested in this module
   ... the other thing that KDDI is not a member of W3C

   <ChrisL> I would like to see the Japanese version on the W3C site as
   an official translation

   DS: so they can't make a submission

   JF: It will be a proposal from the IG

   CL: We need to get patent statements from all of the authors
   ... agreeing to W3C patent policy

   JF: People in SVG IG JP agree to W3C patent policy

   <ChrisL> [46]http://www.svgopen.org/2004/papers/indigo/

     [46] http://www.svgopen.org/2004/papers/indigo/

   <ChrisL> Development of location based search engine service using

   <ChrisL> Yuzo Matsuzawa

   <ChrisL> Indigo Corporation

   JF: The goal is to come up with SVG Map profile which might be based
   on SVG 2.0 Core
   ... or some other useful module like Transforms
   ... SVG JIS project will be two year
   ... it started this April and ended in Mar 2009
   ... that is the goal in the first year to do the translation
   ... of the whole specification
   ... we have to finish the translation around the end of next March
   ... in the second year the committee will take a formal process to
   publish the standard
   ... in order to achieve this the timing for SVG Tiny to achieve PR
   and Rec is important
   ... and will start the translation as soon as the PR spec is
   ... so we hope this will happen in early Nov

   DS: So you will start translating when it's in PR and not Rec

   JF: Yes

   DS: So as part of the translation I'm sure they will find typos
   ... I'd be surprised if reading the specification they will not be
   confused, will they be able to propose a question
   ... if the english is not clear

   JF: The problem is the translation is out sourced
   ... but perhaps the SVG IG can review the translation

   CL: If someone perhaps miss understand somethings
   ... then it would be nice for it to come back to us

   DS: They have an investment on getting it correct
   ... if something is confusing to the translator they should know
   that they should communicate with the SVG WG

   <ChrisL2> its good in that case to ask the WG for clarification.
   Sometimes the English is not clear to a non native speaker.
   (Actually some of the spec is written by non-native speakers, too)

   DS: Our plan is early next week we will do our call for transition
   ... it is possible as early as Wed
   ... we think we can go to PR on Nov 3rd as PR and we will to Rec on
   Dec 2nd

   CL: When we go to Rec we will make a press release
   ... it would be nice to have Canon on the press release

   DS: Just so you know RIM has announced that it is developing SVG
   Tiny 1.2

   <ed> scribe: Erik

   <ed> scribeNick: ed

svg transformations module

   <dino> i just sent in comments on svg transformations. Did they make
   it to the list?

   <dino> shepazu, are you moderator?

   <shepazu> dino, just modded it

   <shepazu> dino: can you join us?

   <dino> shepazu, thankyou!

   <dino> yes, i'll come up if you promise to be nice

   DS: dino sent another message (I'm moderating this now, it got


     [47] http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0224.html

   AG: sent the proposal to the public wg list
   ... tried to keep it as close as possible to the css proposal
   ... the one in css uses z-order
   ... I decided to leave that out for now and use the painters
   ... it's an extension of the svg 2d transforms
   ... it's extended to 3x4 matrix to give you the extra rotation
   ... we think that's all that's necessary
   ... obviously extending this means we need to extend the DOM

   DS: does this have impacts on declarative animations?

   AG: yes, we need to consider that use-case
   ... and we need to add a section there to say how that should be
   ... if you have a circle on top of a rectangle and you rotate both
   as a group you'll still see the circle because it's on top of the
   ... rotate in the 3d sense

   DJ: the way css transformations work is that anything that has a
   transforms gets a css stacking context
   ... which means it goes into the z-index system
   ... z-index doesn't mean position, it's just like an offscreen
   buffer and the order you draw those
   ... you can have something something with a z value that puts
   something close to the viewer, but have a z-index that puts it below
   some other elements
   ... one question is how the svg transformations are supposed to be

   CL: it's hard to do a rotation of two elements that rotate in a
   circle in z

   if you have two elements in differnt 3d coordinate systems each
   group is rendered in two offscreens, so you can't have one elements
   sometimes in front of and sometimes behind

   DJ: most systems in 3d don't allow you to do grouping

   CL: opengl doesn't allow that, but PHIGS does
   ... opengl is immidiatemode, PHIGS is more like svg, it has a
   structure and a DOM, it has nesting, transformations
   ... in PHIGS has the same concept of grouping and transformations as
   svg, but everything is in the same 3d coordinate system

   ALG: are you talking about real 3d rendering in svg? is there any
   use in x3d?

   CL: 3d rendering in 2d

   DJ: you can position things but it's like drawing a postcard in 3d

   CL: 2.5d is 3x3 matrices

   AG: the problem is that it's bad for authoring, it's difficult to
   write the transformations and hard to animate

   DS: are we proposing 2.5d or 3d transforms?

   AG: localized 3d transforms
   ... it's still sort of 2.5d because you don't have a single 3d
   coordinate system, you have localized 3d coordinate systems

   CL: the 3d transforms are still affine transforms?

   DJ: the proposal canon sent has non-affine transformations available
   ... 3d affine transforms
   ... they have true perspective, so they're not 2d affine transforms

   CL: normally geometry are seen as structure
   ... in svg, and colors and such are seen as styling, so properties
   vs attributes

   DS: but if it's going to be in css it should be properties

   CL: but then the transforms in svg should also be properties?

   AG: the reason for having them as properties is to keep it as close
   to css as possible

   ED: people have been asking for transforms to be in css for some
   time (even for svg use-cases)

   DS: can you still have the animated "starwars" effect?

   AG/DJ: yes

   CL: how do we move this forward?

   AG: what's the priority of transforms in css?

   DJ: it's not part of css until the group is rechartered
   ... mozilla just implemented css transforms, but only the 2d parts

   DS: are you willing to work with the SVGWG to move this forward?

   DJ: currently css transforms can apply to svg root elements only,
   like a postcard

   DS: we need to figure out how SVG and CSS should work together wrt
   to transforms

   DJ: there are no units in svg in transform values, might be a
   problem for example

   AG: i'm happy to work with the css wg to move this

   DJ: mostly the proposals are the same
   ... we now do a full 4x4 matrix
   ... things you need to be aware of
   ... hit testing

   AG: and how do you get boundingboxes?

   <ChrisL2> non-invertible matices. singularities

   DJ: we have it on the phones
   ... what happens is that sometimes, with overflow hidden in css, you
   have to flatten the whole tree
   ... sometimes it looks like 3d but it's really not
   ... [draws on whiteboard]

   <fantasai> There were two concerns that came up when we discussed
   transforms in Beijing

   <fantasai> one was syntax: making the syntax match more closely CSS

   <fantasai> the other was the default value of the property

   <fantasai> which can't be the same as the identity transform

   <fantasai> because transformation needs to trigger some side effects
   in CSS

   <fantasai> such as turning the element into a block formatting

   DJ: clipping in 3d is difficult

   <fantasai> so it contains all its floating children ,etc

   DJ: you can't preserve 3d and have clipping

   <ChrisL2> yes. so the initial value needs to be 'no transform
   applied' so you dont get a css stacking context, right?

   DJ: the transforms spec isn't very big, but it's probably full of
   things that needs further discussion
   ... perspective-transform ...??
   ... read our proposal and ask for clarifications where needed
   ... reason we haven't got much feedback is probably because not many
   have tried implementing it so far
   ... css has a lot of edge cases that affect the 3d transforms

   CL: the initial value for transform needs to be 'none' not identity,
   because it sets up a stacking context

   DJ: it's nice to put the perspective on a parent div or svg:g, and
   then use it for the child elements

   AG: understand the need to the property

   DJ: preserve3d is something svg would need too probably

   AG: it would be nice to have DJ for another F2F for more discussion
   on this
   ... we could achieve faster progress that way

   DJ: i'll join the svg mailinglist

   JF: it's important to work with the CSSWG on this
   ... we don't want two specs on this

   RESOLUTION: we won't form a joint taskforce, we'll work with DJ and
   the CSS WG to ensure that 3d transforms can be used in both CSS,
   HTML and SVG

next F2F meeting(s)

   JF: canon has an experimental implementation of the 3d transforms
   module in svg, and we can confirm that we can easily describe
   3d-based UI:s by using this
   ... maybe at the next F2F we can have a demo ready

   <ChrisL2> Foundations of Open Media Software (FOMS)

   AG: we can host the next F2F in sydney, we want to do it after the
   FOMS conference

     [48] http://www.foms-workshop.org/foms2009/pmwiki.php/Main/CFP)

   <ChrisL2> Developer Workshop

   <ChrisL2> Thursday 15 - Friday 16 January 2009

   <ChrisL2> Hobart (Tasmania), Australia


     [49] http://www.foms-workshop.org/foms2009/pmwiki.php/Main/CFP

   AG: so Jan 19

   ED: i would prefer to have it a bit later

   CL: there's is an AC meeting in march

   ED: early february would be better

   DS: i'll be speaking at a conference in february, *checking when*
   ... let's schedule the f2f for february 16-20

   <fantasai> Minutes from CSSWG meeting in Beijing:

     [50] http://lists.w3.org/Archives/Member/w3c-css-wg/2007JulSep/0184.html

   <ChrisL2> Scribe: Chris

   <ChrisL2> scribenick: ChrisL2

More Last Call Comments

   <ed> [51]http://www.w3.org/Graphics/SVG/WG/track/products/11

     [51] http://www.w3.org/Graphics/SVG/WG/track/products/11

   ED: We now have only 9 issues


     [52] http://www.w3.org/Graphics/SVG/WG/track/products/11


   RNG link

   Link to RelaxNG Schema


   <trackbot> ISSUE-2153 -- Link to RelaxNG Schema -- RAISED

   <trackbot> [53]http://www.w3.org/Graphics/SVG/WG/track/issues/2153

     [53] http://www.w3.org/Graphics/SVG/WG/track/issues/2153

   this can be closed, Doug has updated the spec to point to the actual
   correct RNG that we are all editing

   also the make scrip updates this master -> publish


   <trackbot> ISSUE-2145 -- Clarify media timeline and document
   timeline -- RAISED

   <trackbot> [54]http://www.w3.org/Graphics/SVG/WG/track/issues/2145

     [54] http://www.w3.org/Graphics/SVG/WG/track/issues/2145

   ED: Prefer to have AE on this one

   sync behaviours not currently impleented in Opera

   postpone to tomorrow?

   DS: Perfer to do not if poss

   ED: Some suggested text in the comment

   (we discuss 'locked')

   CL: On this part "The specification should say what happens when a
   video/audio element points to a file or a set of streams containing
   multiple audio tracks (english and french, or AAC and AC3) or
   multiple video tracks.


   the answer is that it depends on whatever fragment syntax is defined
   for that media type registration. Depends also on what the media
   fragents WG comes up with

   there are other technologies that relate to this eg MPEG-21

   its outside our spec. But clearly something that needs to be solved

   DS: on his second-;ast para

   ED: .... agree about media timeline rather than 'play time'

   CL: What does smil say about sync delay and the allowed amount of

   ED: eg a straming video, it can be difficult to seek back. Thats an
   example where the media timeline cannot be controlled
   ... not always possible to restart from time zero

   DS: Media eleents are time containers. So locking one does not lock
   its parent

   CL: But if they are locked, and you pause the child, what happens to
   the parent. Thats what he is asking


     [55] http://www.w3.org/TR/SMIL2/smil-timing.html#Timing-ControllingRuntimeSync

   DS; Lockimng is only in terms of timeline sync, so if you pause an
   element its timeline is frozen; when its playing its synced to the

   CL: I read there "Note that the semantics of syncBehavior do not
   describe or require a particular approach to maintaining sync; the
   approach will be implementation dependent. Possible means of
   resolving a sync conflict may include:"

   also under "Paused elements and the active duration"

   "In addition, when an element is paused, the accumulated
   synchronization offset will increase to reflect the altered sync
   relationship. See also The accumulated synchronization offset."


     [56] http://www.w3.org/TR/SMIL2/smil-timing.html#Timing-PausedElementsAndActiveDur

   DS: So in the end its defined by SMIL there

   ED: So I can change playtime. will do that now

   <scribe> ACTION: Doug respond on ISSUE-2145 citing these minutes and
   pointing to SMIL 2.1 to talk about elapsed time offset when paused
   [recorded in

   <trackbot> Created ACTION-2330 - Respond on ISSUE-2145 citing these
   minutes and pointing to SMIL 2.1 to talk about elapsed time offset
   when paused [on Doug Schepers - due 2008-10-30].


   <trackbot> ISSUE-2107 -- i18n comment 6: Direction and bidi-override
   attributes -- OPEN

   <trackbot> [58]http://www.w3.org/Graphics/SVG/WG/track/issues/2107

     [58] http://www.w3.org/Graphics/SVG/WG/track/issues/2107

   CL: We are almost done on that one
   ... we had a native Hebrew speaker earlier today check our examples
   and tests
   ... its added to the spec, tested and impleented
   ... doug has an action to add an example to the spec

   DS: Want a step by step example and also a template for people to

   Still open until the examples are added

   Still open until the examples are added

   <ChrisL> ISSUE-2147?

   <trackbot> ISSUE-2147 -- Section on externally referenced documents
   confusing -- OPEN

   <trackbot> [59]http://www.w3.org/Graphics/SVG/WG/track/issues/2147

     [59] http://www.w3.org/Graphics/SVG/WG/track/issues/2147

   <ChrisL> ED: Cameron wrote about this on public list. 2 script
   elements with same UIR, execute twice not once so section is

   <ChrisL> DS: That section is badly writted

   <ChrisL> ED: AE did a small rewrite of some of it

   <ChrisL> DS: I sent an email with a more extensive rewrite

   <ChrisL> ED: There are multiple copy pasted sentences there


     [60] http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/att-0161/externalRefs.html

   <ChrisL> 14.1.6 Externally referenced documents


     [61] http://www.w3.org/TR/SVGMobile12/linking.html#externalReferences

   <ed> DS: my proposed text is the last one in the externalRefs.html
   file above

   <ChrisL> ED: Scripting chapter covers the script case, Cameron fixed


     [62] http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0216.html

   <ed> actually not yet


     [63] http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0201.html

   <ChrisL> the questions on external media and external scripts are in
   fact completely independent of the section on primary and resource
   documents, which are only about svg


   <ChrisL> media-audio-206-t is passed in GPAC

   <ChrisL> but animate-elem-226-t fails

Summary of Action Items

   [NEW] ACTION: Anthony to Add the text from the wording proposed by A
   Emmons to the specification regarding ISSUE2139 [recorded in
   [NEW] ACTION: Chris to clarify QName expansion to tuples [recorded
   in [65]http://www.w3.org/2008/10/23-svg-minutes.html#action04]
   [NEW] ACTION: Doug respond on ISSUE-2145 citing these minutes and
   pointing to SMIL 2.1 to talk about elapsed time offset when paused
   [recorded in
   [NEW] ACTION: Doug to Coordinate on Kaz on JP IG list description
   [recorded in
   [NEW] ACTION: Doug to Propose wording and examples for ISSUE-2017
   [recorded in
   [NEW] ACTION: Doug to Propose wording for document focus vs user
   agent focus that addresses ISSUE-2085 [recorded in
   [NEW] ACTION: Erik to Add the proposed wording for ISSUE-2110
   [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [71]scribe.perl version 1.133
    ([72]CVS log)
    $Date: 2008/10/23 16:15:57 $

     [71] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [72] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output


 Chris Lilley                    mailto:chris@w3.org
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG
Received on Friday, 24 October 2008 07:27:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 24 October 2008 07:27:28 GMT