W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2010

CSS-SVG Task Force Teleconference25 Oct 2010 Agenda

From: Patrick Dengler <patd@microsoft.com>
Date: Mon, 25 Oct 2010 22:45:46 +0000
To: "public-fx@w3.org" <public-fx@w3.org>
Message-ID: <4A2DB3AE4504E944AF122BBFBA7FBA1F54D6DA82@TK5EX14MBXC114.redmond.corp.microsoft.com>
http://www.w3.org/2010/10/25-fx-minutes.html


- DRAFT -CSS-SVG Task Force Teleconference25 Oct 2010 Agenda
See also: IRC log
AttendeesPresentheycam, smfr, anthony, ed, pdengler, plinss, TabAtkins_, adrianba, CLRegretsChairSV_MEETING_CHAIRScribepdenglerContents•Topics1.TPC Meeting
2.Transforms and getCoordsAt
3.What is the status of animations and transitions

•Summary of Action Items

--------------------------------------------------------------------------------


<trackbot> Date: 25 October 2010
<TabAtkins_> Oh wait, 2pm
<smfr> TabAtkins_: ? it's now!
<TabAtkins_> Dang timezone math!
<scribe> scribeNick: pdengler
TPC Meeting<ed> http://lists.w3.org/Archives/Public/public-fx/2010OctDec/0017.html

ed: Chris was noting Thursday afternoon was bets for both WG
smfr: I won't be able to meet at TPAC but I would like to call in
pdengler: meta question: who from CSS is in this task force?
TabAtkins: simon and tab
pdengler: I talked to Sylvain who had said he hand't heard anything from CSS SVG Task force
TabAtkins_: We should do more to communicate back to the CSS task foce
ed: How do we communicate back?
smfr: communicate back to the CSS working group via actions
ed: sounds like a good idea
pdengler: I looked at the latest version and it looked as though we were getting back to the CSS team
shepazu: Why do we have two
ChrisL: Thought we decided to move this to the CVS of the task force and merge them
shepazu: That was my impression as well
ChrisL: Does that mean that the CSS has continued to evolve?
smfr: There have been some minor changes to the 2d trasnforms spec
... The 3d spec hasn't been worked on recenlty
ChrisL: There needs to be one spec for both SVG and CSS
... Both have been working on similar concepts in the past, but there should only be one of these
anthony: That was my impression as well which is why we added simon and dean
ed: This is the view of the CSS working group as well?
smfr: Make sure that the CSS working group includes this in the list of CSS working gruop is invovled in
ChrisL: There is a list of CSS specs. We should update the link to the one we are working on
<smfr> the FX spec would need to be linked from here: http://www.w3.org/Style/CSS/current-work

