- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 06 Dec 2013 08:44:42 +1100
- To: "www-svg@w3.org" <www-svg@w3.org>
Minutes from this week's SVG telcon are below.
http://www.w3.org/2013/12/05-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
05 Dec 2013
[2]Agenda
[2] http://www.w3.org/Graphics/SVG/WG/wiki/Agenda
See also: [3]IRC log
[3] http://www.w3.org/2013/12/05-svg-irc
Attendees
Present
krit, laudrain, cabanier, Thomas_Smailus, [IPcaller],
heycam, birtles_, Rich_Schwerdtfeger, stakagi, nikos,
ed, Tav, Doug_Schepers
Regrets
Chair
Cameron
Scribe
Cameron, Rik
Contents
* [4]Topics
1. [5]telecon time
2. [6]moving Blending and Compositing to CR
3. [7]Latest SVG DOM proposals and possible problems
* [8]Summary of Action Items
__________________________________________________________
<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: [9]http://dev.w3.org/fxtf/compositing-1/
[9] 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:
[10]http://www.w3.org/2005/10/Process-20051014/tr#cfi
[10] 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>
[11]http://mire.github.io/css-blending-test-plan-proposal/css-b
lending-test-plan-proposal.html
[11]
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> [12]http://www.w3.org/TR/css3-images/
[12] http://www.w3.org/TR/css3-images/
<nikos> [13]http://www.w3.org/TR/css3-fonts/#cr-exit-criteria
[13] http://www.w3.org/TR/css3-fonts/#cr-exit-criteria
<krit> [14]http://www.w3.org/TR/css3-images/#exit
[14] http://www.w3.org/TR/css3-images/#exit
[15]http://www.w3.org/TR/css3-images/#cr-exit-criteria
[15] 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
[16]http://commoncrawl.org/ )
[16] 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
Summary of Action Items
[End of minutes]
__________________________________________________________
Received on Thursday, 5 December 2013 21:45:56 UTC