W3C home > Mailing lists > Public > public-svg-wg@w3.org > July to September 2014

Minutes, 14 August 2014 SVG telcon

From: Erik Dahlström <ed@opera.com>
Date: Thu, 14 Aug 2014 15:53:14 +0200
To: "www-svg@w3.org" <www-svg@w3.org>
Message-ID: <op.xkk4u0vzdhsuf5@gnorps>
Minutes:


     http://www.w3.org/2014/08/14-svg-minutes.html


and as text:

    [1]W3C

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

                                - DRAFT -

                     SVG Working Group Teleconference

14 Aug 2014

    [2]Agenda

       [2]  
http://lists.w3.org/Archives/Public/public-svg-wg/2014JulSep/0035.html

    See also: [3]IRC log

       [3] http://www.w3.org/2014/08/14-svg-irc

Attendees

    Present
           birtles, ed, heycam, krit, nikos_, Doug_Schepers

    Regrets
    Chair
           ed

    Scribe
           Nikos

Contents

      * [4]Topics
          1. [5]New W3C Process document
          2. [6]Accessibility TF
          3. [7]New W3C Process document (continued)
          4. [8]Polyfill for new SVG DOM proposal
          5. [9]Using units and percentages with path
      * [10]Summary of Action Items
      __________________________________________________________

    <trackbot> Date: 14 August 2014

New W3C Process document

    <scribe> Scribe: Nikos

    <scribe> scribenick: nikos_

    <heycam> [11]http://www.w3.org/2014/Process-20140801/

      [11] http://www.w3.org/2014/Process-20140801/

    heycam: I forwarded an email about the new process which came
    into effect last week
    ... most visible change is in merging LC and CR
    ... that change has been discussed before - it's gone ahead now
    ... so that point is now when there is wider review of spec and
    when we ask for implementations

    <heycam>
    [12]http://lists.w3.org/Archives/Public/spec-prod/2014JulSep/00
    57.html

      [12]  
http://lists.w3.org/Archives/Public/spec-prod/2014JulSep/0057.html

    heycam: here is another mail that has links to summaries of the
    changes
    ... also points out importantly that we have the option of
    publishing new versions of existing documents under this
    process if we want to
    ... for the next 2 years
    ... we can continue to publish works in progress under the old
    process if we want during that time
    ... it shouldn't affect us too much

    krit: I'd suggest we use the new proces s with new publications
    that we plan

    shepazu: to me, it's a a slightly more realistic process doc.
    CR was a period of time when you had to wait a month before
    going on - at least
    ... so people were sitting around in CR waiting for the time
    period to finish or they skipped CR
    ... now we skip a period of bureaucracy, so things should
    happen faster

    krit: on that note, CSS Masking has been CR for 1.5 months and
    is still not published
    ... Chris is taking care of it, but because of publication
    moratoriums, etc it hasn't happened yet

    shepazu: I wasn't aware of that
    ... Could you send me the details and I'll try to care care of
    it?
    ... although I'm not staff contact

    krit: to come back to the process, I think there's no objection
    here

    shepazu: one other thing
    ... with accessibility TF

Accessibility TF

    shepazu: there was a contradiction in the work statement

    <shepazu>
    [13]http://www.w3.org/WAI/PF/svg-a11y-tf/work-statement

      [13] http://www.w3.org/WAI/PF/svg-a11y-tf/work-statement

    <shepazu>

    shepazu: in one place it says the SVG 2 to accessibility
    mapping guide will be considered a publication of the PFWG
    ... then down below it says the following documents are managed
    jointly, and that doc is included there
    ... so unlike FX the work statement says it's joint work but
    it's only published by PF
    ... we pushed back on that
    ... I want to confirm that we want jointly published
    deliverables?

    heycam: I think that's the conclusion we came to last time we
    discussed this

    shepazu: anyone disagree with joint publication?

    <silence>

    RESOLUTION: Joint deliverables from task forces shall be
    published by both working groups

New W3C Process document (continued)

    ed: do we need resolution regarding which process we publish
    under?

    RESOLUTION: New documents, including new revisions of working
    drafts, will be published under the new W3C publication process

