IRC log of svg on 2013-11-15

Timestamps are in UTC.

01:27:53 [RRSAgent]
RRSAgent has joined #svg
01:27:53 [RRSAgent]
logging to
01:27:57 [Zakim]
Zakim has joined #svg
01:28:07 [heycam]
Zakim, call Huangshan
01:28:07 [Zakim]
sorry, heycam, I don't know what conference this is
01:28:15 [heycam]
Zakim, room for 4?
01:28:16 [Zakim]
ok, heycam; conference Team_(svg)01:28Z scheduled with code 26631 (CONF1) for 60 minutes until 0228Z
01:28:19 [heycam]
Zakim, call Huangshan
01:28:19 [Zakim]
ok, heycam; the call is being made
01:28:20 [Zakim]
Team_(svg)01:28Z has now started
01:28:21 [Zakim]
01:28:22 [nikos]
nikos has joined #svg
01:29:31 [TabAtkins]
01:29:57 [TabAtkins]
It's a good thing we just switched to unlimited minutes, from 600.
01:30:02 [nikos1]
nikos1 has joined #svg
01:30:19 [nikos1]
scribe: nikos
01:30:23 [nikos1]
scribe: nikos1
01:30:28 [TabAtkins]
My cell plan.
01:30:39 [nikos1]
scribenick: nikos
01:30:42 [Zakim]
01:30:43 [Zakim]
01:30:43 [Zakim]
01:30:45 [jun]
jun has joined #svg
01:31:01 [myakura]
myakura has joined #svg
01:31:05 [nikos1]
Topic: Path rotation and new circluar/elliptical arc commands
01:31:23 [nikos1]
heycam: one of the requirements we had for svg 2 was for a path command to set current rotation
01:31:30 [nikos1]
... subsequent commands are then relative to that rotation
01:31:41 [nikos1]
... the reason for allowing was to avoid having to do trig
01:31:57 [nikos1]
... if you want to animate the path - e.g. rotate one section
01:32:11 [nikos1]
... I wanted that in conjunction with a simpler arc command
01:32:25 [nikos1]
... so you could do circular or elliptical arc from current position by a certain number of degrees
01:32:34 [nikos1]
... I've given that letter 'b' for bearing
01:32:49 [nikos1]
... the capital 'B' takes the angle in degrees
01:33:01 [heycam]
01:33:36 [nikos1]
... the idea is that when you have a bearing that is not zero, that effects only relative path commands after that
01:33:59 [nikos1]
... so 'h' would go that distance in the direction of the bearing
01:34:09 [nikos1]
heycam: initial rotation is zero
01:34:41 [nikos1]
TabAtkins: tradition for angles is to make them zero degrees pointing upwards - especially with bearing
01:35:37 [nikos1]
TabAtkins: you need a capital B, but typically the way angles are done is that zero degrees points upwards
01:35:54 [nikos1]
... it doesn't matter a lot, not sure it makes a difference here
01:36:06 [nikos1]
heycam: it makes a difference which path commands you use to go straight forward
01:36:14 [nikos1]
TabAtkins: the notion of straight forward doesn't have a meaning here
01:36:57 [nikos1]
heycam: if we want 'h' to mean head forward
01:37:06 [nikos1]
... then it makes sense for zero degrees to mean in the positive x axis
01:37:30 [nikos1]
krit: we use always x axis for rotation
01:37:35 [nikos1]
... but bearing is usually looking north
01:37:42 [nikos1]
... e.g. negative y axis
01:37:55 [nikos1]
heycam: unless we want the initial bearing value to be non zero
01:37:57 [birtles]
\me 'v' is Veer left, or Venestre ?
01:38:15 [nikos1]
... then we couldn't have zero degrees meaning upwards
01:38:21 [nikos1]
... and lower case 'h' to mean go to the right
01:38:47 [nikos1]
krit: can this be combined with cubic and quadratic curves?
01:38:51 [nikos1]
heycam: I've defined it so that it does
01:38:57 [nikos1]
... all points are rotated around the origin
01:39:06 [nikos1]
... for straight line segments and quadratics and cubics
01:39:13 [nikos1]
... the point gets rotated
01:39:23 [nikos1]
krit: it's changing the co-ordinate space
01:40:50 [nikos1]
heycam: you can't build up a path in Direct2D and apply a transform half way through
01:41:07 [nikos1]
... I've described in the respective sections what it means to have the transform applied
01:41:43 [nikos1]
heycam: if you look at the cubic bezier command section for example, I added a paragraph detailing how the control points are transformed
01:41:53 [nikos1]
cyril: what are the consequences on animate motion?
01:42:05 [nikos1]
heycam: it's the same as if you have two line segments
01:42:19 [nikos1]
... where we might have to think about it is with the methods that give a path segment that is a particular length
01:43:06 [nikos1]
heycam: I think it makes sense for the default to be zero, and that to be in the positive x axis
01:43:22 [nikos1]
cyril: do you think it should be normalised?
01:43:27 [nikos1]
heycam: good question, I guess it should
01:43:42 [nikos1]
cyril: what about path morphing? Should have no effect right?
01:43:51 [nikos1]
... you normalise first then you apply
01:43:56 [nikos1]
... by morphing I mean path animation
01:44:07 [nikos1]
... so do you require a 'b' to match up with a 'b'?
01:44:11 [nikos1]
heycam: I think so
01:44:18 [nikos1]
... you want to animate the 'b'
01:44:37 [nikos1]
heycam: the other part of the discussion I wanted is
01:44:46 [nikos1]
... the best way to get a bearing relative elliptical arc
01:44:50 [nikos1]
... haven't added this to the spec yet
01:45:11 [nikos1]
... the last thing we came up with in Switzerland was to add the two arc commands that canvas has
01:45:18 [nikos1]
... maybe with long names since we're running out of letters
01:45:24 [nikos1]
... we can still do that
01:45:58 [nikos1]
... but I don't think the canvas arcs are good for doing an arc from the current position in a given direction
01:46:08 [nikos1]
... I wrote up a couple of options for doing that in a text file
01:46:24 [nikos1]
TabAtkins: we also wanted to add in one of the arc commands from paper.js
01:46:34 [nikos1]
... where you give two points that are on the arc
01:46:43 [nikos1]
... three points in total
01:46:46 [heycam]
01:47:10 [nikos1]
... the 'i' command does a circular arc in the given direction for a certain number of degrees
01:47:43 [heycam]
i <radius> <angle> <anticlockwise>
01:47:44 [heycam]
= circular arc with the given radius, beginning in the current bearing
01:47:44 [heycam]
direction, drawing <angle> degrees of the circle, defaults to going clockwise
01:47:44 [heycam]
e <radius-x> <radius-y> <start-angle> <end-angle> <anticlockwise>
01:47:44 [heycam]
= elliptical arc with the given radii, beginning in the current bearing direction,
01:47:45 [heycam]
as if you were <start-angle> already around the ellipse, going to <end-angle>,
01:47:45 [heycam]
defaults to going clockwise
01:48:07 [nikos1]
heycam: I was thinking of having two commands. One for circular, one for elliptical
01:48:30 [nikos1]
... the circular arc (i) goes fowards from the current position in the current direction with a radius and a certain number of degrees
01:48:44 [nikos1]
... the elliptical version takes the x and y radius
01:48:51 [nikos1]
... you also have to specify the start angle
01:49:12 [nikos1]
... might not be so useful but included for completeness
01:49:19 [nikos1]
TabAtkins: the i command makes it easier to do corners for example
01:49:30 [nikos1]
... h, i 90 degrees 4 times
01:49:42 [nikos1]
heycam: the current bearing never changes unless you give a 'b' command
01:50:06 [nikos1]
... so you'd do "h i 90 degrees b 0 (zero degrees off previous arc command) h " and so on
01:50:30 [nikos1]
cyril: with 'e', why do you need a start angle?
01:50:39 [nikos1]
heycam: you need to know where around the elliptical arc you are
01:50:45 [nikos1]
cam draws on whitebaord
01:50:55 [nikos1]
TabAtkins: basically because ellipses aren't radially symmetric
01:51:26 [nikos1]
heycam: the angle is the angle around the arc, not the initial bearing
01:51:52 [nikos1]
shepazu: if you're making a pie chart, is the initial angle always going to be 90 degrees?
01:51:58 [nikos1]
TabAtkins: this command isn't great for making a pie chart
01:52:01 [nikos1]
heycam: it's good for pie charts
01:52:09 [nikos1]
... maybe not as good as the canvas one with the center point
01:52:19 [nikos1]
... you can move the the center point, then bear in whatever direction
01:53:27 [nikos1]
... "m 100,100 b -90 h 40 b 90 i 20 0 b 90 h 40 "
01:53:30 [nikos1]
... then some more
01:53:40 [nikos1]
cyril: why do you need the 'b 90' ?
01:54:14 [nikos1]
heycam: you turn 90 degrees at the end of the upwards line
01:54:26 [nikos1]
shepazu: I like the idea of being able to do angles in svg finally
01:55:09 [TabAtkins]
Hmm, bearings help a little bit with pie charts, but only if you're drawing all the segments in one go.
01:55:24 [nikos1]
heycam: one thing with these two circular elliptical and bearing path commands is that there is no natural absolute version of these commands
01:55:41 [nikos1]
... you could make it so that with the abs version you don't do the rotation of the bearing
01:55:46 [nikos1]
... but it's unlikely you would use it
01:55:49 [TabAtkins]
You need the Canvas arc command to do pie segments separately in an easy way.
01:56:07 [TabAtkins]
01:56:09 [nikos1]
shepazu: this introduces angles into SVG
01:56:20 [nikos1]
... I'm wondering is this a pattern we are going to duplicate?
01:56:26 [nikos1]
... are there other places we could use angles?
01:56:34 [nikos1]
... is this a suitable precedent to follow?
01:56:45 [wonsuk]
wonsuk has joined #svg
01:57:06 [nikos1]
TabAtkins: does the star element use angles?
01:57:12 [nikos1]
shepazu: it doesn't
01:57:23 [nikos1]
heycam: I was wondering whether zero degrees should be positive x?
01:57:32 [nikos1]
TabAtkins: I can't find a decent way to make proper bearing angles easy to use
01:57:40 [nikos1]
... so I think we go with the current proposal
01:57:46 [nikos1]
heycam: I like how 'h' can be thought of as move ahead
01:58:30 [nikos1]
... if anyone have any better ideas for bearing relative arc commands let me know
01:58:48 [nikos1]
... otherwise I'll add lower case 'i's and 'e's
01:59:01 [nikos1]
TabAtkins: not bothered about absolute commands
01:59:51 [nikos1]
heycam: 'b' and lowercase 'i' and 'e' break pattern of last value of command is the ending co-ordinate
02:00:00 [nikos1]
... don't think that's a problem
02:00:25 [TabAtkins]
I honestly didn't even realize that was a pattern.
02:00:42 [nikos1]
heycam: question of what to do with the SVG dom?
02:00:49 [nikos1]
... new path seg interface derivatives?
02:00:55 [nikos1]
... probably no
02:01:08 [nikos1]
birtles: would you even add this feature to the old svg ?
02:01:10 [nikos1]
heycam: ideally not
02:01:24 [nikos1]
heycam: just like with transforms we do have to define what happens if you use them
02:01:33 [nikos1]
... can do the same thing as transforms
02:01:55 [nikos1]
... should markers be painted at the b?
02:02:00 [nikos1]
heycam: I think no
02:02:03 [nikos1]
TabAtkins: agree
02:02:12 [nikos1]
cyril: no, they don't introduce a segment
02:03:11 [nikos1]
cyril: a colleague of mine edited some path commands, where should I put it?
02:03:17 [nikos1]
heycam: mail it?
02:03:39 [nikos1]
Topic: SuperPath commands
02:03:43 [nikos1]
cyril: a colleague of mine edited some path commands, where should I put it?
02:03:46 [nikos1]
heycam: mail it?
02:06:25 [nikos1]
cyril: the idea is to have 'p' for referring to a path
02:07:02 [nikos1]
02:07:42 [nikos1]
cyril: we are proposing two commands, with absolute and relative
02:07:54 [nikos1]
... the piece command takes a url fragment
02:08:13 [nikos1]
... draws a sub path from the current point using the commands from the referenced fragment
02:08:34 [nikos1]
... r draws the referenced path backwards
02:09:11 [nikos1]
krit: so the path needs to be in the same document
02:09:25 [nikos1]
... the syntax is not clear about that
02:09:28 [nikos1]
cyril: iri is defined
02:09:41 [nikos1]
krit: iri is defined to be url and then iri
02:09:50 [nikos1]
cyril: but if the url is not there then it is a fragment to the current document
02:09:56 [nikos1]
... don't think we want to allow the url
02:10:13 [nikos1]
heycam: I would like to use ids for reference in current document, not iri
02:10:46 [nikos1]
cyril: so in the syntax the '#' would be removed
02:10:54 [nikos1]
cyril: can you have spaces in ids?
02:11:07 [nikos1]
birtles: I don't like ids, but we can come back to that
02:11:21 [nikos1]
krit: how do you differ between the different command without '#'
02:11:26 [nikos1]
... could be the pr command for example
02:11:40 [nikos1]
... having # would be a delimiter you could detect
02:12:48 [nikos1]
krit: we aren't strict about spaces or comments
02:13:20 [nikos1]
... I think you want to make it clear that it's a reference
02:13:32 [nikos1]
heycam: I think it's only a problem if we have the repeated parameter thing
02:13:55 [thorton]
thorton has joined #svg
02:14:26 [nikos1]
cyril: the difficulty here is how you draw a reverse path
02:14:35 [nikos1]
... usually you have the ending point and then the following points
02:15:02 [nikos1]
... if you reverse a quadratic bezier the first point isn't given in the command
02:15:22 [nikos1]
... have added some notes in the text
02:15:46 [nikos1]
... see annotation 5
02:16:11 [nikos1]
cyril draws on the board
02:18:40 [nikos1]
shepazu: someone told me (maybe David Dailey) that he heard feedback that the super path thing turns out not to be the solution for mapping that they thought it would be
02:18:55 [nikos1]
... because when you normalise paths the differences aren't significant
02:19:03 [nikos1]
... could you communicate with David Dailey about this?
02:19:15 [nikos1]
krit: the proposal doesn't say how to deal with dash-array especially with shared paths
02:19:18 [nikos1]
cyril: I know
02:19:32 [nikos1]
krit: many implementations can't do it at the moment
02:19:44 [nikos1]
krit: I'd like it added as 'at risk' from the beginning
02:19:54 [nikos1]
... I don't think it will be implemented in the next version of browsers
02:20:33 [nikos1]
heycam: I think all features will be assessed when going to CR
02:20:45 [nikos1]
shepazu: it gives a lack of confidence marking as at risk initially
02:21:22 [nikos1]
... implementers won't even look at it if it's marked as 'at risk'
02:21:31 [nikos1]
... we can always mark it at last call
02:21:42 [nikos1]
heycam: especially since it's in the list of requirements
02:22:00 [nikos1]
cabanier: Flash was never able to fix stroking on edge lists
02:22:03 [nikos1]
... it always looked bad
02:22:25 [nikos1]
... what happens with end caps, etc?
02:22:42 [nikos1]
cyril: the model we had in mind was to copy all the paths as if they were specified there
02:22:51 [nikos1]
heycam: this doesn't address shared edges
02:23:39 [nikos1]
cyril: this isn't trying to address the problem of having touching objects
02:23:47 [nikos1]
... it's for maths
02:24:04 [nikos1]
... you just say you have a common path between two objects
02:24:32 [nikos1]
shepazu: if I have two states on a map that are adjacent
02:24:44 [nikos1]
... in that case, this proposal says they have a shared line
02:24:55 [nikos1]
... and it's referenced in the syntax
02:24:56 [cyril]
s/it's for maths/it's for maps/
02:26:22 [nikos1]
heycam: this does give you information about which pixels are completely covered
02:26:33 [nikos1]
... the underlying graphics libraries aren't going to give us the facility to make use of that
02:26:43 [nikos1]
shepazu: That might be the essence of what David Dailey was alluding to
02:27:22 [nikos1]
cyril: we're not changing how the rendering is working
02:27:31 [nikos1]
... it's just for syntax
02:27:41 [nikos1]
krit: the idea of super paths was to have shared edges
02:27:48 [nikos1]
cyril: that's not what I was thinking
02:28:15 [nikos1]
... it's adding semantics to the document so that path data can be re-used
02:28:28 [nikos1]
.. with animations applied, etc
02:28:37 [nikos1]
krit: I don't think this is the real requirement of super paths
02:28:47 [nikos1]
shepazu: I'd like to point out another thing that troubles me
02:28:59 [nikos1]
... that is, for me it's common when I'm using a map that I
02:29:05 [nikos1]
... might pull out a particular shape
02:29:15 [nikos1]
... e.g. pull out Germany from a map of Europe
02:29:26 [nikos1]
... if I do that now it's got it's own shape
02:29:36 [nikos1]
... with this I have to follow the reference
02:29:44 [nikos1]
... we already have an API for that
02:30:00 [nikos1]
cyril: I was thinking we could import the points into the normalised version
02:30:30 [nikos1]
shepazu: the authoring experience is made more complicated with references
02:31:02 [nikos1]
heycam: in your example you are referencing p1
02:31:23 [nikos1]
... if case of commands was different what would be the effect?
02:32:09 [nikos1]
cyril: if the path you are referencing uses relative commands then those commands are relative to the last point before the referenced path
02:32:16 [nikos1]
... and if the path uses absolute commands then they're absolute
02:32:34 [nikos1]
heycam: does that mean, if you had a mix of absolute and relative, that segment sizes would be different for the same re-used path?
02:32:36 [nikos1]
cyril: yes
02:32:54 [nikos1]
cyril gives example
02:33:08 [thorton]
thorton has joined #svg
02:33:22 [nikos1]
cyril: we kept small 'p' and small 'r' because all existing commands had two versions
02:33:25 [nikos1]
... but they're useless
02:34:04 [nikos1]
krit: 'r' is reserved
02:34:08 [nikos1]
cyril: call it 'x'
02:34:40 [nikos1]
heycam: could you enumerate the problems?
02:35:00 [nikos1]
cyril: I heard it's not solving all the problems
02:36:01 [nikos1]
cyril: I'd like to add it to the spec for further discussion
02:36:03 [nikos1]
heycam: I'm ok with that
02:36:41 [nikos1]
ACTION: cyril to add piece commands to SVG 2 specification
02:36:41 [trackbot]
Created ACTION-3546 - Add piece commands to svg 2 specification [on Cyril Concolato - due 2013-11-22].
02:41:02 [mgylling]
mgylling has joined #svg
02:58:43 [mgylling]
mgylling has joined #svg
03:03:10 [kurosawa]
kurosawa has joined #svg
03:07:01 [nikos]
scribenick: someone else
03:07:05 [heycam]
Zakim, who is on the call?
03:07:05 [Zakim]
On the phone I see Huangshan, TabAtkins
03:08:30 [Zakim]
03:08:50 [TabAtkins]
03:09:11 [heycam]
Zakim, call Huangshan
03:09:11 [Zakim]
ok, heycam; the call is being made
03:09:14 [Zakim]
03:09:14 [Zakim]
03:09:15 [Zakim]
03:10:12 [heycam]
Scribe: Cameron
03:10:15 [heycam]
ScribeNick: heycam
03:10:18 [heycam]
Topic: Filter effects
03:10:26 [krit]
03:10:37 [krit]
03:10:38 [TabAtkins]
I lied, I can't hear anything but an occasional burst of voice.
03:11:18 [cyril]
cyril has joined #svg
03:11:25 [heycam]
krit: first issue is xlink attributes
03:11:30 [heycam]
... we have it on most elements
03:11:33 [heycam]
... which did we decide to remo e
03:11:34 [TabAtkins]
Note that that #issues-index section is auto-generated by Bikeshed. Yet another reason to switch!
03:12:42 [heycam]
heycam: we should remove all except xlink:href
03:12:48 [heycam]
... then do the thing we planned to do with introducing href
03:12:57 [heycam]
krit: can we agree on removing those other attributes?
03:13:00 [heycam]
cabanier: yes
03:13:16 [myakura]
s/remo e/remove/
03:13:48 [heycam]
RESOLUTION: Remove all xlink attributes apart from xlink:href from Filters.
03:14:14 [heycam]
krit: next issue is something I'd like to discuss at the next F2F
03:14:16 [heycam]
... then, issue 3
03:14:44 [heycam]
... the text is saying that xlink:href="" is an IRI to something within the current SVG document fragment
03:14:51 [heycam]
... this limits filters to only the current document
03:14:59 [heycam]
... I think Filter is the only thing restricted like this
03:15:02 [heycam]
ed: gradients does this too
03:15:10 [heycam]
... only for inheriting definitions of gradients
03:15:12 [cyril]
isn't it the 10th time we resolve on removing xlink:href ?
03:15:41 [heycam]
krit: does Firefox implement this?
03:15:45 [heycam]
birtles: I think it may
03:15:52 [heycam]
krit: for WebKit and Blink I'm pretty sure we don't
03:16:14 [heycam]
krit: do we want to deprecate it?
03:16:19 [heycam]
ed: cleaner just to remove it?
03:16:43 [heycam]
heycam: I don't see it as very useful for <filter>
03:16:53 [heycam]
ed: it's of very limited use
03:17:43 [heycam]
heycam: I've never liked this inheriting pattern
03:17:49 [heycam]
krit: Inkscape uses it for gradients
03:17:57 [heycam]
... it doesn't for filters
03:18:30 [heycam]
ed: I wanted to lift the restriction at some point, but the feature isn't that useful
03:18:42 [heycam]
ed: and we decided to keep it limited, since we want to remove it
03:19:10 [heycam]
krit: I won't implement it in WebKit and Blink
03:19:38 [heycam]
heycam: it's probably all right for us to remove it then
03:19:56 [heycam]
RESOLUTION: Remove <filter xlink:href> from Filter Effects.
03:21:23 [heycam]
krit: issue 4, discuss at next F2F
03:21:28 [heycam]
... issue 5 is difficult to discuss without Chris
03:22:05 [heycam]
it's about this in the spec:
03:22:08 [heycam]
Unless otherwise stated, all image filters operate on premultiplied RGBA samples. Some filters like <feColorMatrix>, <feCustom> and <feComponentTransfer> work more naturally on non-premultiplied data. For the time of the filter operation, all color values must temporarily be transformed to the required color multiplication of the current filter unless stated differently on the particular filter primitive.
03:22:18 [heycam]
krit: I think the last part doesn't matter, since none of the primitives have special handling
03:22:27 [heycam]
... they all require one of the colour spaces
03:22:37 [heycam]
... the input must be in premultipled or non-premultiplied
03:22:45 [heycam]
... I think the last sentence is confusing
03:23:19 [heycam]
... I just want to remove the "unless ..."
03:25:12 [heycam]
... the issue is incorrect, it's nothing to do with color space
03:26:17 [heycam]
cabanier: [asking about sepia]
03:26:20 [heycam]
krit: that would be a separate issue
03:26:44 [heycam]
krit: next issue 6
03:26:50 [heycam]
... "Why is SourceGraphic drawn into a fixed linear RGB?"
03:27:07 [heycam]
... SourceGraphic takes the parent object, why do you need to draw it into a temporary buffer in linearRGB?
03:27:14 [heycam]
... why can't you change it to something different?
03:27:23 [heycam]
... would like to get some input from Chris
03:27:32 [heycam]
... Issue 7
03:27:47 [heycam]
... the FillPaint and StrokePaint allow you to reference the fill/stroke of the element you're filtering
03:27:56 [heycam]
... and use these fill or paint servers as generated input images
03:28:07 [heycam]
... the question is, it's not really defined how you actually use them
03:28:22 [heycam]
... you can have FillPaint referencing a paint server, like a pattern, and that can be userSpaceOnUse or objectBoundingBOx
03:28:31 [heycam]
... the objectBoundingBox of what? the element that is filtered?
03:28:43 [heycam]
heycam: I'd say the bounding box of the thing it's targeting
03:28:46 [heycam]
krit: that would make sense
03:28:53 [heycam]
... but the spec doesn't say
03:29:20 [heycam]
... if the paint server is drawn using objectBoundingBox, then it should use the boundign box of the element being filtered
03:29:49 [heycam]
ed: the alternative would be the filter region
03:30:17 [heycam]
RESOLUTION: FillPaint/StrokePaint objectBoundingBox should be relative to the bbox of the filtered element.
03:30:30 [heycam]
krit: issue 8
03:30:36 [heycam]
... which coordinate space for userSpaceOnUse?
03:30:48 [heycam]
... if you have a paint server with userSpaceOnUse, which user space to use?
03:31:17 [heycam]
... the filter can be in an SVG element that has a different viewport from the filtered element
03:31:37 [heycam]
heycam: I think again it only makes sense to use the filtered element's user space
03:31:39 [heycam]
ed: I agree
03:31:54 [heycam]
RESOLUTION: FillPaint/StrokePaint userSpaceOnUse should use the coordinate space of the the filtered element.
03:31:58 [heycam]
krit: skip issue 9
03:32:07 [heycam]
... issue 10, we discussed this multiple times before
03:32:11 [heycam]
... we have different subregions
03:32:33 [heycam]
... should the input of the filter prmitive be clipped, the output clipped, both? or not at all?
03:32:41 [heycam]
... the spec really says you should clip the output
03:32:45 [heycam]
... implementations are inconsistent
03:33:07 [heycam]
... you can't test what they implement, since it's hard to figure it out; it doesn't matter in most cases
03:33:12 [heycam]
... would be good if we define which we use
03:33:15 [heycam]
... just pick one
03:33:22 [heycam]
ed: if it doesn't make a big difference, why do we need to define it?
03:33:42 [heycam]
krit: it does make a difference, but it's hard to test -- it depends on the particular filter operator
03:34:24 [heycam]
heycam: what was the outcome of the previous discussion?
03:34:32 [heycam]
krit: we talked about clipping both
03:34:35 [heycam]
... but that is the most limiting
03:34:41 [heycam]
... do we want to change this? or keep it as it is?
03:35:11 [heycam]
heycam: I say just keep our previous decision
03:35:17 [shepazu]
shepazu has joined #svg
03:35:17 [heycam]
ed: alternative is to add some control over it
03:35:21 [heycam]
krit: don't think that's necessary
03:35:34 [heycam]
RESOLUTION: Filter primitives will clip both input and output.
03:35:42 [heycam]
krit: issue 11
03:35:54 [heycam]
... should we add all remaining blend modes from Compositing?
03:36:07 [heycam]
... feBlend has certain blend modes
03:36:11 [heycam]
... Compositing has more
03:36:13 [heycam]
... do we backport them?
03:36:30 [heycam]
heycam: I think so
03:36:32 [heycam]
ed: yes
03:36:50 [heycam]
krit: I'd like to have a wiki page with all features that aren't in Filters but we might want to deal with in the next level
03:37:07 [heycam]
... I'd like to defer these to the next level
03:38:38 [heycam]
krit: there was also a request to backport all the Compositing modes from that spec to feComposite
03:38:54 [heycam]
... but we removed compositing from CSS
03:39:04 [heycam]
nikos: the extended porter-duff isn't in level 1, deferred to level 2
03:39:12 [heycam]
cabanier: but it is in there for canvas
03:39:20 [heycam]
... you can do all the porter duff with the current keywords
03:39:41 [heycam]
... so I think you should just close this issue
03:39:52 [heycam]
shepazu: whenever I talk to developers/designers, who really want compositing
03:39:59 [heycam]
... what was the rationale for deferring this?
03:40:05 [heycam]
krit: they really want blending, rather than porter duff
03:40:16 [heycam]
shepazu: what was the rationale for not putting it into this level?
03:40:31 [heycam]
cabanier: it was impossible to implement in the way that you expect it
03:40:33 [heycam]
... we're working on it
03:40:41 [heycam]
... I think the browsers are all upgrading their compositors
03:40:49 [heycam]
... we still get pushback because it's much more complex than it first seems
03:41:11 [heycam]
... but we're slowly moving towards getting it working
03:41:16 [heycam]
nikos: and the blend modes have been implemented
03:41:46 [heycam]
shepazu: what's the timeframe for porter duff?
03:41:59 [heycam]
cabanier: we'll start working on the level 2 spec as soon as this one goes out
03:42:08 [heycam]
cabanier: for blink, it'll probably be 1 year out
03:43:22 [heycam]
cabanier: it's not technical issues, but it's convincing people
03:43:25 [heycam]
shepazu: a matter of resources, ok
03:44:22 [heycam]
RESOLUTION: We will defer the addition of the Compositing spec's blend modes to feBlend.
03:44:41 [heycam]
krit: issue 12, this is one together with issue 14 from Tav
03:44:54 [heycam]
... he is saying at the moment if you don't specify anything for in2="", in Firefox/WebKit the filter operation doesn't work
03:45:05 [shepazu]
agenda+ svg logo
03:45:06 [heycam]
... but he expects in2="" to use the same as in=""
03:45:48 [heycam]
... looks like some implementations do so
03:45:59 [heycam]
... I think the spec text meant just that the syntax is the same, though
03:46:51 [heycam]
heycam: should the whole filter fail if you leave off in2?
03:46:57 [heycam]
nikos: or should the input 2 be transparent?
03:47:21 [heycam]
... I think it makes sense for it not to be optional
03:47:52 [heycam]
krit: so Firefox and Blink make the whole filter invalid when you leave off in2
03:48:00 [heycam]
ed: the whole filter?
03:48:03 [heycam]
... or just that primitive?
03:48:19 [heycam]
krit: actually not sure
03:48:43 [heycam]
ed: maybe one thing Opera did that the others didn't was to come up with lacuna values, so use something in most cases
03:48:48 [heycam]
... that might be the reason why it's rendering something
03:48:56 [heycam]
... that was never defined for Filters, since they weren't in 1.2T
03:49:09 [heycam]
krit: sounds like most people think the filter primitive should be invalid in this case?
03:49:30 [heycam]
RESOLUTION: Filter primitives that take in2="" are invalid if in2 is not specified.
03:50:22 [Rossen__]
Rossen__ has joined #svg
03:50:22 [heycam]
03:50:25 [heycam]
03:52:29 [heycam]
s/RESOLUTION: Filter primitives that take in2="" are invalid if in2 is not specified.//
03:52:50 [heycam]
krit: we'll delay this for a week to see if IE people have an opinion, since they don't treat it as invalid
03:53:18 [heycam]
krit: issue 13. some time ago we decided feBlend just to do blending, at the moment is does blending and compositing
03:53:23 [heycam]
... if you want to have that, we'd need to decide on a keyword
03:53:33 [heycam]
... I don't think is important
03:53:57 [heycam]
... though we resolved in Tokyo to have it, we didn't resolve on a name
03:54:24 [heycam]
cabanier: how long will the spec be before CR?
03:54:30 [heycam]
... two years out?
03:54:37 [heycam]
... we could put it in
03:54:43 [heycam]
krit: then we should choose a name
03:55:04 [heycam]
... XML doesn't allow attributes without values
03:55:11 [heycam]
heycam: you do abc="" or abc="abc"
03:55:39 [heycam]
krit: this attribute would switch between blending with or without compositing
03:55:53 [TabAtkins]
Boolean attributes in HTML just give the attribute the empty string as value.
03:56:22 [TabAtkins]
Please no boolean words.
03:56:58 [krit]
03:57:19 [heycam]
heycam: we could also stick another keyword in the mode="" attribute
03:57:23 [heycam]
... to disable the compositing
03:58:15 [heycam]
krit: mode="darken no-composite"?
03:59:52 [heycam]
... or mode="darken src-over" vs mode="darken src"?
04:00:15 [myakura]
myakura has joined #svg
04:00:20 [heycam]
nikos: saying "src" still implies there's a compositing operation
04:01:00 [heycam]
... if you used Compositing & Blending 'src' for the composite operation, and a blend operation, you'd get a different result
04:01:13 [heycam]
... for the two overlapping circles, you'd have a bit of the circle showing up
04:01:21 [heycam]
... if you want to blend without compositing, you kind of want to draw both
04:01:23 [heycam]
cabanier: no
04:01:29 [heycam]
... you want to avoid contributing the backdrop twice
04:01:56 [heycam]
nikos: I think it might be confusing in the future when you have the other method of compositing
04:02:06 [heycam]
nikos: I think you should be clear there's no compositing at all
04:02:21 [heycam]
... since we're going to add compositing, I think it would be confusing
04:02:43 [heycam]
cabanier: the intent is for canvas compositing and css compositing that you can specify blending & compositing, combining the 2 keywords
04:02:52 [heycam]
... if we do it in this filter, it would be consistent with that
04:03:03 [heycam]
... though today it would be a bit odd, having only "src" and "src-over"
04:03:06 [heycam]
nikos: discuss on the ML?
04:03:07 [heycam]
krit: ok
04:03:37 [heycam]
krit: issue 15, feConvolveMatrix and fe lighting are device pixel dependent
04:03:45 [heycam]
... you kind of make it independent using kernelUnitLength
04:04:05 [heycam]
... but unless you create a filter primitive only for a single element, you can't really do that
04:04:19 [heycam]
... you can't generalise it
04:04:43 [heycam]
... my question is, if you want to specify that instead of kernelUnitLength that it always works on device pixels, you always have clear results, but is highlight device dependent
04:04:48 [heycam]
... depends on the pixel density
04:05:05 [heycam]
... otherwise you could do it in the user space of the element
04:05:09 [heycam]
heycam: where one unit = one pixel?
04:05:11 [heycam]
krit: yes
04:05:20 [heycam]
... pixellated results, but it's consistent
04:06:23 [heycam]
krit: I'm fine with having kernelUnitLength in the spec for now, with a note saying it may change in the future
04:06:25 [heycam]
... but without a solution yet
04:06:38 [heycam]
ed: fine with me
04:06:59 [heycam]
RESOLUTION: We will keep kernelUnitLength but add a note explaining why it's not great, and that we may have something different in the future.
04:07:04 [heycam]
krit: issue 16 & 17 are related
04:07:22 [heycam]
... issue 16 the whole para is differing between high res and low quality implementations
04:07:26 [heycam]
... we discussed yesterday about that
04:07:33 [heycam]
... I don't think we should differ between them
04:07:56 [heycam]
... in general, we should allow implementations to scale the whole filter operation if it couldn't be computed otherwise
04:08:00 [heycam]
... if it would run out of memory etc.
04:12:23 [heycam]
krit: I would like to discuss about image-rendering in general
04:12:38 [heycam]
... about whether certain kinds of interpolations are required or not for "high quality" or not implementations
04:12:53 [heycam]
heycam: do you want to require a particular kind of scaling here for filters?
04:12:56 [heycam]
krit: no
04:13:07 [heycam]
heycam: how about remove the last two sentences there altogether?
04:13:08 [heycam]
krit: ok
04:13:46 [TabAtkins]
image-rendering puts only the barest of requirements on what is required.
04:14:07 [TabAtkins]
At the lowest level, you can do linear-interpolation for "auto" and nearest-neighbor for the other two.
04:14:18 [krit]
When the image must be resampled, it is recommended that high quality viewers make use of appropriate interpolation techniques, for example bilinear or bicubic. Depending on the speed of the available interpolents, this choice may be affected by the ‘image-rendering‘ property setting.
04:14:27 [TabAtkins]
(Actually, you can do nearest neighbor for "auto" if you need to.)
04:14:27 [krit]
sentence from current spec
04:14:34 [heycam]
ed: so you're saying image-rendering should not affect the scaling?
04:14:38 [heycam]
krit: for us it doesn't
04:14:54 [heycam]
ed: so it shouldn't be allowed to
04:14:55 [heycam]
04:15:01 [heycam]
krit: it's a MAY
04:15:04 [heycam]
ed: I don't have a strong preference
04:15:07 [heycam]
... it is a hint anyway
04:15:31 [heycam]
krit: what do you think about the first sentence?
04:15:35 [heycam]
ed: the first sentence can go
04:15:41 [heycam]
krit: because image-rendering also specifies bilinear
04:17:31 [heycam]
krit: I'd also like to put that whole sentence and put it at the start of the para
04:17:42 [heycam]
krit: I'll come up with a proposal for changing the wording here
04:18:01 [heycam]
krit: issue 18 is a result of a previous resolution of input/output clipping
04:18:05 [heycam]
... don't need to discuss that now
04:18:13 [heycam]
... issue 19 is also related to that, I need to look into it
04:18:36 [heycam]
... issue 20. it's about feImage and images that don't exist or are blocked. what should happen?
04:18:48 [heycam]
... I think the whole filter chain should fail
04:20:09 [heycam]
heycam: what happens if the 404 response is an image?
04:20:31 [heycam]
... should the feImage still work on the 404 image response?
04:20:45 [heycam]
... if a normal <img> element displays a 404 image response then it should work here
04:23:47 [heycam]
krit: the 404 image is trying to say there is something that should be displayed here, but couldn't
04:23:52 [heycam]
... I don't want to indicate that the image doesn't exist
04:24:00 [heycam]
... it might be a computation map for the filter
04:25:45 [heycam]
heycam: so the broken image image that the browser renders shouldn't be the feImage output, I agree
04:25:55 [heycam]
... but what about if the 404 response from the server had type image/png?
04:26:03 [heycam]
... *that* behaviour should be the same as <img src="404.png">
04:26:07 [TabAtkins]
Images defines the concept of an "invalid image" and uses that in a few different ways, depending on th econtext.
04:27:05 [nikos]
04:27:28 [heycam]
krit: can you agree that if you don't get an image back from the server that the whole filter chain fails?
04:27:37 [heycam]
heycam: not sure if the whole chain should fail, or just the primitive
04:27:48 [heycam]
... or what happens if an individual primitive fails
04:28:12 [heycam]
ed: the question is when do you detect the 404? you could have an feImage inside a filter, that's not used in the filtering
04:28:15 [heycam]
... just sitting on the side
04:28:20 [heycam]
... should you still cancel the entire chain?
04:28:50 [heycam]
krit: we generally still proceed with the filter chain if a failing primtiive isn't used in the chain
04:28:58 [heycam]
krit: I suppose it would be the same here for feImage
04:29:17 [heycam]
krit: I will look into it further and propose something
04:29:29 [heycam]
... continue the remaining issues after lunch; most don't require discussion
04:30:09 [Zakim]
04:30:16 [Zakim]
04:30:17 [Zakim]
Team_(svg)01:28Z has ended
04:30:17 [Zakim]
Attendees were Huangshan, TabAtkins
05:04:36 [cyril]
cyril has joined #svg
05:08:56 [cyril]
RRSAgent pointer
05:09:02 [cyril]
RRSAgent, pointer
05:09:02 [RRSAgent]
05:09:25 [cyril]
RRSAgent, draft minutes
05:09:25 [RRSAgent]
I have made the request to generate cyril
05:13:47 [cyril]
RRSAgent, make minutes public
05:13:47 [RRSAgent]
I'm logging. I don't understand 'make minutes public', cyril. Try /msg RRSAgent help
05:34:16 [myakura]
myakura has joined #svg
05:38:53 [kuroawa]
kuroawa has joined #svg
05:54:41 [stakagi]
stakagi has joined #svg
05:57:40 [mgylling]
mgylling has joined #svg
06:03:45 [heycam]
Zakim, room for 4?
06:03:46 [Zakim]
ok, heycam; conference Team_(svg)06:03Z scheduled with code 26632 (CONF2) for 60 minutes until 0703Z
06:03:48 [heycam]
Zakim, call Huangshan
06:03:48 [Zakim]
ok, heycam; the call is being made
06:03:48 [Zakim]
Team_(svg)06:03Z has now started
06:03:51 [Zakim]
06:05:08 [Zakim]
06:06:18 [heycam]
we haven't really started
06:06:22 [heycam]
just an off topic discussion about color
06:07:22 [TabAtkins]
06:07:54 [heycam]
Scribe: Cameron
06:07:57 [heycam]
ScribeNick: heycam
06:08:00 [heycam]
Topic: More filter issues
06:08:23 [heycam]
06:08:27 [nikos]
nikos has joined #svg
06:08:33 [heycam]
krit: issue 18 and 21 are related
06:08:37 [heycam]
... both are solved by the previous resolutions
06:08:52 [heycam]
krit: issue 22, we talked about gaussian blur before
06:08:59 [heycam]
... if it has a negative value, we say it's like a null filter
06:09:07 [heycam]
... erik on the ML asked if we could do the same for feMorphology
06:09:08 [heycam]
... a year ago
06:09:13 [heycam]
... might be a good time to decide that
06:09:20 [heycam]
... even if you have a negative value, it's treated as if it were zero
06:09:32 [ChrisL]
ChrisL has joined #svg
06:09:39 [heycam]
ChrisL: clamped to zero
06:09:43 [heycam]
krit: we also need to define what zero does
06:10:36 [heycam]
krit: which i've done -- null filter if negative or zero is used
06:12:30 [heycam]
krit: so, identity filter
06:12:33 [heycam]
RESOLUTION: If radius on feMorphology is zero or negative, the filter operates like an null filter (output = input).
06:13:00 [heycam]
krit: issue 23
06:13:40 [heycam]
... "This filter primitive produces an image which contains the specular reflection part of the lighting calculation. Such a map is intended to be combined with a texture using the add term of the arithmetic <feComposite> method."
06:13:44 [heycam]
Tav wanted to replace "map" with "image"
06:13:51 [heycam]
s/Tav/krit: /Tav/
06:13:56 [nikos_]
nikos_ has joined #svg
06:13:57 [heycam]
krit: I don't agree though, since it is a bump map
06:14:01 [heycam]
cabanier: but a bump map is an image
06:14:33 [heycam]
06:14:58 [heycam]
cabanier: does it make a difference if it's required?
06:15:08 [heycam]
... is the result intended to be used, or is required to be used? does it make a difference?
06:15:39 [heycam]
heycam: you need to combine it explicitly
06:16:08 [heycam]
... so it's "intended", because you should feMerge the output of the lighting fliter with the thing you are lighting
06:16:12 [heycam]
... to get the intended effect
06:16:23 [heycam]
... but you are not required to put that additional feMerge, of course
06:18:20 [heycam]
heycam: I'm surprised if browsers differ in how they handled the lighting filter output if it's not merged with the original input, as Tav says
06:18:48 [heycam]
ACTION: Dirk to investigate how lighting filter outputs work when not composited on top of the original thing being lit
06:18:48 [trackbot]
Created ACTION-3547 - Investigate how lighting filter outputs work when not composited on top of the original thing being lit [on Dirk Schulze - due 2013-11-22].
06:19:17 [heycam]
krit: issue 24. clamping the feTurbulence numOctaves. firefox clamps it to 10.
06:19:52 [heycam]
ChrisL: so it's diminishing returns with higher octave values?
06:19:53 [heycam]
ed: yes
06:19:57 [heycam]
heycam: is it fine to choose 10, really?
06:20:11 [heycam]
ChrisL: it would be nice to see in non-clamping implementations what the visual effect is
06:20:21 [heycam]
ed: Presto clamped, can't remember what number
06:20:28 [heycam]
ed: I have some examples written up to show this
06:20:43 [TabAtkins]
Assuming there's example code, it would be easy to demonstrate in canvas.
06:20:54 [heycam]
TabAtkins, there's pseudocode in the spec...
06:21:06 [glenn_]
glenn_ has joined #svg
06:21:06 [heycam]
ACTION: Erik to find his numOctaves examples to find out what a good number to clamp to is
06:21:06 [trackbot]
Created ACTION-3548 - Find his numoctaves examples to find out what a good number to clamp to is [on Erik Dahlström - due 2013-11-22].
06:21:33 [TabAtkins]
Ah, yeah, the spec has C code.
06:22:45 [heycam]
krit: issue 25. this and the next issue is determining "distance" between filters, for additive animation
06:22:51 [heycam]
... for paced animation
06:24:23 [shepazu]
shepazu has joined #svg
06:24:59 [krit]
06:26:37 [heycam]
heycam: I agree with my previous proposal
06:27:40 [glenn]
glenn has joined #svg
06:28:07 [nikos]
nikos has joined #svg
06:28:47 [heycam]
krit: some of these filter primtiives aren't really linear when you combine them
06:29:09 [heycam]
heycam: I think it's similar to transforms, just concatenate the lists
06:29:14 [heycam]
krit: that's mostly fine
06:29:18 [heycam]
... some functions are not linear
06:31:46 [heycam]
krit: what if you have "grayscale blur" on one and "blur grayscale" on the other
06:31:52 [heycam]
heycam: doesn't matter, you just concatenate the lists
06:32:34 [heycam]
ChrisL: sounds like the right thing to do
06:32:45 [heycam]
RESOLUTION: Additive animation of filter property works by concatenating the lists.
06:33:02 [heycam]
krit: let's discuss the issue of distance calculations for paced animation of filter on the list
06:33:23 [krit]
06:33:34 [heycam]
krit: there is one more issue with flood-color and lighting-color
06:34:08 [krit]
06:34:26 [heycam]
krit: currently you have '<color> <icccolor>'
06:34:38 [heycam]
... should we refer to css-color-4, which includes icccolor in <color>?
06:34:53 [heycam]
ChrisL: I'm reluctant to remove it from SVG until it's definitely in CSS
06:35:11 [heycam]
... when it's in a WD
06:35:35 [heycam]
... it's better if it's in CSS as well, but there is still pushback and discussion about the syntax
06:35:49 [heycam]
... however, I talked also with you about needing two types "<color>" things
06:35:54 [heycam]
... one is everything that can be a color
06:36:05 [heycam]
... the other is something used for the fallback sRGB color
06:36:09 [heycam]
... doesn't allow HSL, etc.
06:36:15 [heycam]
... so we need to be careful which one we're using
06:36:37 [heycam]
... for flood-color at the end of the day we have <color> that means "all possible color syntaxes"
06:39:57 [heycam]
ChrisL: css-color-3 defines <color> to mean "sRGB colors, HSL colors, etc.", but not ICC colors
06:40:06 [heycam]
... SVG defines <color> to just mean sRGB colors (and not the functional form)
06:40:14 [heycam]
... we need to be careful about which one we're meaning
06:40:25 [heycam]
TabAtkins: why do we need a difference between those two?
06:40:38 [heycam]
ChrisL: because in the definition of the larger one you use the smaller one as the "fallback"
06:40:44 [heycam]
... as it's used in SVG for sRGB fallback
06:41:59 [heycam]
... we should add an issue in the spec to say we how we'll update when point to css-color-4
06:42:12 [ChrisL]
ChrisL has joined #svg
06:42:16 [heycam]
krit: I'll do that
06:42:18 [TabAtkins]
Is it for when ICC specifies something outside the srgb gamut?
06:43:33 [heycam]
heycam: it's for when you don't understand ICC colors
06:43:46 [heycam]
... but also when you use device colors, and you e.g. apply a filter to that element, which needs rgb colours
06:44:19 [heycam]
Topic: use and shadow dom
06:44:27 [heycam]
krit: we decided to use the shadom dom for the use element, in Hamburg
06:44:30 [heycam]
... the spec hasn't changed yet
06:44:33 [heycam]
... not sure who has the action yet
06:44:36 [heycam]
... the biggest problem is the instance tree
06:44:44 [heycam]
... the Blink people wanted to remove it, and Firefox did not implement it
06:44:49 [heycam]
... the only other engine that supports it is Presto
06:44:51 [heycam]
... not sure about IE
06:44:59 [heycam]
... it might be possible to implement the instance tree on top of shadow dom
06:45:03 [heycam]
... we're exploring it in Blink
06:45:14 [heycam]
... I'd like to try to specify use on top of shadow dom, and instance tree on top of shadow dom
06:46:06 [heycam]
heycam: so the instance tree is for navigating over the original nodes really, since there's no cloning going on
06:46:11 [heycam]
... but for shadow tree, they're cloned nodes
06:46:22 [heycam]
ChrisL: you can modify the shadow dom, but you can also modify the thing that created the shadow dom
06:46:27 [heycam]
... reflecting both changes in to the tree?
06:46:33 [heycam]
... or does instantiating losing the link to the original elements?
06:46:38 [heycam]
TabAtkins: that's not true
06:46:43 [heycam]
... using mutation events we could make it live update
06:46:48 [heycam]
ChrisL: but that's something you need to do manually?
06:46:49 [heycam]
TabAtkins: no
06:46:53 [heycam]
... we can make that part of how use works
06:46:58 [heycam]
ChrisL: that's kind of how you wanted it
06:47:06 [heycam]
... changing the original, and it will affect all of them
06:47:44 [heycam]
heycam: so while with Web Components, the author has to do the mutation observers and propagate changes manually, here we should do it automatically in the spec?
06:47:45 [heycam]
TabAtkins: yes
06:47:51 [heycam]
krit: I won't have time to work on that before Jan
06:47:59 [heycam]
... if we want it to be in SVG2, we'll need to delay
06:48:37 [heycam]
shepazu: we already decided because of the DOM discussions, to delay LC of SVG2
06:48:44 [heycam]
heycam: but we didn't decide to delay our end of year cutoff
06:50:24 [heycam]
heycam: ok, so we've decided to move our cutoff date to the end of the January F2F, but any other items brought up in that F2F we decide to add at that point, we'll give it a couple of months
06:50:48 [heycam]
Topic: Promotion of attributes to properties
06:51:02 [heycam]
krit: who had the action do to this?
06:51:06 [heycam]
s/do to/to do/
06:51:32 [heycam]
heycam: nobody really
06:51:34 [heycam]
krit: can you do it?
06:51:37 [heycam]
heycam: not sure I really want to
06:52:05 [heycam]
krit: it's a big effort, since we need to decide e.g. how 'auto' applies to <rect x="">
06:52:14 [heycam]
heycam: also I'm still not 100% sure I want to do it
06:52:22 [heycam]
ed: not sure how much it ties in to the SVG sizing discussion
06:52:27 [heycam]
... width/height on the root element is special
06:52:44 [heycam]
ed: I think Firefox already made width/height on the root special
06:52:49 [heycam]
... they're presentation attributes more or less
06:52:52 [heycam]
krit: I don't think so?
06:53:00 [heycam]
ed: I think they're separate from the properties
06:53:02 [heycam]
ed: it's kind of both
06:53:08 [heycam]
ChrisL: for many years we pushed that these things were different
06:53:13 [heycam]
... not the same as width/height properties
06:53:22 [heycam]
... it was the canonical examples for attributeType="XML/CSS" in SMIL
06:53:38 [ed] describes the issue
06:53:48 [heycam]
... then, when MS said they'd only do animation of properties, and we discussed promotion of a whole lot of properties, they got merged
06:53:56 [heycam]
... there were unresolved issues there though
06:54:01 [heycam]
... especially around percentages
06:54:27 [heycam]
... we ended up with something saying you either make a fixed width/height to make it nonscalable, or give me an area to draw in and I'll draw as much as I can
06:54:32 [heycam]
... 100% in CSS means something different though
06:54:42 [heycam]
... if we want to make these width/height attributes be the same as the properties, we'd need to redefine them
06:54:47 [heycam]
... and worry about old content
06:55:00 [heycam]
krit: the only thing that needs to be clear is that width attribute and property are the same
06:55:10 [heycam]
... for 'auto' you could say that it defaults to 100%
06:55:16 [heycam]
ChrisL: auto-magic
06:55:26 [heycam]
... and what does 100% mean explicitly?
06:55:38 [heycam]
krit: same as on a div
06:55:44 [heycam]
ChrisL: of the containing block?
06:56:04 [heycam]
... if I say <body><svg width="100%"> is my SVG the whole CSS canvas width?
06:56:27 [heycam]
dbaron: it refers to the containing block width
06:56:40 [heycam]
... which is mostly the content edge, but for many abs positioned objects it's the padding edge
06:57:07 [heycam]
ChrisL: if we do have content that is used in HTML, and it has an explicit width="100%", which is common from authoring tools, what does that change?
06:57:54 [heycam]
... seems like 100% would mean 100% of the cb width
06:58:08 [heycam]
... what about for height?
06:58:20 [heycam]
dbaron: [ missed ]
06:59:06 [heycam]
ChrisL: we don't want all SVGs getting 300x150
06:59:10 [heycam]
krit: that's what happens in Firefxo
06:59:14 [heycam]
dbaron: didn't we sort this out?
06:59:25 [heycam]
krit: at that point, we still had separate width/height attributes from properties
07:00:06 [heycam]
dbaron: I think what we worked out needed those to be different things
07:00:22 [heycam]
ChrisL: so do we have to join these two things?
07:00:26 [heycam]
heycam: yeah maybe not... :)
07:00:53 [heycam]
heycam: even if we promote a bunch of things, we can just keep width/height attributes on <svg> special
07:01:12 [heycam]
ChrisL: not being able to animate them with CSS isn't a great problem
07:03:34 [Rossen__]
Rossen__ has joined #svg
07:03:56 [heycam]
heycam: if we *do* do the promotion of attributes, SVG2 is the time frame to do it!
07:05:40 [heycam]
krit: so the main reason is to have CSS animations/transitions on it
07:05:42 [heycam]
shepazu: is that still necessary?
07:06:02 [heycam]
ed: it would be nice to be able to animate width/height on a rect using CSS animations
07:06:18 [heycam]
ChrisL: sure, but some of these like cx/cy/r -- every element now has these properties?
07:06:30 [heycam]
krit: alternative was to have new property names
07:06:54 [heycam]
shepazu: an alt alt proposal -- why can't we just make CSS animations applying to attributes?
07:07:06 [heycam]
ChrisL: because attributes are sacrosanct! /s
07:08:23 [heycam]
heycam: initially we considered a proposal where you could just target the attributes somehow in CSS animations
07:08:43 [heycam]
ChrisL: selecting attributes in CSS is a thing that's recently come up
07:09:15 [heycam]
dbaron: it's the property more than the selector, though
07:09:26 [heycam]
shepazu: Tab had a proposal for Attribute Sheets...
07:09:30 [heycam]
krit: that's a different thing
07:09:50 [heycam]
TabAtkins: it's for setting a bunch of attributes at once
07:11:13 [heycam]
heycam: I feel like it's a smaller change to allow targetting of attributes in the CSS animation
07:11:17 [heycam]
TabAtkins: but a larger change in implementations
07:13:04 [heycam]
ChrisL: what's the implementation status?
07:13:07 [heycam]
heycam: don't think anyone did anything
07:13:23 [heycam]
krit: so we wait for implementations first then specify?
07:13:30 [heycam]
ChrisL: was just wondering whether they did make any impl progress
07:13:33 [heycam]
krit: no, nothing
07:13:43 [ChrisL]
ChrisL has joined #svg
07:13:52 [heycam]
ChrisL: I'm fine with promoting attributes to properties if they're genuinely properties
07:13:56 [heycam]
... if they apply to different elemetns
07:14:01 [heycam]
... having a radius on everything seems weird
07:14:14 [heycam]
heycam: there's a reason they're attributes to begin with...
07:14:44 [heycam]
ChrisL: [explains history of choice between attributes and properties]
07:15:23 [heycam]
krit: let's talk about later
07:15:56 [heycam]
Topic: load events in SVG
07:16:11 [heycam]
ed: I recently began working on a patch to remove eRR from blink
07:16:17 [heycam]
... in doing that, I discovered that load event handling was strange
07:16:26 [heycam]
... I would like to make the way that load events work more similar to how it works in HTML
07:16:32 [cyril_]
cyril_ has joined #svg
07:16:32 [heycam]
... this is basically a bunch of proposals to do that
07:16:37 [heycam]
07:16:45 [heycam]
ed: first we should use a simple event called "load"
07:16:51 [heycam]
... right now we have SVGLoad
07:17:02 [heycam]
... it seems if you compare what impls are doing now, some of them send SVGLoad, some send load, some send both
07:17:10 [heycam]
... at least you do get load events...
07:17:17 [heycam]
... it would be more consistent to use the same one as in html
07:17:34 [heycam]
heycam: is it unlikely people are doing addEventListener("SVGLoad')?
07:17:36 [heycam]
ed: I think so
07:17:40 [heycam]
... I have some examples ...
07:17:41 [ed]
07:17:50 [heycam]
... couple of test files
07:18:02 [heycam]
... I don't feel the need to go through those examples now
07:18:27 [heycam]
ed: for #3, why originally did we make everything fire load events even when not loading external resources?
07:18:38 [heycam]
ed: I think it was for progressive rendering, which was defined in terms of when things were loaded
07:18:46 [heycam]
cyril_: you could also trigger an animation based on that load
07:18:48 [heycam]
ed: true
07:18:53 [heycam]
... how is that different from parsing?
07:18:57 [heycam]
cyril_: in terms of timeline that's not the same
07:19:11 [heycam]
... if you load an element 30s after the beginning of the document, because your connection is slow, ...
07:19:18 [heycam]
ChrisL: I think the load event is fired once it's rendered, not parsed
07:19:21 [heycam]
ed: that's not how it works
07:19:27 [heycam]
... at least, not my understanding of it
07:19:41 [cyril_]
RRSAgent, pointer
07:19:41 [RRSAgent]
07:19:44 [heycam]
... currently, you parse and then go through and see which elements have a listener for it, only fire if it does
07:19:49 [heycam]
... then you do have to get the order right
07:20:01 [heycam]
... so there is a function called to go through the tree upwards and make sure the load events get to the root
07:20:11 [heycam]
ChrisL: so your proposal #3 says that's not useful and can be removed?
07:20:16 [heycam]
ed: if we could remove that, it'd be more similar to html
07:20:26 [heycam]
RRSAgent, make minutes public
07:20:26 [RRSAgent]
I'm logging. I don't understand 'make minutes public', heycam. Try /msg RRSAgent help
07:20:29 [heycam]
RRSAgent, help
07:20:51 [heycam]
RRSAgent, set logs public
07:21:00 [ChrisL]
ChrisL has joined #svg
07:21:15 [heycam]
ed: I don't think any viewers wait for a load event to do rendering
07:21:46 [heycam]
RRSAgent, pointer?
07:21:46 [RRSAgent]
07:21:56 [heycam]
ed: the proposal #3 is to fire only the load events if you have an external reference to something
07:22:14 [heycam]
ed: another interesting thing is if there are errors, or the link is a 404, then some viewers send both load and error events
07:22:17 [heycam]
... which is a bit strange
07:22:23 [heycam]
... in HTML, the <img> element sends either load or error
07:22:27 [heycam]
... but not both
07:22:31 [heycam]
... I think we should do the same thing
07:22:35 [heycam]
... also use "error" and not "SVGError"
07:22:41 [heycam]
... same with some other SVG* events
07:23:25 [heycam]
heycam: for firing load events only when external resources are needed, does that include e.g. 'fill' with an external paint server?
07:23:27 [heycam]
ed: no
07:23:34 [heycam]
... though I haven't tested what's done tehre
07:23:47 [heycam]
ed: I'm surprised that Firefox doesn't send load for <image> at all
07:23:50 [heycam]
... only the root
07:24:05 [heycam]
... judging by that, hopefully there's not much content relying on getting load events there
07:24:16 [heycam]
heycam: this all makes sense to me so far
07:25:12 [heycam]
RESOLUTION: We will only dispatch "load" event to elements that have a non-style related external reference, and never "SVGLoad".
07:25:22 [heycam]
heycam: we should check what HTML does for common elements like script, style, etc.
07:25:55 [heycam]
ed: #7 is something that is a bit more interesting
07:26:07 [heycam]
... currently, in Blink, we fire the load event on <image> elements before actually completing the load
07:26:12 [heycam]
... so it's like a parse time load, not everything done load
07:26:19 [heycam]
... which sort of doesn't make sense to me
07:26:26 [heycam]
... and you have to set eRR="true" to make it wait
07:26:29 [heycam]
... I think the spec was a bit unclear
07:26:40 [heycam]
... maybe with some reading of it you could say that's correct... but it's not what I'd expect as an author
07:26:58 [heycam]
... I don't think that's necessary to stop rendering, if you don't have the resources, you should just continue
07:27:02 [heycam]
... don't think we need to say anything special for that
07:27:09 [heycam]
... possibly I will remove some spec text to address this
07:27:39 [heycam]
cabanier: can you just reference HTML?
07:27:44 [heycam]
ed: it's very complicated there
07:27:50 [heycam]
... we probably don't need all the quirky cases
07:28:19 [heycam]
ed: one issue I found is listed at the bottom
07:28:27 [heycam]
... the outermost svg element, whether we should mimic what <body> is doing in HTML
07:28:36 [heycam]
... if you have onload, it actually sets the window onload
07:28:42 [heycam]
... is this something we want in SVG?
07:28:47 [heycam]
... or can we live with normal behaviour?
07:29:36 [heycam]
heycam: do we dispatch load to root svg all the time?
07:29:40 [heycam]
ed: we need to decide that
07:29:46 [heycam]
heycam: if we don't, then we probably do need the auto-forwarding to window
07:29:56 [heycam]
... since there is lots of content that has onload="" on a root <svg> and expects it to fire
07:30:44 [heycam]
heycam: in HTML, does the root <html> (or the <body>?) always get a load event?
07:30:52 [heycam]
... if you use addEventListener?
07:30:54 [heycam]
ed: don't think so
07:31:05 [heycam]
heycam: that might argue for doing the window-forwarding
07:31:16 [heycam]
ed: it's probably what we want anyway, as it will wait for all resources to be loaded
07:31:34 [heycam]
heycam: what's the set of events that does forward to window?
07:31:48 [heycam]
ed: onblur, onerror, onfocus, onscroll, ...
07:32:07 [heycam]
heycam: I think we should probably do that then
07:32:30 [heycam]
ed: even for inline svg in html?
07:32:32 [heycam]
heycam: don't know...
07:34:09 [heycam]
ed: is everyone ok with removing the SVG-prefixed events/
07:34:13 [glenn]
glenn has joined #svg
07:34:13 [heycam]
heycam: just do it, see what happens
07:34:44 [heycam]
ed: for inline svg, is content putting onload="" on that svg fragment root?
07:34:47 [heycam]
07:35:03 [heycam]
cyril_: that does mean the events can't be used for animation
07:35:11 [heycam]
... right now we have this table, with the name of the event, how we can use it
07:35:22 [heycam]
... we'll need to be careful there, maybe make a list of keywords you can use for triggering animations
07:35:23 [heycam]
ed: sure
07:35:31 [heycam]
... I think the events will still be there, just not with the SVG prefix
07:36:05 [heycam]
ed: one way to handle the inline fragment, is to have the author just put the listener on the window
07:37:22 [heycam]
... I think it's not so likely for people to be using onload on the inline fragment root
07:37:44 [heycam]
heycam: can we try not firing the event there?
07:37:45 [heycam]
ed: ok
07:37:54 [heycam]
... if things break we can figure out a solution
07:37:58 [heycam]
... it's possible it's not a big problem
07:38:53 [heycam]
RESOLUTION: onload etc. on root <svg> will forward to window like HTML, and we will try not firing load on inline SVG fragment roots
07:39:16 [heycam]
ACTION: Erik to do these event cleanups
07:39:16 [trackbot]
Created ACTION-3549 - Do these event cleanups [on Erik Dahlström - due 2013-11-22].
07:43:58 [Zakim]
07:45:00 [TabAtkins]
Was that intentional?
07:48:59 [Zakim]
disconnecting the lone participant, TabAtkins, in Team_(svg)06:03Z
07:49:01 [Zakim]
Team_(svg)06:03Z has ended
07:49:01 [Zakim]
Attendees were Huangshan, TabAtkins
07:49:08 [ChrisL]
ChrisL has joined #svg
07:49:51 [Tomoyuki]
Tomoyuki has joined #svg
08:06:48 [Tomoyuki1]
Tomoyuki1 has joined #svg
08:09:38 [ChrisL]
ChrisL has joined #svg
08:09:51 [Tomoyuki]
Tomoyuki has joined #svg
08:10:52 [kurosawa]
kurosawa has joined #svg
08:13:56 [Tomoyuki1]
Tomoyuki1 has joined #svg
08:14:11 [krit]
08:15:02 [heycam]
Zakim, room for 4?
08:15:04 [Zakim]
ok, heycam; conference Team_(svg)08:15Z scheduled with code 26632 (CONF2) for 60 minutes until 0915Z
08:15:18 [heycam]
Zakim, dial Huangshan
08:15:18 [Zakim]
ok, heycam; the call is being made
08:15:19 [mgylling]
mgylling has joined #svg
08:15:19 [Zakim]
Team_(svg)08:15Z has now started
08:15:21 [Zakim]
08:16:22 [ChrisL]
ChrisL has joined #svg
08:17:21 [heycam]
Topic: zooming and panning
08:17:28 [heycam]
stakagi: I wrote a wiki page
08:17:32 [stakagi]
08:17:33 [ChrisL]
ChrisL has joined #svg
08:17:44 [cyril]
cyril has joined #svg
08:17:47 [heycam]
stakagi: thomas smailus posted some related input
08:17:49 [stakagi]
08:18:03 [heycam]
stakagi: he added a third paragraph to the wiki page
08:18:08 [stakagi]
(Many are manually ....)
08:18:57 [heycam]
krit: you say that many implementations do not implement pan&zoom for svg
08:19:05 [heycam]
... you mean with fingers?
08:19:13 [heycam]
... gestures
08:19:40 [heycam]
stakagi: the issues I want to fix are the slowing down of zooming/panning gesture
08:21:04 [heycam]
heycam: so you want a way to "freeze" the rendering so that zooming/panning can occur on the gpu without having to rerender the element at each step
08:21:38 [heycam]
krit: by the way, Cmd+Shift+K works in Blink to do zooming & panning
08:23:17 [heycam]
heycam: so previously I had thought that a better way to support zooming & panning is some way to integrate it with CSS box overflow
08:23:21 [heycam]
... didn't flesh out any proposal
08:23:35 [heycam]
stakagi: so I want not only the built in browser z&p ux, but doing this from js
08:23:42 [heycam]
... currently with js you can't do this
08:24:42 [heycam]
heycam: so we have buffered-rendering property
08:24:45 [heycam]
... which is a hint, but related
08:25:00 [heycam]
ed: which is implemented in blink
08:25:11 [heycam]
heycam: so some people want a stronger indication of when to layerize an element
08:25:17 [heycam]
... to avoid having to use transform:translateZ(0)
08:25:33 [heycam]
krit: the buffered-rendering property only works for the <image> element in Blink
08:27:10 [heycam]
heycam: I imagine we could have a property which was stronger than buffered-rendering
08:27:26 [heycam]
... which means "definitely don't re-render this element if only its transform property changes"
08:27:47 [heycam]
stakagi: for this hierarchy of elements, all of the documents should not re-render when zooming and panning
08:28:20 [heycam]
heycam: yes I think that's how it would work
08:28:35 [heycam]
... if you set it on an element, then anything below that element won't be rerendered if you only change the transform
08:28:57 [Tomoyuki]
Tomoyuki has joined #svg
08:30:10 [heycam]
heycam: I think suspendRedraw isn't a great solution for this because it's on SVGSVGElement, but would be good to have on any element
08:30:22 [heycam]
... also, suspendRedraw was traditionally defined to stop rendering on *any* change, not just on a transform change
08:30:26 [heycam]
... and the implementation of that was hard
08:30:36 [heycam]
... can you explain the mentions of the mouse events?
08:31:34 [heycam]
stakagi: that's just an example of how you would use the methods
08:32:08 [heycam]
heycam: I think this could apply to any content, even HTML
08:32:22 [heycam]
stakagi: I prefer it applying to any HTML content, but SVG tends to have heavy content
08:32:31 [heycam]
... so it's more important with SVG content
08:32:44 [heycam]
ed: I'm not sure what's the best solution
08:32:55 [heycam]
... to me, it seems a bit strange to add suspendRedraw again
08:33:02 [heycam]
... I'm not sure if it makes sense to have it on all SVG elements
08:33:08 [heycam]
... because it still has this "tracking" behaviour
08:33:11 [heycam]
... which is hard to implement
08:33:19 [heycam]
... and you still have to worry about all the DOM modifications
08:33:35 [heycam]
... if it just renders to a bitmap, when does it get updated?
08:33:51 [heycam]
... to me it sounds similar to buffered-rendering, at least, so why not use that?
08:33:57 [heycam]
heycam: a new value for buffered-rendering?
08:35:33 [heycam]
ed: maybe not ... just make the existing buffered-rendering?
08:35:56 [heycam]
s/buffered-rendering?/buffered-rendering work here/
08:36:11 [heycam]
cabanier: this could be related to display:clip
08:36:15 [heycam]
08:37:03 [kotakagi]
kotakagi has joined #svg
08:37:45 [heycam]
heycam: so is it ok if the element is re-rendered in the middle of the zoom and pan, if you stop moving your fingers?
08:37:52 [heycam]
... so if there is a chance to re-render, it is allowed?
08:37:59 [heycam]
... or do you want to require that the re-rendering not happen?
08:38:04 [ChrisL]
... as long as that does not produce additional delay
08:38:12 [heycam]
... until you call unsuspendRedraw (or remove the property)
08:38:13 [stakagi]
08:41:14 [heycam]
stakagi: I think it's application dependent
08:41:28 [heycam]
heycam: so maybe two values for buffered-rendering then... the existing one, which means you can re-render if you want
08:41:37 [heycam]
ChrisL: prioritise UI over rerendering
08:41:53 [heycam]
heycam: yes. and another value, which means "never rerender this if you only change the transform until I say to"
08:42:33 [heycam]
ed: is it a good thing to allow the content to fill up graphics memory?
08:42:38 [heycam]
... it's simple to do, in that case
08:43:04 [heycam]
heycam: what about a best effort?
08:44:00 [heycam]
ed: in the worst case, you could render to a buffer in memory
08:44:21 [heycam]
ed: would the worst case make it slower than it would otherwise be?
08:45:13 [heycam]
heycam: what are the current values of buffered-rendering?
08:45:25 [heycam]
ed: auto, dynamic, static
08:45:46 [myakura]
myakura has joined #svg
08:46:58 [heycam]
heycam: I'm not sure what would be a good name to add for a new value for buffered-rendering
08:49:42 [kotakagi_]
kotakagi_ has joined #svg
08:49:56 [kotakagi_]
kotakagi_ has joined #svg
08:50:00 [heycam]
ChrisL: sounds like a good idea, doing it this way
08:50:10 [heycam]
heycam: and it's consistent with our goal to allow implementing z&p widgets using script
08:50:17 [kotakagi_]
kotakagi_ has joined #svg
08:50:33 [heycam]
stakagi: I think this is not useful only for mapping, but other professional graphics, high precision graphics
08:54:56 [heycam]
RESOLUTION: We will add a new value to buffered-rendering to allow smooth z&p widgets to be created.
08:55:11 [heycam]
ACTION: Cameron to add a new buffered-rendering value to support smooth z&p widgets, per these minutes.
08:55:11 [trackbot]
Created ACTION-3550 - Add a new buffered-rendering value to support smooth z&p widgets, per these minutes. [on Cameron McCormack - due 2013-11-22].
08:55:55 [masatakayakura]
masatakayakura has joined #svg
08:56:08 [heycam]
Topic: SVG Fonts still in SVG2?
08:56:19 [heycam]
ChrisL: Erik argued for keeping SVG Tiny fonts in SVG2 due to the implementation Opera
08:56:26 [heycam]
... but now Opera uses Blink, that's no longer true
08:56:33 [heycam]
... given the traction behind SVG-in-OpenType
08:56:41 [heycam]
... and that SVG Fonts was a short term hack
08:56:57 [heycam]
... I propose that we get rid of SVG Fonts completely from SVG 2
08:58:01 [heycam]
cyril: what is problematic with removing this is making them on the fly
08:58:07 [heycam]
ChrisL: have you seen roc's font workshop page?
08:58:08 [heycam]
cyril: no...
08:58:45 [heycam]
heycam: [explains how the font workshop works]
09:00:01 [Tav]
09:00:32 [heycam]
09:00:42 [heycam]
09:00:57 [heycam]
09:01:13 [heycam]
shepazu: I still like SVG Fonts, but I don't think we're going to win this fight
09:01:31 [heycam]
ChrisL: I liked SVG Fonts in that they used the same graphics as in the document
09:01:39 [heycam]
... but we knew it had large limitations in terms of i18n
09:01:48 [heycam]
... the new proposal uses great new OpenType features
09:02:02 [heycam]
... the SVG glyphs in OpenType give you both of those things
09:03:16 [ChrisL]
ChrisL has joined #svg
09:03:20 [heycam]
RESOLUTION: We will remove the SVG Fonts from SVG2, and informatively point to the SVG-in-OpenType spec.
09:03:31 [heycam]
ACTION: Cameron to remove SVG Fonts from SVG2.
09:03:31 [trackbot]
Created ACTION-3551 - Remove svg fonts from svg2. [on Cameron McCormack - due 2013-11-22].
09:06:42 [heycam]
Topic: F2F schedule for 2014
09:07:20 [heycam]
ChrisL: so we have Seattle in January
09:07:30 [heycam]
... maybe Winchester in August, next to Graphical Web
09:07:48 [heycam]
shepazu: TPAC will be at the end of October next year, in Santa Clara
09:08:23 [heycam]
... we should meet at TPAC
09:08:29 [heycam]
... we should request to have our sessions on the first 2 days
09:09:25 [TabAtkins]
(where is winchester?)
09:09:47 [nikos]
09:09:48 [heycam]
south england
09:09:55 [TabAtkins]
Ah, cool.
09:10:02 [heycam]
shepazu: we should do a meeting with local developers
09:10:10 [heycam]
heycam: so we did the survey asking about number of meetings next year
09:10:21 [heycam]
... there was an even split between 3 and 4 meetings, in the responses
09:10:32 [ed]
09:10:41 [ChrisL]
ChrisL has joined #svg
09:12:09 [heycam]
ChrisL: where is Libre Graphics?
09:12:12 [heycam]
ed: Lepzig
09:12:18 [heycam]
09:12:48 [heycam]
ChrisL: could probably get a meeting room at the conference
09:13:16 [heycam]
krit: I live in Leipzig!
09:13:36 [heycam]
nikos: that's April 2-5
09:14:15 [heycam]
heycam: if we do have 4 meetings, it is pretty evenly spread
09:14:19 [heycam]
3 months between each, approx
09:14:39 [heycam]
so two US, two Europe (no Asia)
09:14:50 [heycam]
krit: before/after these conferences, doesn't matter?
09:14:51 [heycam]
shepazu: right
09:15:29 [heycam]
krit: if we're really serious about the new SVG DOM, we should probably have 4
09:15:37 [heycam]
ChrisL: having nothing between January and August wouldn't be great
09:16:17 [Tav]
+1 Leipzig, +1 Winchester
09:19:37 [heycam]
RESOLUTION: We will have 4 meetings in 2014; Seattle in January, two adjacent to Libre Graphics and Graphical Web, and then TPAC.
09:20:00 [Zakim]
disconnecting the lone participant, Huangshan, in Team_(svg)08:15Z
09:20:01 [Zakim]
Team_(svg)08:15Z has ended
09:20:01 [Zakim]
Attendees were Huangshan
09:20:09 [ChrisL]
ChrisL has joined #svg
09:20:25 [heycam]
Topic: SVG Logo
09:20:43 [heycam]
shepazu: the guy who designed the HTML5 logo said he'd be willing to make a free CSS logo
09:21:27 [heycam]
... so, I presented to the CSS WG that we should have a logo
09:21:29 [heycam]
... they agreed
09:21:41 [heycam]
... I started a mailing list about logo development and a wiki page about it
09:21:52 [heycam]
... so we're going to have a meeting with the designer
09:21:59 [heycam]
... he'll come back with some proposals
09:22:18 [heycam]
... ultimately, we'll have the logo and release it
09:22:42 [heycam]
... Dirk asked what about an SVG logo
09:23:08 [heycam]
... I think it dovetail nicely with releasing SVG2
09:23:20 [heycam]
... a good opportunity to rebrand
09:24:30 [heycam]
ChrisL: the CSS3 blue shield logo is pretty much the CSS logo
09:25:02 [heycam]
shepazu: so to the CSSWG I said, if anyone from the WG wants to join the conversation they can
09:25:13 [heycam]
... I don't know if the same guy would also be willing to do a free SVG logo
09:25:51 [TabAtkins]
I'm pretty sure Tantek nailed the CSS logo years ago:
09:26:02 [heycam]
09:26:52 [heycam]
-- meeting closed --
09:27:10 [heycam]
-- meeting reopened briefly! --
09:27:15 [heycam]
Topic: paint-order naming
09:27:34 [heycam]
ed: can we resolve on keeping the paint-order property name?
09:27:49 [heycam]
krit: didn't the CSSWG object?
09:28:08 [heycam]
heycam: in the end they said they can't think of a better name, so we can use it
09:28:29 [heycam]
RESOLUTION: We will settle on paint-order property name as is.
09:28:43 [heycam]
Topic: pointer-events:boundingBox
09:28:58 [heycam]
ed: the keyword can change; I'm interested in the functionality
09:29:52 [heycam]
ed: so should we back/forwardport this to SVG2, since we're not going to rely on CSS UI defining it?
09:29:59 [heycam]
ed: it'll be slightly different from in Tiny, it was too limited
09:30:01 [heycam]
... missed some nice use cases
09:30:17 [heycam]
RESOLUTION: We will forward port pointer-events:boundingBox from 1.2T to SVG2.
09:30:24 [heycam]
ACTION: Erik to add pointer-events:boundingBox to SVG2.
09:30:25 [trackbot]
Created ACTION-3552 - Add pointer-events:boundingbox to svg2. [on Erik Dahlström - due 2013-11-22].
09:30:29 [heycam]
-- meeting really closed! --
09:30:51 [TabAtkins]
yup yup!
09:30:53 [nikos]
09:31:08 [heycam]
RRSAgent, make minutes
09:31:08 [RRSAgent]
I have made the request to generate heycam
09:31:51 [heycam]
Present: Cameron, Doug, Brian, Satoru, Jun, Nikos, Chris, Cyril, Erik, Dirk, Rik, Tab
09:31:55 [heycam]
Chair: Cameron
09:32:02 [heycam]
RRSAgent, make minutes
09:32:02 [RRSAgent]
I have made the request to generate heycam
09:32:18 [stakagi]
stakagi has joined #svg
09:33:35 [nikos]
train journey planner
09:33:36 [nikos]
09:35:59 [glenn]
glenn has joined #svg
10:18:44 [Rossen__]
Rossen__ has joined #svg
10:46:37 [glenn]
glenn has joined #svg
10:58:10 [myakura]
myakura has joined #svg
11:46:55 [glenn]
glenn has joined #svg
11:48:33 [glenn_]
glenn_ has joined #svg
11:58:36 [myakura]
myakura has joined #svg
12:59:01 [myakura]
myakura has joined #svg
13:33:05 [glenn]
glenn has joined #svg
13:59:29 [myakura]
myakura has joined #svg
14:59:54 [myakura]
myakura has joined #svg
16:00:19 [myakura]
myakura has joined #svg
17:00:46 [myakura]
myakura has joined #svg
18:01:08 [myakura]
myakura has joined #svg
18:16:53 [kotakagi]
kotakagi has joined #svg
18:34:21 [myakura]
myakura has joined #svg
18:36:16 [thorton]
thorton has joined #svg
19:13:28 [kotakagi_]
kotakagi_ has joined #svg
19:38:59 [kotakagi]
kotakagi has joined #svg
19:46:08 [kotakagi_]
kotakagi_ has joined #svg
21:26:13 [myakura]
myakura has joined #svg
22:30:57 [myakura]
myakura has joined #svg
22:36:42 [thorton_]
thorton_ has joined #svg
23:31:22 [myakura]
myakura has joined #svg