W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2015

Minutes, FXTF F2F Sydney 2015

From: Erik Dahlstrom <ed@opera.com>
Date: Wed, 11 Feb 2015 18:05:15 +1100
To: "public-fx@w3.org" <public-fx@w3.org>
Message-ID: <op.xtvsm1xlgeuyw5@meh>


and the same as plaintext below:


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

                                - DRAFT -

                          FXTF F2F, Sydney 2015

10 Feb 2015

    See also: [2]IRC log

       [2] http://www.w3.org/2015/02/10-fx-irc



           Cameron, Cyril, Nikos


      * [3]Topics
          1. [4]css3-ui
          2. [5]Interaction between overflow, positioning and
          3. [6]Canceling and interrupting transitions
          4. [7]Filter Effects CR
          5. [8]CSS Blending PR
          6. [9]Colored font palette control
          7. [10]text-rendering
          8. [11]Canceling and interrupting transitions
          9. [12]css-transforms: Specifying decomposition of scale
         10. [13]Web Animations status update
         11. [14]ID-less referencing
         12. [15]Referencing properties
         13. [16]text in a shape
         14. [17]FlexBox
         15. [18]::selection
      * [19]Summary of Action Items

    <heycam> ScribeNick: heycam

    <scribe> Scribe: Cameron

    <ed> Agenda: [20]https://wiki.csswg.org/planning/sydney-2015

      [20] https://wiki.csswg.org/planning/sydney-2015



      [21] https://lists.w3.org/Archives/Public/www-style/2015Feb/0243.html

    <tantek> hello


      [22] https://lists.w3.org/Archives/Public/www-style/2015Feb/0243.html

    <tantek> [css3-ui] box-sizing and replaced element intrinsic
    width and/or ratios

    <tantek> regarding this issue:

      [23] https://wiki.csswg.org/spec/css3-ui#issue-69

    tantek: the first email I posted a couple of test cases
    ... each has an HTML file and three SVG elements
    ... the first one we should bring up is the replaced element
    test case
    ... it shows what happens in three different cases of embedding
    SVG as an image that has intrinsic width and ratio, or just
    intrinsic width, or just intrinsic ratio
    ... and what happens when you apply the max-height property to
    ... shows interaction of CSS 2.1 width computations and
    embedding replaced SVG element
    ... I want to start with this example because it's all stuff
    that should "just work" across browsers, btu we found
    differences that merit questions
    ... before we decide what box-sizing should do in these cases

    [florian projects replaced-element-001.html]

    tantek: in doing these tests we didn't find any differences
    between Blink and Safari
    ... there are some interesting things going on here
    ... I put the style rules that are taking place at the top
    ... that apply to each SVG element
    ... then the SVG markup inline so you can see what the source
    ... my understanding is that the top row should all be yellow
    ... 150x150 px
    ... it looks like IE is doing the wrong thing there
    ... by not maintaining the aspect ratio
    ... that's in the SVG file
    ... first, I want to verify that that's correct and that it's a
    bug in IE

    fantasai: so the specified width is 100px?

    tantek: no the intrinsic width is

    fantasai: and the specified width is not specified?

    tantek: correct

    dbaron: and it has a viewBox such that it has an intrisic ratio
    of 1:1

    Florian: and there is max-height: 100px that shouldn't take
    ... but if you look at IE it seems to be doing something
    ... both IE and safari are doing strange things on the bottom

    tantek: I want to check with SVG people that these cases are
    buggy in the browsers


      [24] https://lists.w3.org/Archives/Public/www-style/2015Feb/0243.html

    gregwhitworth: in Edge the top yellow one is fixed, the bottom
    one is the same as Firefox/Presto

    Florian: so that confirms the IE cases I'm looking at are bugs
    ... IE11

    tantek: so latest IE11 and latest Safari are buggy in handling
    intrinsic ratio, but not intrinsic width/height
    ... and Chrome does the same as Safari, so Blink/WebKit must be
    the same

    dbaron: Safari is buggy on the third case

    heycam: we had a big discussion about SVG sizing last year at a
    ... I don't remember the details except that we resolved on
    Firefox's behaviour modulo some corner cases

    tantek: so Edge has these fixed, and I'm hoping that
    WebKit/Blink can fix the third sub-test
    ... so this isn't the actual issue I want to discuss; just want
    to get a baseline about which behaviour is correct

    ed: I think the behaviour on the left side (Firefox and Presto)
    is what we want

    krit: people who are very familiar with this topic are not in
    this room so I would like to consult them

    <scribe> ACTION: Dirk to confirm that the Firefox/Presto
    behaviour of this SVG sizing test is correct and get back to
    Tantek [recorded in

    <trackbot> Created ACTION-87 - Confirm that the firefox/presto
    behaviour of this svg sizing test is correct and get back to
    tantek [on Dirk Schulze - due 2015-02-17].

    tantek: so we'll switch to box-sizing-replaced-element-001.html

    <tantek> second test here:

      [26] https://lists.w3.org/Archives/Public/www-style/2015Feb/0243.html

    <tantek> file name box-sizing-replaced-element-001.html

    tantek: what the box-sizing property allows you to do is change
    what width/height properties do
    ... you can make them include the borders and padding of the
    ... so if you want to figure out the content width you would
    subtract the border/padding
    ... any question about box-sizing:border-box?
    ... (default behaviour is content-box)


      [27] http://dev.w3.org/csswg/css-ui-3/#propdef-box-sizing

    <tantek> hello?

    tantek: in this one, because box-sizing is set to border-box,
    now the 40px solid transparent border kicks in, and cuts out
    from the max-height

    Florian: we still have an SVG file with an intrinsic width of
    100 and a viewBox ratio of 1:1

    tantek: identical SVG files to the previous test
    ... the three subtests are in the same order as the previous

    dbaron: I think the firefox behaviour on the second subtest is
    clearly buggy
    ... I think we're applying to the box-sizing to the width that
    is coming from inside the SVG, which we should not be doing

    fantasai: are these embedded cases?

    Florian: SVG in <img>
    ... as far as we can tell Presto is doing the right thing here

    tantek: we think that is the desired result, so we want to

    dbaron: I agree

    fantasai: should be equivalent to max-height:110px?

    Florian: max-height:70px

    tantek: on the first row we have IE and Safari agreeing on the
    wrong thing
    ... so we just want to confirm our assumption on which is

    fantasai: one thing making it more confusing is that the
    content box height is different
    ... so if you put border:25px max-height:200px you should get
    the same result as the previous test
    ... the boundary of the width of the SVG is 100px, in the prev
    test you were above that, in this test you're below that
    ... so you're triggering different cases
    ... I think you should test in all cases above the trigger
    point, or all below the trigger point
    ... the behaviour differenes might be due to something other
    than max-height

    tantek: so we changed just one property to see what happens

    fantasai: the numbers you picked made it change more than one

    tantek: that was unintentional

    gregwhitworth: Edge is matching Firefox here

    fantasai: change the border to 25px max-height to 200px
    ... we should also test this situation, btw

    gregwhitworth: chrome is doing the same as firefox on my
    windows laptop
    ... v40
    ... so this may end up being an issue with them talking to our
    ... right now on windows, firefox / edge ie / chrome have
    ... on the second case

    <dbaron> Filed Gecko bug

      [28] https://bugzilla.mozilla.org/show_bug.cgi?id=1131812

    dbaron: in the second case I believe we have some code that
    extracts a width that's specified embedded in an SVG, and
    applies that to the sizing outer of the img element
    ... because that's kind of how the sizing algorithm works
    ... so we're taking the width from the SVG, applying it to the
    img element, then applying box-sizing

    Florian: so doing the same thing as if the SVG was embedded
    inline in the HTML?

    dbaron: yes

    Florian: if that were the case the box would be 20px wide
    wouldn't it?
    ... and it looks more than that

    dbaron: yeah...

    <tantek> new test with fantasai suggested changes:

      [29] https://lists.w3.org/Archives/Public/www-style/2015Feb/0245.html

    <gregwhitworth> Windows SVG Test: [30]http://imgur.com/xbHMI0r

      [30] http://imgur.com/xbHMI0r

    dbaron: OK I'm not sure what's happening then. but I think it's

    tantek: I just sent the updated test that fantasai asked for to

    <tantek> file name box-sizing-replaced-element-002.html

    dbaron: this would be a lot easier if you emailed the
    individual files as attachments of the one email

    tantek: so now this test has fewer effective changes as

    fantasai: so this test -002 now looks identical to the first
    thing we looked at

    gregwhitworth: IE edge matches Firefox/Presto here

    Florian: which is the same as Safari except for the third case
    ... so it's just a bug in Safari

    tantek: which is why we wanted to show you without box-sizing,
    to show the WebKit's handling of intrinsic ratio is buggy
    ... if we can agree here what behaviour we want florian and I
    will specify it

    Florian: once box-sizing gets involved, if we don't apply
    min/max width/height it's not explicit, but still not ambiguous
    ... but with min/max-width/height, we need to specify something
    ... I think Presto has reasonable behaviour

    krit: this is something we should clarify with SVG the correct

    Florian: what is missing on the SVG side?

    krit: at least consensus on how viewBox etc. should operate on
    an SVG in <img>

    Florian: is there anything other than SVG that can give an
    intrinsic width, ratio, but no height?
    ... the spec says if you have an intrinsic width, do this. if
    you have width and ratio, do this. ...

    tantek: CSS has explicit clauses for each of these cases

    krit: this is with intrisic width and ratio, but not intrinsic

    Florian: yes
    ... we haven't got to intrinsic height but no width yet

    krit: ok then the left two browsers are right

    cyril: in the cases where the square is a rectangle and not a
    square, do you know if there's a bug in the rendering of the
    SVG and the aspect ratio is not preserved...
    ... and the box is filled with the SVG content?

    dino: for all three we need a circle in the SVG to see whether
    the bottom one is being clipped or stretched

    Florian: so can we use something other than SVG for testing

    tantek: no

    dino: as Dirk is saying, it's not well defined. it also has its
    own rules for preserving aspect ratio internally inside its

    tantek: we're trying to look at this from the point of view
    that implementations are converging, so we'd like to follow

    dbaron: I think this is well defined now

    tantek: in SVG?

    fantasai: I remember the SVG WG saying that it's totally clear,
    or that they would fix it
    ... so either that didn't happen or someone's confused

    krit: in this case we also didn't discuss object-fit

    Florian: that's not involved yet. but we will discuss that

    krit: that is the case for inline SVG. for <img> we haven't had
    the discussion yet.
    ... we likely should have the same rules for inline and in

    Florian: the way they start interacting with CSS is different

    tantek: the width attribute in inline is not intrinsic but
    ... so that's very different for these sizing computations

    <fantasai> width/height in an inline SVG is both specified and
    intrinsic size

    <fantasai> SVG specifies that it's the intrinsic size, and CSS
    specifies that it's the specified style

    <Tav> [31]http://tavmjong.free.fr/SVG/SCHILLER/html

      [31] http://tavmjong.free.fr/SVG/SCHILLER/html

    Tav: these are some tests I made from a few years ago, with SVG
    sizing in img, iframe, etc.

    dbaron: what are we trying to accomplish right now?

    Florian: tantek and I have an idea on patching the spec that
    seems reasonable. we want to see if it matches reality and that
    others agree.
    ... if none of the browsers is doing the right then, then...

    dbaron: what are the questions about how to integrate

    Florian: as long as you don't involve max-height/width, it's
    ... once you have a bit of an algorithm and lots of rules for
    width height, it doesn't say which width height to work on

    dbaron: I think that algorithm should be interpreted as working
    on content box sizes
    ... there might be other implementation bugs that are worth
    discussing separately
    ... I think the box-sizing spec update should be done because
    that's how it should work

    fantasai: is there any question in what you want to specify?

    Florian: unless someone strongly believes a non-Presto
    behaviour is right, no

    fantasai: that's fine

    tantek: we didn't expect this many bugs :-)

    dbaron: the SVG sizing stuff is pretty recently specced

    <TabAtkins> Just found out the <iframe src=foo.svg> sizes
    itself to the SVG's intrinsic dimensions, rather than 300x150
    like the spec says.

    <TabAtkins> WTF explicitly changing sizing rules without
    telling the WG about it.

    <TabAtkins> Sorry, *in Safari*.

    <TabAtkins> dino: ^^^ ???

    gregwhitworth: on windows, the very first test is similarly
    buggy in firefox/presto/IE

    tantek: the concern is that we if we have bugwards compat on
    this purple case, that's worrisome, because we think Presto's
    behaviour is correct

    <fantasai> TabAtkins: Why do you think the spec says to make it

    tantek: presto is treating the intrinsic width all by itself,
    and because there's nothing in the dimensions that apply to the
    width computations at all, ...

    Florian: there is no constraint on the width

    <cyril> email sent with updated svg tests (including a circle),
    please consider the second email (the first one had a wrong
    radius value)

    Florian: in the height dimension it shrinks down to 70

    tantek: there's no intrinsic ratio, so they're computed

    <TabAtkins> fantasai: Because the spec doesn't specify where to
    take dimensions from for <iframe>?

    <fantasai> It's a replaced element


      [32] https://lists.w3.org/Archives/Public/www-style/2015Feb/0247.html

    <fantasai> Just like an image

    Florian: this purple subtest has no intrinsic ratio

    ed: do you have enough to go on here?

    <fantasai> There is nothing in any spec that says <iframe> (as
    a tag) is style differently from <object> or <img>. No
    tag-specific behavior is specified anywhere.

    <hober> fantasai++

    tantek: firefox sets the width to 47px, which is very odd

    gregwhitworth: since I don't know about SVG I'm completely ok
    with this

    dbaron: the weird Firefox behaviour is not related to
    ... if I remove the box-sizing, remove the max-height, change
    the border, I get the same output
    ... this might be coming from default sizing not being 300x150,
    for SVG
    ... if you work through that long list of rules, the way
    max-height applies doesnt always preserve the intrinsic ratio

    Florian: on the second one there's no intrinsic ratio

    dbaron: or doesn't always preserve the things you want
    ... if I change the max-height to height, you get the expected
    ... I think therei s something in the spec rules that gives the
    47px result

    fantasai: I think the only weird cases are when you're
    balancing conflicting requirements

    Florian: but in this case we're not over constrained

    fantasai: let's resolve the behaviour on we want, not on "what
    Presto does"

    SimonSapin: is this looking at CSS 2.1?

    tantek: yes, plus box-sizing

    <SimonSapin> (as opposed to the CSS Images module)

    RESOLUTION: We will patch the CSS 2.1 width computations to
    specify it uses content width, which is implied but not
    explicit (which we assume will get Presto's behaviour).

    <tantek> [33]https://wiki.csswg.org/spec/css3-ui#issue-69

      [33] https://wiki.csswg.org/spec/css3-ui#issue-69

Interaction between overflow, positioning and filters

    <roc> [34]http://fiddle.jshell.net/mkud1Lnm/1/

      [34] http://fiddle.jshell.net/mkud1Lnm/1/

    roc: this is basically a spec issue, as to what should be
    ... right now specs don't really say
    ... and it's tricky to fix, there's no obvious way to fix it

    <fantasai> CSS2.1: “This property specifies the content width
    of boxes. ”

    roc: if you look at the fiddle, what we have is there's a div
    container with overflow hidden, but it could be any clipping
    ... it has a filter on it, in this case a blur

    <fantasai> CSS2.1 is very clear that it's talking about content

    roc: and a couple of elements inside

    <dbaron> FWIW, I can explain where the 47px comes from

    roc: one of the elements is position:fixed (but also happens
    with position:absolute)
    ... the positioned div is not supposed to be clipped by the
    element that has overflow:hidden
    ... but it's in a filter and some of the content of the
    filtered image should be clipped, while some shouldn't
    ... it's really unclear how to render this example

    <smfr> to me this is a pretty fundamental failure to spec the
    interactions between the clipping tree (which follows
    containing blcok) and the z-order tree

    <fantasai> dbaron, go ahead, I'm very curious :)

    roc: if you bring it up in Chrome or Firefox, you get a
    rendering where both of the elments are clipped
    ... in particular the yellow one is clipped to the
    overflow:hidden element, but technically it shouldn't be
    ... you can't say it's not clipped, since with the blur, some
    pixels have contributions from both the blur and the yellow
    ... it's unclear what the visual result should be
    ... there's no way to preserve the behaviour that one of these
    elements is clipped, one is not, but they're filtered together

    <dbaron> Without the max-height, the SVG should be 100px wide
    and 150px tall, since the default size is 300px x 150px, and
    the SVG has a width=100 that overrides the 300. Then the
    max-height:150px with the box-sizing is equivalent to
    max-height: 70px... and when we apply the max-height, we scale
    the image down by its ratio, so the 150px -> 70px and 100px ->
    47px (in the same ratio). So the bug is that we're incorrectly
    scaling down by ratio in that case, I believe.

    roc: the problem does not arise for opacity, that's because
    opacity commutes with clipping
    ... if you clip then opacity, it's the same as opacity then
    ... not true for general filters
    ... because opacity commutes, you can push it down, and get the
    results you'd expect
    ... but with filters you can't
    ... what gecko and chrome are doing is rendering the contents
    to a buffer, applying the filter, then because the filtered
    element is in overflow:hidden, we clip the filtered result
    ... the question is what to spec
    ... try to explain that behaviour, or we introduce some
    restrictions on the interactions between filters and
    overflow:hidden and positioning
    ... so that it's well defined
    ... is the problem clear?
    ... we could directly specify what Chrome/Firefox are doing,
    and one way to do that would be to say that overflow clips ---
    right now overflow:hidden clips every descednatn for which it
    is a containing block
    ... we could say it clips every descednatn for which it's a
    containing block plus it clips all descendants of elements that
    have a filter
    ... that's option #0 (I didn't put that in my email)
    ... option #1 from my email is that filter is like transform,
    becomes a containing block for positioned elements
    ... so they can't escape from the filter
    ... so the current definition of overflow:hidden would mean it
    applies to them
    ... option #2 is you could say the filter doesn't affect the
    positioned descendant, it can escape the filter
    ... so filters only apply to things for which the filtered
    element is the containing block

    dino: so the yellow element would not be filtered

    roc: yes

    Tav: I'm a little confused. the way I think about it, if you
    take something that's being filtered -- if you have an image
    and you move/animate it, you don't want to see side effects

    dino: simon prefers filtering winning over the overflow
    ... so stacking context is more important overflow
    ... so not the choice where yellow div is not filtered

    roc: I'm for option #1
    ... if we can make filters a container for positioned
    ... there's some web compat risk, not a whole lot

    heycam: would you often want positioned things inside filtered
    elements? maybe not.

    dino: simon says sucks opacity and filters are not treated the

    roc: it does kind of suck
    ... I don't have any alternative to that

    dino: with blending, we don't have the same issue?

    roc: no, because blending commutes with clipping
    ... if you have an opacity:0 pixel, blending can't turn that
    into something that is not opacity:0

    krit: not yet

    roc: if we add all the porter duff modes then it would be an
    ... we could change blend modes now, to force the same
    ... that would guard us in the future

    Tav: option #1 makes sense to me

    dino: I agree with making blending operate the same, and doing
    that now

    roc: we've been talking about adding an escape hatch for
    ... so transforms are not a positioning container
    ... if we do that we could have keyword on transforms

    krit: all blend modes we implement use src-over compositing
    ... I don't think we want to combine blend modes with other
    compositing modes

    roc: if we introduce other compositing modes, will it be in
    mix-blend-mode or a different property?

    nikos: suggested to be in a separate property

    roc: in that case we don't need to add restrictions for
    mix-blend-mode now
    ... so that new property would need to create a container for
    positioned elements
    ... so we won't change mix-blend-mode behaviour, but will do it
    for filters

    heycam: you could restrict this filter behaviour for only some
    predefined filter keywords

    roc: I don't feel like we want to do somethign taht complicated

    <smfr> heycam: ick, what if you animate between them?

    smfr indeed, the position of elements could change when you
    change the filter behaviour

    RESOLUTION: non-none values of filter induce a containing block
    for all positioned descendants

    <scribe> ACTION: Erik to make non-none values of filter induce
    a containing block for all positioned descendants [recorded in

    <trackbot> Created ACTION-88 - Make non-none values of filter
    induce a containing block for all positioned descendants [on
    Erik Dahlström - due 2015-02-17].

    -- 15 min break, back at 10:49 --

    <smfr> sgalineau: it’s break time

    <smfr> sgalineau: scones and cream

    <sgalineau> doh. carry on :)

    <sgalineau> smfr: scones are very important.

    <smfr> background: jam 100% 100%, cream 200% 200%;

    <shane> Anyone in Sydney: please RSVP for dinner tonight! I
    need numbers and menu preferences by 12. The venue is Redoak
    (redoak.com.au), at 7:00pm. Use this form:

      [36] http://goo.gl/forms/KthFB4ip99

    <sgalineau> you had me at boutique beer

    <sgalineau> smfr: overflow: visible?

    <liam> sgalineau: overflow: burp

    <hober> fx

    <liam> wait, is that for scones or beer? :)

    <shane> beer scone spiders - why not have both?

