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


[38] https://github.com/w3c/fxtf-drafts/blob/master/filters/issues-lc-2015.html

   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


[46] http://test.csswg.org/suites/compositing-1_dev/nightly-unstable/report/

   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


[55] https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/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


[60] http://people.mozilla.org/~bbirtles/pres/201502%20fxtf%20web-anim%20update/

   (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


[61] https://docs.google.com/document/d/1f-KxMJwQ3f3OXSMvY-uQjpsy788BfyHlW9VoUWFvWQ4/edit#heading=h.b601rl56wy2f

   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


[65] http://people.mozilla.org/~bbirtles/pres/referencing-proposal-2015/

   <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

Reply via email to