SVG WG London F2F 2014 -- 23 Aug 2014

<krit> scribeNick: krit

Getting rid of uses of const enums in SVG DOM

ed: Ties in tinto disucssion yesterday
... would get rid of const enums from SVG DOM
... might fall out of SVG DOM removal
... I prefer replacing it by simple DOMStrings
... I am concerned about new units getting new values
... we did not expose these new values
... this causes complexity in implementation. which values are exposed, which aren't
... do we want do wait until we experimented with removing SVG DOM first?

heycam: would be interesting what is kept
... SVGTransform has individual enums as does SVGPath
... interested if they are used and useful

krit: no

ed: there are convertTo methods on SVGLength for instance
... same for SVGAngle and others

heycam: preseverveAspectRatio

krit: filters have a lot of these enumeration

heycam: we should keep SVGLength around every though we remove SVGAnimated objects

<heycam> http://www.w3.org/TR/SVG/types.html#__svg__SVGLength__convertToSpecifiedUnits

krit: don’t think that there is

heycam: there are some conversions used in SVGLength

krit: point is, people just convert to px

heycam: If you are able to remove SVGLength all together then….

krit: we should discuss enums in isolation from SVG DOM removal

heycam: yeah

ed: should we do it in addition?

heycam: in addition would be easy
... we could have type()
... and take then IDL enum type

ed: I added a unit turn to SVGAngle which is not exposed as an enum value in Blink

krit: for SVGLength alone we have a huge amount of new units
... which enumerations are you thinking about? In all IDL files or all of them?

ed: everywhere
... and use new unit types
... also, there is no way to know if an implementation is supporting certain units

heycam: could create a new SVGAngle object
... and apply “7turns"
... and look at the unit less value and look if it is 7

krit: for a short term it is reasonable

heycam: I wonder how many improvements should we do before knowing if we remove SVG DOM or not?

krit: Implementations removing SVG DOM now, obviously don’t need to care. The spec can still be ahead and change SVG DOM in case experiment fails

ed: we have the existing method take a number or string
... can you have multiple types on a property with WebIDL?

heycam: yes

<heycam> http://dev.w3.org/SVG/proposals/improving-svg-dom/#enumerations

krit: sure you want a string and not a enum value in the sense of WebIDL

heycam: I think you do

krit: they are still basically string with special exception handling

ed: yes, that is what i want

heycam: still wonder if it is worth to do now

ed: I think it is ok to have it in parallel

heycam: if we need to keep the object around and have new stuff….
... .. in my proposal I had a hard cut
... I suppose it makes sense if we need to keep SVG DOM

ed: I would still go ahead with both,… experimenting with removing SVG DOM and implement the new enum

krit: so you suppoty old enums and the new? where is the benefit for you? complexity stays?

ed: so I will probably remove the old const enums and replace it with new enums

krit: if you break the old one… do you think it is worth still having enums at all? will ppl move over?

ed: seeing where the experiment goes probably makes more sense
... ok, I’ll bring up the topic again

Raw cubic bezier coordinate list accessors

birtles: proposal was to add a method to get the points of a path as an array of dicts
... we talked about details in the past… open vs closed paths
... tow motivations: simplicity
... and performance
... in many implementations there is a perf hit from switching from JS to native code
... with Cameron’s DOM we get a bunch of dict objects as an array
... performance is less significant

Tav: can you handle arc?

birtles: approximations
... didn’t work out on details

Tav: how about markers

birtles: doesn’t take markers into account just path data
... same data structure for setting and getting on path generation

heycam: are there perf improvements with using types instead of arrays?

birtles: no
... I can still shim and implement it

heycam: do you have comparisons between my proposal and yours?

birtles: we can do that fairly easy
... seems worth while investigating
... question if we bother at all

heycam: think it is reasonable
... think the normalization is nice

birtles: we also do not implement normalized path segments in Mozilla

ChrisL: why?

krit: heycam: difficult to keep live objects in synch

birtles: also, it is an array of arrays
... because of subpaths

krit: I think for normalization you don’t care too much about precise results, but you want to have the same amount of segments with the same order
... that is where Opera Presto and WebKit behave totally different sometimes

shepazu: we should say how a basic shape transforms into a path

heycam: I didn’t do that yet

Tav: we had the discussion at least

krit: didn’t you do that for dash array heycam ?

<Rossen_> can somebody let me into the bldg please

