See also: IRC log
<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
<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
<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
<nikos1> ... the 'i' command does a circular arc in the given direction for a certain number of degrees
<heycam> i <radius> <angle> <anticlockwise>
<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> e <radius-x> <radius-y> <start-angle> <end-angle> <anticlockwise>
<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?
<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> 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
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam
<TabAtkins> I lied, I can't hear anything but an occasional burst of voice.
krit: first issue is xlink
... 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
... then do the thing we planned to do with introducing href
krit: can we agree on removing those other attributes?
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
... it doesn't for filters
ed: I wanted to lift the
restriction at some point, but the feature isn't that
... 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
... 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
... 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
... 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
... 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
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
... 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
... 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?
krit: we'll delay this for a week
to see if IE people have an opinion, since they don't treat it
... 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
... 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.
heycam: we could also stick
another keyword in the mode="" attribute
... to disable the compositing
... 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
... 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
... 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?
... 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?
... 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
... 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?
heycam: how about remove the last two sentences there altogether?
<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
... 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
... 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
... 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.
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
... 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
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
... 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
... 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"
krit: I don't agree though, since it is a bump map
cabanier: but a bump map is an image
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
... 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?
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
... for paced animation
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: there is one more issue with flood-color and lighting-color
krit: currently you have
... 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
... 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
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
... 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?
... we can make that part of how use works
ChrisL: that's kind of how you
... 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?
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
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
... 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
... for 'auto' you could say that it defaults to 100%
... and what does 100% mean explicitly?
krit: same as on a div
ChrisL: of the containing
... 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
... 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
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
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: 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
... 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?
... 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
... 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
... 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
... 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
... 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?
... 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?
stakagi: I wrote a wiki page
stakagi: thomas smailus posted some related input
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?
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
... 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
... 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
... 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: 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].
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?
heycam: [explains how the font workshop works]
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].
ChrisL: so we have Seattle in
... 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?)
<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
ChrisL: where is Libre Graphics?
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?
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.
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
... 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
-- meeting closed --
-- meeting reopened briefly! --
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.
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!
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/it's for maths/it's for maps/ Succeeded: s/remo e/remove/ Succeeded: s/RESOLUTION: Filter primitives that take in2="" are invalid if in2 is not specified.// WARNING: Bad s/// command: s/Tav/krit: /Tav/ Succeeded: s/do to/to do/ Succeeded: s/ed/heycam/ Succeeded: s/buffered-rendering?/buffered-rendering work here/ Succeeded: s/display/overflow/ Succeeded: s/Lepzig/Leipzig/ Found Scribe: nikos WARNING: "Scribe: nikos" command found, but no lines found matching "<nikos> . . . " Use "ScribeNick: dbooth" (for example) to specify the scribe's IRC nickname. Found Scribe: nikos1 Inferring ScribeNick: nikos1 Found ScribeNick: nikos Found ScribeNick: someone else Found Scribe: Cameron WARNING: No scribe lines found matching ScribeNick pattern: <someone\ else> ... Found ScribeNick: heycam Found Scribe: Cameron Found ScribeNick: heycam Scribes: nikos, nikos1, Cameron ScribeNicks: nikos1, nikos, someone else, heycam WARNING: Replacing list of attendees. Old list: Huangshan TabAtkins New list: Huangshan Default Present: Huangshan Present: Cameron Doug Brian Satoru Jun Nikos Chris Cyril Erik Dirk Rik Tab WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting Got date from IRC log name: 15 Nov 2013 Guessing minutes URL: http://www.w3.org/2013/11/15-svg-minutes.html People with action items: cameron cyril dirk erik[End of scribe.perl diagnostic output]