SV_MEETING_TITLE -- 15 Nov 2013

<TabAtkins> kk

<TabAtkins> It's a good thing we just switched to unlimited minutes, from 600.

<nikos1> scribe: nikos

<nikos1> scribe: nikos1

<TabAtkins> My cell plan.

<scribe> scribenick: nikos

Path rotation and new circluar/elliptical arc commands

<nikos1> heycam: one of the requirements we had for svg 2 was for a path command to set current rotation

<nikos1> ... subsequent commands are then relative to that rotation

<nikos1> ... the reason for allowing was to avoid having to do trig

<nikos1> ... if you want to animate the path - e.g. rotate one section

<nikos1> ... I wanted that in conjunction with a simpler arc command

<nikos1> ... so you could do circular or elliptical arc from current position by a certain number of degrees

<nikos1> ... I've given that letter 'b' for bearing

<nikos1> ... the capital 'B' takes the angle in degrees

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

<nikos1> ... the idea is that when you have a bearing that is not zero, that effects only relative path commands after that

<nikos1> ... so 'h' would go that distance in the direction of the bearing

<nikos1> heycam: initial rotation is zero

<nikos1> TabAtkins: tradition for angles is to make them zero degrees pointing upwards - especially with bearing

<nikos1> TabAtkins: you need a capital B, but typically the way angles are done is that zero degrees points upwards

<nikos1> ... it doesn't matter a lot, not sure it makes a difference here

<nikos1> heycam: it makes a difference which path commands you use to go straight forward

<nikos1> TabAtkins: the notion of straight forward doesn't have a meaning here

<nikos1> heycam: if we want 'h' to mean head forward

<nikos1> ... then it makes sense for zero degrees to mean in the positive x axis

<nikos1> krit: we use always x axis for rotation

<nikos1> ... but bearing is usually looking north

<nikos1> ... e.g. negative y axis

<nikos1> heycam: unless we want the initial bearing value to be non zero

<birtles> \me 'v' is Veer left, or Venestre ?

<nikos1> ... then we couldn't have zero degrees meaning upwards

<nikos1> ... and lower case 'h' to mean go to the right

<nikos1> krit: can this be combined with cubic and quadratic curves?

<nikos1> heycam: I've defined it so that it does

<nikos1> ... all points are rotated around the origin

<nikos1> ... for straight line segments and quadratics and cubics

<nikos1> ... the point gets rotated

<nikos1> krit: it's changing the co-ordinate space

<nikos1> heycam: you can't build up a path in Direct2D and apply a transform half way through

<nikos1> ... I've described in the respective sections what it means to have the transform applied

<nikos1> heycam: if you look at the cubic bezier command section for example, I added a paragraph detailing how the control points are transformed

<nikos1> cyril: what are the consequences on animate motion?

<nikos1> heycam: it's the same as if you have two line segments

<nikos1> ... where we might have to think about it is with the methods that give a path segment that is a particular length

<nikos1> heycam: I think it makes sense for the default to be zero, and that to be in the positive x axis

<nikos1> cyril: do you think it should be normalised?

<nikos1> heycam: good question, I guess it should

<nikos1> cyril: what about path morphing? Should have no effect right?

<nikos1> ... you normalise first then you apply

<nikos1> ... by morphing I mean path animation

<nikos1> ... so do you require a 'b' to match up with a 'b'?

<nikos1> heycam: I think so

<nikos1> ... you want to animate the 'b'

<nikos1> heycam: the other part of the discussion I wanted is

<nikos1> ... the best way to get a bearing relative elliptical arc

<nikos1> ... haven't added this to the spec yet

<nikos1> ... the last thing we came up with in Switzerland was to add the two arc commands that canvas has

<nikos1> ... maybe with long names since we're running out of letters

<nikos1> ... we can still do that

<nikos1> ... but I don't think the canvas arcs are good for doing an arc from the current position in a given direction

<nikos1> ... I wrote up a couple of options for doing that in a text file

<nikos1> TabAtkins: we also wanted to add in one of the arc commands from paper.js

<nikos1> ... where you give two points that are on the arc

<nikos1> ... three points in total

<heycam> http://pastebin.com/se55bMW3

<nikos1> ... the 'i' command does a circular arc in the given direction for a certain number of degrees

<heycam> = circular arc with the given radius, beginning in the current bearing

<heycam> direction, drawing <angle> degrees of the circle, defaults to going clockwise

<heycam> = elliptical arc with the given radii, beginning in the current bearing direction,

<heycam> as if you were <start-angle> already around the ellipse, going to <end-angle>,

<heycam> defaults to going clockwise

<nikos1> heycam: I was thinking of having two commands. One for circular, one for elliptical

<nikos1> ... the circular arc (i) goes fowards from the current position in the current direction with a radius and a certain number of degrees

<nikos1> ... the elliptical version takes the x and y radius

<nikos1> ... you also have to specify the start angle

<nikos1> ... might not be so useful but included for completeness

<nikos1> TabAtkins: the i command makes it easier to do corners for example

<nikos1> ... h, i 90 degrees 4 times

<nikos1> heycam: the current bearing never changes unless you give a 'b' command

<nikos1> ... so you'd do "h i 90 degrees b 0 (zero degrees off previous arc command) h " and so on

<nikos1> cyril: with 'e', why do you need a start angle?

<nikos1> heycam: you need to know where around the elliptical arc you are

<nikos1> cam draws on whitebaord

<nikos1> TabAtkins: basically because ellipses aren't radially symmetric

<nikos1> heycam: the angle is the angle around the arc, not the initial bearing

<nikos1> shepazu: if you're making a pie chart, is the initial angle always going to be 90 degrees?

<nikos1> TabAtkins: this command isn't great for making a pie chart

<nikos1> heycam: it's good for pie charts

<nikos1> ... maybe not as good as the canvas one with the center point

