Minutes, SVG WG London F2F 2014 minutes, day 1



as text:


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

                                  - DRAFT -

                            SVG WG London F2F 2014

22 Aug 2014


         [2] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda

      See also: [3]IRC log

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


             Chris, Erik, Cameron, Doug, Nikos, Jet, Jonathan, Brian,
             Razvan, Dirk, Rossen, Rik, Tav


             birtles, Nikos


        * [4]Topics
            1. [5]Agenda review
            2. [6]The topic index
            3. [7]Putting SVG 2 spec on GitHub
            4. [8]marker, symbol: refX and refY shorthand anchor
               points: 'top left' 'center center', etc.
            5. [9]variable stroke width
            6. [10]New SVG DOM
        * [11]Summary of Action Items

Agenda review

      <birtles> scribenick: birtles

      <scribe> scribe: birtles

      ed: one suggestion was to split up the spec editing over all
      the days
      ... e.g. one hour per day for editing instead of a full day

      shepazu: just a suggestion, e.g. 4-5pm

      heycam: maybe not the end of the day
      ... just after/before lunch?

      shepazu: after lunch is fine

      (shuffling of PM agenda to put spec editing after lunch)

      ed: any other topics missing from agenda?

      krit: I'd like to give a progress report about CSS layout
      ... and discuss fill/stroke properties
      ... any day other than today is fine

      Tav: I'd like to get some review on my talk for the conference
      if there's time at the end

      (conference = graphical web conference)

      ed: no one calling in?

      heycam: I don't think so

The topic index


        [12] https://www.w3.org/Graphics/SVG/WG/wiki/Topics

      heycam: one problem we seem to have is that we easily lose
      track of previous discussion about topics
      ... we type up our minutes, send them to the ml, tracker picks
      up issues/actions but apart from that there's no
      indexing/tracking of topics
      ... often you want to find out the latest on an issue and you
      have to trawl through the ml
      ... so I wrote a couple of scripts to manage links to
      discussions on particular topics
      ... they harvest mails sent to the mailing list
      ... the above link, links to pages from telcon minutes etc.


        [13] https://www.w3.org/Graphics/SVG/WG/wiki/Topic_database

      heycam: if you follow the first link ^
      ... that's where it's getting its information from
      ... I've only added a couple of topic lists just to give you an
      idea of the kind of format

      <scribe> ... new ones will automatically get added as we send
      out more minutes to the list

      UNKNOWN_SPEAKER: it extracts out the names of topics and
      ... since tracker doesn't do that for us

      krit: are resolutions also tracked?

      heycam: they're automatically added but they're not
      automatically copied to the topic page

      shepazu: is this a tool that you can make available to other

      heycam: it's on my github but there may be some SVG-specific

      krit: so we have to use the same topic every time?

      heycam: that is a problem but you can go back and edit the
      topic names
      ... the new minutes will get added automatically and then
      myself or someone else will adjust the titles so they coalesce

      nikos: I've got a similar record on our wiki if you want to use
      that data for historical records

      heycam: I could also run the script on old mails
      ... hopefully that's useful
      ... let me know if you have problems/suggestions

      shepazu: w3c is looking now at exposing group/spec data through
      an API
      ... so this might be another tool
      ... we're finally abandoning the RDF structures we use
      ... it's quite likely that this information would be useful..
      to be able to drill down into topics that a WG discussed
      ... for example we manually maintain a list of our
      ... there's no way for us right now to get all our
      specifications and their statuses

      krit: what
      ... what's the problem with that?

      shepazu: it's not nicely maintained, e.g. what WG is producing
      what specs etc.
      ... which revision each spec is etc.
      ... if there's any data you feel you want from w3c then let us

      krit: resolutions are really important

      shepazu: I think this is good, and if it's in a wiki that good
      ... can we edit to add notes?

      heycam: it expects a precise format the moment but I can adjust

      shepazu: we use various bots
      ... I've never been very happy with the way we handle minutes
      ... it might be worth fixing those bots

      heycam: that's something I've often wanted to do, have links to
      etherpads etc.

      krit: can we add it to svgwg.org as well?

      heycam: yes, of course

      nikos: it might be good to highlight which telcons have

      heycam: I have this infrastructure to munch emails from the
      list now

