FXTF F2F, Sydney 2015 -- 10 Feb 2015

<heycam> ScribeNick: heycam

<scribe> Scribe: Cameron

<ed> Agenda: https://wiki.csswg.org/planning/sydney-2015 (Wednesday)

css3-ui

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

<tantek> hello

<tantek> 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: 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> 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 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: 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> 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 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: https://lists.w3.org/Archives/Public/www-style/2015Feb/0245.html

<gregwhitworth> Windows SVG Test: 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> 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> 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> https://wiki.csswg.org/spec/css3-ui#issue-69

Interaction between overflow, positioning and filters

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

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

dbaron: let's postpone until after lunch

Filter Effects CR

<krit> https://github.com/w3c/fxtf-drafts/blob/master/filters/issues-lc-2015.html

krit: this is the disposition of comments document

<plinss> 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> 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 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> 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> 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> 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> 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> 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> 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> 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 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> 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 http://www.w3.org/2015/02/10-fx-minutes.html#action04]

<trackbot> Error finding 'jdaggett'. You can review and register nicknames at <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 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> 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> 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> 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 http://www.w3.org/2015/02/10-fx-minutes.html#action06]

<trackbot> Error finding 'Takagi-san'. You can review and register nicknames at <http://www.w3.org/Graphics/fx/track/users>.

<scribe> ACTION: stakagi to propose specification text for new scalar value for CSS transforms [recorded in 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> 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> 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 https://greensock.com/why-gsap/ under "Scale, rotate, skew, and move without the headaches"

<birtles> demo at: 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: 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> 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])"

<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> 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 http://www.w3.org/TR/xsl/#vertical-align and 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. 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 ]

<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> 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 -- http://www.w3.org/TR/xslfo20/#fo_extension-region and scroll up to figure 50 with the yellow hexagons ]

<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

<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? 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 http://dev.w3.org/csswg/css-pseudo/#highlight-pseudos [17:18] <cyril_> Topic: FlexBox

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

- DRAFT -

FXTF F2F, Sydney 2015

10 Feb 2015

Attendees

Contents

css3-ui

Interaction between overflow, positioning and filters

Canceling and interrupting transitions

Filter Effects CR

CSS Blending PR

Colored font palette control

text-rendering

Canceling and interrupting transitions

css-transforms: Specifying decomposition of scale

Web Animations status update

ID-less referencing

Referencing properties

text in a shape

FlexBox

::selection

Summary of Action Items

Scribe.perl diagnostic output