<nikos1> ... you can move the the center point, then bear in whatever direction

<nikos1> ... "m 100,100 b -90 h 40 b 90 i 20 0 b 90 h 40 "

<nikos1> ... then some more

<nikos1> cyril: why do you need the 'b 90' ?

<nikos1> heycam: you turn 90 degrees at the end of the upwards line

<nikos1> shepazu: I like the idea of being able to do angles in svg finally

<TabAtkins> Hmm, bearings help a little bit with pie charts, but only if you're drawing all the segments in one go.

<nikos1> heycam: one thing with these two circular elliptical and bearing path commands is that there is no natural absolute version of these commands

<nikos1> ... you could make it so that with the abs version you don't do the rotation of the bearing

<nikos1> ... but it's unlikely you would use it

<TabAtkins> You need the Canvas arc command to do pie segments separately in an easy way.

<TabAtkins> SO MANY ARCS NECESSARY

<nikos1> shepazu: this introduces angles into SVG

<nikos1> ... I'm wondering is this a pattern we are going to duplicate?

<nikos1> ... are there other places we could use angles?

<nikos1> ... is this a suitable precedent to follow?

<nikos1> TabAtkins: does the star element use angles?

<nikos1> shepazu: it doesn't

<nikos1> heycam: I was wondering whether zero degrees should be positive x?

<nikos1> TabAtkins: I can't find a decent way to make proper bearing angles easy to use

<nikos1> ... so I think we go with the current proposal

<nikos1> heycam: I like how 'h' can be thought of as move ahead

<nikos1> ... if anyone have any better ideas for bearing relative arc commands let me know

<nikos1> ... otherwise I'll add lower case 'i's and 'e's

<nikos1> TabAtkins: not bothered about absolute commands

<nikos1> heycam: 'b' and lowercase 'i' and 'e' break pattern of last value of command is the ending co-ordinate

<nikos1> ... don't think that's a problem

<TabAtkins> I honestly didn't even realize that was a pattern.

<nikos1> heycam: question of what to do with the SVG dom?

<nikos1> ... new path seg interface derivatives?

<nikos1> ... probably no

<nikos1> birtles: would you even add this feature to the old svg ?

<nikos1> heycam: ideally not

<nikos1> heycam: just like with transforms we do have to define what happens if you use them

<nikos1> ... can do the same thing as transforms

<nikos1> ... should markers be painted at the b?

<nikos1> heycam: I think no

<nikos1> TabAtkins: agree

<nikos1> cyril: no, they don't introduce a segment

<nikos1> cyril: a colleague of mine edited some path commands, where should I put it?

<nikos1> heycam: mail it?

SuperPath commands

<nikos1> cyril: a colleague of mine edited some path commands, where should I put it?

<nikos1> heycam: mail it?

<nikos1> cyril: the idea is to have 'p' for referring to a path

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

<nikos1> cyril: we are proposing two commands, with absolute and relative

<nikos1> ... the piece command takes a url fragment

<nikos1> ... draws a sub path from the current point using the commands from the referenced fragment

<nikos1> ... r draws the referenced path backwards

<nikos1> krit: so the path needs to be in the same document

<nikos1> ... the syntax is not clear about that

<nikos1> cyril: iri is defined

<nikos1> krit: iri is defined to be url and then iri

<nikos1> cyril: but if the url is not there then it is a fragment to the current document

<nikos1> ... don't think we want to allow the url

<nikos1> heycam: I would like to use ids for reference in current document, not iri

<nikos1> cyril: so in the syntax the '#' would be removed

<nikos1> cyril: can you have spaces in ids?

<nikos1> birtles: I don't like ids, but we can come back to that

<nikos1> krit: how do you differ between the different command without '#'

<nikos1> ... could be the pr command for example

<nikos1> ... having # would be a delimiter you could detect

<nikos1> krit: we aren't strict about spaces or comments

<nikos1> ... I think you want to make it clear that it's a reference

<nikos1> heycam: I think it's only a problem if we have the repeated parameter thing

<nikos1> cyril: the difficulty here is how you draw a reverse path

<nikos1> ... usually you have the ending point and then the following points

<nikos1> ... if you reverse a quadratic bezier the first point isn't given in the command

<nikos1> ... have added some notes in the text

<nikos1> ... see annotation 5

<nikos1> cyril draws on the board

<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

<nikos1> ... because when you normalise paths the differences aren't significant

<nikos1> ... could you communicate with David Dailey about this?

<nikos1> krit: the proposal doesn't say how to deal with dash-array especially with shared paths

<nikos1> cyril: I know

<nikos1> krit: many implementations can't do it at the moment

<nikos1> krit: I'd like it added as 'at risk' from the beginning

<nikos1> ... I don't think it will be implemented in the next version of browsers

<nikos1> heycam: I think all features will be assessed when going to CR

<nikos1> shepazu: it gives a lack of confidence marking as at risk initially

<nikos1> ... implementers won't even look at it if it's marked as 'at risk'

<nikos1> ... we can always mark it at last call

<nikos1> heycam: especially since it's in the list of requirements

<nikos1> cabanier: Flash was never able to fix stroking on edge lists

<nikos1> ... it always looked bad

<nikos1> ... what happens with end caps, etc?

<nikos1> cyril: the model we had in mind was to copy all the paths as if they were specified there

<nikos1> heycam: this doesn't address shared edges

<nikos1> cyril: this isn't trying to address the problem of having touching objects

<nikos1> ... it's for maps

<nikos1> ... you just say you have a common path between two objects

<nikos1> shepazu: if I have two states on a map that are adjacent

<nikos1> ... in that case, this proposal says they have a shared line

<nikos1> ... and it's referenced in the syntax

<nikos1> heycam: this does give you information about which pixels are completely covered

<nikos1> ... the underlying graphics libraries aren't going to give us the facility to make use of that

