minutes, SVG WG TPAC F2F 2014, day 2 from Cameron McCormack on 2013-11-15 (www-svg@w3.org from November 2013)

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 15 Nov 2013 17:32:51 +0800
To: "www-svg@w3.org" <www-svg@w3.org>
Message-ID: <5285EA43.8070907@mcc.id.au>

http://www.w3.org/2013/11/15-svg-minutes.html

[1]W3C

[1] http://www.w3.org/

- DRAFT -

SV_MEETING_TITLE

15 Nov 2013

See also: [2]IRC log

[2] http://www.w3.org/2013/11/15-svg-irc

Attendees

Present
Cameron, Doug, Brian, Satoru, Jun, Nikos, Chris, Cyril,
Erik, Dirk, Rik, Tab

Regrets
Chair
Cameron

Scribe
nikos, nikos1, Cameron

Contents

* [3]Topics
1. [4]Path rotation and new circluar/elliptical arc
commands
2. [5]SuperPath commands
3. [6]Filter effects
4. [7]More filter issues
5. [8]use and shadow dom
6. [9]Promotion of attributes to properties
7. [10]load events in SVG
8. [11]zooming and panning
9. [12]SVG Fonts still in SVG2?
10. [13]F2F schedule for 2014
11. [14]SVG Logo
12. [15]paint-order naming
13. [16]pointer-events:boundingBox
* [17]Summary of Action Items
__________________________________________________________

<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>
[18]https://svgwg.org/svg2-draft/paths.html#PathDataBearingComm
ands

[18] 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> [19]http://pastebin.com/se55bMW3

[19] 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>
[20]http://lists.w3.org/Archives/Public/public-svg-wg/2013OctDe
c/0055.html

[20]
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
[21]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> [22]http://dev.w3.org/fxtf/filters/

[22] http://dev.w3.org/fxtf/filters/

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

[23] 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?

[24]http://tavmjong.free.fr//INKSCAPE/MANUAL/images/FILTERS/Fil
ters_SolarFlare.svg

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

[25]http://tavmjong.free.fr//INKSCAPE/MANUAL/images/FILTERS/Fil
ters_SolarFlare.svg

[25]
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>
[26]http://dev.w3.org/fxtf/filters/#feConvolveMatrixElementPres
erveAlphaAttribute

[26]
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> [27]http://dev.w3.org/csswg/css-images-3/#invalid-image

[27] 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: [28]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

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

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
[29]http://lists.w3.org/Archives/Public/public-fx/2013OctDec/01
37.html

[29]
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
[30]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
[31]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>
[32]http://lists.w3.org/Archives/Public/public-fx/2013JulSep/00
94.html

[32]
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#Flo
odColorProperty

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

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

[33] 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>
[34]http://lists.w3.org/Archives/Public/www-svg/2013Oct/0014.ht
ml describes the issue

[34] http://lists.w3.org/Archives/Public/www-svg/2013Oct/0014.html

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

[35]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/load-event
s/

[35] 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> [36]http://dahlström.net/svg/events/load-events/

[36] http://dahlstr/

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
[37]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> [38]http://wiki.csswg.org/tools/shepherd/specs

[38] http://wiki.csswg.org/tools/shepherd/specs

zooming and panning

stakagi: I wrote a wiki page

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

[39]
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>
[40]http://lists.w3.org/Archives/Public/public-svg-wg/2013OctDe
c/0049.html

[40]
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> [41]http://svg2.mbsrv.net/devinfo/devstd/panZoom/

[41] 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
[42]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?

[43]http://robert.ocallahan.org/2013/08/svg-in-opentype-progres
s-update.html

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

[44]https://github.com/rocallahan/svg-opentype-workshop

[44] https://github.com/rocallahan/svg-opentype-workshop

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

[45] 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
[46]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>
[47]http://www.w3.org/Graphics/SVG/WG/wiki/Meetings#F2F_Meeting
_Information

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

[48]
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
[49]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> [50]http://www.shenzhenparty.com/ferry/shekou-hong-kong

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

Summary of Action Items

[NEW] ACTION: Cameron to add a new buffered-rendering value to
support smooth z&p widgets, per these minutes. [recorded in
[51]http://www.w3.org/2013/11/15-svg-minutes.html#action05]
[NEW] ACTION: Cameron to remove SVG Fonts from SVG2. [recorded
in [52]http://www.w3.org/2013/11/15-svg-minutes.html#action06]
[NEW] ACTION: cyril to add piece commands to SVG 2
specification [recorded in
[53]http://www.w3.org/2013/11/15-svg-minutes.html#action01]
[NEW] ACTION: Dirk to investigate how lighting filter outputs
work when not composited on top of the original thing being lit
[recorded in
[54]http://www.w3.org/2013/11/15-svg-minutes.html#action02]
[NEW] ACTION: Erik to add pointer-events:boundingBox to SVG2.
[recorded in
[55]http://www.w3.org/2013/11/15-svg-minutes.html#action07]
[NEW] ACTION: Erik to do these event cleanups [recorded in
[56]http://www.w3.org/2013/11/15-svg-minutes.html#action04]
[NEW] ACTION: Erik to find his numOctaves examples to find out
what a good number to clamp to is [recorded in
[57]http://www.w3.org/2013/11/15-svg-minutes.html#action03]

[End of minutes]

Received on Friday, 15 November 2013 09:33:50 UTC