heycam: yes, it would be a reason to support it

shepazu: do you have anything about animating shapes?

birtles: really do want to do that

shepazu: we are not going to make it perfect :)
... lets pick it up another time

<Tav> http://tavmjong.free.fr/blog/?p=741

action birtles Try implementing path data array and get performance numbers

<trackbot> Created ACTION-3645 - try implementing path data array and get performance numbers [on Brian Birtles - due 2014-08-30].

ISSUE: look into shape morphing

<trackbot> Created ISSUE-2461 - Look into shape morphing. Please complete additional details at <http://www.w3.org/Graphics/SVG/WG/track/issues/2461/edit>.

<heycam> ACTION: Make topic scripts capture actions and issues too. [recorded in http://www.w3.org/2014/08/23-svg-minutes.html#action01]

<trackbot> Error finding 'Make'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.

<heycam> ACTION: Cameron Make topic scripts capture actions and issues too. [recorded in http://www.w3.org/2014/08/23-svg-minutes.html#action02]

<trackbot> Created ACTION-3646 - Make topic scripts capture actions and issues too. [on Cameron McCormack - due 2014-08-30].

<Tav> https://stackoverflow.com/questions/9489736/catmull-rom-curve-with-no-cusps-and-no-self-intersections/23980479#23980479

<heycam> ACTION: Cameron to add math for Catmull-Rom curves to the spec [recorded in http://www.w3.org/2014/08/23-svg-minutes.html#action03]

<trackbot> Created ACTION-3647 - Add math for catmull-rom curves to the spec [on Cameron McCormack - due 2014-08-30].

<heycam> ACTION-3647: https://stackoverflow.com/questions/9489736/catmull-rom-curve-with-no-cusps-and-no-self-intersections/23980479#23980479

<trackbot> Notes added to ACTION-3647 Add math for catmull-rom curves to the spec.

<heycam> ACTION-3640: This should be done for symbol, marker and foreignObject.

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

<heycam> -- actions session --

<heycam> fg

<ed> bg

<ed> ^C^C^C

<ChrisL> issue-59?

<trackbot> Sorry, but issue-59 does not exist.

<ChrisL> issue-58?

<trackbot> Sorry, but issue-58 does not exist.

<cabanier> scribenick: cabanier

Catmull-Rom

cam: I added a section on Catmull-rom to the spec

<heycam> heyheycam has joined #svg

<heycam> https://svgwg.org/svg2-draft/paths.html#PathDataCatmullRomCommand

cam: syntax wise, I added just what Doug's polyfill said
... you need 3 coordinates
... the curves take a sequence of point and the path goes from the second control point to ???

shepazu: in my implementation, the first point is the moveto and the last 2 points are the same
... technically it needs an extra control point

(lots of discussion at the whiteboard)

shepazu: I suggest that we have 2 point

heycam: I think it should be a minimum of 1 point

shepazu: then it should be a line
... I agree that it should only be 1 point

heycam: the spec at the moment, if the previous is a moveto...

ChrisL: I think there should be a minimum of 2. (draws on whiteboard)
... you always need 4 points
... you always go between 2nd and third point
... you make up first and last by doing the tangent
... you always start drawing from the first point
... you can do a fictitious last point

shepazu: the point you start from is the last point from the previous

heycam: it's the current point

ChrisL: yes
... currentpoint is inferred

ed: what would it look like if you do a circle

Tav: would 4 points make a circle?

shepazu: I don't think so?

Tav: how do I close the path?

ChrisL: closepath will be a straight line
... to do it smoothly we need a different symbol
... which is a new requirement

shepazu: I don't agree
... that is not the point of this

ChrisL: suppose you draw a set of CR pieces, he wants a new command that does the continuity

shepazu: so, I understand what Tav is asking for but I'd rather not take on that requirement since it makes the model so complex
... you can do it. we don't have it for beziers

ChrisL: I don't agree. you just get the data differently

shepazu: I would like to split it into 2 different issues
... CR and the issue of soft closing
... I can see a reasonable additional command that closes smoothly
... for instance 'y' and possible reuse the catmull rom algorithm
... we rejected tangient parameter to keep it simple
... we just want point

<krit> RRSAgent: q+

Tav: in order to make a closed path you might need to choose
... given a circle a, b,c,d you may want to consider point d to do a smooth close to point a
... you might want to consider d to a, to draw a to b

shepazu: why do you want it to be a circle?

tav: I don't. it can be any shape

shepazu: rather than treat this a catmull-rom curve, let's call this a smooth closed path
... and it would act differently if it was a bezier

ChrisL: not quite

shepazu: catmull rom is the only one where the previous point changes the next point

(more heated discussion)

heycam: if you have beziers it's not always possible to calculate the point

krit: why does inkscape need it?

Tav: it doesn't

krit: as an implementor, I don't need this and wouldn't implement

ChrisL: are you making an informed decision?

krit: can you do it today with bezier?

ChrisL: given an arbitrary sequence of points can you today make a smooth curve through them?

heycam: yes, we can use beziers.

ChrisL: and the group agreed to do it

krit: that doesn't really matter.

ChrisL: so you don't want new features in SVG?

<Rossen_> The circle of Tav https://onedrive.live.com/redir?resid=DA0535041C44EB4D!26327&authkey=!AL_LeXmaTwrSbZc&v=3&ithint=photo%2cjpg

krit: I didn't say that?

ChrisL: are you opposed to new features

jwatt: are you against bezier curves?

Tav: it's about authors just doing smooth graphs
... and I'm against it because it will be used incorrectly

ChrisL: people can do a lot of things wrong

krit: is catmull rom the best algorithm?
... it's the most known

shepazu: and the easiest to do
... but it's not trivial to do

krit: but you can do it with bezier unlike with line to approximate beziers

shepazu: I'd like to stay with the resolution that we'll implement this
... everytime I mention this, people like it
... authors have asked for this
... what is the point of your objection?
... if you have a better implementation, please put it forward

krit: I think we have primitives to do this.

shepazu: let's not waste f2f time on this

krit: there's no proposal.
... we've discussed this many times already

shepazu: that is inaccurate. you're trying to knock us back

ChrisL: we have a formula and a couple of issues

heycam: I think we should talk about the issues

shepazu: the smooth close path is a separate issue

ChrisL: agreed

shepazu: I would be ok to do a smooth closed path command

tav: inkscape has that problem, but I don't want to distract
... a smooth bezier to catmull-rom transition
... you can get the first point from the handle

ChrisL: I propose that we'll just address the issues
... should we add a tension parameter?

resolution: Catmull-Rom will not add a tension parameter and will stay with the standard
... Catmull-Rom will not add a tension parameter and will stay with the standard parameters
... should we allow less than three coordinate pairs?

heycam: if you're building up a path, you need them

<shepazu> http://schepers.cc/svg/path/dotty.svg

ChrisL: as long as we define what it is so we don't get degenerate behavior
... one point is a straight line from the current point
... two points will give you a smooth curve

RESOLUTION: the r command will take at mimum 1 coordinate pair that will draw a straight line

ChrisL: issue 8 is no longer a problem then
... the moving without drawing anything was solved by the previous resolution

<ed> (for reference, issue 8 was: "Is it a problem that the command will move then pen from the current position to (x1, y1) without drawing anything? If so, should we made the first control point explicit in the command rather than implicitly taken from the current position? That would then mirror the behavior written above for how the current position is left at the second-last control point.")

heycam: I think it's more about having the implicit points

ChrisL: we now move what multiple r commands means
... a single r with give you continuity
... by having multiple ones, you will not get the continuity

shepazu: I don't really like that. it's a bit confusing

ChrisL: if it didn't have that behavior it would act as if it was one command

heycam: I think I prefer that each r is its own smooth curve

Tav: bezier to catmull rom needs a way to break it

ChrisL: can we agree that we don't get continuity

heycam: a new r command will not be continuous with the previous?

shepazu: I agree with that

RESOLUTION: multiple R commands will not have curve continuity between them

ChrisL: issue 9: Where should we link to for a definition of Catmull-Rom curves so that we don't have to redefine them here?
... there's a wikipedia with the math

heycam: there were a couple of different options

<ChrisL> http://en.wikipedia.org/wiki/Centripetal_Catmull%E2%80%93Rom_spline

heycam: mostly about the implicit begin and end points

Tav: they're mostly about how to avoid loops

ChrisL: I propose to use the Centripetal one from the wikipedia article

heycam: I think that's a good idea
... I'm going to read up on it
... do we want the formulation that doesn't introduce the loops and cusps?

<heycam> https://stackoverflow.com/questions/9489736/catmull-rom-curve-with-no-cusps-and-no-self-intersections/23980479#23980479

RESOLUTION: catmull-rom will use the formula that doesn't introduce the loops and cusps

Tav: the stackoverflow with the six votes is the one we want

shepazu: can we also put in the spec on how to deform this to beziers?

heycam: we don't have to do that
... informally, it might be good to have it

shepazu: can we call it 'p' instead of 'r'?

heycam: it doesn't really matter

ChrisL: sure

jwatt: I want more than one letter

ChrisL: people don't really care

heycam: people will just fiddle with it

RESOLUTION: the name of the Catmull-Rom command is 'p' reflecting 'points'

heycam: one final issue is that we should decide that we get the implicit points from the tangent

shepazu: wasn't there a good pdf?

ChrisL: yes, I will drop it in

<ChrisL> http://www.cemyuksel.com/research/catmullrom_param/catmullrom.pdf

heycam: this does limit the set of curves that you can produce

shepazu: I would contend that you're not looking for precision but convenience

heycam: that's reasonable
... so, at the start of the p command and the previous is a curve, how do you determine the preceding point?
... if it's cubic or quadratic, since we have the control point, we will use that
... if we don't, we continue the line and use the point from the same distance

cabanier: do you need to remember an extra point?

heycam: you have to do that anyway
... to summarize: if you have a previous command other than 'p', the implicit first point is based on the tangent just preceding the curve
... you always know the one coming in if it's a line or curve

shepazu: can you come back with a more concrete proposal?

heycam: I'll make an issue in the spec

<heycam> ScribeNick: heycam

Parameterised SVG

jwatt: we have a need that I want to discuss
... it stems from Firefox OS people who need performance, and keep memory usage down -- they use icon fonts
... I'd like to move them away from icon fonts towards using SVG
... I ran through some alternatives to make performance of SVG-in-<img> enough for their needs
... I think we can get close to that, but one thing they want is to be able to do what they do with icon fonts
... the color font on the <span> element they apply the font to, can be used to style the content of the icon
... right now we have no mechanism to do that

ChrisL: not any style across that boundary

jwatt: they want to have a way to reference out of the SVG to get a computed value
... or pass it in, either way
... they want to do it with CSS selectors, so set a property on it
... rather than like the params spec, where you have to add something to the query string or param elements

heycam: why?

jwatt: because that's going to be more convenient to theme things

shepazu: the way I've rethought parameters, in the context of CSS Variables --
... params consisted of two things. the way to specify how you pass the things into the file, the second was how to propagate those values and use them in the file
... they're two separate problems
... I think Variables are probably good enough for the second half
... I'm proposing we're left with the problem of the behaviour of passing the values in, and/or having implicit behaviour
... I don't care if parameters are explicitly declared, or if you can implicitly extract them from the context
... both seem reasonable to me

krit: my question first is, does it need to be <img>? can it be <object>?
... <img> has security implications
... the webapps sec wg asked us not to have selectors
... you could change the appearance of things in the document, and thus time things
... <object> doesn't have these restrictions
... not only timing attacks, but tricking with the appearance

shepazu: [explains the :visited style restriction]

jwatt: a mechanism other than the document reaching in and styling stuff would be sufficient

shepazu: for the SVG document to be able to say what things change under what circumstance

<ChrisL> itslike passing a bundle of computed style values across the boundary for re-use in styling the image

jwatt: essentially what they need for parity with icon fonts, is to be able to get the computed value of the color property

shepazu: currently in params you explicitly have a name/value pair
... color=foo, foo=orange
... then in the image you use "foo"
... we could have keywords that say you want to pass in the color and the background-color, then the SVG file says how to use those
... my original proposal was saying name/value pairs, but now you choose the set of values you pass in
... let's say the icon wants to use the background-color of the page as the foreground color in the image
... and the color from the document as some accent in the icon
... on the outside you pass in background-color and color
... on the inside you use those two things whereever you need them

heycam: [explains how context-fill and palette variable work in SVG-in-OpenType fonts]

krit: people want to use @media queries based on width/height. not sure if passing width/height into that would help with that?

Rossen_: you could tie in the vw/vh values to that

shepazu: thinking outside the icon use case for a second
... [draws a spark line]
... I want to pass in the values in the spark line to the SVG <img>
... not propose that we do this, but it's the sort of thing you could allow if you support more than just color passing in
... two good things about icons, they take on the context size and color
... but you can't pass in multiple styles, and they aren't responsive
... if the icon is big I want more detail

krit: does it need to be <img>?

jwatt: for us we want it to be possible with <img> because we are able to optimize <img> that we can't do with <object>
... we want to be able to get rid of as much memory as possible for small devices

birtles: if it's <object> you can do it all in script anyway

heycam: unless it's cross domain

jwatt: our people want parity. so the parameterisation that allows more than just style property mapping sounds like a bigger thing to nail down.

shepazu: I have also heard from people wanting to use SVG as an icon that at different sizes you get different crispness things
... when we're trying to solve icons as SVG that's another thing to discus

<jwatt> https://svgwg.org/svg2-draft/intro.html#TermContextElement

jwatt: is it acceptable to have the context element be the <img> referencing the SVG?

heycam: I would say only if you opt in to that

krit: I agree

ChrisL: so maybe foo.svg#context-fill=currentColor

krit: can we just say the fill and stroke applied to the image? they don't do anything on image

jwatt: it's problematic if you need an opt in
... well not sure how big a problem
... this person wants to be able to change style sheet to say all img are fill:red
... he doesn't want to add something to each <img> element
... I want it to be opt in in the SVG, but not in the embedding document

shepazu: I think both
... img { context-fill: currentColor; context-stroke: red; }

p { color: blue; }

<p> <img> ...

jwatt: what about one property that represents the set of properties that can be accessed
... you could have a list of the properties

heycam: will-pass-through: color, background-color;

krit: you could also list a custom property

shepazu: "parameters" might be a good name for it

ChrisL: sounds like we have agreement on a principle, can discuss the name

jwatt: what about same origin <img>s? can we avoid the opt in from the outside?
... what about not having to write { pass-through: context-fill, ... } for same origin images
... it would be less standardisation effort

shepazu: I'd like this to apply to other cases like <use>

krit: this is one specific use case from a pool of use cases

shepazu: I think the mitigating factor is that what jonathan is asking for the minimal support for context-fill use in the <img> document
... this is not going to restrict us from doing more expansive things in the future
... this is just the simplest case of it
... so it doesn't lock us out of other solutions in the future

krit: I tend to agree

Rossen_: I'm not sure. I wanted to get back to the opening remarks -- you're after this because of performance and memory pressure from using fonts?

jwatt: no, fonts is good. I want embedded SVG closer to the performance of fonts.
... this is so they can do theming of icons without having to go through each icon element

Rossen_: so the performance memory relief will come later on

jwatt: yes that's a different thing
... if the feature parity barriers are eliminated, then there is value in us pushing memory usage down

ChrisL: one obvious benefit from icon fonts is you get them all from one file

jwatt: you can use fragment IDs to get that same benefit

<ChrisL> yes, agreed using fragment ids

krit: presumably you share images across documents. is it safe to share these across?

jwatt: that's an implementation detail for us to make sure it's not possible to get the wrong images in other documents
... so for now I want to go ahead with same origin context-fill/context-stroke with <img> being the context element

shepazu: short of us thinking through that the expanded uses are ok, we can agree that it will be ok with <img> same origin

krit: is there something we need from the HTML WG on this?

heycam: probably not

krit: worried about others saying no after jwatt goes ahead with this

Rossen_: I wouldn't necessarily object to it, I'm just not sure if/how sufficient this is

ed: I agree with Rossen. I've used params myself for passing strings e.g. across, that wouldn't be covered by this

heycam: would we do this for all of the context-* values?

jwatt: would think for consistency it would be all

shepazu: maybe just limit it to context-fill/context-stroke for now

jwatt: I don't think the spec decisions should be driven by Firefox OS deadlines

Rossen_: if the general intent was to probe the temperature for this, I wouldn't stop with proceeding
... with your implementation
... push it to your nightlies, tryi t out
... to reiterate your situation, you want to start driving on perf
... to do this you need to allow this one property passing
... try it out
... I don't think there's strong pushback

- DRAFT -

SVG WG London F2F 2014

23 Aug 2014

Attendees

Contents

Getting rid of uses of const enums in SVG DOM

Raw cubic bezier coordinate list accessors

Catmull-Rom

Parameterised SVG

Summary of Action Items

Scribe.perl diagnostic output