<nikos1> shepazu: That might be the essence of what David Dailey was alluding to

<nikos1> cyril: we're not changing how the rendering is working

<nikos1> ... it's just for syntax

<nikos1> krit: the idea of super paths was to have shared edges

<nikos1> cyril: that's not what I was thinking

<nikos1> ... it's adding semantics to the document so that path data can be re-used

<nikos1> .. with animations applied, etc

<nikos1> krit: I don't think this is the real requirement of super paths

<nikos1> shepazu: I'd like to point out another thing that troubles me

<nikos1> ... that is, for me it's common when I'm using a map that I

<nikos1> ... might pull out a particular shape

<nikos1> ... e.g. pull out Germany from a map of Europe

<nikos1> ... if I do that now it's got it's own shape

<nikos1> ... with this I have to follow the reference

<nikos1> ... we already have an API for that

<nikos1> cyril: I was thinking we could import the points into the normalised version

<nikos1> shepazu: the authoring experience is made more complicated with references

<nikos1> heycam: in your example you are referencing p1

<nikos1> ... if case of commands was different what would be the effect?

<nikos1> cyril: if the path you are referencing uses relative commands then those commands are relative to the last point before the referenced path

<nikos1> ... and if the path uses absolute commands then they're absolute

<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?

<nikos1> cyril: yes

<nikos1> cyril gives example

<nikos1> cyril: we kept small 'p' and small 'r' because all existing commands had two versions

<nikos1> ... but they're useless

<nikos1> krit: 'r' is reserved

<nikos1> cyril: call it 'x'

<nikos1> heycam: could you enumerate the problems?

<nikos1> cyril: I heard it's not solving all the problems

<nikos1> cyril: I'd like to add it to the spec for further discussion

<nikos1> heycam: I'm ok with that

