SVG Working Group Teleconference -- 28 Oct 2009

<trackbot> Date: 28 October 2009

<ed> http://mcc.id.au/2007/03/telcon/

<scribe> Scribe: anthony

Telcon Times

DS: I see 20:00 UTC

ED: That would be 21:00 for Chris and me

AG: That would be 8:00am following day for me

DS: Marked 18:30 on Monday as bad
... no wait just double checking
... we talked about 19:00 to 20:30 UTC
... Chris marked 19:00 to 20:30 UTC as best and then good
... for him that would be 20:00 to 21:30 UTC + 1

ED: I would prefer to start 20:30 UTC + 1

<ed> ...or better still 21:00 UTC+1

DS: Chris has that for Monday and Thursday as good and best
... for me that would be
... 15:00 my time

AG: So for me that would be 7am the following day which is fine

DS: Starting at 20:00 UTC and going for an hour and a half
... one thing Chris said wanted to have a block of time
... before and after
... for getting together to do work
... we could have this as an understood convention
... that this is going on
... and is time to use for actions
... just a convention to follow, more for him
... I'll probably do the same thing

ED: Did we want to go for two telcons or one

DS: I think we should go for two
... so lets go ahead and block off those times
... just incase

ED: That would be Monday and Thursday 20:00 UTC

RESOLUTION: We will change telephone conference times to Monday and Thursday 20:00 UTC

<scribe> ACTION: Erik to Email the change of telephone conference times to the group and update the wiki page with the new times [recorded in http://www.w3.org/2009/10/28-svg-minutes.html#action01]

<trackbot> Created ACTION-2687 - Email the change of telephone conference times to the group and update the wiki page with the new times [on Erik Dahlström - due 2009-11-04].

DS: Chris and I will not be at the telcon next week
... because we will be at TPAC

ED: So the new times will be active the week after next
... I think it's Monday 9th
... Doug you will make sure Zakim knows the new times as well?

DS: I'll change that now

SVG Full 1.1 Marathon

ED: Should we start off with having a telcon
... or is it fine to do the work normal office hours?
... for me it will be fine to have a telcon at the time we usually have
... just to start off

DS: I'm not fussed either way

ED: Try to be available on IRC and try to be available for a small telcon will be good
... I pretty much know what I need to do anyway
... I thought I'd move some of the tests from the old errata location
... to the test suite
... we have some tests there that cover some things that are not tested at the moment
... we need to do some more reviewing of tests
... and make sure the Java binding appendix goes in

AG: Do we want the svgweb version to be available as a local version only or as a web version or both?

ED: It would be convenient to have the svgweb version as an online reference
... if you have time you can do both

Rendering Order and Z-Index proposal

ED: I guess we could discuss it but Chris and JWatt are not here

DS: I saw JWatt's proposal
... and it seemed reasonable
... I'm not totally convinced it covers all the use cases we have
... Andrew's doesn't seem like it has effective preventions for abuse
... JWatt's provide a consistent method for resolving complicated cases
... I think that if we do this
... we should caution people to use this sparingly
... and talk about cases with hit testing

ED: cases I've seen this pop up is pseudo 3D

DS: We should also think of this in the context of 3D Transforms
... we should look at tightly integrating this with 3D Transforms
... I personally like the idea that z-index would be the name of the property
... I think people who are using z-index from HTML and CSS will know what they are looking for

ED: Being able to move elements in the tree
... without taking them out of the tree
... is useful
... it gives you z-index type benefits for some operations

DS: I think it's orthogonal, both are useful

ED: It doesn't complicate the rendering model
... but I guess people want z-index anyway

DS: It only works when using scripting
... this sounds like something for DOM 4, like what happens when you move an element - do you reload it
... I think the best thing to do is move forward on z-index with the CSS
... this is something to think about this for 3D Transforms anyway
... when you are structuring documents specifying things in z-index can be very useful
... we should stay what happens in the default case that when a transform z puts something behind something else

ED: The proposal from JWatt is that being put into spec text?

JW: Would it be better to put it into something
... instead of it's own stand alone document
... seems a bit weird to have a single property in it's own document

DS: Let's say that we have this single property defined if an implementer wanted to do SVG 1.1 + this
... that would permit them to do so
... they could say we implement SVG 1.1 and this

JW: What's the difference to them taking it out of a spec
... and saying they just do that
... feature?

DS: People will want very clear conformance criteria to say they support a particular spec

JW: As an implementer I can see the bits and I put it together
... but as an author it's difficult
... having picking and choosing things can make things worse
... for example people might just implement it because it's part of spec

DS: What about putting it into 3D Transforms?

JW: Well I'm not opposed to having it as separate spec or putting it somewhere
... I just don't see how it's going to be easier to comment on

DS: The more I think about it I think it belongs in compositing

ED: Because it affects the rendering model
... it should go into render concepts

DS: Certainly that's where it should go in 2.0

AG: [rambles on about defining a rendering model spec to bring all the work together]

ED: Do we want to start the rendering concepts spec right away
... or do we need to something first?

DS: I think that is a very useful level
... start with the rendering model from 1.2
... reconcile that with 1.1
... put in rendering index

RESOLUTION: We will start writing a rendering concepts specification detailing the rendering model

<scribe> ACTION: Jonathan to Begin authoring the rendering concepts specification [recorded in http://www.w3.org/2009/10/28-svg-minutes.html#action02]

<trackbot> Created ACTION-2688 - Begin authoring the rendering concepts specification [on Jonathan Watt - due 2009-11-04].

list collection

DS: right now you create a list collection and you put it into the newest collection

JW: I sent two replies to that
... did you see them?

DS: I only saw one of them

ED: Forgot to CC Doug
... I would like this feedback to go to the public list

JW: We plan to implement what the spec says
... probably do it at the same time we do animation for lists
... code needs to be rewritten for animaiton

ED: Doing live objects and removal of objects from previous lists
... there's no extra costs
... you do one you get the other one free

JW: My opinion you do it live
... you take one matrix from one list and put it into another list then you have two elements using the same matrix
... you have to tell both elements when one changes
... so if using hundreds of elements this can be a performance hit

DS: Seems like you guys both agreed that it's better to do it this way

CSS pseudo classes for <a>

DS: Do you guys agree that CSS pseudo classes should be supported in SVG?
... even if they aren't

ED: They are in Opera
... and in FireFox too

JW: Just consistency in the web platform

ED: It's a bug if it doesn't work

- DRAFT -

SVG Working Group Teleconference

28 Oct 2009

Attendees

Contents

Telcon Times

SVG Full 1.1 Marathon

Rendering Order and Z-Index proposal

list collection

CSS pseudo classes for <a>

Summary of Action Items

Scribe.perl diagnostic output