See also: IRC log
<trackbot> Date: 05 December 2013
<birtles_> Zakim: [ is me
<cabanier> scribenick: cabanier
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
<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
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:[End of scribe.perl diagnostic output]