<trackbot> Date: 05 December 2013

<birtles_> Zakim: [ is me

<cabanier> scribenick: cabanier

telecon time

heycam: at the f2f, we discussed this to move it to the other end of the day
... to make it easier for europeans
... ... I sent out a survey but I
... ... am unsure what to do now
... ...tav can do one hour later but it wouldn't work for Rich

richardschwerdtfeger: I could show up 1 hour later if needed

krit: I'm happy with the current time

heycam: it's not great for Brian

krit: Chris can do it before 10pm

heycam: so he could attend 30min with the current time
... ... other meetings have a different time every second meeting
... ... should we consider that

Tav: I think we should keep it until the end of winter

birtles: it's OK for me. Takagi is on the phone too

krit: I would be fine to switch a couple of times a year. doing it more often is too error prone

richardschwerdtfeger: people will dial in at the wrong time

heycam: I would like to hear from Doug, Chris and Cyril
... ... we'll leave it at the current time

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

moving Blending and Compositing to CR

<cabanier> spec: http://dev.w3.org/fxtf/compositing-1/

cabanier: the spec has been in LC for 6 weeks
... and we had a 4 week comment period
... haven't heard anything since then, so I think it should be ready to move to CR
... I'm asking here in the SVG WG, and next week I'll ask in CSS

krit: I have a comment on some changes I see
... first, do you have a Changes section?
... since the first LC?

cabanier: I added isolation to the at-risk list

krit: I think that's something we can't do?

cabanier: no, that's according to the process
... going to CR you list the at risk issues

krit: don't you have to do that before LC?

cabanier: no it's part of going to CR
... I sent an email a couple of days ago

<cabanier> link: http://www.w3.org/2005/10/Process-20051014/tr#cfi

krit: in the Changes section, you have four items
... you may want to update that list

cabanier: I'll update it
... if you look at the link I pasted...
... [reads out some process text]

heycam: I think Rik is right

krit: were there any changes since the last call?

cabanier: no

krit: you could mention that in the Changes section

cabanier: I'll update it

heycam: no open issues on the spec?

cabanier: all resolved at LC
... only reason isolation is on the at risk list, is that we have only one implementation so far
... but I'm confident we'll have another one by the time we exit CR

krit: the W3C logo at the top of the spec is missing
... perhaps Chris will fix it when you go to publish
... anyway, I am fine with publishing CR

cabanier: any objections?

<ed> minor thing that would be nice to have, a link to the editor's draft at the top

heycam: what's the plan for a test suite?

cabanier: someone from our team is working on a team right now
... she has more than 100 tests at the moment
... some people at TtwF also wrote some tests
... also Blink/Firefox/WebKit implementors writing some tests
... we have a test plan

Tav: does that include SVG tests?

cabanier: yes, as well as HTML tests

<krit> http://mire.github.io/css-blending-test-plan-proposal/css-blending-test-plan-proposal.html

krit: we're creating tests according to that plan

cabanier: and the W3C GitHub people have made some progress on tests too

heycam: do you have CR Exit Criteria listed in the spec?

<krit> http://www.w3.org/TR/css3-images/

<nikos> http://www.w3.org/TR/css3-fonts/#cr-exit-criteria

<krit> http://www.w3.org/TR/css3-images/#exit

http://www.w3.org/TR/css3-images/#cr-exit-criteria

heycam: I suggest just copying one of the CSS specs' CR Exit Criteria sections

<ThomasSmailus> can hear you fine

krit: you shouldn't, because it will get added automatically

RESOLUTION: We will publish Compositing and Blending as CR.

Tav: what's the plan for having all the blending modes into Filters?

cabanier: the missing ones?

krit: we discussed this at the F2F
... we resolved not to add them in the first level, but to add them in the next level

cabanier: and the Compositing modes are all there already
... there are four of them, and by combining them you can do src-in, dest-in, etc.
... except for 'clear', but you can accomplish that in other ways

krit: but yes the blend modes are missing, and will be added in the next level

Tav: I have them already implemented in Inkscape

cabanier: if people want to implement them, they can...

krit: I'd like to ask at the beginning of next year to start the next level of this spec
... while we're still working on this first level

Tav: yes it'd be good to have the second level spec started

nikos: same with Compositing and Blending 2

Tav: what's going to be in there?

nikos: Compositing for SVG and HTML

heycam: compositing for elements

RESOLUTION: We will begin working on a Level 2 of Compositing and Blending.

<scribe> Scribe: Rik

<scribe> ScribeNick: cabanier

Latest SVG DOM proposals and possible problems

krit: I would like to ask Brian
... I was updating the proposal to always use the HTML namespaece
... but Brian brought up that some libraries use the SVG namespace and this would cause a problem

heycam: if there are script that check that, then yes the behavior would change

krit: we found one with xref or xlink:href but since we already resolved on that, it would not be an issue

heycam: is there a library that does that?

birtles: jquery SVG does this
... it uses the namespace to tell if there's SVG in the document
... were you proposing a change to Cameron's proposal?

krit: I was changing it slightly so we don't have to duplicate all the elements

birtles: if we were to make SVG elements return in an HTML namespace... (?)

krit: I'm planning on making that change in blink and webkit

<birtles_> the example here is script that tests for elem.namespaceURI == SVGNS then sets className.baseVal or className appropriately

krit: we want to duplicate the classname and stylename from SVG into HTML to make it compatible

heycam: ID as well

krit: I don't think so. That wouldn't work for WK

heycam: ah yes.
... the classname one works out well since my proposal turns it into a DOMString

krit: one was a list

<ed> .classList

heycam: it makes sense to drop them if we inherit from HTML Element which is my proposal
... so are you saying that we should inherit them?

krit: my proposal is that the new HTML elements still provide the old SVG DOM

heycam: can you explain again?

krit: in your proposal the new elements would not have the old DOM. but in my proposal would still expose the old DOM
... for example, the x attribute is a union that's a string or an animatedLength

heycam: one of the issue is what the initial value is
... for compatibility, it should be an animatedLength
... so it begins as an object
... and as soon as you assign a string, it becomes a value
... are you most concerned with the code duplication?

krit: yes. maintenance (2 implementations) and you could have mixtures of elements in different namespaces
... this mixture is very confusing for authors

heycam: it would be nice to not have both existing at once but it might not be feasible

<scribe> ... new APIs for instance, should only be available on the new API

shepazu: do you think that we need to incentivize people to move to the new model?
... I think the majority of the old content will stay as is
... for instance the content for the old SVG viewer was never updated
... they would only update it for business reasons
... so the incentive argument should not be part of the dialog

heycam: but I still think that we only need to implement new APIs on the new HTML elements

shepazu: the incentivizing time is so short, we should not consider it

heycam: that sounds reasonable
... do you think we should kill the old interfaces?

shepazu: I actually think we should just have a new model and not prioritize backwards compatibility
... there is a lot of SVG content but most is static

krit: no
... it's mainly dynamic. d3, snap, raphael which are dynamic
... which is the majority on the web

shepazu: those libraries can change

krit: I looked and snap and raphael don't use the DOM

shepazu: I think the amount SVG that is dynamic, is very small
... if we change it, the documentation would become invalid
... there are such quirky things in the DOM that they are not used

krit: the problem is not the script libraries but that authors don't update their versions

shepazu: I don't think it realistic to say that browser will take out SVG when we ship SVG 2
... they will probably phase it out
... we should plan that, but not specify it

Thomas: what is dynamic SVG?

shepazu: it's SVG that uses script

ThomasSmailus: at Boeing we're switching over to SVG and for us it is critical that things don't change around
... if it changes soon, we can probably adjust

shepazu: most dynamic script would probably not be affected
... creating elements for instance, we have to be very careful with namespace
... changing attributes (createElement, setAttribute) would not be affected

heycam: old the core DOM methods will stay the same
... the question is how much of the SVG specific API that you are using. It would be good to know if you're using those

ThomasSmailus: we're still at a stage where we can adjust. It probably won't affect us but there are probably large companies that are in the same boat as us

<krit> Checked: d3 uses baseVal for special transform calculations

<krit> no animVal

shepazu: yes. it might be useful if we say what things are going to change/drop

<ed> I'm curious re feature-detection libs, e.g if used for detecting svg 1.1 support, but only as a toggle for loading static svg content

Tav: and example of before and after

shepazu: yes. have an analogue of what things used to look like

<Luc> sorry, I have to quit

shepazu: why don't we just get rid of it?

heycam: how easily can we support the old stuff in the new way? My proposal keeps the old implementation alive

shepazu: having the old interface is a burden on implementations and developers
... I'm willing to be proven wrong. we are not like HTML where we have to support it
... since there's so little content
... maybe we can do a web search for these APIs

heycam: we discussed this during the F2f

krit: the blink team tried it but it failed. now they don't have time to do it.

<shepazu> (CommonCrawl: open repo for web crawl data http://commoncrawl.org/ )

heycam: I will reply on the mailing list and show how the new DOM will look like compared to the old one
... can you send out the minutes?

<heycam> cabanier, ok

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/xref/href/
Succeeded: s/should/should not/
Succeeded: s/???/Thomas/
Found ScribeNick: cabanier
Found Scribe: Cameron
Found ScribeNick: heycam
Found Scribe: Rik
Found ScribeNick: cabanier
Scribes: Cameron, Rik
ScribeNicks: cabanier, heycam
Default Present: krit, laudrain, cabanier, Thomas_Smailus, [IPcaller], heycam, birtles_, Rich_Schwerdtfeger, stakagi, nikos, ed, Tav, Doug_Schepers
Present: krit laudrain cabanier Thomas_Smailus [IPcaller] heycam birtles_ Rich_Schwerdtfeger stakagi nikos ed Tav Doug_Schepers
Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/Agenda
Found Date: 05 Dec 2013
Guessing minutes URL: http://www.w3.org/2013/12/05-svg-minutes.html
People with action items: