SVG Working Group Teleconference -- 16 Mar 2011

<trackbot> Date: 16 March 2011

<ChrisL> http://www.w3.org/TR/2011/WD-SVGCompositing-20110315/

<scribe> Scribe: anthony

<scribe> Scribenick: anthony

Telcon Time

<heycam> http://lists.w3.org/Archives/Member/w3c-svg-wg/2011JanMar/0028.html

CM: US have already moved to daylight saving time
... Europe is moving soon
... AUS and NZ change on the 6th April
... we should see what time is suitable for everyone once those changes have been made

CL: What time will the call be once the changes have been made?

CM: In AUS and NZ it will be 4:30am
... In the email there you can see what the times will be after April 6th if the time doesn't change
... I'm assuming the current time is not suitable
... We should see if we can shift the time by a few hours

CL: I have a call after this one which is the WOFF call
... so I will have a conflict
... this call is 8:30 - 10:00 then WOFF is 10:00 - 11:00

<ChrisL> (all the above times pm)

CL: so a call after WOFF would be late for me

TB: After 11:00PM would be too late for me as well

CM: I propose we keep this current time leading up to April 6th. So on March 30th when Europe changes
... they will go back to the original telecon time

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Full_11#Remaining_work_for_SVG1.1F2

AG: Once we decide on a new telcon time it will kick in once we've all changed to our respective daylight savings times?

CM: Yes

SVG Full 1.1 2nd Edition

CM: I've updated that page
... We haven't had any progress on these things since the F2F
... just wanted to make sure everyone is on the same page about things left to do

CL: Sorry haven't finished my Action I need to do
... regarding ACTION-2910

CM: That's for the spec text

<heycam> http://dev.w3.org/SVG/profiles/1.1F2/test/status/implementation_matrix.html

CM: and for the test suite

CL: There is one test that it has a problem converting
... I'm not sure how to convert that in FontForge
... I'll ask someone in the Fonts Working Group on how it's done

<heycam> http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMiniApproved/fonts-desc-04-t.html

CM: Let me see if this one already has a WOFF
... so we should wait for the WOFF variant

ED: Ok

CM: So looking at the implementation matrix
... it lists 6 testes there as not having 2 passes
... 2 of them we have decided it was ok, because there are implementations for it on the way
... 1 of the tests is waiting for a patch in FireFox
... and another is being implemented by Abbra

<ed> http://lists.w3.org/Archives/Public/www-svg/2011Mar/0064.html

ED: I made changes to two of the font-text tests
... based on some feedbcak

<ed> http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObject/text-intro-02-b.html

ED: it may affect how implementations pass those

<ed> http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObject/text-intro-09-b.html

ED: it affects the positioning text anchor
... and both of those should pass in Opera 11.10 release

CM: I'm looking at text-intro-02 now
... I think we get incorrect behaviour
... can you say what the change was?

ED: Change was to make the last line have a specific text anchor

CM: There is no auto value?

ED: Initial value is "start"
... There was some confusion whether direction should affect the text when unicode-bidi is set to "normal"

<ChrisL> I willretest text-intro-02 and 09 in abbra

<ed> http://dev.w3.org/SVG/profiles/1.1F2/publish/text.html#TextAnchorProperty

CM: Why isn't that text-anchor="end" is considered to be the left of the point of the text line when going "rtl"?

<ChrisL> abbra still fails -02

CM: ok, I'm happy with that

CL: I just tried that in Abbra
... it fails, I don't think it implements bidi override

<ChrisL> think bidi-override is not implemented perhaps

ED: The reasoning behind the changes, was based on the i18n groups feedback
... so I made the tests so that they specify the direction and not have it based off the initial character
... I think that's what Webkit does as well

CM: This is not an issue with regular HTML? With normal HTML or SVG what effect does the direction property have?

ED: For "middle" I don't think it makes too much of a difference
... I don't think it makes any change to word order or special substitutions. It just aligns the text fragment

CM: So in CSS 2, from their definition. It effects which side of the box it overflows out of.
... if it's Justified text it effects which direction the last line goes
... I guess it makes sense that the last line doesn't apply to us

