W3C home > Mailing lists > Public > www-svg@w3.org > December 2013

minutes, 5 December 2013 SVG WG telcon

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 06 Dec 2013 08:44:42 +1100
Message-ID: <52A0F3CA.7070202@mcc.id.au>
To: "www-svg@w3.org" <www-svg@w3.org>
Minutes from this week's SVG telcon are below.



       [1] http://www.w3.org/

                                - DRAFT -

                     SVG Working Group Teleconference

05 Dec 2013


       [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


           krit, laudrain, cabanier, Thomas_Smailus, [IPcaller],
           heycam, birtles_, Rich_Schwerdtfeger, stakagi, nikos,
           ed, Tav, Doug_Schepers


           Cameron, Rik


      * [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
    ... ... 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

    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

    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: 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

    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

    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

    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
    ... 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
    ... 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
    ... 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

    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

    <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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:48 UTC