W3C home > Mailing lists > Public > www-svg@w3.org > November 2013

minutes, SVG WG TPAC F2F 2014, day 2

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


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

                                - DRAFT -


15 Nov 2013

    See also: [2]IRC log

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


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


           nikos, nikos1, Cameron


      * [3]Topics
          1. [4]Path rotation and new circluar/elliptical arc
          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

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

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

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

    <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


      [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

    <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

    <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

    <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

    <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

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

    <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

    <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

    <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

    <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

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


    <nikos1> shepazu: this introduces angles into SVG

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

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

    <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

    <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

    <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

    <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

    <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

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

    <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

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

    <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

    <nikos1> heycam: I'm ok with that

    <nikos1> ACTION: cyril to add piece commands to SVG 2
    specification [recorded in

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

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

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

    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

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



    heycam: we could also stick another keyword in the mode=""
    ... 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
    ... 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

    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
    ... though today it would be a bit odd, having only "src" and

    nikos: discuss on the ML?

    krit: ok
    ... issue 15, feConvolveMatrix and fe lighting are device pixel
    ... 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

    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

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

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



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

    <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

    <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



    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

    <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

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

    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
    ... 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
    ... not the same as width/height properties
    ... it was the canonical examples for attributeType="XML/CSS"
    in SMIL

    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

    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

    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

    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

    krit: let's talk about later

load events in SVG

    ed: I recently began working on a patch to remove eRR from
    ... in doing that, I discovered that load event handling was
    ... 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-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

    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

    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

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

    ed: no
    ... though I haven't tested what's done tehre
    ... I'm surprised that Firefox doesn't send load for <image> at
    ... 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

    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

    <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: 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?
    ... 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 &

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

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

    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

    <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

    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?




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


      [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

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



    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

    <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



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


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

    <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
    [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
    [NEW] ACTION: Dirk to investigate how lighting filter outputs
    work when not composited on top of the original thing being lit
    [recorded in
    [NEW] ACTION: Erik to add pointer-events:boundingBox to SVG2.
    [recorded in
    [NEW] ACTION: Erik to do these event cleanups [recorded in
    [NEW] ACTION: Erik to find his numOctaves examples to find out
    what a good number to clamp to is [recorded in

    [End of minutes]
Received on Friday, 15 November 2013 09:33:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:47 UTC