<scribe> ACTION: Cameron to Retest text-intro-02 and text-intro-09 in FireFox and Webkit and report back [recorded in http://www.w3.org/2011/03/16-svg-minutes.html#action01]

<trackbot> Created ACTION-3010 - Retest text-intro-02 and text-intro-09 in FireFox and Webkit and report back [on Cameron McCormack - due 2011-03-23].

Compositing Publication

CL: It has been published!

AG: Yay! :D

<heycam> http://www.w3.org/TR/2011/WD-SVGCompositing-20110315/

<ChrisL> http://www.w3.org/TR/2011/WD-SVGCompositing-20110315/

CM: We have LC period for 4 weeks?

CL: Yes, usual thing. I sent an email off to the CG asking if anyone needed longer
... no one spoke up, so it's fine then
... I asked CSS and XSL specifically if they can provide feedback

CM: Do we normally announce publish documents on www-svg?

CL: Now that is officially published
... usually the chairs send it out
... just say the document is published, give them links and say when the last period ends
... and some small summary about the document is useful

<scribe> ACTION: Cameron to Send an email to www-svg announcing the publication of the Compositing Specification [recorded in http://www.w3.org/2011/03/16-svg-minutes.html#action02]

<trackbot> Created ACTION-3011 - Send an email to www-svg announcing the publication of the Compositing Specification [on Cameron McCormack - due 2011-03-23].

CM: Is that a transition?

CL: It's not a transition in that it requires a transition meeting

<heycam> ACTION-3011: send one to chairs@ too

<trackbot> ACTION-3011 Send an email to www-svg announcing the publication of the Compositing Specification notes added

CL: but send the same email to the chairs list but don't cross post

Order of Transform and motion animation application

<heycam> http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0093.html

CM: I thought it might be unclear in the spec where the transform in motion animation gets applied in relation to element
... and implementations vary on whether they apply the motion transform first or the transform attribute
... It would be clear in spec if it defined for each element what order things were applied in
... in the email I put some wording in, but it's kind of unclear
... the wording "on top of" is unclear"
... I made a test to see what order things applied in
... I don't remember form that thread whether it should be one way or not

AG: Did you try it out in Tiny 1.2 or Abbra for example?

ED: Alex replied back and said the same as Opera and Firefox

<ed> http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0094.html

AG: Define for SVG 2? or add something in to 1.1?

CM: We could probably add a sentence in if we are going to keep option "A"
... we already have a test for it and there are at least 2 passes for it
... Erik you said legacy content assumes option "A"

<ed> http://lists.w3.org/Archives/Public/public-svg-wg/2011JanMar/0101.html

CM: Ikivo editor tool assumes option "A"
... I'm wondering which way makes more sense though?
... which is more useful?
... either way you can work around things by adding extra <g> element

ED: I think it would be a good idea to ask the public list
... to see what people think. To see if there are any arguments regarding any of those options
... Like I said in my email I don't have any strong opinion. We went with option "A" because we wanted to be compatible with
... the content out there at the time when it was first implemented in opera

<heycam> http://www.w3.org/mid/AANLkTimdSODDNoW7VCm8SXL+OF0GBgOdz35iRK5Jt2_j@mail.gmail.com

CM: There is a thread starting here
... and we'll have to look at that thread
... how about I look through that thread and see if it's clear one way or another
... otherwise if it is not clear I say we go with option "A"

<scribe> ACTION: Camera to Look through the thread "SVG animateMotion specification clarification request" to determine if there is a preference for option "A" or "B" [recorded in http://www.w3.org/2011/03/16-svg-minutes.html#action03]

<trackbot> Sorry, couldn't find user - Camera

<scribe> ACTION: Cameron to Look through the thread "SVG animateMotion specification clarification request" to determine if there is a preference for option "A" or "B" [recorded in http://www.w3.org/2011/03/16-svg-minutes.html#action04]

<trackbot> Created ACTION-3012 - Look through the thread "SVG animateMotion specification clarification request" to determine if there is a preference for option "A" or "B" [on Cameron McCormack - due 2011-03-23].

<ed> http://lists.w3.org/Archives/Public/www-svg/2011Mar/0062.html

Discrete Animation Fix

ED: So this is basically what was proposed at the face-to-face meeting right?

CL: I remember being this discussed, or if there were any downsides - i.e. content that broke

CM: Yes it was discussed, but I don't think it was clear whether this would be part of the changes in SVG 2

ED: Any proposed wording

CM: There isn't any proposed wording in his email

ED: I don't see any broken content because of this

CM: So maybe somebody could take an action to write a test for this to confirm that implementations are doing it this way
... and propose wording change

<scribe> ACTION: Cameron to Write a test to confirm that Brian's proposal is implemented by various different implementations and propose wording for the specification [recorded in http://www.w3.org/2011/03/16-svg-minutes.html#action05]

<trackbot> Created ACTION-3013 - Write a test to confirm that Brian's proposal is implemented by various different implementations and propose wording for the specification [on Cameron McCormack - due 2011-03-23].

CSS Animations

CM: [Summaries discussion in FX call during the week]
... the CSS people were not particularly happy with the attr() syntax

PD: I have been following

CM: It seems the discussions we had at the face-to-face was CSS working group may not like option 2 because they would not a lot of properties being added
... Tab was given an action to email the working group with the options

<ed> http://lists.w3.org/Archives/Public/www-style/2011Mar/0347.html

<ed> http://lists.w3.org/Archives/Public/www-style/2011Mar/0350.html

PD: I just want to get solved
... I liked the idea of '-svg-r' for radius for example

CL: The downside is it makes it hard for Filter properties which were specific to filters
... we might be adding extra storage space in memory by adding about 30 - 40 properties

PD: I was hoping that the svg prefix wouldn't carry over that problem to HTML

CL: Potentially it makes SVG heavier

<ChrisL> I'm concerned about dom bloat making svg heavier and slowerr. 50-odd new properties per element ....

CM: I think it is valid something to worry about
... I don't know how easy it is to optimise but you could only store properties that applied to certain elements
... this was raised by ROC and others
... the other issue being discussed with option number 2 whether to only do for this for select attributes only or all of them up front

PD: I like the staging idea

CM: ROC's argument is that we need to consider what needs to be done up front so we don't paint ourselves into a corner so we can later promote other properties
... I think it would be good to take a look if we were to promote all the attributes
... to see what it would be like
... to see if we need any new syntax values

PD: You want an investigation to see if the entire picture will work

CM: Yes, and how much work it will be
... my impression is once you have the architecture to handle presentation attribute and properties it wouldn't too much extra work
... I might have a look at that later on in the week
... so I'll post something to FX

AG: Any issues with initial values, and inheritence?

CM: Let's keep the discussion going on this for a couple of weeks
... and look at it on the next FX call

trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

16 Mar 2011

Attendees

Contents