IRC log of svg on 2014-08-23

Timestamps are in UTC.

07:25:14 [Tav]
Tav has joined #svg
08:01:39 [nikos]
nikos has joined #svg
08:12:14 [shepazu]
shepazu has joined #svg
08:21:22 [nikos]
nikos has joined #svg
08:32:24 [heycam]
Chair: Cameron
08:32:33 [heycam]
Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda
08:33:33 [ed]
Meeting: SVG WG London F2F 2014
08:34:09 [krit]
scribeNick: krit
08:34:50 [krit]
topic: Getting rid of uses of const enums in SVG DOM
08:35:04 [krit]
ed: Ties in tinto disucssion yesterday
08:35:15 [krit]
ed: would get rid of const enums from SVG DOM
08:35:22 [krit]
ed: might fall out of SVG DOM removal
08:35:40 [krit]
ed: I prefer replacing it by simple DOMStrings
08:35:55 [krit]
ed: I am concerned about new units getting new values
08:36:02 [krit]
ed: we did not expose these new values
08:36:26 [krit]
ed: this causes complexity in implementation. which values are exposed, which aren't
08:36:52 [krit]
ed: do we want do wait until we experimented with removing SVG DOM first?
08:37:01 [krit]
heycam: would be interesting what is kept
08:37:57 [krit]
heycam: SVGTransform has individual enums as does SVGPath
08:38:08 [krit]
heycam: interested if they are used and useful
08:38:11 [krit]
krit: no
08:38:34 [krit]
ed: there are convertTo methods on SVGLength for instance
08:38:40 [krit]
ed: same for SVGAngle and others
08:38:56 [krit]
heycam: preseverveAspectRatio
08:39:14 [konno]
konno has joined #svg
08:39:15 [krit]
krit: filters have a lot of these enumeration
08:40:26 [tkonno]
tkonno has joined #svg
08:40:37 [krit]
heycam: we should keep SVGLength around every though we remove SVGAnimated objects
08:40:38 [heycam]
http://www.w3.org/TR/SVG/types.html#__svg__SVGLength__convertToSpecifiedUnits
08:40:46 [krit]
krit: don’t think that there is
08:40:58 [krit]
heycam: there are some conversions used in SVGLength
08:41:16 [krit]
krit: point is, people just convert to px
08:41:31 [krit]
heycam: If you are able to remove SVGLength all together then….
08:41:54 [krit]
krit: we should discuss enums in isolation from SVG DOM removal
08:41:56 [krit]
heycam: yeah
08:42:08 [krit]
ed: should we do it in addition?
08:42:16 [krit]
heycam: in addition would be easy
08:42:23 [krit]
heycam: we could have type()
08:42:33 [krit]
heycam: and take then IDL enum type
08:43:01 [krit]
ed: I added a unit turn to SVGAngle which is not exposed as an enum value in Blink
08:43:36 [krit]
krit: for SVGLength alone we have a huge amount of new units
08:44:04 [krit]
krit: which enumerations are you thinking about? In all IDL files or all of them?
08:44:09 [krit]
ed: everywhere
08:44:16 [krit]
ed: and use new unit types
08:44:42 [krit]
ed: also, there is no way to know if an implementation is supporting certain units
08:45:28 [krit]
heycam: could create a new SVGAngle object
08:45:36 [krit]
heycam: and apply “7turns"
08:45:53 [krit]
heycam: and look at the unit less value and look if it is 7
08:45:55 [Tav]
Tav has joined #svg
08:46:06 [krit]
krit: for a short term it is reasonable
08:46:49 [krit]
heycam: I wonder how many improvements should we do before knowing if we remove SVG DOM or not?
08:47:26 [krit]
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
08:47:59 [krit]
ed: we have the existing method take a number or string
08:48:38 [krit]
ed: can you have multiple types on a property with WebIDL?
08:48:40 [krit]
heycam: yes
08:49:03 [heycam]
http://dev.w3.org/SVG/proposals/improving-svg-dom/#enumerations
08:49:12 [krit]
krit: sure you want a string and not a enum value in the sense of WebIDL
08:49:19 [krit]
heycam: I think you do
08:49:41 [krit]
krit: they are still basically string with special exception handling
08:49:48 [krit]
ed: yes, that is what i want
08:50:01 [krit]
heycam: still wonder if it is worth to do now
08:50:31 [krit]
ed: I think it is ok to have it in parallel
08:50:52 [krit]
heycam: if we need to keep the object around and have new stuff….
08:51:03 [krit]
heycam: .. in my proposal I had a hard cut
08:51:16 [krit]
heycam: I suppose it makes sense if we need to keep SVG DOM
08:53:03 [krit]
ed: I would still go ahead with both,… experimenting with removing SVG DOM and implement the new enum
08:53:33 [krit]
krit: so you suppoty old enums and the new? where is the benefit for you? complexity stays?
08:54:17 [krit]
ed: so I will probably remove the old const enums and replace it with new enums
08:54:36 [krit]
krit: if you break the old one… do you think it is worth still having enums at all? will ppl move over?
08:54:55 [krit]
ed: seeing where the experiment goes probably makes more sense
08:56:15 [krit]
ed: ok, I’ll bring up the topic again
09:06:47 [krit]
topic: Raw cubic bezier coordinate list accessors
09:08:08 [krit]
birtles: proposal was to add a method to get the points of a path as an array of dicts
09:08:23 [krit]
birtles: we talked about details in the past… open vs closed paths
09:08:30 [ChrisL]
ChrisL has joined #svg
09:08:32 [krit]
birtles: tow motivations: simplicity
09:08:37 [krit]
birtles: and performance
09:08:55 [krit]
birtles: in many implementations there is a perf hit from switching from JS to native code
09:09:22 [krit]
birtles: with Cameron’s DOM we get a bunch of dict objects as an array
09:09:35 [krit]
birtles: performance is less significant
09:09:44 [krit]
Tav: can you handle arc?
09:09:49 [krit]
birtles: approximations
09:09:57 [krit]
birtles: didn’t work out on details
09:10:03 [krit]
Tav: how about markers
09:10:15 [krit]
birtles: doesn’t take markers into account just path data
09:10:32 [krit]
birtles: same data structure for setting and getting on path generation
09:11:14 [krit]
heycam: are there perf improvements with using types instead of arrays?
09:11:16 [krit]
birtles: no
09:11:57 [krit]
birtles: I can still shim and implement it
09:12:10 [krit]
heycam: do you have comparisons between my proposal and yours?
09:12:18 [krit]
birtles: we can do that fairly easy
09:12:26 [krit]
birtles: seems worth while investigating
09:12:33 [oslego]
oslego has joined #svg
09:12:36 [krit]
birtles: question if we bother at all
09:12:44 [krit]
heycam: think it is reasonable
09:13:08 [krit]
heycam: think the normalization is nice
09:13:50 [krit]
birtles: we also do not implement normalized path segments in Mozilla
09:13:55 [krit]
ChrisL: why?
09:14:11 [krit]
krit: heycam: difficult to keep live objects in synch
09:15:01 [krit]
birtles: also, it is an array of arrays
09:15:30 [krit]
birtles: because of subpaths
09:19:22 [krit]
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
09:19:43 [krit]
krit: that is where Opera Presto and WebKit behave totally different sometimes
09:20:44 [krit]
shepazu: we should say how a basic shape transforms into a path
09:20:51 [krit]
heycam: I didn’t do that yet
09:21:12 [krit]
Tav: we had the discussion at least
09:21:13 [Rossen_]
Rossen_ has joined #svg
09:21:42 [krit]
krit: didn’t you do that for dash array heycam ?
09:21:45 [Rossen_]
can somebody let me into the bldg please
09:21:51 [krit]
heycam: yes, it would be a reason to support it
09:23:35 [krit]
shepazu: do you have anything about animating shapes?
09:23:41 [krit]
birtles: no don’t want to do that
09:24:18 [krit]
s/no don’t want to do that/really do want to do that/
09:25:49 [krit]
shepazu: we are not going to make it perfect :)
09:26:02 [krit]
shepazu: lets pick it up another time
09:27:13 [Tav]
http://tavmjong.free.fr/blog/?p=741
09:27:23 [krit]
action birtles Try implementing path data array and get performance numbers
09:27:23 [trackbot]
Created ACTION-3645 - try implementing path data array and get performance numbers [on Brian Birtles - due 2014-08-30].
09:28:06 [krit]
ISSUE: look into shape morphing
09:28:06 [trackbot]
Created ISSUE-2461 - Look into shape morphing. Please complete additional details at <http://www.w3.org/Graphics/SVG/WG/track/issues/2461/edit>.
09:28:28 [heycam]
ACTION: Make topic scripts capture actions and issues too.
09:28:28 [trackbot]
Error finding 'Make'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.
09:28:31 [heycam]
ACTION: Cameron Make topic scripts capture actions and issues too.
09:28:32 [trackbot]
Created ACTION-3646 - Make topic scripts capture actions and issues too. [on Cameron McCormack - due 2014-08-30].
09:38:45 [Tav]
https://stackoverflow.com/questions/9489736/catmull-rom-curve-with-no-cusps-and-no-self-intersections/23980479#23980479
09:41:32 [tkonno]
tkonno has joined #svg
09:42:43 [heycam]
ACTION: Cameron to add math for Catmull-Rom curves to the spec
09:42:43 [trackbot]
Created ACTION-3647 - Add math for catmull-rom curves to the spec [on Cameron McCormack - due 2014-08-30].
09:42:47 [heycam]
ACTION-3647: https://stackoverflow.com/questions/9489736/catmull-rom-curve-with-no-cusps-and-no-self-intersections/23980479#23980479
09:42:47 [trackbot]
Notes added to ACTION-3647 Add math for catmull-rom curves to the spec.
09:49:19 [heycam]
ACTION-3640: This should be done for symbol, marker and foreignObject.
09:49:19 [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).
09:50:59 [nikos]
nikos has joined #svg
09:53:36 [heycam]
-- actions session --
10:05:22 [nikos]
nikos has joined #svg
10:10:45 [jwatt]
jwatt has joined #svg
10:44:25 [ChrisL]
ChrisL has joined #svg
10:45:29 [tkonno_]
tkonno_ has joined #svg
10:48:41 [Rossen_]
Rossen_ has joined #svg
10:51:14 [nikos]
nikos has joined #svg
10:54:32 [jwatt]
jwatt has joined #svg
11:06:01 [heycam]
RRSAgent, make minutes
11:06:01 [RRSAgent]
I have made the request to generate http://www.w3.org/2014/08/23-svg-minutes.html heycam
11:06:08 [heycam]
fg
11:09:45 [ed]
bg
11:10:18 [ed]
^C^C^C
11:42:23 [nikos_]
nikos_ has joined #svg
12:50:23 [heycam]
heycam has joined #svg
13:55:47 [tkonno]
tkonno has joined #svg
14:00:06 [heycam]
heycam has joined #svg
14:09:48 [ChrisL]
issue-59?
14:09:48 [trackbot]
Sorry, but issue-59 does not exist.
14:10:09 [ChrisL]
issue-58?
14:10:09 [trackbot]
Sorry, but issue-58 does not exist.
14:11:59 [nikos]
nikos has joined #svg
14:13:44 [tkonno]
tkonno has joined #svg
14:17:01 [cabanier]
scribenick: cabanier
14:17:17 [cabanier]
topic: Catmull-Rom
14:17:49 [cabanier]
cam: I added a section on Catmull-rom to the spec
14:17:53 [Rossen_]
Rossen_ has joined #svg
14:18:45 [heycam]
heycam has joined #svg
14:18:57 [cabanier]
s/cam/heycam
14:18:59 [heycam]
https://svgwg.org/svg2-draft/paths.html#PathDataCatmullRomCommand
14:19:23 [cabanier]
... syntax wise, I added just what Doug's polyfill said
14:19:28 [cabanier]
... you need 3 coordinates
14:21:07 [cabanier]
... the curves take a sequence of point and the path goes from the second control point to ???
14:21:41 [cabanier]
shepazu: in my implementation, the first point is the moveto and the last 2 points are the same
14:22:08 [cabanier]
... technically it needs an extra control point
14:22:50 [cabanier]
(lots of discussion at the whiteboard)
14:24:28 [cabanier]
shepazu: I suggest that we have 2 point
14:25:07 [cabanier]
heycam: I think it should be a minimum of 1 point
14:25:18 [cabanier]
shepazu: then it should be a line
14:25:59 [cabanier]
... I agree that it should only be 1 point
14:26:09 [nikos_]
nikos_ has joined #svg
14:26:28 [cabanier]
heycam: the spec at the moment, if the previous is a moveto...
14:26:47 [cabanier]
ChrisL: I think there should be a minimum of 2. (draws on whiteboard)
14:27:51 [cabanier]
... you always need 4 points
14:28:10 [cabanier]
... you always go between 2nd and third point
14:28:21 [cabanier]
... you make up first and last by doing the tangent
14:28:31 [cabanier]
... you always start drawing from the first point
14:28:43 [cabanier]
.... you can do a fictitious last point
14:28:58 [cabanier]
shepazu: the point you start from is the last point from the previous
14:29:03 [cabanier]
heycam: it's the current point
14:29:07 [cabanier]
ChrisL: yes
14:29:17 [cabanier]
... currentpoint is inferred
14:29:27 [cabanier]
ed: what would it look like if you do a circle
14:29:46 [cabanier]
Tav: would 4 points make a circle?
14:29:53 [cabanier]
shepazu: I don't think so?
14:30:04 [cabanier]
Tav: how do I close the path?
14:30:26 [cabanier]
ChrisL: closepath will be a straight line
14:30:38 [cabanier]
... to do it smoothly we need a different symbol
14:30:45 [cabanier]
... which is a new requirement
14:30:51 [cabanier]
shepazu: I don't agree
14:31:00 [cabanier]
... that is not the point of this
14:31:30 [cabanier]
ChrisL: suppose you draw a set of CR pieces, he wants a new command that does the continuity
14:32:56 [shepazu]
q+
14:33:30 [cabanier]
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
14:33:41 [cabanier]
... you can do it. we don't have it for beziers
14:33:54 [cabanier]
ChrisL: I don't agree. you just get the data differently
14:34:12 [cabanier]
shepazu: I would like to split it into 2 different issues
14:34:27 [cabanier]
... CR and the issue of soft closing
14:34:58 [cabanier]
... I can see a reasonable additional command that closes smoothly
14:35:20 [cabanier]
... for instance 'y' and possible reuse the catmull rom algorithm
14:35:50 [cabanier]
... we rejected tangient parameter to keep it simple
14:35:58 [cabanier]
... we just want point
14:36:23 [krit]
RRSAgent: q+
14:36:23 [RRSAgent]
I'm logging. I don't understand 'q+', krit. Try /msg RRSAgent help
14:36:28 [cabanier]
Tav: in order to make a closed path you might need to choose
14:36:31 [krit]
Zakim, q+
14:37:38 [cabanier]
... given a circle a, b,c,d you may want to consider point d to do a smooth close to point a
14:38:02 [cabanier]
... you might want to consider d to a, to draw a to b
14:38:22 [cabanier]
shepazu: why do you want it to be a circle?
14:38:33 [cabanier]
tav: I don't. it can be any shape
14:38:58 [cabanier]
shepazu: rather than treat this a catmull-rom curve, let's call this a smooth closed path
14:39:21 [cabanier]
... and it would act differently if it was a bezier
14:39:27 [cabanier]
ChrisL: not quite
14:39:36 [krit]
q+
14:39:55 [cabanier]
shepazu: catmull rom is the only one where the previous point changes the next point
14:40:26 [krit]
q+
14:40:36 [cabanier]
(more heated discussion)
14:41:41 [cabanier]
heycam: if you have beziers it's not always possible to calculate the point
14:41:59 [cabanier]
krit: why does inkscape need it?
14:42:04 [cabanier]
Tav: it doesn't
14:42:19 [cabanier]
krit: as an implementor, I don't need this and wouldn't implement
14:42:30 [cabanier]
ChrisL: are you making an informed decision?
14:42:46 [cabanier]
krit: can you do it today with bezier?
14:43:15 [cabanier]
ChrisL: given an arbitrary sequence of points can you today make a smooth curve through them?
14:43:29 [cabanier]
heycam: yes, we can use beziers.
14:43:39 [cabanier]
ChrisL: and the group agreed to do it
14:43:50 [cabanier]
krit: that doesn't really matter.
14:44:06 [cabanier]
ChrisL: so you don't want new features in SVG?
14:44:09 [Rossen_]
The circle of Tav https://onedrive.live.com/redir?resid=DA0535041C44EB4D!26327&authkey=!AL_LeXmaTwrSbZc&v=3&ithint=photo%2cjpg
14:44:13 [cabanier]
krit: I didn't say that?
14:44:33 [cabanier]
ChrisL: are you opposed to new features
14:45:15 [cabanier]
jwatt: are you against bezier curves?
14:46:25 [cabanier]
Tav: it's about authors just doing smooth graphs
14:46:48 [cabanier]
... and I'm against it because it will be used incorrectly
14:47:02 [cabanier]
ChrisL: people can do a lot of things wrong
14:47:30 [cabanier]
krit: is catmull rom the best algorithm?
14:47:35 [cabanier]
... it's the most known
14:47:45 [cabanier]
shepazu: and the easiest to do
14:48:15 [cabanier]
... but it's not trivial to do
14:48:37 [cabanier]
krit: but you can do it with bezier unlike with line to approximate beziers
14:49:16 [cabanier]
shepazu: I'd like to stay with the resolution that we'll implement this
14:49:32 [cabanier]
... everytime I mention this, people like it
14:49:43 [cabanier]
... authors have asked for this
14:50:02 [cabanier]
... what is the point of your objection?
14:50:30 [cabanier]
... if you have a better implementation, please put it forward
14:50:43 [cabanier]
krit: I think we have primitives to do this.
14:51:03 [cabanier]
shepazu: let's not waste f2f time on this
14:51:23 [cabanier]
krit: there's no proposal.
14:51:38 [cabanier]
... we've discussed this many times already
14:52:03 [cabanier]
shepazu: that is inaccurate. you're trying to knock us back
14:52:15 [cabanier]
ChrisL: we have a formula and a couple of issues
14:52:27 [cabanier]
heycam: I think we should talk about the issues
14:52:44 [cabanier]
shepazu: the smooth close path is a separate issue
14:52:50 [cabanier]
ChrisL: agreed
14:53:24 [cabanier]
shepazu: I would be ok to do a smooth closed path command
14:54:16 [ChrisL]
Q= to propose solutions to the issues in 9.3.8
14:54:16 [cabanier]
tav: inkscape has that problem, but I don't want to distract
14:54:26 [ChrisL]
q+ to propose solutions to the issues in 9.3.8
14:54:50 [cabanier]
... a smooth bezier to catmull-rom transition
14:55:20 [cabanier]
... you can get the first point from the handle
14:56:14 [cabanier]
ChrisL: I propose that we'll just address the issues
14:56:28 [cabanier]
... should we add a tension parameter?
14:57:29 [cabanier]
resolution: Catmull-Rom will not add a tension parameter and will stay with the standard
14:58:04 [cabanier]
RESOLUTION: Catmull-Rom will not add a tension parameter and will stay with the standard parameters
14:58:40 [cabanier]
... should we allow less than three coordinate pairs?
14:58:59 [cabanier]
heycam: if you're building up a path, you need them
14:59:15 [shepazu]
http://schepers.cc/svg/path/dotty.svg
14:59:22 [cabanier]
ChrisL: as long as we define what it is so we don't get degenerate behavior
15:00:25 [cabanier]
... one point is a straight line from the current point
15:00:38 [cabanier]
... two points will give you a smooth curve
15:03:47 [cabanier]
RESOLUTION: the r command will take at mimum 1 coordinate pair that will draw a straight line
15:04:14 [cabanier]
ChrisL: issue 8 is no longer a problem then
15:04:43 [cabanier]
.... the moving without drawing anything was solved by the previous resolution
15:04:53 [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.")
15:04:56 [cabanier]
heycam: I think it's more about having the implicit points
15:05:32 [cabanier]
ChrisL: we now move what multiple r commands means
15:05:50 [cabanier]
... a single r with give you continuity
15:06:10 [cabanier]
... by having multiple ones, you will not get the continuity
15:06:55 [cabanier]
shepazu: I don't really like that. it's a bit confusing
15:07:16 [cabanier]
ChrisL: if it didn't have that behavior it would act as if it was one command
15:07:34 [cabanier]
heycam: I think I prefer that each r is its own smooth curve
15:07:49 [cabanier]
Tav: bezier to catmull rom needs a way to break it
15:08:09 [cabanier]
ChrisL: can we agree that we don't get continuity
15:08:33 [cabanier]
heycam: a new r command will not be continuous with the previous?
15:08:38 [cabanier]
shepazu: I agree with that
15:09:26 [cabanier]
RESOLUTION: multiple R commands will not have curve continuity between them
15:10:34 [cabanier]
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?
15:10:51 [cabanier]
... there's a wikipedia with the math
15:10:59 [cabanier]
heycam: there were a couple of different options
15:11:21 [ChrisL]
http://en.wikipedia.org/wiki/Centripetal_Catmull%E2%80%93Rom_spline
15:11:25 [cabanier]
... mostly about the implicit begin and end points
15:11:43 [cabanier]
Tav: they're mostly about how to avoid loops
15:12:29 [cabanier]
ChrisL: I propose to use the Centripetal one from the wikipedia article
15:12:48 [cabanier]
heycam: I think that's a good idea
15:13:09 [cabanier]
... I'm going to read up on it
15:14:19 [cabanier]
... do we want the formulation that doesn't introduce the loops and cusps?
15:14:47 [heycam]
https://stackoverflow.com/questions/9489736/catmull-rom-curve-with-no-cusps-and-no-self-intersections/23980479#23980479
15:14:49 [cabanier]
RESOLUTION: catmull-rom will use the formula that doesn't introduce the loops and cusps
15:16:15 [cabanier]
Tav: the wikipedia with the six votes is the one we want
15:16:42 [cabanier]
s/wikipedia/stackoverflow/
15:17:46 [cabanier]
shepazu: can we also put in the spec on how to deform this to beziers?
15:18:14 [cabanier]
heycam: we don't have to do that
15:19:37 [cabanier]
... informally, it might be good to have it
15:19:58 [cabanier]
shepazu: can we call it 'p' instead of 'r'?
15:20:09 [cabanier]
heycam: it doesn't really matter
15:20:11 [cabanier]
ChrisL: sure
15:22:20 [cabanier]
jwatt: I want more than one letter
15:22:33 [cabanier]
ChrisL: people don't really care
15:22:55 [cabanier]
heycam: people will just fiddle with it
15:23:07 [cabanier]
RESOLUTION: the name of the Catmull-Rom command is 'p' reflecting 'points'
15:24:33 [cabanier]
heycam: one final issue is that we should decide that we get the implicit points from the tangent
15:24:41 [cabanier]
shepazu: wasn't there a good pdf?
15:24:51 [cabanier]
ChrisL: yes, I will drop it in
15:24:52 [ChrisL]
http://www.cemyuksel.com/research/catmullrom_param/catmullrom.pdf
15:25:18 [cabanier]
heycam: this does limit the set of curves that you can produce
15:25:46 [cabanier]
shepazu: I would contend that you're not looking for precision but convenience
15:26:00 [cabanier]
heycam: that's reasonable
15:27:16 [cabanier]
... so, at the start of the p command and the previous is a curve, how do you determine the preceding point?
15:27:53 [cabanier]
... if it's cubic or quadratic, since we have the control point, we will use that
15:28:27 [cabanier]
... if we don't, we continue the line and use the point from the same distance
15:28:51 [ChrisL]
q?
15:29:04 [ChrisL]
rrsagent, here
15:29:04 [RRSAgent]
See http://www.w3.org/2014/08/23-svg-irc#T15-29-04
15:29:36 [Zakim]
Zakim has joined #svg
15:32:36 [cabanier]
cabanier: do you need to remember an extra point?
15:32:43 [cabanier]
heycam: you have to do that anyway
15:34:22 [cabanier]
... to summarize: if you have a previous command other than 'p', the implicit first point is based on the tangent just preceding the curve
15:34:43 [cabanier]
... you always know the one coming in if it's a line or curve
15:36:31 [cabanier]
shepazu: can you come back with a more concrete proposal?
15:36:57 [cabanier]
heycam: I'll make an issue in the spec
15:56:59 [nikos]
nikos has joined #svg
16:02:31 [heycam]
ScribeNick: heycam
16:02:36 [heycam]
Topic: Parameterised SVG
16:02:51 [heycam]
jwatt: we have a need that I want to discuss
16:03:06 [heycam]
... it stems from Firefox OS people who need performance, and keep memory usage down -- they use icon fonts
16:03:23 [heycam]
... I'd like to move them away from icon fonts towards using SVG
16:03:51 [heycam]
... I ran through some alternatives to make performance of SVG-in-<img> enough for their needs
16:04:03 [heycam]
... 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
16:04:15 [heycam]
... the color font on the <span> element they apply the font to, can be used to style the content of the icon
16:04:20 [heycam]
... right now we have no mechanism to do that
16:04:26 [heycam]
ChrisL: not any style across that boundary
16:05:33 [heycam]
jwatt: they want to have a way to reference out of the SVG to get a computed value
16:05:36 [heycam]
... or pass it in, either way
16:05:44 [heycam]
... they want to do it with CSS selectors, so set a property on it
16:05:56 [heycam]
... rather than like the params spec, where you have to add something to the query string or param elements
16:06:00 [heycam]
heycam: why?
16:06:12 [heycam]
jwatt: because that's going to be more convenient to theme things
16:07:03 [heycam]
shepazu: the way I've rethought parameters, in the context of CSS Variables --
16:07:26 [heycam]
... 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
16:07:34 [heycam]
... they're two separate problems
16:07:41 [heycam]
... I think Variables are probably good enough for the second half
16:08:01 [heycam]
... I'm proposing we're left with the problem of the behaviour of passing the values in, and/or having implicit behaviour
16:08:19 [heycam]
... I don't care if parameters are explicitly declared, or if you can implicitly extract them from the context
16:08:21 [heycam]
... both seem reasonable to me
16:08:30 [heycam]
krit: my question first is, does it need to be <img>? can it be <object>?
16:08:36 [heycam]
... <img> has security implications
16:08:47 [heycam]
... the webapps sec wg asked us not to have selectors
16:09:01 [heycam]
... you could change the appearance of things in the document, and thus time things
16:09:11 [heycam]
... <object> doesn't have these restrictions
16:09:52 [heycam]
krit: not only timing attacks, but tricking with the appearance
16:10:54 [heycam]
shepazu: [explains the :visited style restriction]
16:12:28 [heycam]
jwatt: a mechanism other than the document reaching in and styling stuff would be sufficient
16:13:26 [heycam]
shepazu: for the SVG document to be able to say what things change under what circumstance
16:13:33 [ChrisL]
itslike passing a bundle of computed style values across the boundary for re-use in styling the image
16:14:11 [heycam]
jwatt: essentially what they need for parity with icon fonts, is to be able to get the computed value of the color property
16:14:28 [heycam]
shepazu: currently in params you explicitly have a name/value pair
16:14:33 [heycam]
... color=foo, foo=orange
16:14:39 [heycam]
... then in the image you use "foo"
16:15:09 [heycam]
... 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
16:15:19 [heycam]
... my original proposal was saying name/value pairs, but now you choose the set of values you pass in
16:17:00 [heycam]
shepazu: let's say the icon wants to use the background-color of the page as the foreground color in the image
16:17:08 [heycam]
... and the color from the document as some accent in the icon
16:17:36 [heycam]
... on the outside you pass in background-color and color
16:17:42 [heycam]
... on the inside you use those two things whereever you need them
16:25:18 [heycam]
heycam: [explains how context-fill and palette variable work in SVG-in-OpenType fonts]
16:26:17 [heycam]
krit: people want to use @media queries based on width/height. not sure if passing width/height into that would help with that?
16:26:36 [heycam]
Rossen_: you could tie in the vw/vh values to that
16:26:42 [heycam]
shepazu: thinking outside the icon use case for a second
16:26:54 [heycam]
shepazu: [draws a spark line]
16:27:40 [heycam]
... I want to pass in the values in the spark line to the SVG <img>
16:28:27 [heycam]
... 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
16:29:58 [heycam]
... two good things about icons, they take on the context size and color
16:30:27 [heycam]
... but you can't pass in multiple styles, and they aren't responsive
16:30:59 [heycam]
... if the icon is big I want more detail
16:31:22 [heycam]
krit: does it need to be <img>?
16:31:37 [heycam]
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>
16:31:46 [heycam]
... we want to be able to get rid of as much memory as possible for small devices
16:31:57 [heycam]
birtles: if it's <object> you can do it all in script anyway
16:32:05 [heycam]
heycam: unless it's cross domain
16:32:46 [heycam]
jwatt: our people want parity. so the parameterisation that allows more than just style property mapping sounds like a bigger thing to nail down.
16:33:12 [heycam]
shepazu: I have also heard from people wanting to use SVG as an icon that at different sizes you get different crispness things
16:33:27 [heycam]
... when we're trying to solve icons as SVG that's another thing to discus
16:34:11 [jwatt]
https://svgwg.org/svg2-draft/intro.html#TermContextElement
16:34:19 [heycam]
jwatt: is it acceptable to have the context element be the <img> referencing the SVG?
16:34:46 [heycam]
heycam: I would say only if you opt in to that
16:35:09 [heycam]
krit: I agree
16:36:31 [heycam]
ChrisL: so maybe foo.svg#context-fill=currentColor
16:37:20 [heycam]
krit: can we just say the fill and stroke applied to the image? they don't do anything on image
16:37:53 [heycam]
jwatt: it's problematic if you need an opt in
16:37:57 [heycam]
... well not sure how big a problem
16:38:11 [heycam]
... this person wants to be able to change style sheet to say all img are fill:red
16:38:18 [heycam]
... he doesn't want to add something to each <img> element
16:38:32 [heycam]
... I want it to be opt in in the SVG, but not in the embedding document
16:38:47 [heycam]
shepazu: I think both
16:39:17 [heycam]
shepazu: img { context-fill: currentColor; context-stroke: red; }
16:39:47 [heycam]
p { color: blue; }
16:39:54 [heycam]
<p><img> ...
16:40:48 [heycam]
jwatt: what about one property that represents the set of properties that can be accessed
16:41:00 [heycam]
... you could have a list of the properties
16:41:12 [heycam]
heycam: will-pass-through: color, background-color;
16:41:49 [heycam]
krit: you could also list a custom property
16:43:01 [heycam]
shepazu: "parameters" might be a good name for it
16:43:10 [heycam]
ChrisL: sounds like we have agreement on a principle, can discuss the name
16:44:17 [heycam]
jwatt: what about same origin <img>s? can we avoid the opt in from the outside?
16:44:50 [heycam]
jwatt: what about not having to write { pass-through: context-fill, ... } for same origin images
16:49:37 [heycam]
... it would be less standardisation effort
16:50:30 [heycam]
shepazu: I'd like this to apply to other cases like <use>
16:53:12 [heycam]
krit: this is one specific use case from a pool of use cases
16:53:35 [heycam]
shepazu: I think the mitigating factor is that what jonathan is asking for the minimal support for context-fill use in the <img> document
16:53:44 [heycam]
... this is not going to restrict us from doing more expansive things in the future
16:53:47 [heycam]
... this is just the simplest case of it
16:53:55 [heycam]
... so it doesn't lock us out of other solutions in the future
16:53:59 [heycam]
krit: I tend to agree
16:54:31 [heycam]
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?
16:54:41 [heycam]
jwatt: no, fonts is good. I want embedded SVG closer to the performance of fonts.
16:55:11 [heycam]
... this is so they can do theming of icons without having to go through each icon element
16:55:29 [heycam]
Rossen_: so the performance memory relief will come later on
16:55:34 [heycam]
jwatt: yes that's a different thing
16:55:57 [heycam]
jwatt: if the feature parity barriers are eliminated, then there is value in us pushing memory usage down
16:56:17 [heycam]
ChrisL: one obvious benefit from icon fonts is you get them all from one file
16:56:23 [heycam]
jwatt: you can use fragment IDs to get that same benefit
16:57:05 [ChrisL]
yes, agreed using fragment ids
16:57:15 [heycam]
krit: presumably you share images across documents. is it safe to share these across?
16:57:26 [heycam]
jwatt: that's an implementation detail for us to make sure it's not possible to get the wrong images in other documents
16:58:17 [heycam]
jwatt: so for now I want to go ahead with same origin context-fill/context-stroke with <img> being the context element
16:58:32 [heycam]
shepazu: short of us thinking through that the expanded uses are ok, we can agree that it will be ok with <img> same origin
16:59:29 [heycam]
krit: is there something we need from the HTML WG on this?
16:59:50 [heycam]
heycam: probably not
17:00:23 [heycam]
krit: worried about others saying no after jwatt goes ahead with this
17:01:03 [heycam]
Rossen_: I wouldn't necessarily object to it, I'm just not sure if/how sufficient this is
17:01:22 [heycam]
ed: I agree with Rossen. I've used params myself for passing strings e.g. across, that wouldn't be covered by this
17:03:05 [heycam]
heycam: would we do this for all of the context-* values?
17:04:28 [heycam]
jwatt: would think for consistency it would be all
17:04:53 [heycam]
shepazu: maybe just limit it to context-fill/context-stroke for now
17:05:10 [heycam]
jwatt: I don't think the spec decisions should be driven by Firefox OS deadlines
17:06:06 [heycam]
Rossen_: if the general intent was to probe the temperature for this, I wouldn't stop with proceeding
17:06:09 [heycam]
... with your implementation
17:06:17 [heycam]
... push it to your nightlies, tryi t out
17:06:24 [heycam]
... to reiterate your situation, you want to start driving on perf
17:06:31 [heycam]
... to do this you need to allow this one property passing
17:06:36 [heycam]
... try it out
17:09:24 [heycam]
... I don't think there's strong pushback
17:10:34 [heycam]
RRSAgent, make logs public
17:10:36 [heycam]
RRSAgent, make minutes
17:10:36 [RRSAgent]
I have made the request to generate http://www.w3.org/2014/08/23-svg-minutes.html heycam
17:11:40 [heycam]
Present: Rossen, Jonathan, Chris, Doug, Erik, Cameron, Tav, Dirk, Rik, Nikos, Brian, Konno
17:11:44 [heycam]
RRSAgent, make minutes
17:11:44 [RRSAgent]
I have made the request to generate http://www.w3.org/2014/08/23-svg-minutes.html heycam
17:33:39 [ChrisL]
ChrisL has joined #svg
17:34:29 [Zakim]
Zakim has left #svg
20:15:19 [jwatt]
jwatt has joined #svg
20:27:23 [Tav]
Tav has joined #svg
20:35:24 [ChrisL]
ChrisL has joined #svg
21:52:06 [jwatt]
jwatt has joined #svg
22:37:56 [commit]
commit has joined #svg
22:37:56 [commit]
[13test] 15dirkschulze pushed 1 new commit to 06master: 02http://git.io/gAlg2Q
22:37:56 [commit]
13test/06master 143fda217 15Dirk Schulze: Test commit bot from GitHub
22:37:56 [commit]
commit has left #svg
23:26:17 [shepazu]
shepazu has joined #svg