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 http://www.w3.org/2013/11/15-svg-irc

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]

+Huangshan

01:28:22 [nikos]

nikos has joined #svg

01:29:31 [TabAtkins]

kk

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]

+TabAtkins

01:30:43 [Zakim]

-TabAtkins

01:30:43 [Zakim]

+TabAtkins

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]

https://svgwg.org/svg2-draft/paths.html#PathDataBearingCommands

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]

http://pastebin.com/se55bMW3

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]

SO MANY ARCS NECESSARY

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]

http://lists.w3.org/Archives/Public/public-svg-wg/2013OctDec/0055.html

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]

-Huangshan

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]

-TabAtkins

03:09:14 [Zakim]

+TabAtkins

03:09:15 [Zakim]

+Huangshan

03:10:12 [heycam]

Scribe: Cameron

03:10:15 [heycam]

ScribeNick: heycam

03:10:18 [heycam]

Topic: Filter effects

03:10:26 [krit]

http://dev.w3.org/fxtf/filters/

03:10:37 [krit]

http://dev.w3.org/fxtf/filters/#issues-index

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]

http://tavmjong.free.fr//INKSCAPE/MANUAL/images/FILTERS/Filters_SolarFlare.svg

03:50:25 [heycam]

http://tavmjong.free.fr//INKSCAPE/MANUAL/images/FILTERS/Filters_SolarFlare.svg

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]

http://dev.w3.org/fxtf/filters/#feConvolveMatrixElementPreserveAlphaAttribute

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]

http://dev.w3.org/csswg/css-images-3/#invalid-image

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]

-Huangshan

04:30:16 [Zakim]

-TabAtkins

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]

See http://www.w3.org/2013/11/15-svg-irc#T05-09-02

05:09:25 [cyril]

RRSAgent, draft minutes

05:09:25 [RRSAgent]

I have made the request to generate http://www.w3.org/2013/11/15-svg-minutes.html 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]

+Huangshan

06:05:08 [Zakim]

+TabAtkins

06:06:18 [heycam]

we haven't really started

06:06:22 [heycam]

just an off topic discussion about color

06:07:22 [TabAtkins]

kk

06:07:54 [heycam]

Scribe: Cameron

06:07:57 [heycam]

ScribeNick: heycam

06:08:00 [heycam]

Topic: More filter issues

06:08:23 [heycam]

krit: http://dev.w3.org/fxtf/filters/#issues-index

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]

see http://lists.w3.org/Archives/Public/public-fx/2013OctDec/0137.html

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]

http://lists.w3.org/Archives/Public/public-fx/2013JulSep/0094.html

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]

file:///Users/dschulze/Documents/hg/FXTF/filters/index.html#FloodColorProperty

06:33:34 [heycam]

krit: there is one more issue with flood-color and lighting-color

06:34:08 [krit]

http://dev.w3.org/fxtf/filters/#propdef-flood-color

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]

http://lists.w3.org/Archives/Public/www-svg/2013Oct/0014.html 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]

http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/load-events/

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]

http://dahlström.net/svg/events/load-events/

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]

See http://www.w3.org/2013/11/15-svg-irc#T07-19-41

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]

See http://www.w3.org/2013/11/15-svg-irc#T07-21-46

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]

s/ed/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]

-Huangshan

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]

http://wiki.csswg.org/tools/shepherd/specs

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]

+Huangshan

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]

http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/GpuZoomPan#Smooth_Zooming_and_Panning_UX_for_SVG

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]

http://lists.w3.org/Archives/Public/public-svg-wg/2013OctDec/0049.html

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]

s/display/overflow/

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]

http://svg2.mbsrv.net/devinfo/devstd/panZoom/

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]

link?

09:00:32 [heycam]

http://robert.ocallahan.org/2013/08/svg-in-opentype-progress-update.html

09:00:42 [heycam]

https://github.com/rocallahan/svg-opentype-workshop

09:00:57 [heycam]

http://people.mozilla.com/~roc/animated-SVG-glyphs.webm

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]

UK

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]

http://www.w3.org/Graphics/SVG/WG/wiki/Meetings#F2F_Meeting_Information

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]

s/Lepzig/Leipzig/

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: http://girliemac.github.io/presentation-slides/html5-mobile-approach/images/css-is-awesome.png

09:26:02 [heycam]

TabAtkins++

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]

http://www.shenzhenparty.com/ferry/shekou-hong-kong

09:31:08 [heycam]

RRSAgent, make minutes

09:31:08 [RRSAgent]

I have made the request to generate http://www.w3.org/2013/11/15-svg-minutes.html 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 http://www.w3.org/2013/11/15-svg-minutes.html heycam

09:32:18 [stakagi]

stakagi has joined #svg

09:33:35 [nikos]

train journey planner

09:33:36 [nikos]

http://www.mtr.com.hk/eng/getting_around/aestations_hk.html

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