- From: Erik Dahlstrom <ed@opera.com>
- Date: Wed, 11 Feb 2015 18:05:15 +1100
- To: "public-fx@w3.org" <public-fx@w3.org>
Minutes:
http://www.w3.org/2015/02/10-fx-minutes.html
and the same as plaintext below:
[1]W3C
[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
Attendees
Present
Regrets
Chair
ed
Scribe
Cameron, Cyril, Nikos
Contents
* [3]Topics
1. [4]css3-ui
2. [5]Interaction between overflow, positioning and
filters
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
(Wednesday)
[20] https://wiki.csswg.org/planning/sydney-2015
css3-ui
[21]https://lists.w3.org/Archives/Public/www-style/2015Feb/0243
.html
[21] https://lists.w3.org/Archives/Public/www-style/2015Feb/0243.html
<tantek> hello
<tantek>
[22]https://lists.w3.org/Archives/Public/www-style/2015Feb/0243
.html
[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
[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
it
... 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
is
... my understanding is that the top row should all be yellow
square
... 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
effect
... 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
<tantek>
[24]https://lists.w3.org/Archives/Public/www-style/2015Feb/0243
.html
[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
F2F
... 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
[25]http://www.w3.org/2015/02/10-fx-minutes.html#action01]
<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
[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
element
... 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)
<tantek>
[27]http://dev.w3.org/csswg/css-ui-3/#propdef-box-sizing
[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
test
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
check
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
right/wrong
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
thing
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
compositor
... right now on windows, firefox / edge ie / chrome have
interop
... on the second case
<dbaron> Filed Gecko bug
[28]https://bugzilla.mozilla.org/show_bug.cgi?id=1131812
[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
[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
buggy.
tantek: I just sent the updated test that fantasai asked for to
www-style
<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
-001.htm
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
behaviour
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
height?
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
here?
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
viewBox.
tantek: we're trying to look at this from the point of view
that implementations are converging, so we'd like to follow
them
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
later.
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
<img>
Florian: the way they start interacting with CSS is different
tantek: the width attribute in inline is not intrinsic but
specified
... 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
box-sizing?
Florian: as long as you don't involve max-height/width, it's
easy
... 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
300x150?
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
separately
<TabAtkins> fantasai: Because the spec doesn't specify where to
take dimensions from for <iframe>?
<fantasai> It's a replaced element
<cyril>
[32]https://lists.w3.org/Archives/Public/www-style/2015Feb/0247
.html
[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
box-sizing
... 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
behaviour
... 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
rendered
... 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
widths.
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
divs
... 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
clip
... 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
descendants
... 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
same
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
issue
... we could change blend modes now, to force the same
behaviour
... 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
transforms
... 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
[35]http://www.w3.org/2015/02/10-fx-minutes.html#action02]
<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
[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
[37] https://lists.w3.org/Archives/Public/www-style/2014Dec/0150.html
dbaron: let's postpone until after lunch
Filter Effects CR
<krit>
[38]https://github.com/w3c/fxtf-drafts/blob/master/filters/issu
es-lc-2015.html
[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
effects
<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
[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
default
... 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
behaviour
... 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
filter:none
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
attribute
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
normally.
<krit>
[42]http://dev.w3.org/fxtf/filters/issues-lc-2015.html#issue-6
[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.
<krit>
file:///Users/dschulze/Documents/fxtf-drafts/filters/issues-lc-
2015.html#issue-8
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
<krit>
[43]http://dev.w3.org/fxtf/filters/#element-attrdef-values
[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
<krit>
file:///Users/dschulze/Documents/fxtf-drafts/filters/issues-lc-
2015.html#issue-11
<astearns>
[44]https://www.w3.org/Bugs/Public/show_bug.cgi?id=27464
[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]
<krit>
[45]http://dev.w3.org/fxtf/filters/issues-lc-2015.html#issue-12
[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
different
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
done?
(none heard)
RESOLUTION: Publish a CR of Filters spec (under the new
process).
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>
[46]http://test.csswg.org/suites/compositing-1_dev/nightly-unst
able/report/
[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?
<plinss>
[47]http://www.w3.org/TR/compositing-1/#cr-exit-criteria
[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
<plinss>
[48]http://test.csswg.org/harness/results/compositing-1_dev/gro
uped/
[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
elements
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
[49]http://www.w3.org/2015/02/10-fx-minutes.html#action03]
<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
<heycam>
[50]https://lists.w3.org/Archives/Public/www-style/2015Feb/0211
.html
[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
glyphs
<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
variables
<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
doing
<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
specify
<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
later
<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
[51]http://www.w3.org/2015/02/10-fx-minutes.html#action04]
<trackbot> Error finding 'jdaggett'. You can review and
register nicknames at
<[52]http://www.w3.org/Graphics/fx/track/users>.
[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
similar
<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
evolve
<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
version
<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
variables
<cyril_> ... I tried to implement css variables and palettes
<cyril_> ... (explaining something about caching)
<cyril_> ... we could need a non-variable way to indicate
palette
<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
text-rendering
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
requirement
... 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
metrics)
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
situations
... 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
[53]http://www.w3.org/2015/02/10-fx-minutes.html#action05]
<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
about
... anything that's a new feature is marked to defer to level 2
... there are a few that are about animating specific value
types
... 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
<dbaron>
[54]https://www.w3.org/Bugs/Public/show_bug.cgi?id=16265
[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
z-index:auto
... ?
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
interpolate
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
cycle
... and would like to leave room for optimisation
... there was a statement that it was specifically not
specified
... 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
interactions
... I haven't gotten a huge amount of feedback
... given the number of implementations I think we should go to
CR
... 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>
[55]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Specifyin
g_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
detail
... 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
functionality
... 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
scales
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
detail
... we're talking about extreme zoom
... we need level of detail and it needs to work regardless of
transformations
... 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
referenced
... 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
value
... 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
matter
birtles: there's a formula in the wiki
krit: we'd be putting it into the transform spec without any
context
... 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
spec
... 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
[57]http://www.w3.org/2015/02/10-fx-minutes.html#action06]
<trackbot> Error finding 'Takagi-san'. You can review and
register nicknames at
<[58]http://www.w3.org/Graphics/fx/track/users>.
[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
[59]http://www.w3.org/2015/02/10-fx-minutes.html#action07]
<trackbot> Created ACTION-91 - Propose specification text for
new scalar value for css transforms [on Satoru Takagi - due
2015-02-18].
RESOLUTION: Publish new WD of CSS transforms with Takagi-san's
changes
Web Animations status update
<birtles>
[60]http://people.mozilla.org/~bbirtles/pres/201502%20fxtf%20we
b-anim%20update/
[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
publication?
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
still
... 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
generic?
birtles: don't think so
... we already have the term
dino: no fear of clobbering third party library that uses
Animation?
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
suggestions
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
function
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>
[61]https://docs.google.com/document/d/1f-KxMJwQ3f3OXSMvY-uQjps
y788BfyHlW9VoUWFvWQ4/edit#heading=h.b601rl56wy2f
[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
reject
... 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
itself
... 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
one
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
considering
... 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
animations
... 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
restart=never
... 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
property
... 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
rotates
... 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
matrices)
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
useful
dino: this is really a change to the transform spec, not
animations
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:
transform
... 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
transition?
<birtles> also, for reference, this request comes up a lot:
[64]https://twitter.com/rachelnabors/status/518773879117197313
[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
<birtles>
[65]http://people.mozilla.org/~bbirtles/pres/referencing-propos
al-2015/
[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
children
<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
agree
<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
child(2)
<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
both
<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
[68]http://www.w3.org/TR/xsl/#area-alignment
[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
them
<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:
vertical-*
<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
that
<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
work?
<cyril_> astearns: we did not want to add that syntax in
shape-inside
<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
specs
<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
exclusions
<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
complexity
<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
.../></text>
<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
[72] http://dev.w3.org/csswg/css-pseudo/#highlight-pseudos
FlexBox
<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
[73]http://dev.w3.org/csswg/css-pseudo/#highlight-pseudos
[17:18] <cyril_> Topic: FlexBox
[73] http://dev.w3.org/csswg/css-pseudo/#highlight-pseudos
::selection
<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
[74]http://www.w3.org/2015/02/10-fx-minutes.html#action05]
[NEW] ACTION: Dirk to ask Rik to produce SVG versions of the
blending tests. [recorded in
[75]http://www.w3.org/2015/02/10-fx-minutes.html#action03]
[NEW] ACTION: Dirk to confirm that the Firefox/Presto behaviour
of this SVG sizing test is correct and get back to Tantek
[recorded in
[76]http://www.w3.org/2015/02/10-fx-minutes.html#action01]
[NEW] ACTION: Erik to make non-none values of filter induce a
containing block for all positioned descendants [recorded in
[77]http://www.w3.org/2015/02/10-fx-minutes.html#action02]
[NEW] ACTION: jdaggett to add font palette selection to CSS
Fonts level 4 [recorded in
[78]http://www.w3.org/2015/02/10-fx-minutes.html#action04]
[NEW] ACTION: stakagi to propose specification text for new
scalar value for CSS transforms [recorded in
[79]http://www.w3.org/2015/02/10-fx-minutes.html#action07]
[NEW] ACTION: Takagi-san to propose specification text for new
scalar value for CSS transforms [recorded in
[80]http://www.w3.org/2015/02/10-fx-minutes.html#action06]
[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/
scribe/
[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
names/
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
people/
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
ame.
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
idornq
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