Canceling and interrupting transitions


      [37] https://lists.w3.org/Archives/Public/www-style/2014Dec/0150.html

    dbaron: let's postpone until after lunch

Filter Effects CR



    krit: this is the disposition of comments document

    <plinss> [39]http://dev.w3.org/fxtf/filters/issues-lc-2015.html

      [39] http://dev.w3.org/fxtf/filters/issues-lc-2015.html

    krit: we have some open issues still in the spec
    ... one of them is error handling in general with filter

    <krit> [40]http://fiddle.jshell.net/ev10jtmp/3/

      [40] http://fiddle.jshell.net/ev10jtmp/3/

    krit: here's a test for error handling
    ... the filter property can take a url, which references a
    <filter> element
    ... what happens if the url is invalid

    <dbaron> or alternatively

      [41] http://drafts.fxtf.org/filters/issues-lc-2015.html

    krit: if it's invalid then I think it's clear that we should
    ignore the setting of the filter property, and fall back to the
    ... that's standard CSS behaviour
    ... what if it's valid syntax but does not reference a filter,
    or the ID doesn't exist
    ... behaviour is different between browsers
    ... SVG 1.1 said that the filtered element disappears
    ... there were objections that this might not be the preferred
    ... firefox does what SVG 1.1 says, so if you apply
    filter:url(#badID) then it makes the object disappear
    ... other browsers ignore the filter

    heycam: I think Firefox should display the element normally,
    i.e. ignore the filter

    RESOLUTION: If a filter references a missing ID or an element
    that is not a <filter>, the element is rendered normally as if

    krit: the next problem is, what happens if the URL is valid,
    you reference an element, it exists, but now you have certain
    filter effects in it and they take an input that doesn't exist
    ... e.g. <feGaussianBlur in="invalid">
    ... SVG 1.1 makes the whole filtered element disappear
    ... WebKit does that, as Firefox does
    ... Blink does something different
    ... or you could reference the previous filter effect (i.e.
    default in="" value) or default SourceGraphic

    dino: or make the primitive use transparent black as input

    roc: yes

    krit: if you make a mistake in the filter chain, it's not going
    to give you a result you want
    ... if you reference a filter input that doesn't exist, that
    could kill the whole processing of the filter

    <liam> [having the element not rendered means you can't easily
    right-click on it and "inspect" to debug the problem]

    krit: I don't think we should just make transparent black for
    that primitive's input

    Tav: I agree with that

    nikos: making just one primitive's input transparent black can
    help you understand where the error is

    ed: I think what Presto is doing is following the 1.2T model,
    which says to take the default value if you have an error in an

    krit: which would be the previous filter effect

    heycam: I'm fine with disabling the filter

    RESOLUTION: If a filter primitive references an invalid input,
    then the whole filter is disabled and the element is rendered


      [42] http://dev.w3.org/fxtf/filters/issues-lc-2015.html#issue-6

    krit: next, issue #6
    ... if someone uses currentColor in feColorMatrix, what is it?
    ... the proposal is to have currentColor resolve against the
    element that is being filtered, not with the value of color on
    the actual primitive element

    Tav: we have context-fill
    ... we decided to make that work in all referencing elements,
    like filter, pattern, etc.

    krit: I'd like to delay putting anything in the filters spec
    for this

    ed: I think that's fine with me

    heycam: happy to do that later

    RESOLUTION: Defer context-fill usage in Filter-specific
    properties until level 2 of Filters.


    RESOLUTION: next is issue #8
    ... luminance has fixed colour matrix values. in most places
    they have 3 digits after the dot, in some places they have 4
    ... the request was to have 4 digits everywhere, instead of
    just 3


      [43] http://dev.w3.org/fxtf/filters/#element-attrdef-values

    heycam: so it's using 4 digits in the luminance matrix, but 3
    in the other types

    krit: any objection to using 4 digits everywhere?

    (none heard)

    RESOLUTION: The feColorMatrix pre-defined matrices should all
    use 4 digits after the decimal point.

    krit: next, issue #11



      [44] https://www.w3.org/Bugs/Public/show_bug.cgi?id=27464

    krit: if you have objectBoundingBox units, and you try to use
    say 47em, what does that mean?
    ... not clear what element the ems are resolved to px

    heycam: I guess they should be resolved against the font-size
    of the element they're on

    ed: not sure if this needs to be mentioned in the spec
    ... could put a note that these values will give useless
    results [as they're much > 1]

    RESOLUTION: Make it clear that em units on
    filterUnits-affecting attributes are resolved against font-size
    on the same element; and we'll add a note mentioning that it
    won't do anything useful for you.

    (unless you use very small em values of course)

    <liam> [the note should explain why, as there are cases where
    it works]


      [45] http://dev.w3.org/fxtf/filters/issues-lc-2015.html#issue-12

    <liam> (yes - I think that's not uncommon)

    krit: finally, issue #12
    ... I thought we already discussed this and decided

    Tav: specularExponent is used in two different places
    ... just adding a note to say that two uses of this are

    krit: I think I made that change already
    ... now, how do we want to proceed with the spec. should we
    continue with a WD or should we publish a CR of it?

    ed: any objections to publishing as CR after the edits are

    (none heard)

    RESOLUTION: Publish a CR of Filters spec (under the new

CSS Blending PR

    krit: I'm speaking for Rik who can't be here
    ... we already had a resolution to PR at TPAC, but there was
    one issue that forced us to have another CR
    ... there haven't been any complaints since then
    ... Rik is working on the necessary documents to get to PR, and
    I'd like to have the resolution from the WG to go to PR

    ChrisL: implementation report with two passes for everything?

    krit: we do have 2 implementaitons for each feature and Rik is
    preparing that implementation report

    ChrisL: shouldn't need a resolution of the WG

    Florian: we could resolve that we think the test suite is
    sufficiently extensive
    ... that passing it is meaningful
    ... and then we you pass it everything is fine

    ChrisL: what's the test coverage like?

    Tav: including SVG?

    krit: yes we have tests covering each section



    krit: the other part of the test suite are the canvas tests
    that were published with philip's test suite

    ChrisL: what do the CR exit criteria say?


      [47] http://www.w3.org/TR/compositing-1/#cr-exit-criteria

    ChrisL: the SotD section says that CR must last until at least
    March 17

    Tav: you have some SVG specific tests, but you don't test each
    of these things in both HTML and SVG?
    ... it'd be nice if each of these actually linked to the tests


      [48] http://test.csswg.org/harness/results/compositing-1_dev/grouped/

    krit: I will ask Rik to provide the necessary documents

    ChrisL: it looks like they're all HTML tests?

    Tav: I am concerned we're not testing enough applying to SVG

    ChrisL: there are some broken links too

    <ChrisL> links like ../support/* should be support/*

    Tav: would be good for pure SVG documents so I can provide
    results for Inkscape

    <scribe> ACTION: Dirk to ask Rik to produce SVG versions of the
    blending tests. [recorded in

    <trackbot> Created ACTION-89 - Ask rik to produce svg versions
    of the blending tests. [on Dirk Schulze - due 2015-02-18].

    <cyril_> scribe: Cyril

    <cyril_> scribeNick: cyril

Colored font palette control

    <cyril_> heycam: I sent an email to www-style about this


      [50] https://lists.w3.org/Archives/Public/www-style/2015Feb/0211.html

    <cyril_> heycam: in the latest version of hte OpenType spec

    <cyril_> ... which reached a stage where only editorial changes
    can be made

    <cyril_> ... there is 3 types of colourful glyphs:

    <cyril_> ... bitmap format like PNG

    <cyril_> ... vector format reusing existing glyf and cff table

    <cyril_> ChrisL: was it extended to CFF ?

    <cyril_> heycam: it was an assumption

    <cyril_> ... might not be

    <cyril_> ... and the 3rd option is embedded SVG document

    <cyril_> ... in the last 2 options they have the option of
    using a palette

    <cyril_> ... in fact for option 2 it is mandatory

    <cyril_> ... for SVG glyphs it is an option by using CSS

    <cyril_> ... some CSS variiables are defined automatically

    <cyril_> ... in the font you can define a number of palettes

    <cyril_> ... but there is no way to select the palette you want

    <cyril_> ... or provide your own custom palette

    <cyril_> ... I thought it moght be a good thing to allow

    <cyril_> ... my email has an actual proposal

    <cyril_> ... for selecting which palette, there would be a new
    property font-palette referencing the palette by a name

    <cyril_> ... there is no name in the font

    <cyril_> ... the idea would be to map indices to names for a
    particular font

    <cyril_> ... you don't want to set ffont-palette: 3 and then
    depend on the font

    <cyril_> dino: I think for these fonts, you know what you're

    <cyril_> ChrisL: we don't know what fonts you have on the
    machine or what fonts are downloaded

    <cyril_> roc: there is an issue with editable content, it is
    easy for users to add characters that are not in the font

    <cyril_> ... and you can have fallback to system fonts and that
    might not be what you want

    <liam> [that's true for any font, including woff]

    <ChrisL> we already have that issue with font feature
    selection, where feature numbers are not portable across
    different fonts

    <cyril_> dino: the theory is that if you specify the palette
    you end up with a font that has the right palette ?

    <cyril_> heycam: jdaggett was of the opinion that it should go
    in font feature values

    <cyril_> dino: it's not a big deal but it might be longer to

    <cyril_> ... people might end up with names 'one', 'two' ...
    for the palettes

    <liam> [could some suggested names be proposed for palette
    entries? e.g. highlight, shadow, front, layer1, layer2 ? We
    don't have CSS rules that are conditionally applied dependingon
    which font is in use]

    <cyril_> heycam: if people were happy with disabling palette
    selection if you use a fallback selection, I'll be happy

    <cyril_> dino: tab's suggestion is good too

    <cyril_> ... you can use palette name but if the name is a
    number that's the index then

    <cyril_> roc: we could disable fallback for now and add it

    <cyril_> TabAtkins: reasonnable

    <cyril_> heycam: do people think this should be in the next
    level of the font spec ?

    <cyril_> ChrisL: it doesn't make sense to put in the current
    level because it's stable

    <cyril_> heycam: what about adding font palette selection to
    level 4

    <cyril_> ... and it uses an index to begin with and font
    fallback disables selection

    <cyril_> ... and later we can add a more detailed feature

    <cyril_> TabAtkins: yes

    <cyril_> resolution: add font palette selection to CSS Fonts
    level 4

    <cyril_> ACTION: jdaggett to add font palette selection to CSS
    Fonts level 4 [recorded in

    <trackbot> Error finding 'jdaggett'. You can review and
    register nicknames at

      [52] http://www.w3.org/Graphics/fx/track/users

    <cyril_> heycam: the next step, if we want to, is to specify
    custom palette values

    <cyril_> ... for my example (in the email), the font creator
    would provide different fonts

    <cyril_> ... it's normal to have a choice to select the palette

    <cyril_> ... in my optional proposal #2, I added something

    <cyril_> ... adds a @font-palette

    <cyril_> TabAtkins: I don't think we need the indirection of
    the @font-palette

    <cyril_> ... we can use directly the font property to specify
    the color palette

    <cyril_> ... for colors, giving a name is useful

    <cyril_> ChrisL: people asked a long time ago to be able to
    name colors

    <cyril_> heycam: I'm happy with not having the named palettes
    and not having the @font-palette rule

    <cyril_> ... does the order of the names and colors in the
    font-palette property have to match the indices ?

    <cyril_> TabAtkins: no

    <cyril_> heycam: what happens if you miss out one of the
    palette entries ?

    <cyril_> ChrisL: you default to transparent black ?

    <cyril_> TabAtkins: no simply black

    <cyril_> ChrisL: I agree I made a big mistake here

    <cyril_> heycam: do we agree we want the feature ?

    <cyril_> Tav: yes

    <cyril_> TabAtkins: why don't overload the color property ?

    <cyril_> ... you might to use a palette function

    <cyril_> heycam: what does fill=currentColor on a shape if you
    have that ?

    <cyril_> ChrisL: color can be used for other usages: stroke,
    fill, ...

    <cyril_> TabAtkins: yes

    <cyril_> ChrisL: not objecting but concerned about how it would

    <cyril_> TabAtkins: so if you omit some palette index names, we
    could default to using the color value

    <cyril_> ed: is it possible to use a palette and override some
    colors ?

    <cyril_> ChrisL: palette is a preset, you can override it all

    <cyril_> ... we've had that discussion on gradients, overriding
    some stops, but it's not used

    <cyril_> (chris digresses on Web audio)

    <cyril_> resolution: we add custom palette support without the
    @font-palette rule

    <TabAtkins> Assuming that duplicated palette index names take
    the last one, you can always store a palette in a custom
    property, and override individual bits by putting them at the
    end, like "font-palette: var(--my-palette), highlight white;"

    <cyril_> heycam: we'll still name the individual palette
    entries inside font-feature values

    <cyril_> heycam: the final part in my email, proposal 3

    <cyril_> ... you can specify if one of the predefined palette
    is appropriate for dark, light, both or neither background

    <cyril_> ... emoji fonts have dark versions and light version

    <cyril_> ... i'm suggesting adding keywords to select the

    <cyril_> TabAtkins: +1

    <cyril_> ... I'm suggesting to name it according to the system
    it is supposed to be used: lightSomething, darkSomehting

    <cyril_> heycam: you probably always want to use the
    highcontrast one without analysing the background color

    <cyril_> ... I'm ok with starting with just light and dark

    <cyril_> .. do people agree ?

    <cyril_> ChrisL: yes

    <cyril_> resolution: font-palette property will have light and
    dark keywords to select the first light or dark annotated
    palette in the font

    <cyril_> heycam: I'd like to bring a little issue regarding css

    <cyril_> ... I tried to implement css variables and palettes

    <cyril_> ... (explaining something about caching)

    <cyril_> ... we could need a non-variable way to indicate

    <cyril_> ... I don't know if we can do that

    <cyril_> ... It's a bit late in the open type process

    <cyril_> ... but we might have this problem in other contexts

    <cyril_> TabAtkins: for svg fonts, I see the problem

    <cyril_> ... but using variables in UA specific way is a
    viloation of the spec anyway

    <cyril_> heycam: it's probably possible to detect that the
    palette variables are used in a sensible way

    <cyril_> ... but I'm concerned more about the general pattern

    <cyril_> ... like a stroke-width controllable by variables

    <heycam> Scribe: Cameron

    <heycam> ScribeNick: heycam


    roc: this is a google request
    ... we got an email from docs people complaining that in
    Firefox when you zoom the page in google docs, the layout of
    the text changes
    ... the width of the string in css px changes when you zoom
    in/out of the page
    ... turns out this is true in all pages, including chrome in
    some situations
    ... the reason is because of font hinting, in this case
    ... there are some other issues
    ... with vertical metrics it can also occur if you round line
    height to pixels
    ... they saw this as a bug, though I don't think it is a bug
    ... generally you do want to hint on windows, as you want to
    match OS text rasterisation
    ... basically after a short discussion, we determined that the
    right thing to do would be to make
    text-rendering:geometricPrecision disable hinting and try to
    make sure we just use the metrics in the font
    ... and render that font with no regard to what the device
    resolution is
    ... then if we do that consistently we can make text rendering
    device resolution independent
    ... as you zoom in/out you'd get the same metrics
    ... apparently chrome has or will do this

    ChrisL: that seems consistent with what geometricPrecision was
    designed for

    roc: if we do this, then the spec should make this a
    ... this would apply to HTML and SVG

    Rossen: when you zoom, what do you mean?
    ... user zoom in firefox?

    roc: a full page zoom that causes a layout
    ... so for any layout-changing zoom
    ... (non-layout-changing zoom already doesn't affect text

    Rossen: so this would affect high dpi devices, you're opting in
    to some level of zoom?

    roc: right now you can get different layout on high/lo dpi
    ... this would make those layouts consistent with each other
    ... and across the web
    ... we could make layouts fully consistent across browsers, at
    least text width

    Rossen: I think Ted and Matt Rakow want to make that happen

    roc: in Firefox I would make text metrics incl advance widths
    depend only on the content of the OpenType font
    ... the problem is platform APIs apply rounding in different
    ... I'd like to bypass that and just get data from the font

    Rossen: do you have any test cases we could look at?

    roc: I'll send you one
    ... I should mention that our plan is to continue to render
    glyphs with subpixel AA where possible
    ... eventhough we're not doing any hinting
    ... this doesn't mean we need to turn off subpixel AA
    ... it's a layout issue, not glyph rendering issue
    ... sounds OK?

    ChrisL: yes

    dino: yes

    RESOLUTION: text-rendering:geometricPrecision will require that
    font metrics and text measurement will be independent of the
    device resolution
    ... and zoom level

    <scribe> ACTION: Cameron to make
    text-rendering:geometricPrecision change [recorded in

    <trackbot> Created ACTION-90 - Make
    text-rendering:geometricprecision change [on Cameron McCormack
    - due 2015-02-18].

    -- lunch break, 90 mins --

    <nikos> scribenick: nikos

    <scribe> scribe: Nikos

Canceling and interrupting transitions

    dbaron: There have been some relatively large edits since the
    WD - but only stuff that implementors would care about
    ... such as cancelling and interrupting transitions
    ... I think I'm ready to take the spec to new new process CR
    ... there's a bunch of issues in bugzilla
    ... I made some minor edits and there's a few we should talk
    ... anything that's a new feature is marked to defer to level 2
    ... there are a few that are about animating specific value
    ... like images and gradients
    ... those should be deferred to css images
    ... one question is whether there should be transition rules
    defined for z-index:auto


      [54] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16265

    dbaron: apparently testing showed that a bunch of engines do
    transitions between z-index:auto and numbers
    ... this may or may not just be a bug related to treating the
    value as zero
    ... the behaviour that was observed was that if tehre was a
    transition between auto and number there was interpolation as
    if it were between zero and a number
    ... and a jump at the end
    ... apparently zero to auto jumps were at both ends
    ... do people thing we should have special transition rules for
    ... ?

    TabAtkins: I'd prefer not, I don't see how to do it properly

    dbaron: a special rule would mean that any intermediate
    interpolation that was not 100% value or the other would treat
    auto as zero

    dino: it looks to me like it's a bug
    ... what would you do otherwise?

    dbaron: current behaviour says if one value is auto you can't

    dino: think it's just a bug that webkit should fix
    ... we don't check that it's auto

    <smfr> that might have compat risk for webkit but we should fix
    it (maybe with the non-prefixed transition, dino)

    dbaron: a few of the issues are a mix of feature requests for
    new things or things we've fixed
    ... so I'm inclined not to look at them
    ... if someone wants to help?

    RESOLUTION: Leave z-index as is

    dbaron: the one other issue filed is for more constraints
    specifying when computed values change
    ... e.g. when transitions start
    ... i've avoided specifying too much there
    ... don't want to make this a spec for the browser refresh
    ... and would like to leave room for optimisation
    ... there was a statement that it was specifically not
    ... I realised I could specify it in a more useful way by
    saying the spec does not define when computed values change but
    if you do something with the computed value then the computed
    value has to have changed
    ... I wrote prose this morning
    ... so there is a definition that leads to useful results
    ... and doesn't allow implementation to be conformant without
    doing anything

    Florian: intent sounds useful

    dbaron: the big changes in this draft are mostly stuff we've
    discussed before
    ... more precise definition of cancelling and interrupting
    running transitions
    ... and the things we discussed in Paris about the details of
    ... I haven't gotten a huge amount of feedback
    ... given the number of implementations I think we should go to
    ... and we'll get feedback from implementors

    RESOLUTION: CSS transitions can go to CR

    Florian: you're not currently in LC?

    dbaron: this is the new process
    ... so we can go straight to CR

css-transforms: Specifying decomposition of scale



    stakagi: I've prepared a wiki page
    ... I'd like to specify decomposition of scale
    ... the use case of scale are non scaling objects, and level of
    ... this scale is not scaleX or scaleY
    ... non scaling objects are a part of vector graphics
    ... of svg 2
    ... the svg working group decided to put non scaling object
    functionality in svg 2
    ... you can see a polyfill in the link on the wiki page
    ... and level of detail also determines standardisation of
    ... there is a video to demonstrate this
    ... the scale value decomposed from the transform matrix is
    required for each function
    ... and such a scale value should be one scalar value
    ... which is always meaningful on all the affine transformation
    involving skew
    ... the chapters on decomposing 2d and 3d matrices for scaling
    are dependent on specific axis
    ... I'd like to specify a method that does not depend on a
    specific axis
    ... I would like to introduce this into that chapter
    ... each scale is based on the determinant of the matrix
    ... 2d decomposition is sqrt of determinant
    ... 3d is cube root
    ... decomposition of scale can be calculated based on these

    birtles: the specific proposal is to add an extra definition to
    css transforms
    ... of a scalar value for scale
    ... takagi-san has prepared a polyfill. In this he compares the
    definitions that are axis dependent with this version
    ... if you skew the shape you can see that the area of the
    shape changes dramatically
    ... if you use the scalar value you can avoid this

    heycam: we already have transform ref in the svg spec
    ... which undoes all transforms from one space to another
    ... never mind

    ChrisLilley: this is obviously correct - this is something
    we've needed

    <ChrisLilley> [56]http://www.w3.org/Graphics/ScalableReq

      [56] http://www.w3.org/Graphics/ScalableReq

    ChrisLilley: we've achieved all requirements except level of
    ... we're talking about extreme zoom
    ... we need level of detail and it needs to work regardless of
    ... I support this

    birtles: the proposal is to add this definition of scale to the
    part of css transforms that defines decomposition of matrices
    ... not necessarily to use in css transforms, but able to be
    ... don't think it requires behaviour of spec to change
    ... this seemed like the most appropriate place to define it

    krit: decomposition has multiple steps

    birtles: this would be another definition alongside the method
    that obtains a vector, that returns a scalr
    ... it doesn't replace the current definition
    ... we could possibly also add to the interpolation section.
    And in recomposition we can say multiply by these values

    dino: you'd never be able to interpolate between the two values

    heycam: are you saying existing definitions could be simplified
    by referencing this new definition?

    birtles: I don't think that's the suggestion

    dino: so in non scaling stroke part of svg we can say that when
    you change zoom levels you should unscale by this decomposed
    ... and if you animate you should animate between these values

    heycam: going back to broader level of zoom media queries
    ... couple of years ago Ted was going to investigate different
    zoom use cases
    ... do you know if anything came of that?

    dino: don't know

    Florian: with zoom media queries we want to be really careful
    ... some things you don't want to expose
    ... e.g. pinch zoom

    heycam: I think to solve the use cases we may need a switch to
    control what pinch zoom does

    birtles: we talked about that but Takagi-san hasn't had a
    chance to come up with a proposal

    dino: this is only really going to have an impact if people are
    scaling with a different amount on different axis

    birtles: that's right

    dino: how many people skew?

    heycam: I think Takagi-san recognised that in most cases it
    doesn't matter
    ... but we should provide the definition for cases when it does

    birtles: there's a formula in the wiki

    krit: we'd be putting it into the transform spec without any
    ... does it need testing?

    heycam: just review it to make sure it's o
    ... ok
    ... then when another spec depends on it test that

    stakagi: we might use it in svg 2 and then we can test it there

    heycam: Dirk, as editor how do you feel about it?

    krit: I need to look at the formula
    ... idea seems ok

    dino: it's important we specify the exact value for non scaling
    stroke so all implementations are the same - I think that's
    enough reason to accept this

    heycam: question is where should it live

    krit: best thing to do is to propose prose we can put into the
    ... as long as there's no requirement to test it

    stakagi: I will send a pull request

    RESOLUTION: Include Takagi-san's definition of linear scale in
    CSS transforms

    krit: Can I publish a new wd? last one was a long time ago

    <ChrisLilley> how about putting that recently agreed change in
    there first

    <scribe> ACTION: Takagi-san to propose specification text for
    new scalar value for CSS transforms [recorded in

    <trackbot> Error finding 'Takagi-san'. You can review and
    register nicknames at

      [58] http://www.w3.org/Graphics/fx/track/users

    <scribe> ACTION: stakagi to propose specification text for new
    scalar value for CSS transforms [recorded in

    <trackbot> Created ACTION-91 - Propose specification text for
    new scalar value for css transforms [on Satoru Takagi - due

    RESOLUTION: Publish new WD of CSS transforms with Takagi-san's

Web Animations status update



    (Brian presents)

    krit: Back to transforms WD - Simon added new preserve 3d
    stuff. Do we need agreement on it or can we talk about it after

    dino: is it ok to publish the WD with this section in it even
    though we may need to discuss it further?

    roc: did we get any specific feedback from MS?

    krit: there were competing proposals

    roc: there was just one minor issue I brought up

    krit: I think the spec has an issue noting that so it should be
    ok to publish a WD

    (and back to Brian's presentation)

    birtles: want to give an update and ask some questions
    ... started to ship in little pieces
    ... Chrome and FF have started at opposite ends of the API
    ... and FF has some dev tools
    ... we've published two WDs so far and another to come soon
    ... diagram (slide 2) shows moving pieces
    ... been some simplification
    ... had motion path but that's been removed
    ... there's now a motion path module
    ... created by Dirk
    ... recently we also deferred grouping to a subsequent level
    ... it's useful but not critical
    ... diagram is now simpler - and I'd like to make it simpler
    ... would like to merge Animation and Keyframe Effect
    ... Animations are the dynamic part
    ... Keyframe Effect is static
    ... this isn't in the spec yet
    ... there's some concern that this may make Keyframe Effect
    objects less shareable
    ... but this is the model I'm proposing
    ... it also makes the naming more straight forward
    ... A lot of people found Players confusing
    ... that's an update on where the spec is at now

    krit: different name for Keyframe Effect? Anything shorter?

    shane: we had Player and it was too generic - is Animation too

    birtles: don't think so
    ... we already have the term

    dino: no fear of clobbering third party library that uses

    shane: something we need to do a little research on

    dino: what other effects do you have?

    birtles: only Keyframe Effects
    ... level 2 will have Group Effects and Sequence Effects
    ... still considering what to do with Custom Effects

    krit: how do you set up a Keyframe Effect?

    birtles: new KeyframeEffect

    shane: also element.animate

    heycam: I would find Group Effect a bit confusing
    ... effect doesn't seem like the right word there - don't have

    dino: could be concurrent effect

    shane: I find the name good - you're grouping a set of effects

    heycam: that should be an effects group then

    birtles: distinction is it's the static definition
    ... it's attached to an animation which is the dynamic part

    ChrisLilley: shouldn't it be grouped effect then?

    birtles: other APIs use 'set'
    ... we can think about names some more
    ... other question I had - easing, iterations, fill. We chose
    these names because they're short to type. But it does
    introduce the problem that they're very different to the terms
    CSS animation uses
    ... better to line up with css or keep short?
    ... two votes for keeping it short

    ChrisLilley: if it aligns with CSS it has to be exactly the
    same thing

    TabAtkins: it is

    shane: easing is much more of an industry standard than timing

    ChrisLilley: fill on the other hand I've only ever seen in the
    context of SMIL

    krit: seen it used a lot in JS libraries

    ChrisLilley: iterations over animation-iteration-count is good
    ... could you put an issue in the spec saying calling out to
    script for easing will be possible in the future

    dino: we shouldn't really announce features

    ChrisLilley: True - but good to explain why it's not there

    birtles: couple of other questions



    shane: First events and promises
    ... we switched from events to promises
    ... only used in two scenarios
    ... turns out that in different scenarios either events or
    promises can be useful
    ... in FF OS they've been doing things where you set up a
    transition to move between states of the UI
    ... and key on the end
    ... all sorts of reasons why that won't trigger
    ... so it's difficult to build a reliable system on top of that
    ... but with a promise you're guaranteed it will resolve or
    ... much easier to be reliable
    ... so a strong use case for promises
    ... but promises can be the wrong tool as well
    ... e.g. if you have an event you want to reuse you can call
    play.play and when it gets to the end it will clean up after
    ... if you use promises every time you call play you need to
    set up the promise
    ... promises are one shot
    ... so in this case events are cleaner and easier than promises
    ... so could we have both?

    heycam: as long as you make sure that we have a consistent
    pattern in the order they are resolved and dispatched

    TabAtkins: I don't have an order specified so we should think
    about that

    dino: one of the best things about events is you can pass an
    object in to a listener

    RESOLUTION: Allow both events and promises in Web Animations

    shane: other thing I wanted to talk about
    ... got an animation that's filling forward
    ... can't change the value of the property that is animated
    ... that's probably the single most complained about thing
    ... people ask why can't I change the animated value later -
    they try to do so in the dev tools and it doesn't allow them to
    ... the other problem is that we can't clean up because
    animations may be deleted and we have to fall back
    ... so memory cost in some situations can be expensive
    ... finally, if you want to cancel the animation - everything
    works ok first time, but if you start and cancel again you jump
    to the end state because you haven't cleaned up the previous

    heycam: would it be a layering violation if those values meant
    fill unless there is another animation on top of me?

    shane: I'd like to be able to say that fill only applies until
    there is a style change
    ... if you have a fill and you want it to transition to a new
    value, if you set a transition and you set a new value then it
    should interrupt when you set the new value

    dbaron: what counts as a style change?

    shane: same as transitions

    dbaron: so any change to that property on that element
    ... so this is different to css transitions

    shane: yes, so can we do this? would it break the web?

    dbaron: yes it would

    <dbaron> (Dean and Greg also said yes at the same time)

    shane: ok so it would be a separate thing then

    dbaron: seems to be like one of the use cases for fill is I
    want this effect to happen where it starts somewhere and
    animates in some way and when animation finishes it stays there

    ChrisLilley: wanting it to stay where it is is a good result
    ... but there's two ways to do that
    ... one is to have a keyword that changes dom with final value
    ... other is to have an animation engine running that keeps the
    value there

    dbaron: I'm worried about things where other things change the
    computed value
    ... never mind

    heycam: one you get to the point where you're filling you want
    to have another mechanism for setting the fill value
    ... where is that mechanism?

    dino: why doesn't it become another keyword to fill
    ... that is an end event handler that sets the value

    shane: this is the simpler behaviour that will avoid
    programming errors so it should be the default

    heycam: regardless how you control it, not sure what the
    mechanism is for setting the value

    shane: in our implementation we have an animation stack where
    we apply all the style rules
    ... once we
    ... once we've applied the static styles we apply the animated
    styles on top - to override
    ... so that's where strongly held value is
    ... animations with fill don't say they need to be updated
    every frame
    ... transitions work a little differently
    ... this was the value I was transitioning to and the new value
    - if they're different we can stop

    heycam: I was thinking maybe it would be something like - for
    every element there's some level in the cascade
    ... with properties that can be set or not
    ... and when animation gets to fill but not strongly, it sets
    that value in the cascade
    ... which is beneath the animations
    ... what does setting the value mean .style.something = ?

    shane: yes

    heycam: I'm a little worried - how transitions trigger is
    difficult to get a handle on

    shane: if transitions didn't have similar behaviour I probably
    wouldn't want to go down this path
    ... once you're using web animations under the hood,
    transitions and animations should be the same thing
    ... I'd also welcome suggestions for other novel solutions

    dbaron: it feels weird for a fill animation
    ... but it does feel there may be a short cut for setting the
    style to this and also run this animation
    ... or run the animation and while doing so set the style value
    to this

    shane: the issue is where to put that - you can't put it in the
    inline style

    birtles: the idea that you're updating the specified style in
    the background would avoid any discontinuity of behaviour when
    you reach the end of the animation as opposed to updating the
    style when the animation finishes

    shane: the problem with setting a value in the background is
    that there's no sensible place to set it

    dino: so your proposal is to still run the fill animation
    ... it's just implicitly cancellable by any change
    ... which is new behaviour

    shane: yes

    dino: I'd like to think about this
    ... I can see the need

    shane: I just wanted to get a sense whether it was worth
    ... and that seems to be the case

    birtles: we've had requests in svg to have animations that
    update the dom

    dino: bit more obvious if it comes from an api rather than SMIL
    ... maybe it's that you would always set via animations. So
    take the result of the last animation rather than having a fill
    ... everything could be an animation

    cyril_: we had a related issue when converting flash to svg
    ... we had animations per layer in the flash display list
    ... wanted to get rid of the old animations in previous frames
    ... there was no way to signal
    ... in smil we could use an attribute something like
    ... as an indicator that you could do garbage collection

    shane: we have one more set of things to talk about

    TabAtkins: some time ago Shane and I proposed adding to the
    family of transform properties a translate, rotate and scale
    ... that get slotted into the use translate list at the end
    ... some were hostile, some liked it
    ... I think we should revisit this
    ... we have more precedent with motion path
    ... which exists as a property and a function
    ... for good reason - and those same reasons apply here

    shane: Jack Doyle's selling point is the can independently
    animate rotate, scale and translate
    ... a lot of his customers find it useful

    heycam: I worry it works well for separate translate and
    ... as soon as you have something that doesn't decompose into
    at most these three types
    ... it breaks down
    ... so I'd prefer to see some mechanism that allows you to
    combine the values somehow

    shane: for the simple case you're requiring people have
    knowledge of the ordering of transforms

    heycam: you have fixed order

    TabAtkins: there is a single correct order if you want them to
    act independently
    ... and it's not trivial

    shane: you can define that rigorously

    dino: right to some people
    ... it's not what everyone wants

    shane: we force people to think in terms of the scene
    ... so it makes sense to define it in a particular way

    birtles: we've got some pretty strong requests for this in the
    animation community

    dino: you can still do it - it's just a little cumbersome with
    additive animation

    shane: you can't
    ... with custom properties maybe
    ... with the web animations api I mean

    dino: you can't write an animation that independently animates
    translation, scale and rotation?

    birtles: you can do it
    ... it's hard

    dino: at the moment in css you do it with nested elements

    shane: I'll get back to you

    (shane gives an example that requires knowing how to decompose

    TabAtkins: is the argument all about whether you can tween in
    web animations?

    dino: I don't think so - if we do add these other properties,
    what's the fall back strategy?
    ... if I add these properties and also add transform because I
    want it to work in other browsers
    ... you have properties that combine in a particular order

    TabAtkins: there's a lot of layout features that also work like
    this - flexbox for example
    ... you can't polyfill, you just have to wait for support

    <birtles> For reference, GreenSock's description of independent
    animation of transform components is described at
    [62]https://greensock.com/why-gsap/ under "Scale, rotate, skew,
    and move without the headaches"

      [62] https://greensock.com/why-gsap/

    <birtles> demo at: [63]http://codepen.io/GreenSock/full/kingu/

      [63] http://codepen.io/GreenSock/full/kingu/

    birtles: from a use case point of view I think it's really

    dino: this is really a change to the transform spec, not

    dbaron: I guess I'm ok with it if there's a rule for how they
    all compose

    dino: so if you did translate(10,10) transform="scale(2)" then
    it's not round tripable

    dbaron: it might be confusing to people if they do transition:
    ... that won't transition if they change translate

    TabAtkins: does that confuse people if they transition on
    transform and then change the perspective property it does not

    <birtles> also, for reference, this request comes up a lot:

      [64] https://twitter.com/rachelnabors/status/518773879117197313

    shane: I think this is one of those situations where you have a
    simple and a complex world and let people opt into the complex
    worid if they want
    ... the case for using both is a programming error and should
    be avoided
    ... so we want to add a simple model

    dino: my main issue is I'm not sure it's worth it
    ... I understand the issues people are hitting

    shane: if just for the static cases I would agree, but there's
    a powerful animation argument. it's very hard to do some things
    without this

    TabAtkins: I hear more conclusions that it would be worth
    having so we should take another look at it
    ... ideally I'd like to put it in and see if we get objections

    dmitry: what if I want to animate rotation and rotation?

    TabAtkins: use transform

    shane: if we put this in the spec and it turns out there's
    other ways of doing it we'll take it out
    ... so can we put it in the spec?
    ... in CSS transforms

    dbaron: in level 2?

    shane: I'd be happy with that

    RESOLUTION: We will add translate,rotate and scale properties
    in CSS transforms level 2

    <astearns> liam: yes

    <liam> tx

    <cyril_> Scribe: Cyril

    <cyril_> SCcribeNick: cyril_

ID-less referencing



    <cyril_> birtles: quick proposal about referencing elements
    from css properties without using id

    <cyril_> ... the motivation is masking for example

    <cyril_> ... you want to point to another element

    <cyril_> ... but mash-ups can have conflicts

    <cyril_> ... unique ids is a solution but that's a bit too much

    <cyril_> ... readability, file size ... and a pain to generate
    from JS

    <cyril_> ... semantically not great

    <cyril_> ...it'd be better if we could nest mask in path

    <cyril_> ChrisLilley: the downside is you can only have one
    child in some cases

    <cyril_> birtles: we could try nesting

    <cyril_> ... but that's not good for backward compatibility

    <cyril_> ... I proposed a keyword

    <cyril_> ... 'child' to say the first descendant

    <cyril_> ... if you have multiple masks, child would mean the
    last one

    <cyril_> ... would work for paint servers

    <cyril_> ... one issue is both fill and stroke refer to the

    <cyril_> ... the proposal is to use a select syntax

    <cyril_> Tav: you could also need a list: gradient and pattern
    as a fill

    <cyril_> birtles: the proposal is to use selectors scoped to
    the subtree

    <cyril_> ... that was removed from CSS masking to find a more
    generic solution

    <cyril_> ChrisLilley: I don't see how it could be more generic
    than selector

    <cyril_> ... the only constraint is the fact that it selects
    amongst the children

    <cyril_> (link to an email on www-style)

    <cyril_> heycam: using selectors you could have things
    depending on attribute values, structure of the tree

    <cyril_> ... making it difficult to watch mutations in the tree

    <cyril_> ... if the selector would be limited to children or
    element names

    <cyril_> ... it'd make it easier to track

    <cyril_> fantasai: we have an outstanding issue in GCPM

    <cyril_> ... that the element function in gpcm and CSS 4 don't

    <cyril_> ... changing syntax is on the table

    <cyril_> birtles: element() with an id doesn't help

    <cyril_> heycam: concenrs are different with navigation

    <cyril_> ... you don't watch for changes

    <cyril_> ChrisLilley: previously it was not enough generic, now
    it is too generic

    <cyril_> cyril_: why don't we restrict selectors to nth-child

    <cyril_> TabAtkins: we could add full selectors in the future

    <cyril_> ChrisLilley: I would rather use selectors and
    constrain it

    <cyril_> TabAtkins: select(nth-child(2)) is longer than

    <cyril_> ... what if you want the 2nd linearGradient here and
    not the 2nd child

    <cyril_> birtles: if you allow element name and child

    <cyril_> ... we could disambiguate by giving the element name

    <cyril_> TabAtkins: I don't like remembering what arbitrary
    things I'm allowed to use

    <cyril_> heycam: I don't see use cases for selecting things
    other than children

    <cyril_> ... I don't like to write mask="select(mask[1])"

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

    <cyril_> heycam: the gcpm function takes a custom identifier

    <cyril_> krit: do we care if we have a different solution for

    <cyril_> ed: we could restrict the order in which you put
    children elements for fill and stroke

    <cyril_> krit: you can have fill with multiple layers

    <cyril_> TabAtkins: the child keyword does not allow that

    <cyril_> krit: that's why it's not useful

    <cyril_> TabAtkins: is that a huge deal if we restrict
    selectors to matching children

    <cyril_> heycam: you'd still have to watch for class changes,

    <cyril_> ... it's unlikely I'd be able to reuse the existing
    machinery for style changes

    <cyril_> ... I'd like to see if Erik's model could work

    <cyril_> ... it needs more thoughts

    <cyril_> ed: do we expect that it will be common for people to
    use multiple fill and strokes

    <cyril_> TabAtkins: we could solve the common case now (1 child
    per paint server) and expand later

    <cyril_> TabAtkins: fill="child child child" could be use the 3
    first children to use for fill

    <cyril_> heycam: we could use that for markers

    <cyril_> ... but markers have zillions of properties

    <cyril_> TabAtkins: I don't think we want to use paint order

    <cyril_> ... the mental model isn't as intuitve

    <cyril_> resolution: accept the 'child' keyword in all
    referencing properties

    <cyril_> krit: do we define in it in the common spec ?

    <cyril_> heycam: yes in the SVG 2 spec

    <cyril_> ed: the order is we consume children for fill first
    and then for stroke

    <cyril_> cyril_: what if the same paint server is used for fill
    and strok

    <cyril_> TabAtkins: you have to repeat it

    <cyril_> Tav: or give an id

    <Tav> [66]http://tavmjong.free.fr/SVG/PROPERTIES/index.html

      [66] http://tavmjong.free.fr/SVG/PROPERTIES/index.html

Referencing properties

    <cyril_> Tav: i've been working on the text part of svg

    <cyril_> ... and one of the problems is that it references so
    many properties

    <cyril_> ... the modules are in various stages of preparation

    <cyril_> ... what do we allow to reference

    <cyril_> ... for example writing modes redefines writing-mode a
    little bit differently

    <cyril_> fantasai: text-decoration-fill would go in Level 4 of
    Text Decoration

    <cyril_> krit: so you could put it in SVG

    <cyril_> Tav: are we allowed to reference a WD ?

    <cyril_> ChrisLilley: but you'll wait in CR

    <cyril_> Tav: Shapes 2 is needed but in ED

    <cyril_> astearns: but it's ready to be in WD

    <cyril_> heycam: what's new ?

    <cyril_> astearns: shape-margin, shape-inside, referencing svg
    shapes ...

    <cyril_> ed: can we have a resolution to publish WD ?

    <cyril_> fantasai: we probably have quorum for publishing

    <cyril_> fantasai: adobe is ok with publishing, google is

    <cyril_> dbaron: that seems fine

    <cyril_> dino: 'im ok

    <cyril_> resolved: CSS WG agrees to publish Shapes 2 as a FPWD

    <cyril_> tav: I'm happy to have a agreement that I can
    reference those specs

    <cyril_> fantasai: about baseline-shift

    <cyril_> ... do you output it in the CSS form or SVG form ?

    <cyril_> Tav: in the CSS form

    <cyril_> heycam: I have a separate topic on that

    <fantasai> Plan is to have a dominant-baseline property

    <fantasai> and then a vertical-align property with longhand
    salignment-baselin and baseline-shift

    <cyril_> Tav: how soon ?

    <cyril_> fantasai: I can get you a very rough draft today

    <cyril_> Tav: we need to do that in the SVG 2

    <cyril_> heycam: you have a future model in mind, reduccing the
    number of properties by half, simplifying the model

    <cyril_> ... in FF we implement only dominant-baseline

    <cyril_> ... peopl have content that uses it to position text

    <cyril_> heycam: webkit supports alignement baseline, dominant
    baseline and baseline shift

    <cyril_> ... the effect if you specify a-b and d-b is unclear

    <cyril_> fantasai: the initial value of a-b should be auto and
    auto should look at the d-b property of the parent

    <cyril_> dbaron: not a-b ?

    <cyril_> heycam: b-shift has length + keywords: superscript ...

    <cyril_> heycam: my overriding concenr is to make sure we just
    have what SVG needs without constraining your model

    <cyril_> ... if you're happy to write a minimal document that
    we can reference then we're fine

    <cyril_> fantasai: I can have a document in a year

    <cyril_> heycam: ok

    <dbaron> there are some useful definitions in
    [67]http://www.w3.org/TR/xsl/#vertical-align and

      [67] http://www.w3.org/TR/xsl/#vertical-align
      [68] http://www.w3.org/TR/xsl/#area-alignment

    <cyril_> ... that has 4 properties instead of 3

    <cyril_> heycam: the XSL properties were used at some point in
    the SVG spec and then tweaked

    <cyril_> fantasai: what is in the SVG spec is what I might put
    in the CSS spec

    <cyril_> (discussing new process)

    <cyril_> heycam: the other part is what to do about the old
    writing-mode values and glyph orientation vertical stuff

    <cyril_> ... fantasai seems to be of the opinion that there are
    interesting things even if not in the open web

    <cyril_> ... dirk showed some output of Photoshop for vertical
    text using writing mode TB

    <liam> [ the XSL-FO properties were in turn supposed to be
    aligned with CSS 2 where possible, modulo the evolving box
    model. [69]http://www.w3.org/TR/xslfo20/#vertical-align was the
    most recent/final draft before we stopped working on it, but i
    think it unchanged from 1.1 ]

      [69] http://www.w3.org/TR/xslfo20/#vertical-align

    <heycam> in SVG there are old keyword values for writing-mode,
    and an old glyph-orientation-vertical property that lets you
    control how latin glyphs are oriented in vertical text

    <heycam> in writing modes spec, there are new keywords for
    writing-mode, and a text-orientation property for controlling
    glyph orientation

    <cyril_> krit: glyph orientation horizontal and vertical have
    the same usage statistics

    <cyril_> ... i would suggest we deprecate them but not remove

    <cyril_> heycam: I haven't seen bug reports about them, but I
    have about alignement-baseline

    <cyril_> ChrisLilley: some people said that most fonts don't
    give that information

    <cyril_> heycam: I have enough information about the plan for
    those properties

    <Tav> [70]http://tavmjong.free.fr/SVG/TEXT_FLOWED/index.html

      [70] http://tavmjong.free.fr/SVG/TEXT_FLOWED/index.html

text in a shape

    <cyril_> Tav: SVG 2 reintroduces text flow in a shape

    <cyril_> ... the initial version 1.2 got supported only by
    Batik and Inkscape

    <dbaron> fantasai: On previous topic, I was just commenting
    that I should have named sideways-left and sideways-right as
    sideways-lr and sideways-rl, but it's probably too late to
    change that.

    <dbaron> fantasai: writing-mode has values like horizontal-tb
    and vertical-lr

    <cyril_> fantasai: writing-mode has values that are
    horizontal-tb and vertical-lr and text-orientation:
    sideways-left, sideways-right

    <dbaron> fantasai: text-orientation could change from
    sideways-left and sideways-left... could change to sideways-lr
    and sideways-rl

    <dbaron> heycam: why not sideways-tb etc.?

    <dbaron> fantasai: text-orientation talks about orientation of
    glyphs -- where is top/bottom of line -- not where is start/end
    of line

    <dbaron> fantasai: the correct text-orientation:sideways-* for
    horizontal scripts is the one that matches the writing-mode:

    <dbaron> heycam: question

    <dbaron> fantasai: [diagram that's hard to minute because it's
    in vertical writing]

    <dbaron> fantasai: Might be deployed content in Japan that
    relies on these things.

    <cyril_> Tav: back to the text in shape topic

    <liam> [ Tav --
    [71]http://www.w3.org/TR/xslfo20/#fo_extension-region and
    scroll up to figure 50 with the yellow hexagons ]

      [71] http://www.w3.org/TR/xslfo20/#fo_extension-region

    <cyril_> ... in 1.2T you could wrap into one box and another
    and another

    <cyril_> ... could we retain that property ?

    <cyril_> astearns: we've proposed several ways

    <cyril_> ... Florian also proposed another method

    <cyril_> Tav: I looked at regions and it seemed complicated for

    <cyril_> astearns: overflow fragments have to be siblings

    <cyril_> ... not regions

    <cyril_> ... I don't now what your requirements are

    <cyril_> Tav: 3 references comma separated

    <cyril_> heycam: in the old way, you had svg shapes in the
    document, child of some special flow document

    <cyril_> ... and the text flows in then one by one, no
    automatic generation of shape

    <cyril_> ... do you want that behavior ?

    <cyril_> Tav: No, I don't want automatic generation of shapes

    <cyril_> astearns: and if it overflows ?

    <cyril_> Tav: it goes nowhere

    <cyril_> Rossen: you need regions the

    <cyril_> astearns: the concepts are in the regions spec

    <cyril_> Tav: a simple comma separated list of shapes would not

    <cyril_> astearns: we did not want to add that syntax in

    <cyril_> ... that would need to be something for SVG to define

    <cyril_> heycam: that goes on the text element

    <cyril_> astearns: don't know if it needs to extend
    shape-inside or have a new shape-inside-list

    <cyril_> Tav: in SVG there would be two ways to get the content
    region: width for horizontal text and height for vertical text
    or by giving the shape in which it will wrap

    <cyril_> Tav: I wanted to check the syntax

    <cyril_> Rossen: the behavior in SVG 2 seems to combine 2 or 3

    <cyril_> Tav: the text doesn't flow in the 2 rect

    <cyril_> Rossen: so you don't need regions

    <cyril_> .... but you need exclusion

    <cyril_> Tav: 2 separate text elements both shape-inside
    (different) but one has a shape-outside

    <heycam> [this is pointing to the "An example of using
    'shape-outside'" example currently in the spec]

    <cyril_> astearns: shape-outside only apply to floats

    <cyril_> Rossen: or exclusions

    <cyril_> astearns: you'd need wrap flow too

    <cyril_> ... in CSS to get wrapping behavior you need floats or

    <cyril_> ... it's adding one more property

    <cyril_> ... it adds the ability to have the content
    overlapping or wrapping

    <cyril_> Tav: I'm wondering if SVG needs that level of

    <cyril_> Rossen: but you are positioning with x and y

    <cyril_> astearns: I think you need it

    <cyril_> ed: have you considered having a child keyword for
    this as well to keep the shape insde the text

    <cyril_> Tav: possible

    <heycam> <text shape-inside="child">ABC DEF <circle

    <cyril_> ed: I don't think a rect (or shape) is rendered
    currently in a text

    <cyril_> Tav: and also having a text inside a rectangl

    <cyril_> heycam: you think the syntax is more natural to have
    the text inside the rect

    <cyril_> Tav: yes

    <AndreyR> Another topic form css agenda can we discuss issues?

      [72] http://dev.w3.org/csswg/css-pseudo/#highlight-pseudos


    <cyril_> fantasai: can we go to CR ?

    <cyril_> Florian: what do we do about the order ?

    <cyril_> fantasai: so far there are several proposals: don't
    change anything, or make order affect all things and extend
    later, and drop the order properties

    <cyril_> Florian: I'm not excited about opening new things

    <cyril_> ... but the shorthand longhand thing made sense to me

    <cyril_> fantasai: we don't have the person to discuss this

    <cyril_> ... but I would like to publish things

    <cyril_> Florian: I'm happy with publishing

    <cyril_> Rossen: any objection ?

    <cyril_> (silence)

    <cyril_> dbaron: are there any big things that don't match what
    it used to do ?

    <cyril_> fantasai: no

    <cyril_> dbaron: sounds good then

    <cyril_> resolved: Publish flexbox CR under the new process

    <AndreyR> Topic
    [17:18] <cyril_> Topic: FlexBox

      [73] http://dev.w3.org/csswg/css-pseudo/#highlight-pseudos


    <cyril_> fantasai: there is an issue in the spec on how to
    select inactive selections

    <cyril_> ... do we want to add another pseudo for that ?

    <cyril_> ... I don't think that's a good idea

    <cyril_> Florian: inactive selection ?

    <cyril_> fantasai: select and then focus another window

    <cyril_> Florian: that does not match selection, but nothing
    selects it

    <cyril_> resolved: add ::inactive-selection to Pseudo Element
    Level 4

Summary of Action Items

    [NEW] ACTION: Cameron to make text-rendering:geometricPrecision
    change [recorded in
    [NEW] ACTION: Dirk to ask Rik to produce SVG versions of the
    blending tests. [recorded in
    [NEW] ACTION: Dirk to confirm that the Firefox/Presto behaviour
    of this SVG sizing test is correct and get back to Tantek
    [recorded in
    [NEW] ACTION: Erik to make non-none values of filter induce a
    containing block for all positioned descendants [recorded in
    [NEW] ACTION: jdaggett to add font palette selection to CSS
    Fonts level 4 [recorded in
    [NEW] ACTION: stakagi to propose specification text for new
    scalar value for CSS transforms [recorded in
    [NEW] ACTION: Takagi-san to propose specification text for new
    scalar value for CSS transforms [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [81]scribe.perl version
     1.140 ([82]CVS log)
     $Date: 2015-02-11 06:56:33 $

      [81] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [82] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30
Check for newer version at [83]http://dev.w3.org/cvsweb/~checkout~/2002/

      [83] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/ed: I think the behaviour on the left side is what we want/
ed: I think the behaviour on the left side (Firefox and Presto) is what
we want/
Succeeded: s/tantek/fantasai/
Succeeded: s/krit/ChrisL/
Succeeded: s/so if palette is not used/so if you omit some palette index
Succeeded: s/gradientss/gradients/
Succeeded: s/anyhting/anything/
Succeeded: s/rigth/right/
Succeeded: s/tehre/there/
Succeeded: s/Publish new WD of CSS transforms/Publish new WD of CSS tran
sforms with Takagi-san's changes/
Succeeded: s/birtles: yes, so can we do this? would it break the web?/sh
ane: yes, so can we do this? would it break the web?/
Succeeded: s/restartnever/restart=never/
Succeeded: s/somewhow/somehow/
Succeeded: s/decompose/compose/
Succeeded: s/do we expect people/do we expect that it will be common for
Succeeded: s/or regions/or exclusions/
Succeeded: s/rec/rect (or shape)/
Found ScribeNick: heycam
Found Scribe: Cameron
Found Scribe: Cyril
Found ScribeNick: cyril
Found Scribe: Cameron
WARNING: No scribe lines found matching ScribeNick pattern: <cyril> ...
Found ScribeNick: heycam
Found ScribeNick: nikos
Found Scribe: Nikos
Inferring ScribeNick: nikos
Found Scribe: Cyril

WARNING: "Scribe: Cyril" command found,
but no lines found matching "<Cyril> . . . "
Continuing with ScribeNick: <nikos>
Use "ScribeNick: dbooth" (for example) to specify the scribe's IRC nickn

Scribes: Cameron, Cyril, Nikos
ScribeNicks: heycam, cyril, nikos

WARNING: No "Present: ... " found!
Possibly Present: AndreyR AndreyR_ ChrisL ChrisLilley Florian Rossen SCc
ribeNick SimonSapin TabAtkins astearns background birtles cyril cyril_ d
baron dino dmitry ed fantasai file fx glazou gregwhitworth gregwhitworth
_ heycam hober https hyojin hyojin_ hyojin__ iank joined jun koji krit k
wkbtr left liam murakami murakami_ nikos plinss rbyers roc scribenick sg
alineau shane shepazu_ smfr stakagi tantek tantek_ tav trackbot xidorn x
You can indicate people for the Present list like this:
         <dbooth> Present: dbooth jonathan mary
         <dbooth> Present+ amy

Got date from IRC log name: 10 Feb 2015
Guessing minutes URL: [84]http://www.w3.org/2015/02/10-fx-minutes.html
People with action items: cameron dirk erik jdaggett stakagi takagi-san

      [84] http://www.w3.org/2015/02/10-fx-minutes.html

    [End of [85]scribe.perl diagnostic output]

      [85] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Erik Dahlstrom, Web Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Received on Wednesday, 11 February 2015 07:05:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:53 UTC