minutes, SVG WG Sydney F2F 2015, day 2



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

                               - DRAFT -

                     SVG WG Sydney F2F 2015, day 2

12 Feb 2015


      [2] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Agenda_proposals

   See also: [3]IRC log

      [3] http://www.w3.org/2015/02/12-svg-irc


          +61.2.933.6.aaaa, Doug_Schepers


          Cameron, Nikos, tav


     * [4]Topics
         1. [5]superpath
         2. [6]optimizing for machine generation
         3. [7]Miter line join
         4. [8]auto closing path closing
         5. [9]Text on a shape
         6. [10]x/y/width/height on <symbol>
         7. [11]svg2 issues
         8. [12]Text bounding box
         9. [13]Open SVG 2 issues
        10. [14]svg2 issues in the color chapter
        11. [15]Remove above two interfaces.
        12. [16]Painting chapter issues
        13. [17]Issue: stroke-dashcorner doesn't work well for
            rounded rects
     * [18]Summary of Action Items

   <heycam> Scribe: Cameron

   <heycam> ScribeNick: heycam


   <cyril> [19]http://moissinac.github.io/SuperPath/

     [19] http://moissinac.github.io/SuperPath/

   cyril: my colleague has been working on this superpath
   ... the idea is that in many graphics, you need to share paths
   or pieces of paths among bigger paths
   ... for example you need to share them if you have regions in a
   map, share them sometimes in direct order, sometimes in reverse
   ... so the idea is to reuse a piece of a path in another path
   ... benefits in reducing file size, but also more semantically
   correct content. not duplicating information when not needed.
   ... viewers could do better antialiasing on that path, it's
   only present once
   ... it could be rendered seamless
   ... last time we talked about it, I exposed the fact that we
   wanted to have a path with an ID attribute, then another path
   referencing that initial path
   ... after some investigation we realised that it's very hard to
   extract a piece of a path and make it a separate path alone
   ... because what command would you put at the front
   ... the geometry of the path often depends on the point before
   or the point after
   ... so we changed our idea here ab it
   ... nikos suggested instead of having the reusable path a
   separate path, define it while using it in the first place
   ... so you have the full context
   ... you have the previous point if you want to reuse it in
   reverse order, or the next point if you are reusing in direct

   Tav: that's clear, but not sure if it's necessary

   cyril: you can see some examples on this page
   ... don't pay much attention to the syntax yet
   ... my colleague is happy to change the syntax, it's just a

   <cyril> d="M 90,190 220,90 330,150 (p1|L330,150 280,230
   L330,310 280,400)L120,375 z"

   cyril: this is an example of syntax; the path you will be
   reusing is between parens
   ... the ID is the thing after the open paren, and it ends with
   the bar
   ... when you want to reuse it

   <cyril> d="M 500,385 390,460 280,400!p1|L450,50 565,81 z"

   cyril: that's a reverse use
   ... and I think the prototype uses # for forward use


     [20] http://moissinac.github.io/SuperPath/Samples/piece01withExternalScript.svg

   cyril: there's a more complex example with a map


     [21] http://moissinac.github.io/SuperPath/Samples/bretagneSuperPath.svg

   cyril: this is a region of france with three subregions
   ... the blue path for the sea
   ... as I said, the syntax is probably not the best
   ... but the big change is the path is defined inline
   ... when it's first used
   ... to have the full context
   ... what is preserved is the geometry
   ... what he does is any path used is converted to a path that
   has relative commands, so it's easier to reverse
   ... then the reversed relative commands are applied
   ... the next step for us is to fix the syntax, then have it run
   on many examples
   ... JC is writing a program to analyse existing content and
   replace duplicated paths with this
   ... when the content has been authored and the paths don't
   exactly match, e.g. with slightly different floating point

   Tav: in inkscape you can output in relative or absolute
   ... I want to talk about auto closing a path
   ... with a rounded segment
   ... so you'd leave out the first point, then put the first
   point in the path

   nikos: it wasn't to do with smooth curve final segments was it?

   Tav: it helps with positioning the marker

   heycam: so that's a mid marker

   Tav: and makes the orientation expected

   cyril: what does the group think of defining the reusable path
   name in the path data?

   krit: how do we handle compatibility?

   cyril: for the path that defines the reusable path, it you
   could skip the ID then it could render
   ... the path that reuses it you couldn't really do anything

   Tav: now you define a country, as one path, and a region in
   that would be the path that you share?

   cyril: the country would be a single path element, but the d
   attribute would be divided into many subpaths, each having an
   ID for example
   ... then you define a region with an external border with the
   country, when you define the path data for that region you
   reuse the subpath defines in the country border

   Tav: I find that conceptually more complicated than defining
   each subpath separately

   nikos: you could define all the subpaths in defs
   ... and then you only need to reference it because you want to
   fill it

   cyril: if you don't care that the path segment between the
   previous point and the first point of the reused path, then
   doing what you suggest is good

   ed: can you get a continuous curve with reused subpaths?

   cyril: yes

   ed: it's a similar problem to the autoclosing command
   ... also wondering with this proposed syntax, is it possible to
   have nested reusable subpaths?

   cyril: I haven't tested that, I guess the prototype doesn't
   accept that
   ... but in theory it could work
   ... one of the difficult things in the current impl is that the
   path is converted to relative, and if the path you are defining
   is at the end of a big path, and the big path uses another
   path, you need to resolve that one first
   ... there's a possibiltiy you need to process the whole file
   before doing anything
   ... there's also the possibility of doing loops

   Tav: don't we have some rules for dealing with that already

   ed: yes for ID cycles

   cyril: so that would need to be specified

   heycam: bit uneasy about defining the names in the path data
   ... seems odd

   birtles: if I add the get-path-data-as-floats API, how would
   this work?

   cyril: it would return the expanded path
   ... animation is also an open issue
   ... I don't know how it can be implemented in browsers
   ... polyfilling is easy

   heycam: we wouldn't do the seamless rendering first, that would
   need lots of graphics library rewriting

   cyril: I don't think I need a resolution or an action, but if
   anyone is willing to help/test
   ... e.g. prototype in inkscape

   Tav: I'd like to but have enough other prototypes to work on
   for now

   <scribe> ACTION: jean-claude to further develop the protoype
   including with animation support [recorded in

   <trackbot> Created ACTION-3734 - Further develop the protoype
   including with animation support [on Jean-Claude Moissinac -
   due 2015-02-19].

optimizing for machine generation

   jet: I wanted to talk to the group about some implementation
   experience that I've had
   ... recently and in the past
   ... at Mozilla we recently implemented a flash player in JS
   ... and just deployed it in nightly Firefox builds
   ... previously I worked at Adobe on the flash player
   ... before that at Macromedia on the flash authoring tool
   ... at Macromedia, Adobe was building their LiveMotion
   authoring tool
   ... I wanted to share with the group some of why flash got the
   ubiquity it did and Adobe's SVG didn't
   ... it wasn't so much that the technology was better, but that
   we did things at Macromedia so that it would defeat SVG at the
   ... I think there's an opportunity to get past that after all
   this years
   ... and move interactive animations on the web in a way that
   SVG could not at the time
   ... the things that made it get over that hump at the time,
   weren't the things you'd expect
   ... Adobe's authoring tool was good, had a reputation for
   quality software, plugin worked in many places
   ... but when we would evanglize Flash over SVG, we'd demo with
   the worst browsers with SVG, and the best browser with Flash
   ... one company in particular the Flash developers went to at
   the time was Disney
   ... experts in animation, decided to use Flash on the front
   page of their site
   ... at the time, if you wanted to use animation you'd use
   GIF89, and there wasn't really anything else
   ... this is the era of 9600 baud modems and 386 computers
   ... today, the hardware is better, but similar network issues
   ... the things that made Flash successful was bug compatibility
   across browsers, and performance characteristics that were
   consistent across browsers
   ... for example Flash had retained mode API, binary file format
   ... small, fast, compiled
   ... after a while, the workflow would be that you'd take the
   authoring file format, .fla (which is a zip with xml resources,
   not quite svg)
   ... what I'm getting at is that SVG is an excellent authoring
   format, but a poor runtime format
   ... not because of XML vs binary is better or worse, but that
   we're unable to offer the consistent runtime/rendering
   experience because of what the format offers
   ... an example: coons patches, flash doesn't support that; nor
   gradient meshes
   ... but you can build a gradient mesh in the authoring tool and
   it spits out a bitmap under the covers
   ... there are things like that which make SVG very expressive,
   but which on a phone rendering a coons patch for your logo is
   less practical
   ... so what I'd like to get from the SVG group to see if
   there's an appetite to fix that
   ... is there a way for the implementors here to think about
   using SVG in a way that we can start with a subset that is
   normative for a runtime implementation
   ... not enough that we'd say you have to implement a coons
   patch for SVG, but that you could render a subset of SVG and
   have bug compatibility if possible

   krit: it sounds a bit like the Basic SVG Profile

   jet: SVG is one facet of it
   ... vector art and animation, and interactivity
   ... the part that made Flash also be ubiquitous is that its OM
   was very contained and strict
   ... you wouldn't expect that the HTML hosting your Flash file
   could mess with the Flash OM
   ... so maybe a basic profile of SVG?
   ... today, we implemented flash in /canvas
   ... something similar to the React Canvas
   ... implementing flash in JS/canvas
   ... SVG is so rich and powerful that I think it's better suited
   as an authoring format than a runtime one
   ... if we could design a subset that is a subset that has clear
   DOM semantics
   ... that the runtime can then make decisions about rasterising
   ... that's the spiel, don't have concrete ideas

   heycam: are you coming from the perspective of trying to
   implement Flash in SVG, and the performance wasn't there?

   jet: not all performance, but also different rendering model
   ... we also have an ad use case
   ... flash can bundle things up in a package neatly

   ChrisL: sounds like you're asking for a package format
   ... which travels in one unit
   ... or can play without being unpacked

   jet: yes, that's one way. maybe it is a zip container.
   ... there are things that made flash as a tagged binary file
   format, in the order of use
   ... you know before you use an element that you would've pushed
   it through the network
   ... the packaged file fromat like jar files, you have to get
   the whole blob before you can start

   cyril: the work I presented yesterday uses mp4 container rather
   than zip
   ... which can be used for streaming
   ... to come back to the earlier statement, I agree that design
   of Flash was very different
   ... authoring format, and publication format
   ... SVG is completely different in that the authoring format is
   the publication format
   ... so the tradeoffs are different
   ... performance and compact model is not the same
   ... that's a benefit but also a problem for optimisation
   ... looking at converting cartoons to SVG, there are thousands
   of ways of doing it
   ... so it's hard to optimise
   ... there are so many ways to do the same thing

   jet: for an authoring format, that's great
   ... flash was an authoring tool before it was a runtime format
   ... the compile-to-runtime was an artifact of having to send
   things over slow networks
   ... the answer I get to asking people why they're still writing
   flash, games/ads/etc., is both (a) these issues and (b) tooling
   ... so this is a problem we could solve, if we agree that we
   can start with a subset today that is available across all

   Rossen: I heard you mention a few times offering a subset
   ... and also guaranteeing interop
   ... I think we can all agree on how to spec a subset
   ... I don't know about guaranteeing interop
   ... it's what we all try to do
   ... but how do you guarantee it?

   jet: I think that opens us up to the same disadvantages

   Rossen: here's one way to go
   ... if this is something that we expose a number of APIs to the
   web platform, that you can implement SVG as one library, and
   that library is circulated and used
   ... that's the only way I can see that it's interoperable
   ... going back for a second, you're mentioning a subset
   ... do you have an idea?

   jet: I say subset just so it would be surmountable problem
   ... if we say basic shapes are required and then pixel perfect
   ... because that's a simple problem

   ChrisL: last meeting we tried to decide "is a geometry
   coordinate at the top/left of a pixel, or middle of a pixel"
   ... and we couldn't agree, because different graphics libraries
   are different
   ... one reason Flash was successul was that there was one
   implementation (that mattered)
   ... and that the implementation is basically the spec

   jet: so we implemented Flash using JS/canvas
   ... that it was possible is somethign taht got me thinking
   ... if we can render it today, why couldn't we all do the same
   thing? why can we not do it for a format other than swf?
   ... firefox is going to pre-ship with the JS flash
   implementation, but it's not feasible to make all cartoon
   authors have to ship this library
   ... couldn't we polyfill a format other than flash, perhaps a
   subset of svg?
   ... I'd like to build on things already in the web platform

   cyril: there is history to that. SVG Tiny 1.2 was that; an
   attempt to make a subset of SVG that was more efficient for
   mobile devices

   krit: we could do that right now with specifications that
   exist. you could use web components to make your own vector
   format, if you have the right primitives

   cyril: I doubt you'd have good performance there though

   Rossen: I'm still thinking you're talking about two different
   things here
   ... one is packaging, plus maybe additional step of
   standardising extension API where a platform piece can be
   delivered or hosted on CDNs and have lifetimes/updates and
   implementations will download them periodically
   ... so that they become part of the native packaged platform

   ChrisL: [tooling]
   ... the other reason I have Flash installed on my machine is
   that I like to watch video

   krit: content protection

   jet: we're solving the video problems another way, I think
   we'll get there
   ... the use cases are the ones I'd like to cover are ads, 2D
   ... the people who makes those games/ads in Flash, is that SVG
   implementations are fragile
   ... can we make it so that it's less fragile across
   implementaitons, by saying that there's a subset that has to be
   normative across the board

   Rossen: I think everything that we publish is normative
   ... in order to get interop you either have to converge on a
   single implementation, or just pray

   cyril: if you subset SVG, in some sense you don't have 10 ways
   to do the same thing
   ... you can optimise that

   Rossen: example?

   krit: asm.js

   cyril: how do you frame based animation in SVG?

   Rossen: what is it today?

   cyril: you can use display, visibility, opacity
   ... Brian just exposed yesterday all the challenges if you want
   to optimise your animation
   ... there are several ways, will-change, transfromZ

   Rossen: let's go back to SVG
   ... from the SVG spec, tell me what is exposed is ambiguous and
   can be implemented in many ways
   ... if we're saying we're going to converge on one single
   technology that covers the entire web platform, I don't think
   this is the right forum
   ... I'd still like to figure out the problem for SVG

   ChrisL: I'd like to see detail on what they find is fragile

   roc: do people demand exact rasterisation consistency on all
   targets? or are they more concerned about performance
   ... or other things?

   jet: it was consistency across targets

   roc: rasterisation consistency?

   jet: that, performance, ...
   ... we built a Flash renderer in JS, could this be a SVG

   Rossen: what does versioning look like in this case?
   ... I think we are falling down to some basic software
   engineering problems where the answer is either scaling down to
   one implementation, or you pray
   ... there's always a first to market, and others following
   ... are you going to hold everything back so that nobody jumps
   the gun and releases a feature?
   ... I think we build new features so that you have graceful
   ... and that comes back to the single implementation

   roc: are you implicitly saying that you find that canvas has
   sufficient rastiersation consistency to satisfy these people,
   and that builindg something on canvas would help these people?

   cyril: I can't speak for Google, talking to the people who work
   on swiffy, they said exactly that. they started with SVG, and
   moved to canvas

   roc: they're finding canvas more consistent then
   ... you could have authoring tools produce canvas and JS
   ... and compile down to that level
   ... if you do that I think everyone gets what they want

   jet: there's something amiss there, then you have to implement
   the playback engine

   roc: you can customise that engine right down to exactly what
   the ad needs
   ... you won't need most of the features that Shumway has
   ... I don't know how small we can make that, but I think for a
   lot of ads we can make it pretty small

   jet: is that something we could standardise?

   roc: we wouldn't need to, which is why it'd be a great solution
   ... in standards, we could look at making canvas rendering
   ... as canvas is more focused than svg is

   cyril: what's the scalability of canvas?

   ChrisL: well it's immediate mode

   roc: that's a problem that canvas-using apps already have
   ... there's a couple of pieces to solving that
   ... we have consensus on solving that; there's an event that
   first when canvas needs to be re-rendered
   ... and an application listens for that event and rerender
   ... and we need a way for the app to size the backing store to
   device pixels
   ... which is a renderedWidth/Height property on the canvas

   jet: then maybe all we have missing is the packaging side

   roc: you might be able to design your ad such that --- well you
   have image assets etc.
   ... there have been several proposals for zip-like but
   streamable bundles
   ... (you can make zip streamable if you format it correctly
   ... I'm not sure why they didn't go anyway
   ... maybe the use cases weren't compelling enough?
   ... some people were trying to do it as a performance thing in
   a single HTTP transaction
   ... but then SPDY came along
   ... so for speeding up website loading that solved it
   ... but for this problem of content traversing multiple
   networks was not really thought of as a use case
   ... technically it's not a mysterious problem

   cyril: you should look at the SVG streaming spec; it's still a
   draft, but it might help you

   heycam: marcos will know about packaging

   roc: if we could re-use this new app packaging format that
   might be a solution

   cyril: my recollection is that it wasn't streamable

   <Tav> [23]http://tavmjong.free.fr/SVG/MITER_LIMIT/index.html

     [23] http://tavmjong.free.fr/SVG/MITER_LIMIT/index.html

Miter line join

   <cyril> [24]https://github.com/w3ctag/packaging-on-the-web

     [24] https://github.com/w3ctag/packaging-on-the-web

   jet ^ (packaging)

   Tav: people were asking for a different type of miter
   ... instead of clipping at a certain point, when you reach the
   limit, you get a uniform clipping

   ChrisL: the existing one is discontinuous

   krit: in canvas, what do we do there?
   ... do we do the second one?

   Tav: the guy from nvidia (not neil) said that half graphics
   engines do it one way, half do the other
   ... the lower one is existing behaviour in some engines?

   roc: we just use the underlying graphics libraries
   ... so I'm sure it would be different on different platforms


     [25] https://developer.mozilla.org/samples/canvas-tutorial/4_8_canvas_miterlimit.html

   krit: I think different platforms do align

   Tav the proposal is to have a fourth (well, we have 'arcs')

   Tav so if you're already doing something to implement arcs
   (i.e. not solely relying on existing libraries), then
   implementing this proposal is trivial

   ChrisL: a new value would be good

   Tav: I've played with the cairo line join code
   ... and doing this is trivial

   krit: does it work cross platform? cairo uses CoreGraphics on
   OS X.

   roc: so the image rasteriser, not the other backends

   <roc> cyril: in what way is
   ckage-format not streamable?

     [26] http://w3ctag.github.io/packaging-on-the-web/#streamable-package-format

   <roc> shepazu: can you hear us?

   ed: the proposal is?

   krit: a new value that has this behaviour

   Rossen: are you proposing an interpolation function that goes
   between these things?

   <cyril> roc: it depends on the definition of streamable. My
   definition includes timing/synchronization. This packaging
   format is progressively processable, not streamable. Not
   seekable for instance.

   Tav: no just clip the miter rather than fall back to the other

   <roc> ah

   <roc> cyril: OK. When Jet was talking about the Flash format
   being streamable, for the purposes of ad delivery, I think he
   meant "progressively processable"

   <cyril> roc: there are use cases for adaptive streaming of ads
   as well

   ChrisL: so you're using a line cap which never triggers
   ... the numerical value for miter-limit wouldn't affect it?

   Tav: it would

   ChrisL: you're looking for a line-join keyword?

   <cyril> roc: mp4 being ubiquitous in all browser, I think it's
   a candidate that shouldn't be dropped without investigation

   <roc> cyril: maybe, but I think you can't have adaptive
   streaming and a single inviolable package.

   ChrisL: miter-clip

   <cyril> cyril: still controlled/timed delivery of big packages
   is interesting too

   <cyril> roc: still controlled/timed delivery of big packages is
   interesting too

   RESOLUTION: We will add line-join:miter-clip in SVG 2.

   <scribe> ACTION: Tav to add line-join:miter-clip to SVG 2.
   [recorded in

   <trackbot> Created ACTION-3735 - Add line-join:miter-clip to
   svg 2. [on Tavmjong Bah - due 2015-02-19].

   -- 15 min break --

auto closing path closing


     [28] http://tavmjong.free.fr/SVG/AUTO_PATH_CLOSING/index.html

   Tav: there are problems when you have a curved segment at the
   begin/end of a path
   ... in that in order to close the path you have to have a
   0-length z
   ... that causes problems with how markers are rendered
   ... there are inconsistencies with how browsers handle them
   ... if you paste that link in 2 different browsers, compare the
   rendering, you'll see that they're inconsistent
   ... due to rounding errors, if you use relative path segments
   by the time you get to the end your last point may not match up
   with the first point
   ... would be nice to have a way that specifies they should
   match up
   ... some possible solutions on how to do that
   ... one possibility is new commands
   ... the Z command is essentially an L command, where the point
   is the first point
   ... so you could extend that, but I don't think it's good to
   extend Z_a or whatever
   ... you could use a non-numerical parameter
   ... which means "use the first point"
   ... you could use a Z to indicate that you should replace a
   missing point with the first point in the path
   ... so either the second or third solution would be a way of
   doing it

   heycam: would you accept this special symbol anywhere in the

   Tav: maybe but it wouldn't be as useful

   heycam: makes me wonder if you would want to go back to any
   point, not just the first point

   Tav: it reminds me of a different problem, if 2 points are on
   top of each other, say a handle is on top of the start, how is
   direction determined for markers?

   heycam: I think we covered the marker direction issue a couple
   of weeks ago

   cyril: the whole problem comes from rounding errors, right?

   Tav: yes

   nikos: even ignoring precision issues, having a Z command that
   closes a bezier is useful anyway
   ... you could expand the meaning of Z to mean "close a path and
   create a segment if it needs to"

   heycam: that's the third option

   nikos: what if in an arc command you omitted the flag values
   and put a z there

   heycam: I think just make that invalid

   RESOLUTION: We will allow a Z to fill in any final coordinate
   pairs missing from the previous command.

   <scribe> ACTION: Tav to add the new Z behaviour. [recorded in

   <trackbot> Created ACTION-3736 - Add the new z behaviour. [on
   Tavmjong Bah - due 2015-02-20].


     [30] http://tavmjong.free.fr/SVG/TEXT_ON_A_SHAPE/index.html

Text on a shape

   Tav: inkscape originally drew ellipses/circles with paths
   ... some people noticed they could no longer put text along a
   ... because it's a common thing to do, it was proposed that we
   allow text on shapes
   ... in inkscape this is easy to do, because at the time we
   disply we've already converted the shape to a path
   ... the major issues have already been solved, such as the
   start point on a circle, because we had to define that using

   heycam: and dashing

   Tav: there are a couple of challenges
   ... if you put text on a circle it might make sense to use a
   negative startOffset
   ... how do you put text on the other side
   ... we could have a flag to say which way the text goes

   heycam: sounds fine
   ... what about the flag?

   ChrisL: what would the names be? inside/outside? left/right?

   Tav: left/right

   ChrisL: as long as you have a good definition

   roc: clockwise/anticlockwise?
   ... mapping people use "true left" of a river, left when moving

   Tav: how about negative startOffset?

   heycam: negative startOffset is already allowed, but we
   probably don't define what happens with closed subpaths

   RESOLUTION: We will allow <textPath> to reference shapes and a
   flag to say which side of the path the text is put.

   <scribe> ACTION: Tav to update textPath for text on a shape.
   [recorded in

   <trackbot> Created ACTION-3737 - Update textpath for text on a
   shape. [on Tavmjong Bah - due 2015-02-20].

x/y/width/height on <symbol>

   Tav: this is an issue I came across

   <Tav> [32]http://tavmjong.free.fr/SVG/viewport.svg

     [32] http://tavmjong.free.fr/SVG/viewport.svg

   Tav: Opera Presto and Inkscape you see no red boxes

   ChrisL: and red is bad right?

   Tav: it means x/y/width/height are being interpreted when the
   spec says they shouldn't be

   cyril: Firefox/Chrome behave the same

   <ChrisL> IE11 is correct

   Tav: Batik does it wrong, and probably everyone assumed Batik
   does it right
   ... so I don't think following those attributes is useful
   ... I think the spec should be followed in this case

   roc: I suspect those attributes got cloned onto the <svg> and
   they're being interpreted in place
   ... so maybe we should add them for consistency with
   referencing <svg>?

   ChrisL: is it fully defined what it means, if we removed that
   rule from the spec?
   ... given that nested <svg>s already allow this

   Rossen: I don't want to change

   ChrisL: the reason I changed was that we added x/y to <svg>,
   and now referencing it is different from referencing <symbol>

   roc: if the issue is what I think it is, I think it would be
   easy to fix. but consistency between <svg> and <symbol> would
   be good.

   krit: does <symbol> have viewBox?

   Tav: yes

   krit: then I'm starting to agree with roc

   <shepazu> +1 to roc's proposal... we should do the same for
   <marker>, etc.

   ed: if you have width/height on the <use> it will override the
   ones on the cloned tree

   Rossen: and that makes sense

   roc: this is not an argument for making symbol behave
   differently though

   Tav: it's only used by a <use> element

   ed: I think you'll still get the same behaviour if you default
   width/height on <symbol> to 100%
   ... so if we did that I'd be fine with it

   krit: what happens now that x/y are properties?

   Rossen: what is the main use case here that would be broken if
   we don't do this?

   Tav: if someone has incorrectly put x/y/width/height
   ... some browsers have ignored it, others have not

   Rossen: what would be the expected behaviour or use that comes
   out from tooling?
   ... what would be more natual for tooling to output for this?
   ... when you're using <use>, I would expect tooling would
   probably define x/y/width/height on the <use>

   heycam: so I agree that x/y on <symbol> is not useful
   ... but the argument would be consistency with referencing

   krit: it's an edge case, I don't think content would be relying
   on this behaviour

   Rossen: what would be the most natural thing from the author's
   point of view?
   ... in either case the code change would be straightfowrard
   ... I want to know what the effect for users would be

   krit: <symbol width height> and <use x y> without width/height,
   that would be useful to avoid duplicating width/height all the
   ... I think there is an argument to simplify the code
   ... by treating these the same
   ... the user could live with specifying width/height on <use>

   dmitry: it looks more to be a bug in the spec rather than the
   ... as an author, I would expect x/y/width/height to be
   available on <symbol>
   ... it's not a big deal

   ChrisL: the underlying model when this was designed is that
   <use> positions a new thing, and that referenced thing has its
   centre of its coord system would pin it
   ... it does mean sometimes you need to display all four
   ... and there are some issues with clipping
   ... some people would rather specify the middle rather than 0,0

   Tav: well we now have refX/refY on symbol, to match marker

   Rossen: what would users want/say

   roc: I don't think users are necessarily going to use this
   ... do we change the spec to make things things more consistent

   <pdr__> cyril asked me to confirm that swiffy has indeed
   switched to canvas

   ed: send a mail to www-svg asking for feedback, wait two weeks,
   decide then?

   Rossen: sounds reasonable

   <scribe> ACTION: Tav to mail www-svg about the symbol
   x/y/width/height issue and report back in two weeks [recorded
   in [33]http://www.w3.org/2015/02/12-svg-minutes.html#action05]

   <trackbot> Created ACTION-3738 - Mail www-svg about the symbol
   x/y/width/height issue and report back in two weeks [on
   Tavmjong Bah - due 2015-02-20].

   <ed> scribeNick: ed

svg2 issues

   <heycam> [34]https://svgwg.org/svg2-draft/layout.html

     [34] https://svgwg.org/svg2-draft/layout.html

   heycam: this is the chapter for x,y,cx,cy and so on properties

   <ChrisL> botie, tell cyril he was mean to zakim

   <botie> ChrisL: excuse me?

   heycam: issue 1: need to check the initial values for all of

   krit: r has different initial values for gradients and circle
   ... propose to make it 'auto'
   ... to make it work out the correct value depending on element

   heycam: is this done with UA styles?

   TabAtkins: auto is more for when auto is going to affect the
   ... if you're just doing based on the element you should use UA

   krit: next issue, rx and ry should use zero as initial value
   ... something that's not there is fx and fy
   ... on radial gradient
   ... the descirption is complicated, by default uses values from
   cx and cy...
   ... we could set them to auto and make them do the same thing

   heycam: it's a strange feature

   krit: it doesn't define specialcasing for fx,fy

   heycam: we did decide to make fx and fy properties, right?

   krit: yes

   heycam: did we only do this because we did the other gradient

   krit: I think so

   heycam: we should focus on the basic shapes
   ... don't do this for the gradient elements, even with cx, cy
   on gradients

   ChrisL: but you can put presentation attributes on any element

   ed: can't we just make them presentation attributes on
   particular elements?

   heycam: if it's easier since presentation attributes work on
   any element (?)

   krit: in webkit we didn't turn cx cy to properties on

   heycam: i'd prefer not making them presattrs in this case

   RESOLUTION: don't make the layout properties into presentation
   attributes on the gradient elements

   heycam: issue 2, what to do about x and y on text elements?

   Tav: we also have them on tspan right?

   heycam: yes
   ... the issue is that they're list of values
   ... either we could allow list of values in the property, but
   only use the first value
   ... or the attribute has some special processing
   ... one option is to not make x y presentation attributes on
   any of the text elements

   krit: I like that, or alternatively make xy presattr on text,
   but map them to other properties
   ... don't quite like the second idea though

   heycam: we already decided that the x,y lists are bad due to
   font issues
   ... so don't think we should allow the second one

   krit: another way might be to apply the xy property to text
   elements, but also apply the positoning fromthe xy attributes
   ... that would allow positioning from css

   heycam: that'd be a little bit confusing
   ... but might be the best solution

   Tav: so discourage use of the x,y,dx,dy?

   heycam: I think we should try it out

   krit: ok, so spec that and await feedback from implementations?

   Tav: ok

   RESOLUTION: add a new keyword value to the x and y properties
   that means use-the-list-of-lengths in the attributes, and set
   that with the UA stylesheet

   <scribe> ACTION: krit to add a new keyword value to the x and y
   properties that means use-the-list-of-lengths in the
   attributes, and set that with the UA stylesheet and add a note
   to say that it's still an open issue [recorded in

   <trackbot> Created ACTION-3739 - Add a new keyword value to the
   x and y properties that means use-the-list-of-lengths in the
   attributes, and set that with the ua stylesheet and add a note
   to say that it's still an open issue [on Dirk Schulze - due

   <heycam> [36]https://svgwg.org/svg2-draft/coords.html

     [36] https://svgwg.org/svg2-draft/coords.html

   heycam: next chapter, coordinates
   ... issue 2, are there any more up-to-date defs for sizing? (i
   haven't checked)
   ... prob needs some closer review by somebody
   ... someone should take an action to look at this?

   <scribe> ACTION: krit to review the svg2 coordinate chapter
   [recorded in

   <trackbot> Created ACTION-3740 - Review the svg2 coordinate
   chapter [on Dirk Schulze - due 2015-02-20].

   heycam: issue 9, about pAR


     [38] https://svgwg.org/svg2-draft/coords.html#PreserveAspectRatioAttribute

   heycam: do ppl use 'defer' or can we drop it?

   ChrisL: is this somehting new?

   heycam: I think it's from the original 1.0 spec

   krit: don't think webkit implements this

   heycam: we have some tests for defer, but doesn't mean that ppl
   are using it
   ... would be happy to try removing it

   ed: I'm fine with removing it

   heycam: firefox at least supports parsing it

   Tav: inkscape doesn't support it

   krit: webkit parses it but ignores it

   ed: so does that imply that we should allow it but say in the
   spec that it must be ignored?

   heycam: would prefer just to remove it (don't think there's
   much content using it)

   krit: think we should parse it but ignore it

   heycam: I'd prefer removing it

   RESOLUTION: make defer do nothing (and investigate removing it

   <scribe> ACTION: krit to make defer be ignored in pAR [recorded
   in [39]http://www.w3.org/2015/02/12-svg-minutes.html#action08]

   <trackbot> Created ACTION-3741 - Make defer be ignored in par
   [on Dirk Schulze - due 2015-02-20].

   heycam: next, issue 15


     [40] https://svgwg.org/svg2-draft/coords.html#BoundingBoxes

   heycam: in the bbox section
   ... bbox of text with the widht/height set on it
   ... should it be the box that it's laid out in, or the union of
   the glyph cells?

   Tav: the text would just be the content area, can be reduced
   due to padding/margin

   krit: we should handle it like normal block elements in html

   heycam: so what should getBbox return?

   Tav: there are different bboxes in css

   <text x=10 y=10 width=100>A</text>

   heycam: sometimes you have content that can't wrap

   Rossen: inline elements don't have width in css
   ... this is closer to block
   ... the blockrelated properties is what should apply to svg

   heycam: we don't need to make getbbox does like
   ... if we ignore the width feature
   ... we might return the size of A

   Rossen: with the width today if you specify it

   <shepazu> (SVG also has different bboxes... geometric bbox,
   decorated bbox, etc.)

   Rossen: you can say it's the bbox or that it's the union of the
   two, or just the text inside

   Tav: depends on how much text you put in

   heycam: it's a run of glyphs
   ... we can do pre-formatted text
   ... we can union the bboxes
   ... i think we shouldn't return the rect area defined by
   width/height for text

   Tav: if you've wrapped text, some text sticks out further than
   the others, you should make that affect the bbox
   ... you'd have to look at all the lines to figure out the exact

   nikos: if we say width(height is always returned from getbbox
   you could just check the attribute

   Rossen: the information for size of each line is available
   ... you might want each line separately

   ed: multiline text is new in svg2, do we want to allow fetching
   the size of each line?

   krit: cssom defines that getclientrects maps to getbbox (?)

   roc: maybe think of it as shrinkwrapped
   ... the intrinsic preferred width

   heycam: problem is tht dx dy influences the bbox

   krit: we could disable them for the case of having width/height

   heycam: the options
   ... 1) look just a the glyphs, take bbox of each and then union
   the bboxes
   ... 2) if you have width attribute then bbox has that exact
   width and height be multiple of lineheight
   ... 3) union of option 1 and 2

   TabAtkins: option 2 is closest to what css is doing today

   Rossen: what do we do for negative margin on inline boxes?

   TabAtkins: doesn't count

   Rossen: not sure it translates well to svg

   (draws on whiteboard)

   Rossen: think that we want two ways, if you want getclientrects
   (the content) you get only the text - you can do union,
   intersection or whatever you want

   heycam: if we want options we have a param for getBBox that we
   can use

   Rossen: so list of text content boxes, or the parent box that's
   the union essentially

   heycam: we can always add a way to get the other one

   Rossen: right, because we don't have any way to get the

   heycam: the only downside is that it's inconsistent with
   non-areabased text
   ... where we're using css to layout the text
   ... but shrinkwrapping the text

   Rossen: that's fine though, the bbox is defined by the text
   content in that case

   Tav: think we should not consider dx, dy and rotate in the
   textarea case
   ... for the bbox

   heycam: I think the block level element in css should provide
   the bbox (positioned)

   Rossen: when width is auto one of the three possible ways to
   size the box
   ... one is dependency on parent, in percentage
   ... other is that it's fixed
   ... third is that it's attached to the text content

   -- break for lunch --

   <nikos> scribe: Nikos

   <scribe> scribenick: nikos

Text bounding box

   heycam: we discussed over lunch
   ... when you call getBBox on a text element that has % or px or
   specified width then bounding box is the specified width
   ... and height is the height of the CSS box that gets created
   ... and if you leave off the width, then you take the union of
   all the bounding boxes for the text
   ... to handle cases where things are positioned
   ... if you don't have positions then it's like the other two
   cases where you're looking at the box and returning the
   bounding box anyway
   ... think that makes it a consistent model
   ... probably don't need to describe in terms of those three

   Tav: looks like a good solution to me

   RESOLUTION: for text bounding boxes with specified width, % or
   px, then the bounding box is the specified width with height
   being the height of CSS box that is created - otherwise
   bounding box is union of all child text bounding boxes

   <scribe> ACTION: heycam to spec behaviour of getBBox on text
   [recorded in

   <trackbot> Created ACTION-3742 - Spec behaviour of getbbox on
   text [on Cameron McCormack - due 2015-02-20].


     [42] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Open_issues

   heycam: bogdan suggested we gather up open issues on this page
   - we might not have a chance to resolve them all this meeting
   ... so I summarised which I thought were substantive issues
   that need discussing

   ed: back to text, if you have text element without width or
   height and you have white space property set to pre wrap
   ... you have some return characters to specify text as multiple
   ... you get three lines of text
   ... behaviour of bounding box should be as auto

Open SVG 2 issues


     [43] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Open_issues

   heycam: this list is based just on the red issues that are
   noted in the spec
   ... may be a few more things in tracker

   <scribe> ... new ones may also pop up as we continue reviewing
   the existing text

   UNKNOWN_SPEAKER: Erik and I have reviewed some chapters
   ... neither of us are through the whole spec yet
   ... so probably later chapters need a closer look than the
   earlier ones
   ... bearing that in mind, this wiki lists the substantive
   issues that are noted in the spec

   cyril: some chapters start at issue number > 1?

   heycam: we've already discussed some and some don't need
   ... we may or may not get through this list
   ... how would you like to prioritise?

   BogdanBrinza: normally for us we take a first pass at the list
   and find highest priority items

   Rossen: hope we're in agreement we want to ship the spec?
   ... so we can tackle a couple of ways
   ... we can look at the spec as a whole - if we agree we want to
   close all issues and ship the spec
   ... then move to a modular way of advancing svg
   ... then first pass should be to decide the must unstable and
   non core things
   ... that we can live without
   ... and make those modules right now
   ... that will reduce the amount of work we need to do as a
   group to discuss issues
   ... so as a first pass lets find big areas we can remove
   ... then from remaining we can assess what is in most dire need
   of group discussion time

   heycam: I like the idea of creating modules immediately for
   things we're removing

   cyril: maybe not the case for all chapters - but some seem to
   be very close to modules


     [44] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_readiness_assessment

   Rossen: is your list an extraction of this table?

   heycam: has some correlation probably but this is just my
   judgement of the issues
   ... and which are not editorial

   BogdanBrinza: think we agree on chapters that have most issues

   Rossen: do we think we can go through the first step and move
   things to modules?

   krit: I'm in favour of that - do you have features that you
   want to move

   Tav: Think we'd spend more time arguing over which stuff to
   move than how to solve the issues

   BogdanBrinza: Chapters 15, mesh gradients has a lot of issues

   heycam: don't think we should be looking at the chapter level -
   but at features
   ... if we look at my list of open issues - do you agree that if
   we've solved open issues for a feature should it stay?

   Rossen: not sure - if we can move something to the next level
   why spend time talking about it?

   heycam: sounds like you have ideas about features you don't
   want to see in the spec - even though there are no open issues

   Rossen: I wouldn't oppose a stable feature staying

   BogdanBrinza: generally not about features we want in the spec
   - but everyone wants to see a stable spec

   heycam: do you think stability is not solely determined by open

   BogdanBrinza: I'd say that's the most important thing - but
   severity matters too

   heycam: I was going to suggest looking at features that
   correspond to open issues
   ... so if we've resolved issues on a feature it can stay

   Rossen: do we consider features complete?
   ... or just enough stuff there so we think it's complete but
   not sure
   ... are we going to find issues when we review?
   ... ok lets go through each issue then

   heycam: let's finish co-ords chapter then we can talk about
   features in other chapters

   <scribe> ACTION: heycam to make stable issue identifiers in the
   spec [recorded in

   <trackbot> Created ACTION-3743 - Make stable issue identifiers
   in the spec [on Cameron McCormack - due 2015-02-20].

   issue 17, co-ords chapter

   heycam: issue 17, co-ords chapter
   ... should fill correspond to the main area of that element?
   ... so fill:false should exclude that rectangular region?

   <ed> for ACTION-3743 make sure that the template has fields for
   assigned actions, wg discussion and resolution

   heycam: if it's not an svg element you can't call getBBox, but
   you can call it on the parent
   ... so iframe or canvas should contribute to the bbox

   Rossen: if it's not exposed how can you get the bbox?
   ... should define getBBox on these elements

   krit: if you put HTML in an svg document, how does CSS box
   model contribute to the bounding box computations - it's a
   general problem

   Rossen: we define getBBox on foriegnObejct? Behaviour should be
   the same

   krit: but on fo you have a whole html doc

   heycam: fo and iframe and canvas just return the rectangle -
   but issue is whether fill dictionary parameter controls whether
   that contained element contributes or not

   Tav: To me fill:false is not a sensible option
   ... as a control

   heycam: sounds like we agree on that

   RESOLUTION: The fill dictionary parameter doesn't affect
   bounding box of iframe, canvas, etc

   <scribe> ACTION: heycam to update spec for fill dictionary
   parameter when called on iframe, canvas, etc [recorded in

   <trackbot> Created ACTION-3744 - Update spec for fill
   dictionary parameter when called on iframe, canvas, etc [on
   Cameron McCormack - due 2015-02-20].

   heycam: proposing to remove svg:transform’ attribute

   krit: already done

   ChrisL: where is it being moved to ?

   heycam: no one uses it

   ChrisL: mapping people use it
   ... my understanding is we changed behaviour for this to match
   what implementations do

   krit: the removed text was mostly pointless

   cyril: it's not the same as the transform attribute - same name
   but in a different namespace

   heycam: if you think it's being used by people it can stay
   ... just worried wording is outdated

   ChrisL: this was standardised through JIS

   krit: I'll put it in integration spec

   ChrisL: that's ok - just don't want it removed

   AlexD: isn't this what Takagi-san is using for tiling?

   ChrisL: yes

   cyril: don't think it should be in integration spec - should be
   module on it's own
   ... I see integration spec as between svg, html, css

   ChrisL: it's larger - how css uses things

   Tav: I'd like to see it moved before it's taken out

   krit: I'm doing it right now
   ... into a new module right/

   ChrisL: section above it as well?

   heycam: there was going to be a mapping spec?

   ChrisL: yes but mapping spec by itself wasn't useful
   ... by itself
   ... so dispersed these features into svg 2 spec

   Tav: that's why it's good having annotations describing why
   things are moved

   RESOLUTION: svg:transform attribute will be moved to a new

   heycam: let's look at remaining issues in terms of the features
   they encompass
   ... all path issues are for Catmull-Rom

   Rossen: who is implementing it?

   Tav: it's Doug's baby

   Rossen: can we have a Catmull-Rom module?

   <shepazu> why?

   ChrisL: tricky because it's in the path element

   shane: we did that in CSS

   ChrisL: was going to bring that up as a bad example

   shepazu: there's a not great way - which would still be good
   ... supersede description in new spec
   ... good way is define what path commands look like
   ... and say future specs may define new path commands

   ChrisL: agree, not sure how much work it is making it properly

   shane: could put all stuff in path extension spec

   ChrisL: so in core svg 2 path syntax is the same as svg 1.1?

   heycam: we have bearing and stuff
   ... that's an example of a feature that is complete in the
   spec, but people have reservations about it being in core svg 2

   Tav: it's not something I care too much about having - but feel
   it will be ignored once it's in another spec

   Rossen: that's how css works
   ... survival of the fittest - good features progress faster
   ... I think it's a good way to do things

   TabAtkins: don't be afraid of modules

   heycam: Doing things in modules is the right thing- but I'm
   concerned if we move features to modules then svg 2 won't be
   much different to svg 1.1

   ChrisL: that's a problem because we've then spent 10 years
   producing a spec that doesn't have new features

   Rossen: if you have 5 other specs in the pipeline then you have
   a good story

   ChrisL: we've already gone from modules to one monolithic spec
   ... now we're going back

   Tav: how much work to fix Catmull Rom?

   heycam: need to add math to the spec
   ... issues could be summarily decided

   Rossen: this is a good example of a feature that could move imo
   ... it's a good feature
   ... some designers have questioned it's use

   Tav: there's a good use when connecting points in a graph

   heycam: I would have to do investigation of the math

   Tav: it's pretty simple

   Rossen: if it was such a hot feature I'd expect Adobe,
   InkScape, etc to be pushing it

   krit: Adobe already stated we don't care

   heycam: so if you want a sense of it staying in svg 2 or being
   split ... ?

   krit: not necessary for svg 2

   Rossen: can we resolve to move it to it's own module

   heycam: as long as we create a new spec immediately
   ... don't want to lose the work we have done

   ed: do you have same concern about bearing?

   Rossen: I haven't read the bearing stuff

   heycam: I'll be less excited about shipping svg 2 with all the
   features removed

   shane: I think we'll fairly readily be able to find features
   that have no issues or trivial and those that have substantive
   ... why not appoint champion or owner for features with
   substantive issues
   ... if issues aren't resolved by wg within a certain time frame
   we move it out

   Rossen: features without issues shouldn't necessarily remain
   part of the core
   ... if features have expensive implementation cost then they
   should maybe moved out

   heycam: we could mark them at risk

   Jet: is there a list of at risk features/
   ... that's probably the first step

   heycam: table in your wiki page isn't at feature granularity,
   which is what we need to discuss

   Rossen: it's easy to decide on some - basic types for example

   krit: svg 1.1 isn't going to disappear - it can still be

   stakagi: not using transform at the moment - it is ok to remove
   it from this level
   ... you can put me as editor of the svg:transform spec

   heycam: Catmull-Rom - what are we doing?
   ... put with superpath as svg path level 1?

   shane: it's a really nice target for modularisation
   ... doesn't mean it won't be published at the same time as svg

   heycam: let's publish first draft of these things when we
   publish CR of svg 2

   RESOLUTION: Will create SVG path module

   heycam: should svg 2 path only be what is supported by 1.1?
   ... so move all new things (e.g. bearing) into the module?

   shane: there is work involved in moving stuff - if a feature
   has no issues then leave it

   heycam: I'm ok either way

   Rossen: i'm ok with either too

   heycam: minimum work is leave it where it is

   all: let's do that

   <scribe> ACTION: heycam to move Catmull-Rom to SVG path module
   [recorded in

   <trackbot> Created ACTION-3745 - Move catmull-rom to svg path
   module [on Cameron McCormack - due 2015-02-20].

   heycam: Editors will be Cam, Doug, and Cyril

   TabAtkins: do we want to use CSS naming where everything that
   builds off SVG 2 is next level?
   ... then we'd start at 2

   all: that's confusing, let's start at
   ... 1

   heycam: next bunch of issues are to do with text
   ... either shape text or rectangular ref text

   Rossen: are your issues in an order?

   heycam: just numeric

   Rossen: can we do things with only 1 issue?

   heycam: Let's do animate.html, Issue 2

   birtles: basically new features we'll defer to a separate spec
   ... then there's one or two edits I should make with regards to
   ... not sure about allowing animatemotion to use a basic shape
   ... not sure if we want to include those slight improvements
   ... or defer everything

   Rossen: what would it look like after your change?

   ed: we resolved to allow basic shapes for text on path

   birtles: so for consistency we should leave it
   ... major features will be deferred
   ... I can take care of the issues that are there
   ... and get rid of references to features which we'll put in a
   different module

   heycam: can we discuss attributeType="auto"?

   ed: I came across issue with SMIL elements and attributeType
   ... default is auto which means check if it's a property first
   ... if so that's what your'e animated, otherwise attribute
   ... since we made x and y properties
   ... it's a problem on text element
   ... which takes a list of values
   ... I'm wondering if we should try to be smarter here selecting
   the right thing

   heycam: why wouldn't that content work now?
   ... auto means when both property and presentation attribute,
   choose the property right?

   ed: if we make x a property, we'll try to animate x as a css
   ... and that might not give the same result as previously

   heycam: outcome of previous discussion was that it would work
   ... property is the primary thing that determines the value

   ed: if you have a list of values (e.g. "10 20 30") it's not
   valid for the property, so animation will stop working when it
   used to work
   ... one suggestion is to make auto pick the xml version if it's
   a text element
   ... that will preserve old behaviour
   ... and pick css property for any other element

   Rossen: and when number of values is one?

   AlexD: I don't like behaviour of attribute depending on what
   it's parent is

   birtles: you have to look up parent or target anywhere when

   AlexD: but not when binding

   birtles: yes you need to look to see if there's an attribute of
   that name that can be animated

   AlexD: seems like strange behaviour to me
   ... choose one or the other and whatever it breaks it breaks

   Rossen: doesn't sound like much will break

   ed: expect most would use one value

   birtles: I think there'd be some breakage
   ... you see people moving characters around like that

   Rossen: I'd be more concerned about tools and tool makers

   birtles: that suggests keep backwards compat

   AlexD: don't know if there's any tool that generates this

   birtles: I was hoping to deprecate attributeType altogether

   ChrisL: attributeType was introduced to disambiguate a name
   class between width and height attributes and properties

   <birtles> Mozilla bug:

     [48] https://bugzilla.mozilla.org/show_bug.cgi?id=1062106

   ChrisL: so most of the time you didn't need to specify it
   ... in some was we have more of a clash now
   ... we've promoted lots of things that were attribtues into
   ... so I don't think it serves much purpose at the moment
   ... think people tended to guess as to which value to set
   ... and it usually didn't matter
   ... so you'd probably find uses - but removing attributeType
   would probably render just the same

   birtles: but how do we make text case work?

   Rossen: state it's deprecated

   birtles: if we get rid of attributeType how do you animate x
   attribute on text element?

   Rossen: so what are options we have?
   ... option a) remove attributeType altogether because pretty
   much all properties are attributes and only x is problematic
   ... we'll deprecate multiple x/y value animate for text
   ... as a consequence

   ed: do we want to consider deprecating having multiple x/y
   values on text element

   cyril: it's heavily used isn't it ?

   krit: yes but not for animation

   <scribe> ACTION: ed to add use counter for multiple x/y values
   on text element [recorded in

   <trackbot> Created ACTION-3746 - Add use counter for multiple
   x/y values on text element [on Erik Dahlström - due

   Rossen: let's wait for more data then

   ed: don't think we need to make both decisions at the same time

   Rossen: option b) get rid of attributeType and in this case
   have a fall back mechanism for the property that gives a list
   of values
   ... e.g. we can take last or first valid attribute from the
   ... and animate with that
   ... which will again break animation, but not as badly (maybe)
   ... in one case you have no animations at all - second you have
   animations of one frame
   ... not perfect, but less invasive
   ... option c) get rid of attributeType and add special handling
   for x on text
   ... make it context aware
   ... is there another option where we extend the attributeType
   to specify instead of doing context aware

   heycam: it already has values to select attribute or property

   ed: we could make auto on text elements, pick xml as the

   Rossen: option d) attributeType for animate inside of text is
   always xml - there is no auto
   ... would reduce options in future

   cyril: detect number of values?

   Rossen: that would be hacky

   birtles: I think we could drop attributeType and leave a note
   in the spec with the context aware behaviour as an open issue
   ... see what data we get on the use counter
   ... if there's not sufficient usage of multiple values for x we
   drop, otherwise we do context aware

   Rossen: what about if we deprecate it now and see who fights
   for it?

   birtles: I know there's a lot of opposition to multiple values
   for x anyway

   ed: difference between static text with multiple values and
   animated multiple values - there will be a lot less animated

   cyril: removing attributeType is ok - but the consequence in
   option a is not acceptable

   birtles: the consequence only applies to animation

   cyril: ahh ok

   birtles: there is a work around for jittering text
   ... using dx/dy

   RESOLUTION: remove attributeType and deprecate animation of
   multiple values in x/y

   Rossen: that was the big issue with animation - so this chapter
   is mostly clear

   birtles: I need to do some more tidy up but yes

   heycam: interact.html ISSUE 1: should we remove duplicate
   events like SVGLoad? is already resolved
   ... lacuna value for pservers.html ISSUE 3: linearGradient y2
   lacuna value is already resolved
   ... the value should really be zero

   RESOLUTION: lacuna value of y2 on linearGreadient should be

   Rossen: what about masking.html ISSUE 2: define how
   overflow-x,y work ?

   krit: being moved
   ... ISSUE 3: should overflow:auto really be equivalent to
   ... we changed behaviour based on ie

   Rossen: thought we discussed in London?

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


     [50] http://www.w3.org/2014/08/22-svg-minutes.html#item04

   Rossen: seems like a perfect fit for integration spec

   krit: do we move overflow to integration spec?

   heycam: why is it in our spec?

   ed: we have lots of special rules

   heycam: remove that section, add relevant UA rule and that
   should be enough
   ... krit can we really remove it all?
   ... I need to think about it - give me the action

   <scribe> ACTION: Cameron to take care of overflow section in
   the masking chapter [recorded in

   <trackbot> Created ACTION-3747 - Take care of overflow section
   in the masking chapter [on Cameron McCormack - due 2015-02-20].

   nikos: a lot of the stuff in Clipping, Masking and compositing
   will move to rendering chapter or be removed so this chapter
   will probably go

   RESOLUTION: masking.html, issue 2 - Drop overflow-x,y issue and
   don't do anything specific in SVG

   krit: so all these changes are going to integration spec and
   are being removed from svg 2?

   Rossen: yes

   heycam: i'm concerned that it's not valid to state that auto on
   a particular element computes to a different value

   Rossen: we do that all the time

   RESOLUTION: masking.html ISSUE 3: should overflow:auto really
   be equivalent to visible? Should be moved to integration spec
   and removed from SVG 2

   krit: can we remove 15.3 and 15.4 totally?

   heycam: think in rendering chapter we need to describe how
   these things fit into the scheme of things

   nikos: I think rendering chapter should say at what point these
   things occur and that's all

   <ed> -- 15 min break --

   <Tav> scribe: tav

   <scribe> scribenick: Tav

   Rossen: , Let's cover issue in color chapter.

svg2 issues in the color chapter

   <cyril> s/Rossen,/Rossen:/


     [52] https://svgwg.org/svg2-draft/color.html#color-managed-images

   Rossen: Issue 1:
   ... should this be here?

   TabAtkins, : Should be in colors4.

   scribe: not in yet, will be soon.

   krit: What do we need to keep?

   Rossen: Tab, what do we need to keep?

   TabAtkins: Nothing.

   Rossen: Motion: move everything in this chapter to color4.


     [53] https://svgwg.org/svg2-draft/color.html#InterfaceSVGColorProfileRule

   krit: SVG Interface rule should disappear.

   ed: will icc-color be part of the <color> grammar in css?

   Rossen: Yes, should be in colors4.

   RESOLUTION: Drop SVG color profile rule interface.
   ... Remove color chapter from SVG 2. Refer to CSS Color 3 and

   <scribe> ACTION: TabAtkins Finish CSS Color 4 (with stuff from
   SVG). [recorded in

   <trackbot> Created ACTION-3748 - Finish css color 4 (with stuff
   from svg). [on Tab Atkins Jr. - due 2015-02-20].


     [55] https://svgwg.org/svg2-draft/types.html#InterfaceSVGCSSRule


     [56] https://svgwg.org/svg2-draft/types.html#InterfaceSVGRenderingIntent

Remove above two interfaces.

   ed: Should go.

   <ed> (to be clear, the entire room says that, not just me ;)

   RESOLVE: Remove InterfaceSVGCSSRule and

   Rossen: Only two chapters to go from heycam's list: painting &

Painting chapter issues

   <heycam> Scribe: Cameron

   <heycam> ScribeNick: heycam


     [57] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2015/Open_issues

   heycam: first two issues are to do with arcs line-join

   Tav: first issue is the name
   ... nobody suggested a different name
   ... so let's just leave it as is
   ... second one is what do you so with miter-limit
   ... now that we have this clipping option, ...
   ... it's possible to get a very long arc
   ... I would suggest that taking the mid point of the end of the
   stroke before the cap, then measure along the mid-arc the miter

   RESOLUTION: arc line caps are affected by miter-limit by
   measuring along the middle arc and clipping a straight line
   perpendicular at that point

   <scribe> ACTION: Tav to make miter-limit work on arc line caps
   in this way [recorded in

   <trackbot> Created ACTION-3749 - Make miter-limit work on arc
   line caps in this way [on Tavmjong Bah - due 2015-02-20].

   <Tav> Scribe: Tav

   <scribe> ScribeNick: Tav

Issue: stroke-dashcorner doesn't work well for rounded rects

   heycam: New feature in SVG 2. It's nice.
   ... look at pictures in section.


     [59] https://svgwg.org/svg2-draft/painting.html#StrokeDashcornerProperty

   heycam: Illustrator supports.

   krit: Illustator dashing different.

   heycam: Not the most important issue.

   krit: Could we have a stroking enhancement spec?
   ... would like to have a core with what is supported today.

   heycam: Not happy with pulling out stroking.

   ed, Rossen stroking should be well defined.

   krit: doesn't include stroke-alignment...

   Rossen: The fact that stroking will be well defined in SVG 2 we
   could still have a stroking spec.. What would be in it?

   heycam: I can summarize the new things:
   ... stroke-dashadjust
   ... stroke-dashcorner
   ... arcs line join
   ... stroke-alignment

   krit, tav: stroke-alignment often requested.

   tav: would like to have %

   Rossen: stroke-dashcorner: our (IE) implementation for stroking
   is pretty complicated, could be hard to do.

   krit: Used in illustrator.

   heycam: Can just stretch dash array.

   Rossen: We still don't have interopability with normal dashing

   roc: SVG stroking is actually rather simple.

   <ed> (in comparison to css border dashing)

   roc: We need an extensible stroking task force. Lots of neat
   things you can do.

   Rossen: Should there be a new module?
   ... What would be in the new SVG stroking module:

   ed: Variable width stroking.

   Rossen: That's a really cool feature.

   krit/Rossen Dashing and Variable width.

   Rossen: We extend in CSS specs with just one new value of a
   ... New specs should only add stuff that's not in already in
   SVG 2.

   krit: But what should we ship here for SVG 2?

   heycam: I think there are some things already implemented that
   should remain.

   Rossen: Should we start with stroke-dashcorner? (Moving to new

   heycam: Question at approach: we've been telling authors about
   these new things. How can we maintain the message that things
   will be coming at the same pace.

   Rossen: I think that moving things into modules sends the
   message that we can move faster than with a big SVG2 spec.

   krit: I'm happy to move out new marker stuff to new spec.

   heycam: There would be some overlap in text between specs.

   Rossen: there are modules that we would ship ahead of SVG2.
   ... Interlude: explains IE/Microsoft philosophy towards
   choosing what to ship.

   krit: Can we have a resolution having a painting module?
   ... put in paint-order

   ed: Don't think that's a good idea.

   tav: Would you (Rossen) implement 'paint-order' if it was in a
   separate spec?

   Rossen: Yes.

   ed: We could say that this section is stable.

   Rossen: It's not in a stable spec.

   Discussion of where things should go....

   Rossen: Should we start an SVG marker spec?

   heycam: I'm more concerned about public impression of SVG 2 if
   things get moved out.

   <shepazu> modularization is time consuming and confuses

   <ed> +1

   BogdanBrinza: What the SVG working group thinks is more
   important than public perception.

   <ed> (the time consuming part)

   heycam: Things in the past that have been split out tend to
   mean that we don't want to work on it.
   ... One advantage of splitting out is that we would have a well
   defined owner for the spec.

   Tav: A markers spec would be a good trial of this.

   ed: Not clear that a marker spec could move faster. There is a
   lot of stuff tied to SVG core.

   Rossen: having something in PR is much better than having some
   text in the bigger spec.
   ... saying this is stable.

   krit: marker knockout should be moved to a separate markers

   heycam: ignoring the marker knockout, the rest is pretty

   Proposal: Start a new marker spec.

   ed: Not so sure about this but won't object.

   tav: with eric

   heycam: Is willing to try it.

   RESOLUTION: Move new marker features to a separate marker spec.

   Rossen: We won't be discussing the following issues:

   <Rossen> ISSUE 23: what to do with marker knockouts

   <Rossen> ISSUE 18: name these vertex or segment markers?

   <Rossen> ISSUE 30: should paint-order be able to select the
   different types of markers?

   <Rossen> ISSUE 32: should SVGMarkerInstance objects be live?
   (or should we remove those interfaces?)

   Rossen: Let's get back to stroke-dashcorner for rounded rects.

   heycam: Dashing will move slower than markers. Dashing should
   move into a stroking spec.

   Moving on to text issues.

   Tav: Meta issue: how do we treat all the various text

   General discussion...

   Rossen: It would be reasonable to expect that paragraph level
   things would work. (text-indent, etc.)

   heycam: Properties that apply to inline elements should work.

   roc: some aren't appropriate perhaps.

   Rossen: overflow:scroll?

   ChrisL: Don't want a white list.

   krit: Text handled by normal code path.

   Rossen: So do we.
   ... In trident we have the concept of paragraphs that are like
   blocks with out the blocky stuff (padding, etc.)
   ... text alignment, writing mode, etc. are supported.
   ... underline, bold are handled in one level down.

   heycam: We should have a paragraph guiding our intentions so
   when new things come along they can be automatically included
   or excluded.

   Rossen: We could ask the CSS working group to add a term that
   defines paragraph level properties.

   roc: CSS does have the concept of anonymous blocks. We want
   everything that effects these blocks. But there is no name.

   krit: We should ask CSS for an "official" name.

   RESOLUTION: 'text-indent' applies to <text> as it is part of
   the CSS paragraph level properties.
   ... CSS Paragraph level properties are assume to apply to SVG
   <text> element with wrapping context.

   <heycam> Scribe: Cameron

   <heycam> ScribeNick: heycam

   Rossen: so that resolves issues 37 and 38
   ... shape-inside, shape-outside

   Tav: I think I know what to do with these now after discussing
   with CSS folks

   Rossen: I am the editor of that spec, too
   ... so the rest of the issues are shapes related
   ... issue 2, are dx/dy/rotate ignored for auto-wrapped text

   ChrisL: when would you want to do that

   heycam: never

   Tav: I would be fine with that

   ed: I agree

   ChrisL: those things were because we didn't have wrapping text
   ... and some people wanted to do "better" text on a path

   heycam: you could argue from consistency with single line text
   ... you could apply the positioning attributes to content area
   text just as easily
   ... but it won't be useful

   RESOLUTION: dx/dy/rotate are ignored for text with a wrapping

   Rossen: last, issue 4; should x/y specify the corner of the
   content area or the origin of the first glyph

   [Tav draws and shows the two options]

   Rossen: I suggest using extent rather than width/height
   ... then authors won't think you should be able to put both
   width and height

   RESOLUTION: Change width/height on <text> to extent

   <scribe> ACTION: Tav to make the text changes from today's
   meeting [recorded in

   <trackbot> Created ACTION-3750 - Make the text changes from
   today's meeting [on Tavmjong Bah - due 2015-02-20].

   RRSAgent: make minutes

Summary of Action Items

   [NEW] ACTION: Cameron to take care of overflow section in the
   masking chapter [recorded in
   [NEW] ACTION: ed to add use counter for multiple x/y values on
   text element [recorded in
   [NEW] ACTION: heycam to make stable issue identifiers in the
   spec [recorded in
   [NEW] ACTION: heycam to move Catmull-Rom to SVG path module
   [recorded in
   [NEW] ACTION: heycam to spec behaviour of getBBox on text
   [recorded in
   [NEW] ACTION: heycam to update spec for fill dictionary
   parameter when called on iframe, canvas, etc [recorded in
   [NEW] ACTION: jean-claude to further develop the protoype
   including with animation support [recorded in
   [NEW] ACTION: krit to add a new keyword value to the x and y
   properties that means use-the-list-of-lengths in the
   attributes, and set that with the UA stylesheet and add a note
   to say that it's still an open issue [recorded in
   [NEW] ACTION: krit to make defer be ignored in pAR [recorded in
   [NEW] ACTION: krit to review the svg2 coordinate chapter
   [recorded in
   [NEW] ACTION: TabAtkins Finish CSS Color 4 (with stuff from
   SVG). [recorded in
   [NEW] ACTION: Tav to add line-join:miter-clip to SVG 2.
   [recorded in
   [NEW] ACTION: Tav to add the new Z behaviour. [recorded in
   [NEW] ACTION: Tav to mail www-svg about the symbol
   x/y/width/height issue and report back in two weeks [recorded
   in [74]http://www.w3.org/2015/02/12-svg-minutes.html#action05]
   [NEW] ACTION: Tav to make miter-limit work on arc line caps in
   this way [recorded in
   [NEW] ACTION: Tav to make the text changes from today's meeting
   [recorded in
   [NEW] ACTION: Tav to update textPath for text on a shape.
   [recorded in

   [End of minutes]

Cameron McCormack ≝ http://mcc.id.au/

Received on Friday, 13 February 2015 07:05:16 UTC