pdengler: I just need to make sure the CSS working group in on the same page
... Will that apply to filters?
TabAtkins_: Yes
ed: I do have an existing action on the task force to commit the SVG Filters spec and how to deal with CSS box moels and such
adrianba: If specification moves into a joint CVS repository, where does the recommendation get published?
... From a patent policy is for both groups?
<smfr> hard to hear ChrisL
ChrisL: The editors draft is published under both.It is covered under the same patent policy and this is allowed by W3C to form task force
shepazu: To clarify, it will be a safe spec from the IP perspective
ed: there is a filters spec for 2.0
<smfr> minutes are fine
<Zakim> adrianba, you wanted to ask about where the Rec will be published
shepazu: CSS/SVG Transforms should include both
ed: Are there specific topic at TPAC we want to discuss
shepazu: Can we talk about transforms getCoordsAt first
pdengler: I want to discuss whether or not the working groups can focus on a few areas that add a lot of value
... e.g. Transforms (let's close?), transitions and animations (?) how do they apply to just transforms
... and filters
... What is a realistic timeline for a spec to get to last call
shepazu: If it is agreed, it's just about work
ChrisL: Safarai has an implementation that works in HTML
smfr: only works with CSS
ChrisL: do you see problems with applying it as a style for SVG
smfr: Not really
ChrisL: We then need 2 implemenation
shepazu: if there is only one implemenation then there are chances that will be interop problems
pdengler: but isn't this our position on writing test cases per assertion up front
ed: very helpul
shepazu: it's a matter of time and resources
ChrisL: If we have more than one implementer interested in this, then we can move forward more quickly
... Look at current fx draft, and current in CSS and do a merge
shepazu: We should merge those specs and get the point across that we have one spec
<scribe> ACTION: smfr to coordinate back to CSS working group our method for delivering CSS-Transforms Specification as a singluar specification and fix up links [recorded in http://www.w3.org/2010/10/25-fx-minutes.html#action01]
<trackbot> Created ACTION-19 - Coordinate back to CSS working group our method for delivering CSS-Transforms Specification as a singluar specification and fix up links [on Simon Fraser - due 2010-11-01].
Transforms and getCoordsAt<shepazu> http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0013.html

shepazu: We talked about this in the SVG workig group
<shepazu> http://jwatt.org/svg/tmp/mouse-relative-positioning.svg

shepazu: In getting mouse coords for a transformed object is a pain
... We want to have a method that tranlates to the two coordinate spaces
... This applies to CSS and SVG transforms
... This was suggested as an add to DOML3 spec
... But it was to add to CSS/SVG Trasnform specs
... This would be on the element interface, not the MouseEvent interface
... getCoordsAt on mouseEvent is not the proposal, but rather on the elmenet interfaces
smfr: We added a method on the Window interface called convert point to node.
shepazu: Having the two way translate is what is important
smfr: Agree that this is needed
... In 2d Transforms in CSS land we have a 2d matrix; in terms of the task force whether or not it aligns with 3D matrix
... Similarlity we are going to end up with SVGPoint, and whether or not that works in CSS
... We need to think about how other interfaces impact the Transforms interface
shepazu: We need to look at the SVG Methods; let's get them right, maintaining backward compat, but steering toward new methods
<smfr> oops
shepazu: I agree that you probably don't want SVGPoint, we want to make it simple
smfr: Perhaps webPoint webMatrix etc
<smfr> FXPoint@
anthony: That's what I have been worried about
<smfr> !
shepazu: perhaps we could consider DOM
... Bringing in resig and others to help might be a good idea
... This is a process.
<scribe> ACTION: smfr to create initial draft of unified interfaces including data types across SVG and CSS [recorded in http://www.w3.org/2010/10/25-fx-minutes.html#action02]
<trackbot> Created ACTION-20 - Create initial draft of unified interfaces including data types across SVG and CSS [on Simon Fraser - due 2010-11-01].
heycam: If we have a list, I would like to go through them.
<smfr> anthony: you sound like you're at the end of a long narrow pipe
anthony: I'll start sending stuff in email to get a list going
shepazu: Might not be a bad idea to blog about this as well to make it more acessible
... I will write a blog post about this sometime in November
ed: I had an items for the transform spec
<ed> http://lists.w3.org/Archives/Public/public-fx/2010OctDec/0019.html

ed: The transform property is noted as being applied to container elements and graphical elements
<scribe> ACTION: anthony to update spec to read 'transform property applies to any SVG element that uses transform attribute' [recorded in http://www.w3.org/2010/10/25-fx-minutes.html#action03]
<trackbot> Created ACTION-21 - Update spec to read 'transform property applies to any SVG element that uses transform attribute' [on Anthony Grasso - due 2010-11-01].
http://dev.w3.org/Graphics-FX/modules/2D-transforms/spec/2DTransforms.html

<ed> pdengler: there are no svg examples using style="transform: ..."
<ed> ed: yeah, there should be some svg examples
pdengler: CSS: div {transform: rotate(45deg);}
CSS: rect {transform: rotate(45deg);}
ed: Topic: Telecon times
... Daylight savings time switch
anthony: Does that mean that these will be an hour later?
ed: Keep time as is for now
<smfr> fine by me
heycam: THis time is good for m
What is the status of animations and transitionsed: Those modules are in CSS CVS correct
smfr: They are there, they are both working draft.
... Transitions we have 3 implementations
... Animations we have one implementation
pdengler: Do we think they belong in the task force
... I think of CSS animations and transitions animating "stuff"
smfr: The tricky part is if you do both
ChrisL: SMIL animation already has the concept of animating a attribute vs property
pdengler: I think its a difficult proposition to have 2 animation engines colliding
... I woudl preserve SMIL for SVG in XML and move fowrad with CSS transitions and animations for SVG in HTML5, and let those specs live in CSS
Summary of Action Items[NEW] ACTION: anthony to update spec to read 'transform property applies to any SVG element that uses transform attribute' [recorded in http://www.w3.org/2010/10/25-fx-minutes.html#action03]
[NEW] ACTION: smfr to coordinate back to CSS working group our method for delivering CSS-Transforms Specification as a singluar specification and fix up links [recorded in http://www.w3.org/2010/10/25-fx-minutes.html#action01]
[NEW] ACTION: smfr to create initial draft of unified interfaces including data types across SVG and CSS [recorded in http://www.w3.org/2010/10/25-fx-minutes.html#action02]
[
Received on Monday, 25 October 2010 22:46:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 25 October 2010 22:46:29 GMT