Polyfill for new SVG DOM proposal

    heycam: last time we discussed the new DOM stuff was in Germany
    ... the result was that a couple of people were still unsure
    ... the idea of a polyfill was raised
    ... to let us try the new API
    ... to help bring us to a conclusion

    <heycam>
    [14]http://lists.w3.org/Archives/Public/www-svg/2014Aug/0008.ht
    ml

      [14] http://lists.w3.org/Archives/Public/www-svg/2014Aug/0008.html

    heycam: I've sent this mail linking to the polyfill
    ... it's a javascript file
    ... which runs in FF only
    ... because it uses features which aren't available everywhere
    yet
    ... but doesn't matter as it's only intended for us and others
    interested in design of the dom

    <heycam> [15]http://heycam.github.io/new-svg-dom/examples/

      [15] http://heycam.github.io/new-svg-dom/examples/

    heycam: not for general public to use
    ... here's some examples
    ... if you are running FF nightly with web components enabled
    in about:config
    ... then those should work
    ... please try examples and look at source
    ... I've pointed out the different approaches in the examples
    ... and we'll have a broader discussion at the F2F
    ... we can play with it live during the F2F to get a feel for
    it
    ... I just wanted to draw your attention

    krit: I've heard it mentioned that it might be better to use
    properties instead of getters and setters
    ... having something that returns pixel in all cases would be
    great

    shepazu: do you use chaining?

    heycam: I haven't introduced a big suite of new methods for
    constructing methods or anything like that
    ... the one situation where I could have added chaining was a
    method to set list of points for a js array
    ... or a list of path segments
    ... they could return the same object back again
    ... if that's a pattern thats becoming popular I don't mind
    that

    krit: one example is that we should not have element.getBBox()
    ... but a bbox property

    <general agreement>

    krit: that's just some general feedback I got, not necessarily
    my opinion

    <birtles> were we going to try and get input from Hixie before
    the F2F? or was that more related to mixing SVG and HTML
    elements?

    heycam: at last discussion from Germany, the sticking point
    wasn't the details
    ... but the broad question of whether we should do this at all
    ... so I'd like to solve the question of whether we go ahead
    ... I haven't gotten input from hixie or anyone else yet
    ... I think the proposal needs some changes - we probably need
    others agreements regarding ns changes
    ... maybe not important to get that feedback before we decided
    whether to push forward or not
    ... if we do go forward then I'll correspond
    ... if there are specific parts that I haven't implemented yet,
    but you'd like me to implement or you'd like specific examples,
    then let me know

    krit: was transforms part of the proposal?

    heycam: yes, but I haven't done an example for that
    ... I have implemented the thing where you have a get and set
    method to return an array of dictionary like things
    ... that have type and arguments from the objects
    ... instead of SVG transform list stuff
    ... I can make an example if you'd like

    krit: yeh sure

    ed: in the proposal do we have support for making your own
    objects and dictionaries and passing them into the SVG DOM?
    ... does that work or do you have to create custom SVG point or
    whatever?

    heycam: I haven't looked at that part of it
    ... the original proposal didn't look at those methods
    ... that take SVGPoint or SVGMatrix
    ... so polyfill doesn't look at that yet
    ... we should look at that in the context of the geometry spec
    ... for the get and set method for points attribute on polygon
    and polyline, they take an array of dictionary like objects

    krit: for length values
    ... did you spend time to look if it could be implemented more
    efficiently than with get and set attributes?

    heycam: I didn't look, but for us, assigning to an object with
    a type string should be the same as calling a method

Using units and percentages with path

    shepazu: is there a good reason not to do this?

    heycam: it would cause problems for the SVG DOM methods
    ... the reasons for not doing it are not very good though

    ed: this could be implemented as a polyfill maybe?

    shepazu: yes

    krit: for relative segments, what does percentage mean?
    ... percentage of viewport?

    shepazu: that's something we'd have to resolve

    ed: the polyfill would let us identify questions like this

    shepazu: do people think this would be a good idea?

    krit: we discussed in Switzerland and decided it would be a
    good idea
    ... to have these units for path segments would be interesting
    ... I think there's some problems to solve, but in general I
    think this would be a good move

    shepazu: from an editor point of view, an SVG loaded that used
    this stuff would not work

    krit: if you assume we don't update our products
    ... the question is more how can tools make use during export
    rather than import
    ... that's tricky
    ... path segment is intuitive when hand editing, but not with
    tools
    ... tools tend to just export with basic path commands

    shepazu: a lot of content comes from script now

    heycam: what do you think about digging up the minutes and
    rehashing at the next F2F?

    shepazu: I can do that

    <scribe> ACTION: Doug to summarise what was discussed at
    Switzerland F2F regarding units and percentage values in path
    commands [recorded in
    [16]http://www.w3.org/2014/08/14-svg-minutes.html#action01]

    <trackbot> Created ACTION-3637 - Summarise what was discussed
    at switzerland f2f regarding units and percentage values in
    path commands [on Doug Schepers - due 2014-08-21].

    <ed> trackbot, end telcon

Summary of Action Items

    [NEW] ACTION: Doug to summarise what was discussed at
    Switzerland F2F regarding units and percentage values in path
    commands [recorded in
    [17]http://www.w3.org/2014/08/14-svg-minutes.html#action01]

    [End of minutes]
      __________________________________________________________


     Minutes formatted by David Booth's [18]scribe.perl version
     1.138 ([19]CVS log)
     $Date: 2014-08-14 13:49:18 $
      __________________________________________________________

      [18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [19] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11
Check for newer version at [20]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/

      [20] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/stufff/stuff/
Found Scribe: Nikos
Found ScribeNick: nikos_
Default Present: birtles, ed, heycam, krit, nikos_, Doug_Schepers
Present: birtles ed heycam krit nikos_ Doug_Schepers
Agenda: [21]http://lists.w3.org/Archives/Public/public-svg-wg/2014JulSep
/0035.html
Found Date: 14 Aug 2014
Guessing minutes URL: [22]http://www.w3.org/2014/08/14-svg-minutes.html
People with action items: doug

      [21]  
http://lists.w3.org/Archives/Public/public-svg-wg/2014JulSep/0035.html
      [22] http://www.w3.org/2014/08/14-svg-minutes.html


    [End of [23]scribe.perl diagnostic output]

      [23] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm


-- 
Erik Dahlstrom, Web Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Received on Thursday, 14 August 2014 13:53:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:19 UTC