Putting SVG 2 spec on GitHub

      heycam: so Dirk asked about this recently...

      krit: other WGs are experimenting with this
      ... HTML is one of them
      ... it's helping others to contribute to the specification
      ... some developers would be interested in submitting PRs for
      ... I think we could accept PRs under the W3C license

      heycam: I put the WebIDL spec on github and have accepted a few
      ... but it was a bit unclear if PRs from non-w3c members was ok

      krit: you could put a license on the repo

      (discussion about how hard it is/isn't to learn GitHub)

      heycam: one thing is that the mercurial repo does automatic
      building of the spec when you push changes
      ... would that work with github?

      ed: you can do that with git

      ChrisL: with git or github?

      ed: because we have our own server, we can use that

      (discussion about how we could set up automatic building with

      krit: the CSS testsuite runs some scripts on every push



      ed: using webhooks we can trigger actions from github

      heycam: if someone's willing to do the work for that I don't
      see a problem

      krit: I don't have the experience yet to do that

      ChrisL: who was pushing for that?

      heycam: I think Anne was looking to make some changes

      ChrisL: is he ok to pushes changes under W3C license?

      shepazu: it's not just about him, a lot of people are doing
      this and seeing good results

      ed: would we also push to the w3c mercurial repo?

      shepazu: I'd prefer to just push to the github

      (general agreement)

      jwatt: so we'd dump the w3c repo?

      shepazu: MikeSmith has some experience with doing this

      ChrisL: are we moving all the specs for this WG?

      shepazu: yes, I think so

      ed: on a related note, I noticed that web-platform-tests is on
      github and I suggest we drop the svg2-test repository and
      switch to web-platform-tests

      RESOLUTION: We will move SVG WG's specs from the W3C mercurial
      server to Github

      Tav: are we going to use github exclusively or if we still need
      our own server

      ed: we'll still need our own server to run the build scripts
      since we can't run arbitrary scripts on github

      jwatt: but as for the WG members, they'd just be using github

      Tav: and I'd still be able to build it locally

      ed: yes, sure

      Tav: so all the tools are included too

      <scribe> ACTION: Doug to talk to Mike Smith about migrating the
      SVG WG repository to Github [recorded in

      <trackbot> Created ACTION-3638 - Talk to mike smith about
      migrating the svg wg repository to github [on Doug Schepers -
      due 2014-08-29].

      ed: who's going to look at webhooks from github to get a ping
      when someone pushes
      ... so we can tell svgwg.org to rebuild the spec

      <scribe> ACTION: Dirk to actually perform the migration of SVG
      specs to Github in cooperation with Mike Smith [recorded in

      <trackbot> Created ACTION-3639 - Actually perform the migration
      of svg specs to github in cooperation with mike smith [on Dirk
      Schulze - due 2014-08-29].

      jwatt: we need to decide where it lives in github

      shepazu: Mike says he's happy to help and it all looks do-able

      <ed> [17]https://github.com/w3c/csswg-drafts

        [17] https://github.com/w3c/csswg-drafts

      ed: regarding tests, there's web-platform-tests

      <ed> [18]https://github.com/w3c/web-platform-tests

        [18] https://github.com/w3c/web-platform-tests

      ChrisL: regarding that, we previously decided we want to work
      with CSS WG's test infrastructure
      ... and their tools do lots of linking between specs
      ... but none of that's going to be on web-platform-tests

      <ed> there's also [19]https://github.com/w3c/csswg-test

        [19] https://github.com/w3c/csswg-test

      ChrisL: so we should choose wisely

      shepazu: the way that CSS has done things is idiosyncratic to
      the rest of the consortium
      ... I think we're probably better off aligning with the rest of
      the consortium
      ... I think there will be other tools built around

      heycam: the advantage of doing things in the CSS repository is
      that Peter Linss is very active, and works very hard to get
      things going right

      ChrisL: he is very active and we do do a lot of work together
      with the CSSWG

      heycam: it seems like the CSS tests are primarily reftests,
      where do their scripted tests run?

      ChrisL, krit: same repo

      krit: the JS tests can still have metadata

      birtles: the web-platform-tests can have a fair bit of metadata

      shepazu: from the perspective of web-platform org is that we're
      looking for something like icanuse.com
      ... MDN's equivalent is just a table that someone inputs
      ... but for webplatform.org we have scripts that do that
      automatically now
      ... caniuse is good but it's based on very few tests and we
      want to be more rigorous than that
      ... and have a clickable field where you can drill down to
      individual tests
      ... so you have a confidence score about how well a feature is

      ed: do we still want the svg2-tests repository or use one of
      the others?
      ... do we want a separate one?

      krit: shepherd doesn't care

      ChrisL: what you (shepazu) described about drilling down to
      individual tests sounds great
      ... but how far away is that

      shepazu: what we have now is a JSON structure that generates
      the tables
      ... so we can plug anything into those tables we want
      ... going from there to drilling down is probably a couple of
      weeks work
      ... it hasn't been a priority until now but it will be in the
      coming few months

      ChrisL: that's good for developers, but what about the WG who
      are looking for "how far are we from CR?" etc

      Tav: how can I put Inkscape's test results in?

      shepazu: I guess you would have to do it manually

      heycam: are you referring to the boxes in the CSS spec?

      krit: you'd have to ask Peter

      ChrisL: I think you'd have to fill in this data and pass a
      pointer... it's been asked before
      ... I think the answer is to mail Peter and ask

      shepazu: it sounds to me like people are leaning towards
      ... for webplatform.org we'd rather the data be all in one
      place and rather the CSS WG joined in what everyone else did

      krit: we can join these test repositories later
      ... i.e. go to CSS repo first and then merge to web platform

      birtles: can we go the other way?

      ChrisL: no

      Rozvan: what about tests which are only supported behind a
      ... we had this problem for crowdsourcing tests for CSS shapes
      ... users wouldn't know that they had to enable these flags so
      they'd report incorrect results

      shepazu: for webplatform.org we just want to get the results of
      tests (not create them or run them)

      birtles: I know we're doing some work to better integrate
      web-platform-tests into the Mozilla build system

      krit: we have that for the CSS repo as well

      heycam: we have some scripts for the CSS repo too

      shepazu: I'd like to avoid going to the mercurial of tests

      ed: what about user-submitted tests?
      ... do we want to decide a structure for that

      birtles: so TTWF normally submits tests to web-platform-tests?

      ed: yes

      ChrisL: but there are some tests in shepherd from TTWF

      heycam: at some point we need to convert our SVG 1.1 test suite
      to reftests etc. (i.e. automated tests)

      shepazu: that might be a good topic for TTWF

      (discussion about how to write reftests for things like paths)

      ed: another thing to consider about dropping svg2-tests is that
      it's not being pulled into blink's repo

      shepazu: at some point I'd like to add to the agenda discussion
      about using annotations in the SVG spec
      ... we should decide between the CSS test repo or

      heycam: I'd like to know if web-platform-tests supports


        [20] https://github.com/w3c/web-platform-tests/

      scribe: it would be good to use the structure from CSS for
      reftests and the boxes with test results

      shepazu: that's why I'd like to talk about annotations
      ... since we're planning on building that functionality
      ... if that kind of feature is useful, it will get added to

      ed: it doesn't seem like we're arriving at consensus over which
      repo to use

      ChrisL: I feel like I don't have enough information to decide

      Tav: I'd like to see a demonstration of both

      RESOLUTION: We will migrate tests from svg2-tests to either the
      CSS test repository or web-platform-tests (or both)

      (discussion about who to demonstrate the test repositories)

      (break 15mins)

      <heycam> ScribeNick: heycam

marker, symbol: refX and refY shorthand anchor points: 'top left'
'center center', etc.

      Tav: if you remember we decided to extend refX and refY to
      apply to symbols, like markers
      ... Andreas Neumann had requested that
      ... he's also now requested for us to consider adding
      shorthands: top, left, center
      ... because this is typically what people doing mapping stuff

      krit: center would be the bbox center?

      Tav: yes

      krit: do we support % on these attributes?

      Tav: don't know

      ed: they are length in SVG 1.1

      krit: which means it includes percentages
      ... what's it resolved against?

      ChrisL: so we could make left,center,right mean 0%,50%,100%
      ... that's the point of having a symbol rather than g, it has
      its own viewport

      krit: but no viewBox?

      ChrisL: yes

      Tav: right now it's the viewport that's being used

      krit: of the marker or the path?
      ... for refX and refY, is this % resolved against the viewport
      of the marker?

      Tav: yes
      ... I wasn't aware that % was already supported there

      <ChrisL> actually it does have a viewBox attribute

        [21] http://www.w3.org/TR/SVG/struct.html#SymbolElement

      heycam: if the %s mean what Andreas is requesting, then I would
      say just use the %s

      shepazu: this is what I wanted to roll these all up in one

      Tav: I was looking at that...
      ... these different elements differ enough in their uses that I
      think it would be hard?

      ChrisL: I think there is an advantage to having separate names
      for these things

      Tav: e.g. markers change depending on stroke-width, or not

      shepazu: that's sort of like a use? you can change some aspect
      of it, or not

      Tav: there's an attribute that controls whether it scales
      according to stroke width

      <ChrisL> advantage is you can optimise based on typical use eg
      caching patterns

      shepazu: if they haven't different behaviours, that's one
      thing, but if they have additional behaviours, I think we
      should try to do this
      ... consistency of the model, understandability
      ... bugs, etc. if you only have to do one different thing for
      this other use...

      Tav: I can try to find the work I did looking at this

      shepazu: maybe it doesn't make much sense for Inkscape but it
      does for the spec

      ChrisL: if we had a new DOM we could make all of these inherit
      from the one interface

      ed: your question is whether to allow the keywords?

      Tav: I didn't know percentages were already allowed

      ChrisL: so if we did support 'top left' it would be a shorthand
      for '0% 0%' etc.?

      Tav: it would be
      ... I'll ask what Andreas thinks about using the percentages

      ChrisL: one advantage to the shorthands is that CSS does that
      for thing like boxes, tiling of background images it has this
      center top syntax
      ... but it's just syntactic sugar
      ... the one thing to remember is to switch off the clipping
      ... otherwise you only get the first quadrant of your symbol
      ... don't understand why overflow isn't visible by default

      krit: so this is overflow: visible for symbol?

      shepazu: by default

      ChrisL: the only downside I can think of is if they have hidden
      things in the other quadrants
      ... I suggest we do that and have authoring guideliness to
      define symbol around (0,0) to make your life easier

      Tav: Andreas pointed out that in mapping you often have
      different anchor points
      ... a tower would be aligned to the center bottom, for example

      RESOLUTION: symbol will be overflow:visible by default by the
      UA style sheet in SVG 2

      <scribe> ACTION: Chris to add |symbol { overflow: visible; }|
      to the UA style sheet and add authoring suggestion to say to
      design symbols around (0,0) [recorded in

      <trackbot> Created ACTION-3640 - Add |symbol { overflow:
      visible; }| to the ua style sheet and add authoring suggestion
      to say to design symbols around (0,0) [on Chris Lilley - due

      ed: what about the keywords?
      ... transform-origin has these

      Tav: that's where I got the names frmo
      ... it might be useful if that's how it's done in CSS already

      ed: I think it's fine to add that

      heycam: I would prefer not adding the keywords

      ed: do you see refX/refY becoming presentation attribtues in
      the future?

      krit: to x and y maybe

      Tav: I don't think they need to be presentation attributes

      krit: I think for authors it's more important to have the basic
      shape geometry attribtues as properties

      nikos: I don't see any need to add the keywords; I think the
      meaning of the percentages are clear

      shepazu: no strong feeling

      krit: I don't think we should add the keywords

      Tav: ok I'll get back to Andreas with that

      <scribe> ACTION: Tav to get back to Andreas about refX/refY
      top/left/etc. [recorded in

      <trackbot> Created ACTION-3641 - Get back to andreas about
      refx/refy top/left/etc. [on Tavmjong Bah - due 2014-08-29].

      krit: for overflow:visible I thought we were talking about
      marker, not symbol

      ChrisL: I think we should do it for both

      ACTION-3640: Actually this should remove the existing UA style
      rule to set |overflow: hidden|

      <trackbot> Notes added to ACTION-3640 Add |symbol { overflow:
      visible; }| to the ua style sheet and add authoring suggestion
      to say to design symbols around (0,0).

      krit: did IE make overflow:visible by default on root <svg> of
      inline SVG?

      Rossen_: it made the most sense

      ed: it's what people would expect

      Rossen_: I'd expect it to be visible for foreignObject too

      ed: per spec that would be hidden since it's a
      viewport-establishing element


        [24] https://svgwg.org/svg2-draft/masking.html#OverflowProperty

      ed: so I would prefer to drop the last bullet point in that

      krit: I would worry about the inner SVG becoming
      ... otoh I'm surprised that inline root SVG is not breaking
      anything for IE

      ed: I think people are told to workaround it by putting
      ... the less special handling for overflow in SVG the better

      krit: that's a benefit, but I'm just noting that people are
      using inline SVG and I'm not sure if that new behaviour would
      be better
      ... maybe we can make this change and see implementation

      ed: pattern too?

      heycam: no I think that would break things

      <ed> The initial value for ‘overflow’ as defined in
      [CSS21-overflow] is 'visible', and this applies also to the
      rootmost ‘svg’ element; however, for child elements of an SVG
      document, SVG's user agent style sheet overrides this initial
      value and sets the ‘overflow’ property on elements that
      establish new viewports (e.g., ‘svg’ elements), ‘pattern’
      elements and ‘marker’ elements to the value hidden.

      <ed> (this is the last bulletpoint in the link I pasted above)

      ed: so pattern would remain
      ... but viewport establishing elements would all go to
      ... overflow doesn't apply to mask

      krit: mask default has this 10% margin region
      ... this has changed in the masking specification to be auto
      ... so it's effectively overflow:visible

      RESOLUTION: All viewport-establishing elements will be
      overflow:visible by default, except for root <svg> of SVG whole

      ACTION-3640: Plus more, check the minutes here.

      <trackbot> Notes added to ACTION-3640 Add |symbol { overflow:
      visible; }| to the ua style sheet and add authoring suggestion
      to say to design symbols around (0,0).

variable stroke width

      birtles: last time I put forward the proposals for syntax



      birtles: the next action coming out was to make a polyfill
      ... I did the part that does the parsing, but I didn't do the
      part which actually draws the stroke
      ... I don't have the time to do that
      ... so if anyone wants to see the feature progress, it needs
      your help to do that

      shepazu: I've done a lot of that stuff in the past

      ChrisL: did you try and it was complicated? or that's just
      where you stopped


        [26] https://rawgit.com/birtles/curvy/master/index.html

      birtles: I haven't updated the syntax for what we discussed in
      ... if you look at the wiki page, the property is now called
      ... but in the prototype here it's called stroke-widths
      ... so it's not up to date with the proposal

      shepazu: I see it supports inner and outer

      birtles: asymmetric stroke yes

      shepazu: how does it interpolate between the points?

      birtles: we were going to try different ways with the prototype

      ChrisL: would be a good option for Catmull-Rom
      ... the wikipedia page mentions a few different forms of
      Catmull-Rom, some of which are more well behaved than others
      ... i.e. doesn't produce cusps/loops

      Tav: inkscape has something similar implemented

      <scribe> ACTION: Tav to ask Inkscape vsw implementor to add
      Catmull-Rom interpolation to see what it's like [recorded in

      <trackbot> Created ACTION-3642 - Ask inkscape vsw implementor
      to add catmull-rom interpolation to see what it's like [on
      Tavmjong Bah - due 2014-08-29].

      cabanier: there's an Adobe guy who probably would be eager to
      help with the prototype

      <scribe> ACTION: Rik to ask the Adobe guy about working on the
      vsw prototype [recorded in

      <trackbot> Created ACTION-3643 - Ask the adobe guy about
      working on the vsw prototype [on Rik Cabanier - due

      Tav: we have cubic bezier, linear, and spiro as interpolations
      in Inkscape
      ... shouldn't be that hard to add Catmull-Rom
      ... I think this isn't the harder part of the problem
      ... joins are harder

      krit: dashes too

      [discussion about various corner cases]

      m_spline Centripetal Catmull–Rom spline


      <ed> [work on actions until 3.15pm]

      <nikos> trackbot, close ACTION-3599

      <trackbot> Closed ACTION-3599.

      <nikos> trackbot, close ACTION-3168

      <trackbot> Closed ACTION-3168.

      <nikos> trackbot, close ACTION-3170

      <trackbot> Closed ACTION-3170.

      trackbot, close ACTION-3634

      <trackbot> Closed ACTION-3634.

      <ChrisL> action-3640?

      <trackbot> action-3640 -- Chris Lilley to Add |symbol {
      overflow: visible; }| to the ua style sheet and add authoring
      suggestion to say to design symbols around (0,0) -- due
      2014-08-29 -- OPEN


        [30] http://www.w3.org/Graphics/SVG/WG/track/actions/3640

      <ChrisL> <svg><star><star><star><star><star><description>OMG
      its full of stars</description></svg>

      <ChrisL> s/star>/star\//g

      <nikos> Scribe: Nikos

      <scribe> scribenick: nikos


      heycam: last time we discussed the DOM stuff, the discussion
      ended on the point where a couple of people weren't sure about
      going ahead in this direction
      ... so we decided to write a polyfill for experimentation
      ... the polyfill only works in recent FF with a certain pref on
      ... relies on web components, shadow trees, mutation events,
      and some other features
      ... I'll take you through some of the examples that are in the
      ... graphics element causes the new DOM interfaces to be put on
      ... I realised that to avoid breaking the pages that use the
      old one, we need some syntactic way to opt into the new stuff
      ... the best way seemed to be to have a different element name
      for the root
      ... so that existing content gets the old interfaces
      ... and new elements can go in html namespace

      krit: does polyfill create elements in the html namespace?

      heycam: the root graphics element gets a shadow tree. The whole
      tree gets cloned in the shadow tree with updated names and
      cases and so on
      ... and it watches for updates
      ... there are limitations - events, etc

      ed: if you were to have nested graphics elements this wouldn't
      work right?

      heycam: no. inner things are called viewport and outer are

      ed: foreignObject?

      heycam: I didn't do it
      ... I rely on html parsing and these elements go in html
      namespace. there are some tricky bits that require parser
      ... if we had foreignObject it would probably be a good chance
      to use a different name

      birtles: we are going to look at using svg elements in html
      without foreignObject on Monday

      shepazu: rather than be a new element, couldn't the flag be svg
      element without the ns?

      heycam: you don't put the ns already in inline svg in html

      shepazu: the key is that things are going in the html ns

      heycam: yep

      heycam shows some demos

      heycam: there are some options for lengths. There are some
      modes you can set to try different options
      ... I'm not sure which would be best
      ... in terms of the namespace. Because we're in html ns. If I
      want to create a new rectangle I can just use
      ... certain things get a lot shorter - interaction with
      attributes, creation of element

      shepazu: why can't we expose these methods on existing svg

      heycam: the names are already taken
      ... currently if you're interacting with a rect you use
      rect.x.baseVal.value = 100
      ... if you wanted rect.x = 100, that would work
      ... but rect.x == 100 wouldn't work
      ... it doesn't know you want x to be a number
      ... I have an example showing the different ways of exposing
      svg lengths - moving-rects-0.html
      ... this is using the existing dom
      ... creates 10 rectangles, initially diagonally down the page
      at 0em, 1em, etc
      ... then does an animation where a random amount is added each
      ... most concise way to set is via setAttribute
      ... jittering rectangles around means you need .x.baseVal.value
      to get to a number
      ... same example using strings. Creating the object and setting
      initial values is more concise and more familiar for html
      ... doing the numeric stuff is a problem because you need to
      convert to numeric values
      ... this is a limitation of reflecting lengths only as strings

      ChrisL: could it be reflected multiple ways?

      birtles: you can't overload the getter but you can for the

      heycam: reflecting as strings is one option, but there are a
      few other options
      ... next example the properties on assignment can take number
      or string, but when you get them out you always get the user
      unit out

      ChrisL: so when getting values all numbers are converted to a
      canonical unit?

      heycam: yes
      ... this is nicer than string only, but you can't use .x to get
      the string value
      ... final way you could do it is to have parallel accessors
      ... e.g. rect.x_px

      ChrisL: I don't like that as much as .x.px

      shepazu: chaining is a common pattern, I don't know if it's
      only with methods or if it would also be useful for properties

      <ChrisL> no, I was unclear. I don't like either x.px or x_px;
      prefer just .x returning a number

      heycam: not really relevant for properties

      krit: I was talking with Dmitry. He doesn't like this kind of
      ... where you set with one value and getter returns a different
      value because it's in a different unit

      heycam: I think that's a valid point and might be reason to
      pick another proposal over this one
      ... might be an author expectation that returned value is the
      same as the set value

      krit: Dmitry suggested something like x.getPixel()

      shepazu: that's also magical

      ChrisL: problem with returning strings is you have to parse
      them or have utility functions for dealing with them
      ... I think there's something in css where you can assign but
      the returned value is a canonical type
      ... why can't it be the same here?

      krit: not the same in css
      ... internally css uses a canonical type

      ChrisL: I think it will align down the road with css

      heycam: depends if css goes down the road where you assign one
      type and get another out
      ... but they might not go in that direction
      ... whatever they do, it would be good to follow the same

      birtles: I thought the long term plan was to use value objects

      heycam: don't think it's going to happen soon

      birtles: I don't want us to paint ourselves into a corner where
      we can't align

      krit: I'm not sure if it's magic, as far as I read the proposal
      from Tab it's pretty straight forward

      heycam: I don't see that happening soon

      krit: could svg wg push that forward?
      ... I added new section in SVG 2 with x, y presentation
      attributes. We could start working on om for css
      ... I have a fear with any new OM. it's svg specific

      heycam: it's not svg specific in terms of the pattern of
      interacting with objects
      ... the pattern of exposing all properties as types appropriate
      to the property

      ChrisL: people like that sort of thing

      heycam: think there's a lot of antipathy wrt to getAttribute
      and setAttribute

      krit: I support the part of making everything in html namespace
      ... don't support new graphics element
      ... it took 12 years for svg to be adopted. Now they have to
      learn something new

      ChrisL: we can't break all the existing scripts

      krit: if we decide to use new dom we can't

      ChrisL: only way to move forward is to introduce a new element
      with the new dom
      ... so you're arguing for breaking all scripting in svg with
      new dom?

      krit: I'm arguing that we shouldn't introduce new dom because
      we won't do it right this time
      ... like last two times
      ... i prefer to follow pattern of new CSS OM
      ... rather than creating new SVG model
      ... implementations won't support elements in two namespaces
      ... it's duplication of maintenance effort

      heycam: I don't think it'll be too much work
      ... will just be an extra line in tables
      ... I think this DOM thing is actually rather small
      ... mostly it's accessor things
      ... which html elements already have code for reflection of
      ... if we have string or length then that's a bit different
      than html but it's not too much extra
      ... plus a couple of methods for dealing with list type things
      ... so total code to support new DOM is not that big

      krit: for webkit it would be a major change because svg
      animation uses old dom
      ... and needs to be mapped to new dom as well

      ChrisL: I see your point that we need to consider implementer
      ... if we allow opting in and promote the new dom
      ... in a few years we can drop the old method
      ... and break content that hasn't updated

      krit: my point is that supporting new svg dom in the meantime
      with long term plan to go to css om
      ... means three things we have to maintain at once

      ChrisL: css om is 5-10 years away

      krit: new svg dom will be same time frame before it is in
      mainstream use

      ChrisL: don't agree

      krit: in this case you said we'd break a lot of content with
      svg dom, but the adoption of the new dom will be lower than you

      ChrisL: I think as soon as this is implemented people will want
      to use it - it's simpler, probably more performant, etc
      ... everyone hates the existing dom
      ... number one thing people want is the dom fixed

      krit: we are seeing most content comes from tools or scripts
      ... people aren't using svg dom

      shepazu: possibly because it's so crap
      ... the performance hit for marshalling is bad, this might fix
      it right?

      heycam: for lists it should
      ... I can show an example - transform-changes-1.html
      ... graphics element, 3 shapes, each has an initial transform
      and we're doing some script animations
      ... instead of having svg transform list and all the items in
      the list
      ... we have getTransformItems() which returns an array of
      ... each item in the array is a plain javascript object with
      ... it's not a live reflection of the thing
      ... you can push some new object onto the end of the array and
      it takes effect

      krit: that's pretty neat
      ... but it would just work on svg elements?

      heycam: the model I'm thinking of, for elements that have
      attributes, for each attribute there's some accessor method
      ... why couldn't we use that on a div
      ... ?
      ... if cssom had some nice list method like this (which it
      doesn't) then you could

      shepazu: why do you think it's important that it's a generic
      one rather than one that works with svg elements

      krit: it's important to have a unified model

      shepazu: in what way is this not similar to getting the href of
      an a element in html?
      ... I think there's a core difference between svg and html
      ... html is light on attributes and attributes don't have
      complex values
      ... I think this is about as close as you can get with how a
      html dom would work

      ed: looking at an attribute with a complex structure - say path
      - there's talk of adding path to css
      ... would this work similarly on path in css?

      heycam: I would want the same dictionary values to be used

      krit: with the SVG attribute has the least priority in the
      cascade, you would constantly override the values

      heycam: maybe that's an argument for not having accessors on

      krit: it's the same with svg attributes

      heycam: that's true

      krit: I do like this api more than what we have on svg
      ... but it should apply to everything that's transformable

      shepazu: for transform you have a point

      heycam: maybe it would have been better to show an example on

      jet: I was hoping to see the sprite model on svg
      ... what I'm seeing is svg is more machine generated
      ... lists would have many elements and iterating over isn't
      ... what I'm seeing is that you can't pick out a particular

      heycam: one step in making it faster is the 'willchange'
      ... in terms of the dom memory size issue, if you're not going
      to make modifications, it's been suggested to take a snapshot
      of the tree as a raster and throw away the tree
      ... it's kind of possible now with some work using Canvas

      shepazu: there's a problem with that technique because you lose
      quality if someone zooms or does anything similar
      ... though perhaps you could just reconstruct

      heycam: depends if you've thrown away the subtree

      birtles: you could use an image element with a data uri to
      generate a sprite and throw away the dom tree

      heycam: it's a bit like the original promise of use

      shepazu: and by having params you could optimise on what would
      change and what would not
      ... so you could decide what bits to throw away and what to
      ... I hadn't considered that aspect, but params along with
      variables could be used as an optimisation hint
      ... one of the interesting things about svg is that you don't
      just have a static image - you have something you can change
      ... that is an advantage over rasters

      jet: I'm not just talking about performance, but usage
      ... vast majority of svg isn't programmed
      ... so I'd like to be able to opt in to enabling programming on
      svg content

      shepazu: you could specify that on the graphics element

      jwatt: you could probably determine that programatically
      ... you'd need to take note of percentages and layout
      ... it's kind of the thing that you don't want an author to

      heycam: if it's inline svg markup you need to have the dom
      because changes could come from outside

      jet: programmable graphics is useful, but we're making
      assumptions about the dom that come from html
      ... which is mostly hand written, but svg is generated
      ... author just wants a scalable image, but it's slow because
      all the stuff going on under the hood to support the dom

      heycam: you can already make that decision as an author by
      placing the image in line or not
      ... if you're doing inline svg you've made the decision that
      the dom needs to stick around

      krit: if you scale the webpage, is there a performance
      difference between scaling an inline svg or an image svg?

      Rossen_: you will see differences if you use percentages

      krit: if percentages aren't use will images always be faster in

      Rossen_: yes
      ... which goes back to the point before about using the svg as
      an image

      krit: I'm not sure about WebKit, what's FF like?

      birtles: we have optimisations on img that will make it faster
      ... I think we've worked out a way to reduce the cost of the
      DOM if that's what you want

      krit: is there a cost on the dom other than memory?

      jwatt: for us there would be - e.g. hit testing on elements

      krit: for re-rendering only the render tree would be used (in

      heycam: back to the polyfill

      Rossen_: there was a css value proposal that Tab had - I liked
      that he hid all the properties behind a CSS object

      krit: that's the css om

      Rossen_: have you thought of applying the same approach here?

      heycam: I think we considered at one point doing something like
      giving different united access
      ... e.g. element.px.width

      Rossen_: I liked it all being behind css
      ... related to dirk talking about transform, it's clear which
      you're working with

      <Rossen_> link to Tab's proposal

        [31] http://www.xanthir.com/b4UD0

      ed: we are moving more svg properties to css om, there's less
      unique svg attributes (or objects) in the dom

      heycam: for everything that has an attribute on an element,
      there's a dot something that lets you access it
      ... for consistency with html there should be some way of doing

      krit: not sure if we need to be consistent with html at that

      heycam: I think that's a consistency that hasn't been broken in
      ... an author can always guess how to interact with an object

      ed: I'd rather break the existing dom, phase it out and upgrade
      what we have

      heycam: to achieve that new objects shouldn't have access to
      the old dom

      shepazu: I'm don't think there's too much content using the
      current dom

      heycam: we get bugs filed all the time when things change

      krit: there's lots of differences now between Blink and WebKit
      and we don't get many bugs filed on it

      shepazu: I'm skeptical that there's content using the specific
      part of the dom that we would break
      ... some content would break obviously, but is there a
      significant amount?

      heycam: didn't we do a search last time and we found that d3
      uses some

      krit: just transform, with a fallback

      shepazu: I think we talked last time about reaching out to
      those library authors and seeing how they feel

      birtles: it's all the sites that have installed it and aren't
      updating it

      ChrisL: I'd like to take up your point, get Dmitry's input for

      shepazu: that's not what I'm talking about. I'm talking about
      the proposal not having this new graphics element

      ed: are there any other ways of opting in?

      heycam: I couldn't think of any that are reasonable

      shepazu: I'm suggesting that we break backwards compatibility
      ... just say rather than maintain these two paths, just break

      krit: speaking for WebKit and Apple, we would do it

      jwatt: if you do it and get away with it I'd be happy to do it

      shepazu: put out a build and see if people complain

      krit: we can't break getPathLength, but we can break animval

      heycam: I agree that if it's possible to completely replace
      things then that's the best solution
      ... but I'm cautious about doing that

      shepazu: there will be content that breaks, old documentation
      that will no longer be applicable
      ... but I suspect most of that content is not content that is
      being used
      ... a lot of the content would be from the old days
      ... FF broke almost all SVG content when it insisted we include
      the ns in the svg root
      ... I think we should be aggressive and try to change it and
      see what people say

      ed: as long as there's an alternative to the functionality

      shepazu: you can do it with a shim

      ed: that would be difficult with animval

      heycam: 1. whether or not new accessors are what we want

      2. is backwards compat what we want?

      heycam: I still think we should have the nice accessors, but it
      means we can do it in stages

      shepazu: I would be happy with any of the suggestions rather
      than what we have now
      ... I couldn't decide on which one we want now

      ed: it should be possible to drop parts of the old svg e.g the
      SVGPathSeg* API

      heycam: what do you think about the dictionary things?

      krit: everything using dictionaries is more like coding today
      ... could we map svg namespace to html namespace?

      heycam: that's a big dom core change but ....

      ed: we had some hacks in presto to let you do that
      (document.createElement("rect") got you an SVGRectElement if
      the document had an <svg> root)

      heycam: could hack html parser now to put svg elements into
      html namespace
      ... and rely on not inspecting the namespace

      krit: we got bug reports on that - about inheritance of objects
      ... right now is the best time to change svg this way

      <jwatt> Some modern HTML5 elements that have added numerical
      DOM properties:







      shepazu: right now people are using svg like an image, in the
      next few years people will be using it more like something you
      can program

      <jwatt> (so precedent for heycam's proposal)

      heycam: I think we have to provide a nice scripted interface.
      Don't think it's good to require people to use libraries

      jwatt: dirk was saying he didn't like having numerical
      properties - there's precedent for doing that in html5

      heycam: I think we have a path to the next step now
      ... if we can rip the band aid off then that's good
      ... we would still need to work out the details regarding
      namespace stuff
      ... if we're not using a new root element name

      shepazu: I wonder if this is something we should talk about at
      graphical web?
      ... on the panel thing

      heycam: for a couple of the changes here, can you change href
      and classname to a string?

      shepazu: you should also allow href without the xlink

      krit: we also need to talk about image vs img

      heycam: that was one of the wrinkles with this
      ... any way we go about it it's going to require changes to
      ... maybe we should allow img
      ... we are already switching to object-fit and object-position
      ... so to summarise the plan:
      ... 1. can we just remove the existing svg dom? dirk will try
      ... 2. if so, various parts of this proposal don't need to be
      done because we don't need to opt in
      ... we should give people whatever nicer options we can as soon
      as possible, but it doesn't have to be all at the same time
      ... 3. if it fails then we re-evaluate

      krit: WebKit only releases every year
      ... need to talk to someone else for Blink

      ed: I think as long as there's use counter data then it might
      be possible

      krit: introduce a compile or runtime flag

      heycam: decision about switching that flag?

      krit: easy on nightly

      ed: we can do it in parallel

      heycam: dirk, how close are you to being convinced to doing
      something like this if the plan fails?

      krit: my main concern was having a new graphics element that
      forces people to the new svg

      heycam: we didn't talk about lower casing all attributes

      shepazu: it might be advantageous for Blink and WebKit if you
      could point to this conversation and say this is what the svg
      wg is interested in doing to gather data

      jwatt: we should clarify that we're not removing the entire svg
      ... someone should come up with a list

      shepazu: we could give an example - say everything that is
      reflecting something

      RESOLUTION: We will remove SVG DOM attribute accessors pending
      web compatibility checks

      <jwatt> all IDL attributes of type SVGAnimated*

      ACTIONS: Erik to add run time flag to disable parts of SVG DOM
      in Blink

      <scribe> ACTION: Dirk to add compile time flag to disable parts
      of SVG DOM in WebKit [recorded in

      <trackbot> Created ACTION-3644 - Add compile time flag to
      disable parts of svg dom in webkit [on Dirk Schulze - due

      krit: I'd be interested in whether MS would remove the DOM if
      others did?

      Rossen_: likely would
      ... would be in favour of better accessors

      heycam: dirk your biggest concern is graphics element?

      krit: yes, duplicating code paths

      heycam: if we can't do removing and I can come up with another
      method of opting in without root graphics element would you be

      krit: yes

      heycam: I'm not sure there is another way but I could think
      about it

      ed: the point is to make existing svg elements inherit from

      heycam: yes

      shepazu: image element isn't as big a worry as a element as far
      as conflicts go

      krit: it's not used very much
      ... we'd have to discuss with html community
      ... most of html community would be happy if we move to html
      ... not sure they realise the cost though

      heycam: I wonder if we're at a point where we decide that we
      want to put things in the html namespace?

      krit: I think we should

      shepazu: I'm in favour of it

      ed: I'd like it if possible

      heycam: I propose that we work towards having all svg elements
      in the html namespace

      krit: do we need changes to the content model if we do that?
      ... e.g. circle having nested elements?

      heycam: don't think changes would be needed

      shepazu: think it would lead to changes but they're not

      heycam: I don't want to change the structure of elements

      krit: if we decide this is the direction we want to go. we can
      devote next f2f to resolving the issues

      Rossen_: moving to a namespace free world would be awesome

      RESOLUTION: We want better accessor methods for list type
      things. e.g. return array of plain javascript values
      ... All SVG elements should be moved to html namespace pending
      further discussion about details of doing that

      heycam: in my proposal I said that you can put things in html
      namespace or no namespace
      ... with the aim that if you're writing xml by hand you can
      leave off the xmlns
      ... seemed like the nicest thing to do

Summary of Action Items

      [NEW] ACTION: Chris to add |symbol { overflow: visible; }| to
      the UA style sheet and add authoring suggestion to say to
      design symbols around (0,0) [recorded in
      [NEW] ACTION: Dirk to actually perform the migration of SVG
      specs to Github in cooperation with Mike Smith [recorded in
      [NEW] ACTION: Dirk to add compile time flag to disable parts of
      SVG DOM in WebKit [recorded in
      [NEW] ACTION: Doug to talk to Mike Smith about migrating the
      SVG WG repository to Github [recorded in
      [NEW] ACTION: Rik to ask the Adobe guy about working on the vsw
      prototype [recorded in
      [NEW] ACTION: Tav to ask Inkscape vsw implementor to add
      Catmull-Rom interpolation to see what it's like [recorded in
      [NEW] ACTION: Tav to get back to Andreas about refX/refY
      top/left/etc. [recorded in

      [End of minutes]

       Minutes formatted by David Booth's [43]scribe.perl version
       1.138 ([44]CVS log)
       $Date: 2014-08-22 16:47:57 $

        [43] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
        [44] 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 [45]http://dev.w3.org/cvsweb/~checkout~/2002/

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

Guessing input format: RRSAgent_Text_Format (score 1.00)

WARNING: Bad s/// command: s/star>/star\//g
Succeeded: s/ css the attribute/ the SVG attribute/
Succeeded: s/elements/attributes (or objects)/
Succeeded: s/rather than breaking existing dom/I'd rather break the exis
ting dom/
Succeeded: s/drop parts of the old svg/drop parts of the old svg e.g the
    SVGPathSeg* API/
Succeeded: s/presto to let you do that/presto to let you do that (docume
nt.createElement("rect") got you an SVGRectElement if the document had a
n <svg> root)/
Found ScribeNick: birtles
Found Scribe: birtles
Inferring ScribeNick: birtles
Found ScribeNick: heycam
Found Scribe: Nikos
Inferring ScribeNick: nikos
Found ScribeNick: nikos
Scribes: birtles, Nikos
ScribeNicks: birtles, heycam, nikos
Present: Chris Erik Cameron Doug Nikos Jet Jonathan Brian Razvan Dirk Ro
ssen Rik Tav
Agenda: [46]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agend
Got date from IRC log name: 22 Aug 2014
Guessing minutes URL: [47]http://www.w3.org/2014/08/22-svg-minutes.html
People with action items: chris dirk doug rik tav

        [46] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda
        [47] http://www.w3.org/2014/08/22-svg-minutes.html

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

        [48] 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 Friday, 22 August 2014 16:50:30 UTC