<nikos1> ACTION: cyril to add piece commands to SVG 2 specification [recorded in http://www.w3.org/2013/11/15-svg-minutes.html#action01]

<trackbot> Created ACTION-3546 - Add piece commands to svg 2 specification [on Cyril Concolato - due 2013-11-22].

<scribe> scribenick: someone else

<TabAtkins> >_<

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

Filter effects

<krit> http://dev.w3.org/fxtf/filters/

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

<TabAtkins> I lied, I can't hear anything but an occasional burst of voice.

krit: first issue is xlink attributes
... we have it on most elements
... which did we decide to remove

<TabAtkins> Note that that #issues-index section is auto-generated by Bikeshed. Yet another reason to switch!

heycam: we should remove all except xlink:href
... then do the thing we planned to do with introducing href

krit: can we agree on removing those other attributes?

cabanier: yes

RESOLUTION: Remove all xlink attributes apart from xlink:href from Filters.

krit: next issue is something I'd like to discuss at the next F2F
... then, issue 3
... the text is saying that xlink:href="" is an IRI to something within the current SVG document fragment
... this limits filters to only the current document
... I think Filter is the only thing restricted like this

ed: gradients does this too
... only for inheriting definitions of gradients

<cyril> isn't it the 10th time we resolve on removing xlink:href ?

krit: does Firefox implement this?

birtles: I think it may

krit: for WebKit and Blink I'm pretty sure we don't
... do we want to deprecate it?

ed: cleaner just to remove it?

heycam: I don't see it as very useful for <filter>

ed: it's of very limited use

heycam: I've never liked this inheriting pattern

krit: Inkscape uses it for gradients
... it doesn't for filters

ed: I wanted to lift the restriction at some point, but the feature isn't that useful
... and we decided to keep it limited, since we want to remove it

krit: I won't implement it in WebKit and Blink

heycam: it's probably all right for us to remove it then

RESOLUTION: Remove <filter xlink:href> from Filter Effects.

krit: issue 4, discuss at next F2F
... issue 5 is difficult to discuss without Chris

it's about this in the spec:

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.

krit: I think the last part doesn't matter, since none of the primitives have special handling
... they all require one of the colour spaces
... the input must be in premultipled or non-premultiplied
... I think the last sentence is confusing
... I just want to remove the "unless ..."
... the issue is incorrect, it's nothing to do with color space

cabanier: [asking about sepia]

krit: that would be a separate issue
... next issue 6
... "Why is SourceGraphic drawn into a fixed linear RGB?"
... SourceGraphic takes the parent object, why do you need to draw it into a temporary buffer in linearRGB?
... why can't you change it to something different?
... would like to get some input from Chris
... Issue 7
... the FillPaint and StrokePaint allow you to reference the fill/stroke of the element you're filtering
... and use these fill or paint servers as generated input images
... the question is, it's not really defined how you actually use them
... you can have FillPaint referencing a paint server, like a pattern, and that can be userSpaceOnUse or objectBoundingBOx
... the objectBoundingBox of what? the element that is filtered?

heycam: I'd say the bounding box of the thing it's targeting

krit: that would make sense
... but the spec doesn't say
... if the paint server is drawn using objectBoundingBox, then it should use the boundign box of the element being filtered

ed: the alternative would be the filter region

RESOLUTION: FillPaint/StrokePaint objectBoundingBox should be relative to the bbox of the filtered element.

krit: issue 8
... which coordinate space for userSpaceOnUse?
... if you have a paint server with userSpaceOnUse, which user space to use?
... the filter can be in an SVG element that has a different viewport from the filtered element

heycam: I think again it only makes sense to use the filtered element's user space

ed: I agree

RESOLUTION: FillPaint/StrokePaint userSpaceOnUse should use the coordinate space of the the filtered element.

krit: skip issue 9
... issue 10, we discussed this multiple times before
... we have different subregions
... should the input of the filter prmitive be clipped, the output clipped, both? or not at all?
... the spec really says you should clip the output
... implementations are inconsistent
... you can't test what they implement, since it's hard to figure it out; it doesn't matter in most cases
... would be good if we define which we use
... just pick one

ed: if it doesn't make a big difference, why do we need to define it?

krit: it does make a difference, but it's hard to test -- it depends on the particular filter operator

heycam: what was the outcome of the previous discussion?

krit: we talked about clipping both
... but that is the most limiting
... do we want to change this? or keep it as it is?

heycam: I say just keep our previous decision

ed: alternative is to add some control over it

krit: don't think that's necessary

RESOLUTION: Filter primitives will clip both input and output.

krit: issue 11
... should we add all remaining blend modes from Compositing?
... feBlend has certain blend modes
... Compositing has more
... do we backport them?

heycam: I think so

ed: yes

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
... I'd like to defer these to the next level
... there was also a request to backport all the Compositing modes from that spec to feComposite
... but we removed compositing from CSS

nikos: the extended porter-duff isn't in level 1, deferred to level 2

cabanier: but it is in there for canvas
... you can do all the porter duff with the current keywords
... so I think you should just close this issue

shepazu: whenever I talk to developers/designers, who really want compositing
... what was the rationale for deferring this?

krit: they really want blending, rather than porter duff

shepazu: what was the rationale for not putting it into this level?

cabanier: it was impossible to implement in the way that you expect it
... we're working on it
... I think the browsers are all upgrading their compositors
... we still get pushback because it's much more complex than it first seems
... but we're slowly moving towards getting it working

nikos: and the blend modes have been implemented

shepazu: what's the timeframe for porter duff?

cabanier: we'll start working on the level 2 spec as soon as this one goes out
... for blink, it'll probably be 1 year out
... it's not technical issues, but it's convincing people

shepazu: a matter of resources, ok

RESOLUTION: We will defer the addition of the Compositing spec's blend modes to feBlend.

krit: issue 12, this is one together with issue 14 from Tav
... he is saying at the moment if you don't specify anything for in2="", in Firefox/WebKit the filter operation doesn't work
... but he expects in2="" to use the same as in=""
... looks like some implementations do so
... I think the spec text meant just that the syntax is the same, though

heycam: should the whole filter fail if you leave off in2?

nikos: or should the input 2 be transparent?
... I think it makes sense for it not to be optional

krit: so Firefox and Blink make the whole filter invalid when you leave off in2

ed: the whole filter?
... or just that primitive?

krit: actually not sure

ed: maybe one thing Opera did that the others didn't was to come up with lacuna values, so use something in most cases
... that might be the reason why it's rendering something
... that was never defined for Filters, since they weren't in 1.2T

krit: sounds like most people think the filter primitive should be invalid in this case?

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

krit: we'll delay this for a week to see if IE people have an opinion, since they don't treat it as invalid
... issue 13. some time ago we decided feBlend just to do blending, at the moment is does blending and compositing
... if you want to have that, we'd need to decide on a keyword
... I don't think is important
... though we resolved in Tokyo to have it, we didn't resolve on a name

cabanier: how long will the spec be before CR?
... two years out?
... we could put it in

krit: then we should choose a name
... XML doesn't allow attributes without values

heycam: you do abc="" or abc="abc"

krit: this attribute would switch between blending with or without compositing

<TabAtkins> Boolean attributes in HTML just give the attribute the empty string as value.

<TabAtkins> Please no boolean words.

<krit> http://dev.w3.org/fxtf/filters/#feConvolveMatrixElementPreserveAlphaAttribute

heycam: we could also stick another keyword in the mode="" attribute
... to disable the compositing

krit: mode="darken no-composite"?
... or mode="darken src-over" vs mode="darken src"?

nikos: saying "src" still implies there's a compositing operation
... if you used Compositing & Blending 'src' for the composite operation, and a blend operation, you'd get a different result
... for the two overlapping circles, you'd have a bit of the circle showing up
... if you want to blend without compositing, you kind of want to draw both

cabanier: no
... you want to avoid contributing the backdrop twice

nikos: I think it might be confusing in the future when you have the other method of compositing
... I think you should be clear there's no compositing at all
... since we're going to add compositing, I think it would be confusing

cabanier: the intent is for canvas compositing and css compositing that you can specify blending & compositing, combining the 2 keywords
... if we do it in this filter, it would be consistent with that
... though today it would be a bit odd, having only "src" and "src-over"

nikos: discuss on the ML?

krit: ok
... issue 15, feConvolveMatrix and fe lighting are device pixel dependent
... you kind of make it independent using kernelUnitLength
... but unless you create a filter primitive only for a single element, you can't really do that
... you can't generalise it
... 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
... depends on the pixel density
... otherwise you could do it in the user space of the element

heycam: where one unit = one pixel?

krit: yes
... pixellated results, but it's consistent
... I'm fine with having kernelUnitLength in the spec for now, with a note saying it may change in the future
... but without a solution yet

ed: fine with me

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.

krit: issue 16 & 17 are related
... issue 16 the whole para is differing between high res and low quality implementations
... we discussed yesterday about that
... I don't think we should differ between them
... in general, we should allow implementations to scale the whole filter operation if it couldn't be computed otherwise
... if it would run out of memory etc.
... I would like to discuss about image-rendering in general
... about whether certain kinds of interpolations are required or not for "high quality" or not implementations

heycam: do you want to require a particular kind of scaling here for filters?

krit: no

heycam: how about remove the last two sentences there altogether?

krit: ok

<TabAtkins> image-rendering puts only the barest of requirements on what is required.

<TabAtkins> At the lowest level, you can do linear-interpolation for "auto" and nearest-neighbor for the other two.

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

<TabAtkins> (Actually, you can do nearest neighbor for "auto" if you need to.)

<krit> sentence from current spec

ed: so you're saying image-rendering should not affect the scaling?

krit: for us it doesn't

ed: so it shouldn't be allowed to

krit: it's a MAY

ed: I don't have a strong preference
... it is a hint anyway

krit: what do you think about the first sentence?

ed: the first sentence can go

krit: because image-rendering also specifies bilinear
... I'd also like to put that whole sentence and put it at the start of the para
... I'll come up with a proposal for changing the wording here
... issue 18 is a result of a previous resolution of input/output clipping
... don't need to discuss that now
... issue 19 is also related to that, I need to look into it
... issue 20. it's about feImage and images that don't exist or are blocked. what should happen?
... I think the whole filter chain should fail

heycam: what happens if the 404 response is an image?
... should the feImage still work on the 404 image response?
... if a normal <img> element displays a 404 image response then it should work here

krit: the 404 image is trying to say there is something that should be displayed here, but couldn't
... I don't want to indicate that the image doesn't exist
... it might be a computation map for the filter

heycam: so the broken image image that the browser renders shouldn't be the feImage output, I agree
... but what about if the 404 response from the server had type image/png?
... *that* behaviour should be the same as <img src="404.png">

<TabAtkins> Images defines the concept of an "invalid image" and uses that in a few different ways, depending on th econtext.

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

krit: can you agree that if you don't get an image back from the server that the whole filter chain fails?

heycam: not sure if the whole chain should fail, or just the primitive
... or what happens if an individual primitive fails

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
... just sitting on the side
... should you still cancel the entire chain?

krit: we generally still proceed with the filter chain if a failing primtiive isn't used in the chain
... I suppose it would be the same here for feImage
... I will look into it further and propose something
... continue the remaining issues after lunch; most don't require discussion

<cyril> RRSAgent pointer

we haven't really started

just an off topic discussion about color

<TabAtkins> kk

<scribe> Scribe: Cameron

<scribe> ScribeNick: heycam

More filter issues

krit: http://dev.w3.org/fxtf/filters/#issues-index
... issue 18 and 21 are related
... both are solved by the previous resolutions
... issue 22, we talked about gaussian blur before
... if it has a negative value, we say it's like a null filter
... erik on the ML asked if we could do the same for feMorphology
... a year ago
... might be a good time to decide that
... even if you have a negative value, it's treated as if it were zero

ChrisL: clamped to zero

krit: we also need to define what zero does
... which i've done -- null filter if negative or zero is used
... so, identity filter

RESOLUTION: If radius on feMorphology is zero or negative, the filter operates like an null filter (output = input).

krit: issue 23
... "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."

Tav wanted to replace "map" with "image"

s/Tav/krit: /Tav/

krit: I don't agree though, since it is a bump map

cabanier: but a bump map is an image

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

cabanier: does it make a difference if it's required?
... is the result intended to be used, or is required to be used? does it make a difference?

heycam: you need to combine it explicitly
... so it's "intended", because you should feMerge the output of the lighting fliter with the thing you are lighting
... to get the intended effect
... but you are not required to put that additional feMerge, of course
... 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

<scribe> ACTION: Dirk to investigate how lighting filter outputs work when not composited on top of the original thing being lit [recorded in http://www.w3.org/2013/11/15-svg-minutes.html#action02]

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

krit: issue 24. clamping the feTurbulence numOctaves. firefox clamps it to 10.

ChrisL: so it's diminishing returns with higher octave values?

ed: yes

heycam: is it fine to choose 10, really?

ChrisL: it would be nice to see in non-clamping implementations what the visual effect is

ed: Presto clamped, can't remember what number
... I have some examples written up to show this

<TabAtkins> Assuming there's example code, it would be easy to demonstrate in canvas.

TabAtkins, there's pseudocode in the spec...

<scribe> ACTION: Erik to find his numOctaves examples to find out what a good number to clamp to is [recorded in http://www.w3.org/2013/11/15-svg-minutes.html#action03]

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

<TabAtkins> Ah, yeah, the spec has C code.

krit: issue 25. this and the next issue is determining "distance" between filters, for additive animation
... for paced animation

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

heycam: I agree with my previous proposal

krit: some of these filter primtiives aren't really linear when you combine them

heycam: I think it's similar to transforms, just concatenate the lists

krit: that's mostly fine
... some functions are not linear
... what if you have "grayscale blur" on one and "blur grayscale" on the other

heycam: doesn't matter, you just concatenate the lists

ChrisL: sounds like the right thing to do

RESOLUTION: Additive animation of filter property works by concatenating the lists.

krit: let's discuss the issue of distance calculations for paced animation of filter on the list

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

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

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

krit: currently you have '<color> <icccolor>'
... should we refer to css-color-4, which includes icccolor in <color>?

ChrisL: I'm reluctant to remove it from SVG until it's definitely in CSS
... when it's in a WD
... it's better if it's in CSS as well, but there is still pushback and discussion about the syntax
... however, I talked also with you about needing two types "<color>" things
... one is everything that can be a color
... the other is something used for the fallback sRGB color
... doesn't allow HSL, etc.
... so we need to be careful which one we're using
... for flood-color at the end of the day we have <color> that means "all possible color syntaxes"
... css-color-3 defines <color> to mean "sRGB colors, HSL colors, etc.", but not ICC colors
... SVG defines <color> to just mean sRGB colors (and not the functional form)
... we need to be careful about which one we're meaning

TabAtkins: why do we need a difference between those two?

ChrisL: because in the definition of the larger one you use the smaller one as the "fallback"
... as it's used in SVG for sRGB fallback
... we should add an issue in the spec to say we how we'll update when point to css-color-4

krit: I'll do that

<TabAtkins> Is it for when ICC specifies something outside the srgb gamut?

heycam: it's for when you don't understand ICC colors
... but also when you use device colors, and you e.g. apply a filter to that element, which needs rgb colours

use and shadow dom

krit: we decided to use the shadom dom for the use element, in Hamburg
... the spec hasn't changed yet
... not sure who has the action yet
... the biggest problem is the instance tree
... the Blink people wanted to remove it, and Firefox did not implement it
... the only other engine that supports it is Presto
... not sure about IE
... it might be possible to implement the instance tree on top of shadow dom
... we're exploring it in Blink
... I'd like to try to specify use on top of shadow dom, and instance tree on top of shadow dom

heycam: so the instance tree is for navigating over the original nodes really, since there's no cloning going on
... but for shadow tree, they're cloned nodes

ChrisL: you can modify the shadow dom, but you can also modify the thing that created the shadow dom
... reflecting both changes in to the tree?
... or does instantiating losing the link to the original elements?

TabAtkins: that's not true
... using mutation events we could make it live update

ChrisL: but that's something you need to do manually?

TabAtkins: no
... we can make that part of how use works

ChrisL: that's kind of how you wanted it
... changing the original, and it will affect all of them

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?

TabAtkins: yes

krit: I won't have time to work on that before Jan
... if we want it to be in SVG2, we'll need to delay

shepazu: we already decided because of the DOM discussions, to delay LC of SVG2

heycam: but we didn't decide to delay our end of year cutoff
... 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

Promotion of attributes to properties

krit: who had the action to do this?

heycam: nobody really

krit: can you do it?

heycam: not sure I really want to

krit: it's a big effort, since we need to decide e.g. how 'auto' applies to <rect x="">

heycam: also I'm still not 100% sure I want to do it

ed: not sure how much it ties in to the SVG sizing discussion
... width/height on the root element is special
... I think Firefox already made width/height on the root special
... they're presentation attributes more or less

krit: I don't think so?

ed: I think they're separate from the properties
... it's kind of both

ChrisL: for many years we pushed that these things were different
... not the same as width/height properties
... it was the canonical examples for attributeType="XML/CSS" in SMIL

<ed> http://lists.w3.org/Archives/Public/www-svg/2013Oct/0014.html describes the issue

ChrisL: then, when MS said they'd only do animation of properties, and we discussed promotion of a whole lot of properties, they got merged
... there were unresolved issues there though
... especially around percentages
... 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
... 100% in CSS means something different though
... if we want to make these width/height attributes be the same as the properties, we'd need to redefine them
... and worry about old content

krit: the only thing that needs to be clear is that width attribute and property are the same
... for 'auto' you could say that it defaults to 100%

ChrisL: auto-magic
... and what does 100% mean explicitly?

krit: same as on a div

ChrisL: of the containing block?
... if I say <body><svg width="100%"> is my SVG the whole CSS canvas width?

dbaron: it refers to the containing block width
... which is mostly the content edge, but for many abs positioned objects it's the padding edge

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?
... seems like 100% would mean 100% of the cb width
... what about for height?

dbaron: [ missed ]

ChrisL: we don't want all SVGs getting 300x150

krit: that's what happens in Firefxo

dbaron: didn't we sort this out?

krit: at that point, we still had separate width/height attributes from properties

dbaron: I think what we worked out needed those to be different things

ChrisL: so do we have to join these two things?

heycam: yeah maybe not... :)
... even if we promote a bunch of things, we can just keep width/height attributes on <svg> special

ChrisL: not being able to animate them with CSS isn't a great problem

heycam: if we *do* do the promotion of attributes, SVG2 is the time frame to do it!

krit: so the main reason is to have CSS animations/transitions on it

shepazu: is that still necessary?

ed: it would be nice to be able to animate width/height on a rect using CSS animations

ChrisL: sure, but some of these like cx/cy/r -- every element now has these properties?

krit: alternative was to have new property names

shepazu: an alt alt proposal -- why can't we just make CSS animations applying to attributes?

ChrisL: because attributes are sacrosanct! /s

heycam: initially we considered a proposal where you could just target the attributes somehow in CSS animations

ChrisL: selecting attributes in CSS is a thing that's recently come up

dbaron: it's the property more than the selector, though

shepazu: Tab had a proposal for Attribute Sheets...

krit: that's a different thing

TabAtkins: it's for setting a bunch of attributes at once

heycam: I feel like it's a smaller change to allow targetting of attributes in the CSS animation

TabAtkins: but a larger change in implementations

ChrisL: what's the implementation status?

heycam: don't think anyone did anything

krit: so we wait for implementations first then specify?

ChrisL: was just wondering whether they did make any impl progress

krit: no, nothing

ChrisL: I'm fine with promoting attributes to properties if they're genuinely properties
... if they apply to different elemetns
... having a radius on everything seems weird

heycam: there's a reason they're attributes to begin with...

ChrisL: [explains history of choice between attributes and properties]

krit: let's talk about later

load events in SVG

ed: I recently began working on a patch to remove eRR from blink
... in doing that, I discovered that load event handling was strange
... I would like to make the way that load events work more similar to how it works in HTML
... this is basically a bunch of proposals to do that

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

ed: first we should use a simple event called "load"
... right now we have SVGLoad
... it seems if you compare what impls are doing now, some of them send SVGLoad, some send load, some send both
... at least you do get load events...
... it would be more consistent to use the same one as in html

heycam: is it unlikely people are doing addEventListener("SVGLoad')?

ed: I think so
... I have some examples ...

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

ed: couple of test files
... I don't feel the need to go through those examples now
... for #3, why originally did we make everything fire load events even when not loading external resources?
... I think it was for progressive rendering, which was defined in terms of when things were loaded

cyril_: you could also trigger an animation based on that load

ed: true
... how is that different from parsing?

cyril_: in terms of timeline that's not the same
... if you load an element 30s after the beginning of the document, because your connection is slow, ...

ChrisL: I think the load event is fired once it's rendered, not parsed

ed: that's not how it works
... at least, not my understanding of it
... currently, you parse and then go through and see which elements have a listener for it, only fire if it does
... then you do have to get the order right
... so there is a function called to go through the tree upwards and make sure the load events get to the root

ChrisL: so your proposal #3 says that's not useful and can be removed?

ed: if we could remove that, it'd be more similar to html
... I don't think any viewers wait for a load event to do rendering
... the proposal #3 is to fire only the load events if you have an external reference to something
... another interesting thing is if there are errors, or the link is a 404, then some viewers send both load and error events
... which is a bit strange
... in HTML, the <img> element sends either load or error
... but not both
... I think we should do the same thing
... also use "error" and not "SVGError"
... same with some other SVG* events

heycam: for firing load events only when external resources are needed, does that include e.g. 'fill' with an external paint server?

ed: no
... though I haven't tested what's done tehre
... I'm surprised that Firefox doesn't send load for <image> at all
... only the root
... judging by that, hopefully there's not much content relying on getting load events there

heycam: this all makes sense to me so far

RESOLUTION: We will only dispatch "load" event to elements that have a non-style related external reference, and never "SVGLoad".

heycam: we should check what HTML does for common elements like script, style, etc.

ed: #7 is something that is a bit more interesting
... currently, in Blink, we fire the load event on <image> elements before actually completing the load
... so it's like a parse time load, not everything done load
... which sort of doesn't make sense to me
... and you have to set eRR="true" to make it wait
... I think the spec was a bit unclear
... maybe with some reading of it you could say that's correct... but it's not what I'd expect as an author
... I don't think that's necessary to stop rendering, if you don't have the resources, you should just continue
... don't think we need to say anything special for that
... possibly I will remove some spec text to address this

cabanier: can you just reference HTML?

ed: it's very complicated there
... we probably don't need all the quirky cases
... one issue I found is listed at the bottom
... the outermost svg element, whether we should mimic what <body> is doing in HTML
... if you have onload, it actually sets the window onload
... is this something we want in SVG?
... or can we live with normal behaviour?

heycam: do we dispatch load to root svg all the time?

ed: we need to decide that

heycam: if we don't, then we probably do need the auto-forwarding to window
... since there is lots of content that has onload="" on a root <svg> and expects it to fire
... in HTML, does the root <html> (or the <body>?) always get a load event?
... if you use addEventListener?

ed: don't think so

heycam: that might argue for doing the window-forwarding

ed: it's probably what we want anyway, as it will wait for all resources to be loaded

heycam: what's the set of events that does forward to window?

ed: onblur, onerror, onfocus, onscroll, ...

heycam: I think we should probably do that then

ed: even for inline svg in html?

heycam: don't know...

ed: is everyone ok with removing the SVG-prefixed events/

heycam: just do it, see what happens
... for inline svg, is content putting onload="" on that svg fragment root?

cyril_: that does mean the events can't be used for animation
... right now we have this table, with the name of the event, how we can use it
... we'll need to be careful there, maybe make a list of keywords you can use for triggering animations

ed: sure
... I think the events will still be there, just not with the SVG prefix
... one way to handle the inline fragment, is to have the author just put the listener on the window
... I think it's not so likely for people to be using onload on the inline fragment root

heycam: can we try not firing the event there?

ed: ok
... if things break we can figure out a solution
... it's possible it's not a big problem

RESOLUTION: onload etc. on root <svg> will forward to window like HTML, and we will try not firing load on inline SVG fragment roots

<scribe> ACTION: Erik to do these event cleanups [recorded in http://www.w3.org/2013/11/15-svg-minutes.html#action04]

<trackbot> Created ACTION-3549 - Do these event cleanups [on Erik Dahlström - due 2013-11-22].

<TabAtkins> Was that intentional?

<krit> http://wiki.csswg.org/tools/shepherd/specs

zooming and panning

stakagi: I wrote a wiki page

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

stakagi: thomas smailus posted some related input

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

stakagi: he added a third paragraph to the wiki page

<stakagi> (Many are manually ....)

krit: you say that many implementations do not implement pan&zoom for svg
... you mean with fingers?
... gestures

stakagi: the issues I want to fix are the slowing down of zooming/panning gesture

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

krit: by the way, Cmd+Shift+K works in Blink to do zooming & panning

heycam: so previously I had thought that a better way to support zooming & panning is some way to integrate it with CSS box overflow
... didn't flesh out any proposal

stakagi: so I want not only the built in browser z&p ux, but doing this from js
... currently with js you can't do this

heycam: so we have buffered-rendering property
... which is a hint, but related

ed: which is implemented in blink

heycam: so some people want a stronger indication of when to layerize an element
... to avoid having to use transform:translateZ(0)

krit: the buffered-rendering property only works for the <image> element in Blink

heycam: I imagine we could have a property which was stronger than buffered-rendering
... which means "definitely don't re-render this element if only its transform property changes"

stakagi: for this hierarchy of elements, all of the documents should not re-render when zooming and panning

heycam: yes I think that's how it would work
... if you set it on an element, then anything below that element won't be rerendered if you only change the transform
... I think suspendRedraw isn't a great solution for this because it's on SVGSVGElement, but would be good to have on any element
... also, suspendRedraw was traditionally defined to stop rendering on *any* change, not just on a transform change
... and the implementation of that was hard
... can you explain the mentions of the mouse events?

stakagi: that's just an example of how you would use the methods

heycam: I think this could apply to any content, even HTML

stakagi: I prefer it applying to any HTML content, but SVG tends to have heavy content
... so it's more important with SVG content

ed: I'm not sure what's the best solution
... to me, it seems a bit strange to add suspendRedraw again
... I'm not sure if it makes sense to have it on all SVG elements
... because it still has this "tracking" behaviour
... which is hard to implement
... and you still have to worry about all the DOM modifications
... if it just renders to a bitmap, when does it get updated?
... to me it sounds similar to buffered-rendering, at least, so why not use that?

heycam: a new value for buffered-rendering?

ed: maybe not ... just make the existing buffered-rendering work here

cabanier: this could be related to overflow:clip

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?
... so if there is a chance to re-render, it is allowed?
... or do you want to require that the re-rendering not happen?

<ChrisL> ... as long as that does not produce additional delay

heycam: until you call unsuspendRedraw (or remove the property)

<stakagi> http://svg2.mbsrv.net/devinfo/devstd/panZoom/

stakagi: I think it's application dependent

heycam: so maybe two values for buffered-rendering then... the existing one, which means you can re-render if you want

ChrisL: prioritise UI over rerendering

heycam: yes. and another value, which means "never rerender this if you only change the transform until I say to"

ed: is it a good thing to allow the content to fill up graphics memory?
... it's simple to do, in that case

heycam: what about a best effort?

ed: in the worst case, you could render to a buffer in memory
... would the worst case make it slower than it would otherwise be?

heycam: what are the current values of buffered-rendering?

ed: auto, dynamic, static

heycam: I'm not sure what would be a good name to add for a new value for buffered-rendering

ChrisL: sounds like a good idea, doing it this way

heycam: and it's consistent with our goal to allow implementing z&p widgets using script

stakagi: I think this is not useful only for mapping, but other professional graphics, high precision graphics

RESOLUTION: We will add a new value to buffered-rendering to allow smooth z&p widgets to be created.

<scribe> ACTION: Cameron to add a new buffered-rendering value to support smooth z&p widgets, per these minutes. [recorded in http://www.w3.org/2013/11/15-svg-minutes.html#action05]

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

SVG Fonts still in SVG2?

ChrisL: Erik argued for keeping SVG Tiny fonts in SVG2 due to the implementation Opera
... but now Opera uses Blink, that's no longer true
... given the traction behind SVG-in-OpenType
... and that SVG Fonts was a short term hack
... I propose that we get rid of SVG Fonts completely from SVG 2

cyril: what is problematic with removing this is making them on the fly

ChrisL: have you seen roc's font workshop page?

cyril: no...

heycam: [explains how the font workshop works]

<Tav> link?

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

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

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

shepazu: I still like SVG Fonts, but I don't think we're going to win this fight

ChrisL: I liked SVG Fonts in that they used the same graphics as in the document
... but we knew it had large limitations in terms of i18n
... the new proposal uses great new OpenType features
... the SVG glyphs in OpenType give you both of those things

RESOLUTION: We will remove the SVG Fonts from SVG2, and informatively point to the SVG-in-OpenType spec.

<scribe> ACTION: Cameron to remove SVG Fonts from SVG2. [recorded in http://www.w3.org/2013/11/15-svg-minutes.html#action06]

<trackbot> Created ACTION-3551 - Remove svg fonts from svg2. [on Cameron McCormack - due 2013-11-22].

F2F schedule for 2014

ChrisL: so we have Seattle in January
... maybe Winchester in August, next to Graphical Web

shepazu: TPAC will be at the end of October next year, in Santa Clara
... we should meet at TPAC
... we should request to have our sessions on the first 2 days

<TabAtkins> (where is winchester?)

<nikos> UK

south england

<TabAtkins> Ah, cool.

shepazu: we should do a meeting with local developers

heycam: so we did the survey asking about number of meetings next year
... there was an even split between 3 and 4 meetings, in the responses

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

ChrisL: where is Libre Graphics?

ed: Leipzig

ChrisL: could probably get a meeting room at the conference

krit: I live in Leipzig!

nikos: that's April 2-5

heycam: if we do have 4 meetings, it is pretty evenly spread

3 months between each, approx

so two US, two Europe (no Asia)

krit: before/after these conferences, doesn't matter?

shepazu: right

krit: if we're really serious about the new SVG DOM, we should probably have 4

ChrisL: having nothing between January and August wouldn't be great

<Tav> +1 Leipzig, +1 Winchester

RESOLUTION: We will have 4 meetings in 2014; Seattle in January, two adjacent to Libre Graphics and Graphical Web, and then TPAC.

SVG Logo

shepazu: the guy who designed the HTML5 logo said he'd be willing to make a free CSS logo
... so, I presented to the CSS WG that we should have a logo
... they agreed
... I started a mailing list about logo development and a wiki page about it
... so we're going to have a meeting with the designer
... he'll come back with some proposals
... ultimately, we'll have the logo and release it
... Dirk asked what about an SVG logo
... I think it dovetail nicely with releasing SVG2
... a good opportunity to rebrand

ChrisL: the CSS3 blue shield logo is pretty much the CSS logo

shepazu: so to the CSSWG I said, if anyone from the WG wants to join the conversation they can
... I don't know if the same guy would also be willing to do a free SVG logo

<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

TabAtkins++

-- meeting closed --

-- meeting reopened briefly! --

paint-order naming

ed: can we resolve on keeping the paint-order property name?

krit: didn't the CSSWG object?

heycam: in the end they said they can't think of a better name, so we can use it

RESOLUTION: We will settle on paint-order property name as is.

pointer-events:boundingBox

ed: the keyword can change; I'm interested in the functionality
... so should we back/forwardport this to SVG2, since we're not going to rely on CSS UI defining it?
... it'll be slightly different from in Tiny, it was too limited
... missed some nice use cases

RESOLUTION: We will forward port pointer-events:boundingBox from 1.2T to SVG2.

<scribe> ACTION: Erik to add pointer-events:boundingBox to SVG2. [recorded in http://www.w3.org/2013/11/15-svg-minutes.html#action07]

<trackbot> Created ACTION-3552 - Add pointer-events:boundingbox to svg2. [on Erik Dahlström - due 2013-11-22].

-- meeting really closed! --

<TabAtkins> yup yup!

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

- DRAFT -

SV_MEETING_TITLE

15 Nov 2013

Attendees

Contents