/irc-logs / w3c / #fx / 2015-02-11 / end

Options:

# Session Start: Wed Feb 11 00:00:00 2015
# Session Ident: #fx
# [00:00] <Tav> http://tavmjong.free.fr/SVG/SCHILLER/html
# [00:00] <heycam> Tav: these are some tests I made from a few years ago, with SVG sizing in img, iframe, etc.
# [00:02] <heycam> dbaron: what are we trying to accomplish right now?
# [00:02] <heycam> 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.
# [00:02] <heycam> ... if none of the browsers is doing the right then, then...
# [00:02] <heycam> dbaron: what are the questions about how to integrate box-sizing?
# [00:03] <heycam> Florian: as long as you don't involve max-height/width, it's easy
# [00:03] <heycam> ... 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
# [00:03] <heycam> dbaron: I think that algorithm should be interpreted as working on content box sizes
# [00:03] * Joins: hyojin_ (~hyojin@public.cloak)
# [00:03] <heycam> ... there might be other implementation bugs that are worth discussing separately
# [00:03] * fantasai dbaron getting right to the point++
# [00:03] <heycam> ... I think the box-sizing spec update should be done because that's how it should work
# [00:04] <heycam> fantasai: is there any question in what you want to specify?
# [00:04] <heycam> Florian: unless someone strongly believes a non-Presto behaviour is right, no
# [00:05] <heycam> fantasai: that's fine
# [00:05] <heycam> tantek: we didn't expect this many bugs :-)
# [00:05] <heycam> dbaron: the SVG sizing stuff is pretty recently specced
# [00:07] <TabAtkins> Just found out the <iframe src=foo.svg> sizes itself to the SVG's intrinsic dimensions, rather than 300x150 like the spec says.
# [00:07] <TabAtkins> WTF explicitly changing sizing rules without telling the WG about it.
# [00:07] <TabAtkins> Sorry, *in Safari*.
# [00:07] <TabAtkins> dino: ^^^ ???
# [00:07] <heycam> gregwhitworth: on windows, the very first test is similarly buggy in firefox/presto/IE
# [00:08] <heycam> 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
# [00:08] <fantasai> TabAtkins: Why do you think the spec says to make it 300x150?
# [00:08] <heycam> ... 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, ...
# [00:08] <heycam> Florian: there is no constraint on the width
# [00:08] <cyril> email sent with updated svg tests (including a circle), please consider the second email (the first one had a wrong radius value)
# [00:08] <heycam> ... in the height dimension it shrinks down to 70
# [00:08] <heycam> tantek: there's no intrinsic ratio, so they're computed separately
# [00:08] <TabAtkins> fantasai: Because the spec doesn't specify where to take dimensions from for <iframe>?
# [00:08] <fantasai> It's a replaced element
# [00:08] <cyril> https://lists.w3.org/Archives/Public/www-style/2015Feb/0247.html
# [00:09] <fantasai> Just like an image
# [00:09] <heycam> Florian: this purple subtest has no intrinsic ratio
# [00:09] <heycam> ed: do you have enough to go on here?
# [00:09] <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.
# [00:10] <hober> fantasai++
# [00:10] <heycam> tantek: firefox sets the width to 47px, which is very odd
# [00:10] * glazou starts wondering if this is the « best use of your ftf time »
# [00:11] <heycam> gregwhitworth: since I don't know about SVG I'm completely ok with this
# [00:11] <heycam> dbaron: the weird Firefox behaviour is not related to box-sizing
# [00:11] <heycam> ... if I remove the box-sizing, remove the max-height, change the border, I get the same output
# [00:11] <heycam> dbaron: this might be coming from default sizing not being 300x150, for SVG
# [00:11] * ed thinks this topic should have been done 15mins ago...
# [00:12] <heycam> dbaron: if you work through that long list of rules, the way max-height applies doesnt always preserve the intrinsic ratio
# [00:12] <heycam> Florian: on the second one there's no intrinsic ratio
# [00:12] <heycam> dbaron: or doesn't always preserve the things you want
# [00:12] <heycam> ... if I change the max-height to height, you get the expected behaviour
# [00:12] <heycam> ... I think therei s something in the spec rules that gives the 47px result
# [00:13] <heycam> fantasai: I think the only weird cases are when you're balancing conflicting requirements
# [00:13] <heycam> Florian: but in this case we're not over constrained
# [00:13] * fantasai thinks tantek should definitely turn this into a CSS2.1 test
# [00:14] * ed agrees
# [00:14] <heycam> fantasai: let's resolve the behaviour on we want, not on "what Presto does"
# [00:14] * ed bugs in presto? surely not ;)
# [00:14] <heycam> SimonSapin: is this looking at CSS 2.1?
# [00:14] <heycam> tantek: yes, plus box-sizing
# [00:15] <SimonSapin> (as opposed to the CSS Images module)
# [00:15] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [00:15] <heycam> 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).
# [00:16] <tantek> https://wiki.csswg.org/spec/css3-ui#issue-69
# [00:16] <heycam> Topic: Interaction between overflow, positioning and filters
# [00:16] <roc> http://fiddle.jshell.net/mkud1Lnm/1/
# [00:17] <heycam> roc: this is basically a spec issue, as to what should be rendered
# [00:17] <heycam> ... right now specs don't really say
# [00:17] <heycam> ... and it's tricky to fix, there's no obvious way to fix it
# [00:17] <fantasai> CSS2.1: “This property specifies the content width of boxes. ”
# [00:17] <heycam> ... if you look at the fiddle, what we have is there's a div container with overflow hidden, but it could be any clipping
# [00:17] <heycam> ... it has a filter on it, in this case a blur
# [00:17] <fantasai> CSS2.1 is very clear that it's talking about content widths.
# [00:17] <heycam> ... and a couple of elements inside
# [00:17] <dbaron> FWIW, I can explain where the 47px comes from
# [00:17] <heycam> ... one of the elements is position:fixed (but also happens with position:absolute)
# [00:17] <heycam> ... the positioned div is not supposed to be clipped by the element that has overflow:hidden
# [00:18] <heycam> ... but it's in a filter and some of the content of the filtered image should be clipped, while some shouldn't
# [00:18] <heycam> ... it's really unclear how to render this example
# [00:18] <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
# [00:18] <fantasai> dbaron, go ahead, I'm very curious :)
# [00:18] <heycam> ... if you bring it up in Chrome or Firefox, you get a rendering where both of the elments are clipped
# [00:18] <heycam> ... in particular the yellow one is clipped to the overflow:hidden element, but technically it shouldn't be
# [00:18] * Joins: cyril_ (~cyril@public.cloak)
# [00:18] <heycam> ... you can't say it's not clipped, since with the blur, some pixels have contributions from both the blur and the yellow divs
# [00:18] <heycam> ... it's unclear what the visual result should be
# [00:19] <heycam> ... there's no way to preserve the behaviour that one of these elements is clipped, one is not, but they're filtered together
# [00:19] <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.
# [00:19] <heycam> ... the problem does not arise for opacity, that's because opacity commutes with clipping
# [00:19] <heycam> ... if you clip then opacity, it's the same as opacity then clip
# [00:19] <heycam> ... not true for general filters
# [00:19] <heycam> ... because opacity commutes, you can push it down, and get the results you'd expect
# [00:19] * Quits: cyril (~cyril@public.cloak) (Ping timeout: 180 seconds)
# [00:19] <heycam> ... but with filters you can't
# [00:20] <heycam> ... 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
# [00:20] <heycam> ... the question is what to spec
# [00:20] <heycam> ... try to explain that behaviour, or we introduce some restrictions on the interactions between filters and overflow:hidden and positioning
# [00:20] <heycam> ... so that it's well defined
# [00:20] <heycam> ... is the problem clear?
# [00:21] <heycam> ... 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
# [00:22] * Joins: Florian (~Florian@public.cloak)
# [00:22] <heycam> ... 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
# [00:22] <heycam> ... that's option #0 (I didn't put that in my email)
# [00:22] <heycam> ... option #1 from my email is that filter is like transform, becomes a containing block for positioned elements
# [00:22] <heycam> ... so they can't escape from the filter
# [00:22] <heycam> ... so the current definition of overflow:hidden would mean it applies to them
# [00:23] <heycam> ... option #2 is you could say the filter doesn't affect the positioned descendant, it can escape the filter
# [00:23] <heycam> ... so filters only apply to things for which the filtered element is the containing block
# [00:23] <heycam> dino: so the yellow element would not be filtered
# [00:23] <heycam> roc: yes
# [00:24] <heycam> 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
# [00:25] <heycam> dino: simon prefers filtering winning over the overflow
# [00:25] <heycam> ... so stacking context is more important overflow
# [00:25] <heycam> ... so not the choice where yellow div is not filtered
# [00:25] <heycam> roc: I'm for option #1
# [00:25] <heycam> ... if we can make filters a container for positioned descendants
# [00:25] <heycam> ... there's some web compat risk, not a whole lot
# [00:26] <heycam> heycam: would you often want positioned things inside filtered elements? maybe not.
# [00:26] <heycam> dino: simon says sucks opacity and filters are not treated the same
# [00:26] <heycam> roc: it does kind of suck
# [00:27] <heycam> ... I don't have any alternative to that
# [00:27] <heycam> dino: with blending, we don't have the same issue?
# [00:27] <heycam> roc: no, because blending commutes with clipping
# [00:27] <heycam> ... if you have an opacity:0 pixel, blending can't turn that into something that is not opacity:0
# [00:28] <heycam> krit: not yet
# [00:28] <heycam> roc: if we add all the porter duff modes then it would be an issue
# [00:28] <heycam> ... we could change blend modes now, to force the same behaviour
# [00:28] <heycam> ... that would guard us in the future
# [00:28] <heycam> Tav: option #1 makes sense to me
# [00:28] <heycam> dino: I agree with making blending operate the same, and doing that now
# [00:29] <heycam> roc: we've been talking about adding an escape hatch for transforms
# [00:29] <heycam> ... so transforms are not a positioning container
# [00:29] <heycam> ... if we do that we could have keyword on transforms
# [00:29] <heycam> krit: all blend modes we implement use src-over compositing
# [00:30] <heycam> krit: I don't think we want to combine blend modes with other compositing modes
# [00:30] <heycam> roc: if we introduce other compositing modes, will it be in mix-blend-mode or a different property?
# [00:30] <heycam> nikos: suggested to be in a separate property
# [00:31] <heycam> roc: in that case we don't need to add restrictions for mix-blend-mode now
# [00:31] <heycam> ... so that new property would need to create a container for positioned elements
# [00:32] <heycam> ... so we won't change mix-blend-mode behaviour, but will do it for filters
# [00:32] <heycam> heycam: you could restrict this filter behaviour for only some predefined filter keywords
# [00:32] <heycam> roc: I don't feel like we want to do somethign taht complicated
# [00:32] <smfr> heycam: ick, what if you animate between them?
# [00:33] <heycam> smfr indeed, the position of elements could change when you change the filter behaviour
# [00:33] <heycam> RESOLUTION: non-none values of filter induce a containing block for all positioned descendants
# [00:34] <heycam> ACTION: Erik to make non-none values of filter induce a containing block for all positioned descendants
# [00:34] * trackbot is creating a new ACTION.
# [00:34] * RRSAgent records action 2
# [00:34] <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].
# [00:34] <heycam> -- 15 min break, back at 10:49 --
# [00:36] * Quits: kwkbtr (~kwkbtr@public.cloak) (Client closed connection)
# [00:37] * Joins: hyojin__ (~hyojin@public.cloak)
# [00:49] * Joins: sgalineau (~sid26595@public.cloak)
# [00:51] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [00:55] * Quits: jun (~jun@public.cloak) (jun)
# [00:58] <smfr> sgalineau: it’s break time
# [00:58] <smfr> sgalineau: scones and cream
# [00:58] <sgalineau> doh. carry on :)
# [01:00] <sgalineau> smfr: scones are very important.
# [01:00] <smfr> background: jam 100% 100%, cream 200% 200%;
# [01:01] <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
# [01:02] <sgalineau> you had me at boutique beer
# [01:03] <sgalineau> smfr: overflow: visible?
# [01:03] <liam> sgalineau: overflow: burp
# [01:03] <hober> fx
# [01:04] <liam> wait, is that for scones or beer? :)
# [01:04] * hober whoops, sorry
# [01:06] * Quits: hyojin_ (~hyojin@public.cloak) (Ping timeout: 180 seconds)
# [01:06] * Joins: stakagi (~stakagi@public.cloak)
# [01:07] <shane> beer scone spiders - why not have both?
# [01:07] <heycam> Topic: Canceling and interrupting transitions
# [01:07] <heycam> https://lists.w3.org/Archives/Public/www-style/2014Dec/0150.html
# [01:08] * Joins: kwkbtr (~kwkbtr@public.cloak)
# [01:08] * Joins: jun (~jun@public.cloak)
# [01:09] <heycam> dbaron: let's postpone until after lunch
# [01:09] <heycam> Topic: Filter Effects CR
# [01:10] * Joins: Rossen (~rossen@public.cloak)
# [01:10] <krit> https://github.com/w3c/fxtf-drafts/blob/master/filters/issues-lc-2015.html
# [01:10] <heycam> krit: this is the disposition of comments document
# [01:11] <plinss> http://dev.w3.org/fxtf/filters/issues-lc-2015.html
# [01:11] <heycam> krit: we have some open issues still in the spec
# [01:12] <heycam> ... one of them is error handling in general with filter effects
# [01:12] <krit> http://fiddle.jshell.net/ev10jtmp/3/
# [01:12] <heycam> ... here's a test for error handling
# [01:12] <heycam> ... the filter property can take a url, which references a <filter> element
# [01:12] <heycam> ... what happens if the url is invalid
# [01:13] <dbaron> or alternatively http://drafts.fxtf.org/filters/issues-lc-2015.html
# [01:13] <heycam> ... 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
# [01:13] <heycam> ... that's standard CSS behaviour
# [01:13] <heycam> ... what if it's valid syntax but does not reference a filter, or the ID doesn't exist
# [01:13] <heycam> ... behaviour is different between browsers
# [01:13] <heycam> ... SVG 1.1 said that the filtered element disappears
# [01:13] <heycam> ... there were objections that this might not be the preferred behaviour
# [01:14] <heycam> ... firefox does what SVG 1.1 says, so if you apply filter:url(#badID) then it makes the object disappear
# [01:14] <heycam> ... other browsers ignore the filter
# [01:14] <heycam> heycam: I think Firefox should display the element normally, i.e. ignore the filter
# [01:15] <heycam> 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
# [01:15] <heycam> 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
# [01:15] <heycam> ... e.g. <feGaussianBlur in="invalid">
# [01:16] <heycam> ... SVG 1.1 makes the whole filtered element disappear
# [01:16] <heycam> ... WebKit does that, as Firefox does
# [01:16] <heycam> ... Blink does something different
# [01:16] * liam in fact encountered that earlier today with a typo in an id.. and wished firefox had said soemthing on the console
# [01:17] <heycam> krit: or you could reference the previous filter effect (i.e. default in="" value) or default SourceGraphic
# [01:17] <heycam> dino: or make the primitive use transparent black as input
# [01:17] <heycam> roc: yes
# [01:17] <heycam> krit: if you make a mistake in the filter chain, it's not going to give you a result you want
# [01:18] <heycam> krit: if you reference a filter input that doesn't exist, that could kill the whole processing of the filter
# [01:18] <liam> [having the element not rendered means you can't easily right-click on it and "inspect" to debug the problem]
# [01:19] <heycam> krit: I don't think we should just make transparent black for that primitive's input
# [01:19] <heycam> Tav: I agree with that
# [01:19] <heycam> nikos: making just one primitive's input transparent black can help you understand where the error is
# [01:19] <heycam> 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
# [01:19] <heycam> krit: which would be the previous filter effect
# [01:20] <heycam> heycam: I'm fine with disabling the filter
# [01:20] <heycam> RESOLUTION: If a filter primitive references an invalid input, then the whole filter is disabled and the element is rendered normally.
# [01:20] <krit> http://dev.w3.org/fxtf/filters/issues-lc-2015.html#issue-6
# [01:20] <heycam> krit: next, issue #6
# [01:21] <heycam> ... if someone uses currentColor in feColorMatrix, what is it?
# [01:23] <heycam> ... 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
# [01:23] <heycam> Tav: we have context-fill
# [01:23] <heycam> ... we decided to make that work in all referencing elements, like filter, pattern, etc.
# [01:24] <heycam> krit: I'd like to delay putting anything in the filters spec for this
# [01:24] <heycam> ed: I think that's fine with me
# [01:24] <heycam> heycam: happy to do that later
# [01:25] <heycam> RESOLUTION: Defer context-fill usage in Filter-specific properties until level 2 of Filters.
# [01:25] <krit> file:///Users/dschulze/Documents/fxtf-drafts/filters/issues-lc-2015.html#issue-8
# [01:25] * Quits: glazou (~glazou@public.cloak) (glazou)
# [01:25] <heycam> ... next is issue #8
# [01:25] <heycam> ... luminance has fixed colour matrix values. in most places they have 3 digits after the dot, in some places they have 4
# [01:25] <heycam> ... the request was to have 4 digits everywhere, instead of just 3
# [01:26] <krit> http://dev.w3.org/fxtf/filters/#element-attrdef-values
# [01:27] <heycam> heycam: so it's using 4 digits in the luminance matrix, but 3 in the other types
# [01:27] <heycam> krit: any objection to using 4 digits everywhere?
# [01:27] <heycam> (none heard)
# [01:27] <heycam> RESOLUTION: The feColorMatrix pre-defined matrices should all use 4 digits after the decimal point.
# [01:28] <heycam> krit: next, issue #11
# [01:28] <krit> file:///Users/dschulze/Documents/fxtf-drafts/filters/issues-lc-2015.html#issue-11
# [01:28] <astearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27464
# [01:28] <heycam> ... if you have objectBoundingBox units, and you try to use say 47em, what does that mean?
# [01:29] <heycam> ... not clear what element the ems are resolved to px
# [01:30] <heycam> heycam: I guess they should be resolved against the font-size of the element they're on
# [01:30] <heycam> ed: not sure if this needs to be mentioned in the spec
# [01:30] <heycam> ... could put a note that these values will give useless results [as they're much > 1]
# [01:31] <heycam> 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.
# [01:32] <heycam> (unless you use very small em values of course)
# [01:32] * krit fantasai could you fix the links when you edit the minuted please? :P
# [01:32] <liam> [the note should explain why, as there are cases where it works]
# [01:32] * heycam (*editing* minutes?)
# [01:32] <krit> http://dev.w3.org/fxtf/filters/issues-lc-2015.html#issue-12
# [01:32] <liam> (yes - I think that's not uncommon)
# [01:32] <heycam> krit: finally, issue #12
# [01:32] <heycam> ... I thought we already discussed this and decided
# [01:32] <heycam> Tav: specularExponent is used in two different places
# [01:33] <heycam> ... just adding a note to say that two uses of this are different
# [01:33] <heycam> krit: I think I made that change already
# [01:33] <heycam> krit: now, how do we want to proceed with the spec. should we continue with a WD or should we publish a CR of it?
# [01:35] <heycam> ed: any objections to publishing as CR after the edits are done?
# [01:35] <heycam> (none heard)
# [01:35] <heycam> RESOLUTION: Publish a CR of Filters spec (under the new process).
# [01:35] <heycam> Topic: CSS Blending PR
# [01:35] <heycam> krit: I'm speaking for Rik who can't be here
# [01:35] <heycam> ... we already had a resolution to PR at TPAC, but there was one issue that forced us to have another CR
# [01:36] <heycam> ... there haven't been any complaints since then
# [01:36] <heycam> ... 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
# [01:36] <heycam> ChrisL: implementation report with two passes for everything?
# [01:36] <heycam> krit: we do have 2 implementaitons for each feature and Rik is preparing that implementation report
# [01:37] <heycam> ChrisL: shouldn't need a resolution of the WG
# [01:37] <heycam> Florian: we could resolve that we think the test suite is sufficiently extensive
# [01:38] <heycam> ... that passing it is meaningful
# [01:38] <heycam> ... and then we you pass it everything is fine
# [01:38] <heycam> ChrisL: what's the test coverage like?
# [01:38] <heycam> Tav: including SVG?
# [01:38] <heycam> krit: yes we have tests covering each section
# [01:39] <krit> http://test.csswg.org/suites/compositing-1_dev/nightly-unstable/report/
# [01:39] <heycam> krit: the other part of the test suite are the canvas tests that were published with philip's test suite
# [01:40] <heycam> krit: what do the CR exit criteria say?
# [01:40] <heycam> s/krit/ChrisL/
# [01:41] <plinss> http://www.w3.org/TR/compositing-1/#cr-exit-criteria
# [01:42] <heycam> ChrisL: the SotD section says that CR must last until at least March 17
# [01:43] * Joins: ChrisL (clilley@public.cloak)
# [01:44] <heycam> Tav: you have some SVG specific tests, but you don't test each of these things in both HTML and SVG?
# [01:45] * Zakim excuses himself; his presence no longer seems to be needed
# [01:45] * Parts: Zakim (zakim@public.cloak) (Zakim)
# [01:45] <heycam> Tav: it'd be nice if each of these actually linked to the tests
# [01:45] <plinss> http://test.csswg.org/harness/results/compositing-1_dev/grouped/
# [01:46] <heycam> krit: I will ask Rik to provide the necessary documents
# [01:46] <heycam> ChrisL: it looks like they're all HTML tests?
# [01:47] <heycam> Tav: I am concerned we're not testing enough applying to SVG elements
# [01:47] <heycam> ChrisL: there are some broken links too
# [01:49] <ChrisL> links like ../support/* should be support/*
# [01:49] <heycam> Tav: would be good for pure SVG documents so I can provide results for Inkscape
# [01:50] <heycam> ACTION: Dirk to ask Rik to produce SVG versions of the blending tests.
# [01:50] * trackbot is creating a new ACTION.
# [01:50] * RRSAgent records action 3
# [01:50] <trackbot> Created ACTION-89 - Ask rik to produce svg versions of the blending tests. [on Dirk Schulze - due 2015-02-18].
# [01:51] <cyril_> scribe: Cyril
# [01:51] <cyril_> scribeNick: cyril
# [01:51] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [01:51] <cyril_> Topic: Colored font palette control
# [01:51] <cyril_> heycam: I sent an email to www-style about this
# [01:51] <heycam> https://lists.w3.org/Archives/Public/www-style/2015Feb/0211.html
# [01:51] <cyril_> heycam: in the latest version of hte OpenType spec
# [01:52] <cyril_> ... which reached a stage where only editorial changes can be made
# [01:52] <cyril_> ... there is 3 types of colourful glyphs:
# [01:52] <cyril_> ... bitmap format like PNG
# [01:52] <cyril_> ... vector format reusing existing glyf and cff table glyphs
# [01:52] <cyril_> ChrisL: was it extended to CFF ?
# [01:52] <cyril_> heycam: it was an assumption
# [01:53] <cyril_> ... might not be
# [01:53] <cyril_> ... and the 3rd option is embedded SVG document
# [01:53] <cyril_> ... in the last 2 options they have the option of using a palette
# [01:53] <cyril_> ... in fact for option 2 it is mandatory
# [01:53] <cyril_> ... for SVG glyphs it is an option by using CSS variables
# [01:54] <cyril_> ... some CSS variiables are defined automatically
# [01:54] <cyril_> ... in the font you can define a number of palettes
# [01:54] <cyril_> ... but there is no way to select the palette you want
# [01:54] <cyril_> ... or provide your own custom palette
# [01:54] <cyril_> ... I thought it moght be a good thing to allow
# [01:55] <cyril_> ... my email has an actual proposal
# [01:55] <cyril_> ... for selecting which palette, there would be a new property font-palette referencing the palette by a name
# [01:55] <cyril_> ... there is no name in the font
# [01:55] * liam thought it was a good proposal
# [01:55] <cyril_> ... the idea would be to map indices to names for a particular font
# [01:55] * TabAtkins liam, agreed.
# [01:55] <cyril_> ... you don't want to set ffont-palette: 3 and then depend on the font
# [01:56] <cyril_> dino: I think for these fonts, you know what you're doing
# [01:56] <cyril_> ChrisL: we don't know what fonts you have on the machine or what fonts are downloaded
# [01:57] * liam expecting to see www.download10000crappycolorfonts.com any time soon
# [01:57] <cyril_> roc: there is an issue with editable content, it is easy for users to add characters that are not in the font
# [01:58] <cyril_> ... and you can have fallback to system fonts and that might not be what you want
# [01:58] <liam> [that's true for any font, including woff]
# [01:58] <ChrisL> we already have that issue with font feature selection, where feature numbers are not portable across different fonts
# [01:58] <cyril_> dino: the theory is that if you specify the palette you end up with a font that has the right palette ?
# [01:59] * liam zakim, who is on the phone?
# [01:59] * liam ah, no-one
# [01:59] <cyril_> heycam: jdaggett was of the opinion that it should go in font feature values
# [01:59] <cyril_> dino: it's not a big deal but it might be longer to specify
# [02:00] <cyril_> ... people might end up with names 'one', 'two' ... for the palettes
# [02:01] <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]
# [02:01] <cyril_> heycam: if people were happy with disabling palette selection if you use a fallback selection, I'll be happy
# [02:01] <cyril_> dino: tab's suggestion is good too
# [02:01] <cyril_> ... you can use palette name but if the name is a number that's the index then
# [02:02] <cyril_> roc: we could disable fallback for now and add it later
# [02:02] <cyril_> TabAtkins: reasonnable
# [02:03] <cyril_> heycam: do people think this should be in the next level of the font spec ?
# [02:03] <cyril_> ChrisL: it doesn't make sense to put in the current level because it's stable
# [02:03] <cyril_> heycam: what about adding font palette selection to level 4
# [02:04] <cyril_> ... and it uses an index to begin with and font fallback disables selection
# [02:04] * Joins: tantek (~tantek@public.cloak)
# [02:04] <cyril_> ... and later we can add a more detailed feature
# [02:04] <cyril_> TabAtkins: yes
# [02:04] <cyril_> resolution: add font palette selection to CSS Fonts level 4
# [02:05] <cyril_> action: jdaggett to add font palette selection to CSS Fonts level 4
# [02:05] * trackbot is creating a new ACTION.
# [02:05] * RRSAgent records action 4
# [02:05] <trackbot> Error finding 'jdaggett'. You can review and register nicknames at <http://www.w3.org/Graphics/fx/track/users>.
# [02:05] <cyril_> heycam: the next step, if we want to, is to specify custom palette values
# [02:06] <cyril_> ... for my example (in the email), the font creator would provide different fonts
# [02:06] <cyril_> ... it's normal to have a choice to select the palette
# [02:06] <cyril_> ... in my optional proposal #2, I added something similar
# [02:07] <cyril_> ... adds a @font-palette
# [02:07] <cyril_> TabAtkins: I don't think we need the indirection of the @font-palette
# [02:07] <cyril_> ... we can use directly the font property to specify the color palette
# [02:08] <cyril_> ... for colors, giving a name is useful
# [02:08] <cyril_> ChrisL: people asked a long time ago to be able to name colors
# [02:10] * liam thinks "Amanda" would be a good name for a colour.
# [02:10] <cyril_> heycam: I'm happy with not having the named palettes and not having the @font-palette rule
# [02:11] <cyril_> ... does the order of the names and colors in the font-palette property have to match the indices ?
# [02:11] <cyril_> TabAtkins: no
# [02:11] <cyril_> heycam: what happens if you miss out one of the palette entries ?
# [02:11] <cyril_> ChrisL: you default to transparent black ?
# [02:11] <cyril_> TabAtkins: no simply black
# [02:12] * liam hopes the font can provide a default
# [02:12] <cyril_> ChrisL: I agree I made a big mistake here
# [02:12] <cyril_> heycam: do we agree we want the feature ?
# [02:12] <cyril_> Tav: yes
# [02:12] <cyril_> TabAtkins: why don't overload the color property ?
# [02:13] <cyril_> ... you might to use a palette function
# [02:13] <cyril_> heycam: what does fill=currentColor on a shape if you have that ?
# [02:14] <cyril_> ChrisL: color can be used for other usages: stroke, fill, ...
# [02:14] <cyril_> TabAtkins: yes
# [02:14] <cyril_> ChrisL: not objecting but concerned about how it would evolve
# [02:14] <cyril_> TabAtkins: so if palette is not used, we could default to using the color value
# [02:15] <cyril_> ed: is it possible to use a palette and override some colors ?
# [02:15] <cyril_> ChrisL: palette is a preset, you can override it all
# [02:16] <cyril_> ... we've had that discussion on gradients, overriding some stops, but it's not used
# [02:17] <cyril_> (chris digresses on Web audio)
# [02:17] * Joins: glazou (~glazou@public.cloak)
# [02:17] <cyril_> resolution: we add custom palette support without the @font-palette rule
# [02:17] <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;"
# [02:18] <cyril_> heycam: we'll still name the individual palette entries inside font-feature values
# [02:18] <cyril_> heycam: the final part in my email, proposal 3
# [02:18] <cyril_> ... you can specify if one of the predefined palette is appropriate for dark, light, both or neither background
# [02:18] <cyril_> ... emoji fonts have dark versions and light version
# [02:19] <cyril_> ... i'm suggesting adding keywords to select the version
# [02:19] <cyril_> TabAtkins: +1
# [02:20] <cyril_> ... I'm suggesting to name it according to the system it is supposed to be used: lightSomething, darkSomehting
# [02:20] <cyril_> heycam: you probably always want to use the highcontrast one without analysing the background color
# [02:20] <cyril_> ... I'm ok with starting with just light and dark
# [02:20] * Quits: glazou (~glazou@public.cloak) (glazou)
# [02:20] <cyril_> .. do people agree ?
# [02:20] <cyril_> ChrisL: yes
# [02:21] <cyril_> resolution: font-palette property will have light and dark keywords to select the first light or dark annotated palette in the font
# [02:21] <TabAtkins> s/so if palette is not used/so if you omit some palette index names/
# [02:21] <cyril_> heycam: I'd like to bring a little issue regarding css variables
# [02:22] <cyril_> ... I tried to implement css variables and palettes
# [02:23] <cyril_> ... (explaining something about caching)
# [02:23] <cyril_> ... we could need a non-variable way to indicate palette
# [02:23] <cyril_> ... I don't know if we can do that
# [02:24] <cyril_> ... It's a bit late in the open type process
# [02:24] <cyril_> ... but we might have this problem in other contexts
# [02:25] <cyril_> TabAtkins: for svg fonts, I see the problem
# [02:25] <cyril_> ... but using variables in UA specific way is a viloation of the spec anyway
# [02:25] <cyril_> heycam: it's probably possible to detect that the palette variables are used in a sensible way
# [02:26] <cyril_> ... but I'm concerned more about the general pattern
# [02:26] <cyril_> ... like a stroke-width controllable by variables
# [02:27] <heycam> Scribe: Cameron
# [02:27] <heycam> ScribeNick: heycam
# [02:27] <heycam> Topic: text-rendering
# [02:27] <heycam> roc: this is a google request
# [02:27] <heycam> ... 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
# [02:28] <heycam> ... the width of the string in css px changes when you zoom in/out of the page
# [02:28] <heycam> ... turns out this is true in all pages, including chrome in some situations
# [02:28] <heycam> ... the reason is because of font hinting, in this case
# [02:28] <heycam> ... there are some other issues
# [02:28] <heycam> ... with vertical metrics it can also occur if you round line height to pixels
# [02:28] <heycam> ... they saw this as a bug, though I don't think it is a bug
# [02:28] <heycam> ... generally you do want to hint on windows, as you want to match OS text rasterisation
# [02:29] <heycam> ... 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
# [02:29] <heycam> ... and render that font with no regard to what the device resolution is
# [02:29] <heycam> ... then if we do that consistently we can make text rendering device resolution independent
# [02:29] <heycam> ... as you zoom in/out you'd get the same metrics
# [02:29] <heycam> ... apparently chrome has or will do this
# [02:30] <heycam> ChrisL: that seems consistent with what geometricPrecision was designed for
# [02:30] <heycam> roc: if we do this, then the spec should make this a requirement
# [02:30] <heycam> roc: this would apply to HTML and SVG
# [02:30] <heycam> Rossen: when you zoom, what do you mean?
# [02:30] <heycam> ... user zoom in firefox?
# [02:30] <heycam> roc: a full page zoom that causes a layout
# [02:31] <heycam> ... so for any layout-changing zoom
# [02:31] <heycam> ... (non-layout-changing zoom already doesn't affect text metrics)
# [02:31] <heycam> Rossen: so this would affect high dpi devices, you're opting in to some level of zoom?
# [02:31] <heycam> roc: right now you can get different layout on high/lo dpi
# [02:31] <heycam> ... this would make those layouts consistent with each other
# [02:31] <heycam> ... and across the web
# [02:31] <heycam> ... we could make layouts fully consistent across browsers, at least text width
# [02:32] <heycam> Rossen: I think Ted and Matt Rakow want to make that happen
# [02:32] <heycam> roc: in Firefox I would make text metrics incl advance widths depend only on the content of the OpenType font
# [02:32] <heycam> ... the problem is platform APIs apply rounding in different situations
# [02:32] <heycam> ... I'd like to bypass that and just get data from the font
# [02:32] <heycam> Rossen: do you have any test cases we could look at?
# [02:32] <heycam> roc: I'll send you one
# [02:33] <heycam> ... I should mention that our plan is to continue to render glyphs with subpixel AA where possible
# [02:33] <heycam> ... eventhough we're not doing any hinting
# [02:33] <heycam> ... this doesn't mean we need to turn off subpixel AA
# [02:33] <heycam> ... it's a layout issue, not glyph rendering issue
# [02:33] <heycam> ... sounds OK?
# [02:33] <heycam> ChrisL: yes
# [02:33] <heycam> dino: yes
# [02:33] * TabAtkins we lunching soon?
# [02:34] * ed yes, this was the last topic in the AM slot (since we skipped the transitions ones)
# [02:34] <heycam> RESOLUTION: text-rendering:geometricPrecision will require that font metrics and text measurement will be independent of the device resolution
# [02:34] <heycam> ... and zoom level
# [02:35] <heycam> ACTION: Cameron to make text-rendering:geometricPrecision change
# [02:35] * trackbot is creating a new ACTION.
# [02:35] * RRSAgent records action 5
# [02:35] <trackbot> Created ACTION-90 - Make text-rendering:geometricprecision change [on Cameron McCormack - due 2015-02-18].
# [02:35] <heycam> -- lunch break, 90 mins --
# [02:35] * Quits: kwkbtr (~kwkbtr@public.cloak) (Client closed connection)
# [02:36] * Quits: jun (~jun@public.cloak) (jun)
# [02:36] * Joins: jun (~jun@public.cloak)
# [02:37] * Quits: jun (~jun@public.cloak) (jun)
# [02:38] * heycam is now known as heycam|away
# [02:40] * Joins: shepazu_ (schepers@public.cloak)
# [02:41] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
# [02:42] * Quits: shepazu (schepers@public.cloak) (Ping timeout: 180 seconds)
# [02:43] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [02:43] * Rossen is now known as Rossen_away
# [02:43] * Quits: AndreyR_ (~AndreyR@public.cloak) (Ping timeout: 180 seconds)
# [02:45] * Quits: hyojin__ (~hyojin@public.cloak) (Ping timeout: 180 seconds)
# [02:48] * shepazu_ is now known as shepazu
# [02:56] * Quits: murakami_ (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [03:00] * Joins: ChrisL (clilley@public.cloak)
# [03:00] * Joins: ChrisLilley (clilley@public.cloak)
# [03:07] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
# [03:09] * Quits: ChrisLilley (clilley@public.cloak) (Ping timeout: 180 seconds)
# [03:15] * Joins: koji (~sid53200@public.cloak)
# [03:31] * Quits: tantek (~tantek@public.cloak) (tantek)
# [03:38] * Joins: hyojin (~hyojin@public.cloak)
# [03:42] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [03:45] * heycam|away is now known as heycam
# [03:50] * Joins: stakagi (~stakagi@public.cloak)
# [03:53] * Joins: jun (~jun@public.cloak)
# [04:02] * Joins: kwkbtr (~kwkbtr@public.cloak)
# [04:02] * Quits: hyojin (~hyojin@public.cloak) (Ping timeout: 180 seconds)
# [04:02] * Joins: Florian (~Florian@public.cloak)
# [04:02] * Joins: AndreyR (~AndreyR@public.cloak)
# [04:03] * Joins: murakami (~murakami@public.cloak)
# [04:04] * Joins: tantek (~tantek@public.cloak)
# [04:04] <nikos> scribenick: nikos
# [04:04] <nikos> scribe: Nikos
# [04:04] <nikos> Topic: Canceling and interrupting transitions
# [04:04] <nikos> dbaron: There have been some relatively large edits since the WD - but only stuff that implementors would care about
# [04:04] <nikos> ... such as cancelling and interrupting transitions
# [04:05] <nikos> ... I think I'm ready to take the spec to new new process CR
# [04:05] <nikos> ... there's a bunch of issues in bugzilla
# [04:05] <nikos> ... I made some minor edits and there's a few we should talk about
# [04:05] <nikos> ... anything that's a new feature is marked to defer to level 2
# [04:05] <nikos> ... there are a few that are about animating specific value types
# [04:05] <nikos> ... like images and gradientss
# [04:05] <nikos> ... those should be deferred to css images
# [04:06] <nikos> s/gradientss/gradients
# [04:06] <nikos> dbaron: one question is whether there should be transition rules defined for z-index:auto
# [04:06] <dbaron> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16265
# [04:06] <nikos> ... apparently testing showed that a bunch of engines do transitions between z-index:auto and numbers
# [04:06] <nikos> ... this may or may not just be a bug related to treating the value as zero
# [04:07] <nikos> ... 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
# [04:07] <nikos> ... and a jump at the end
# [04:08] <nikos> ... apparently zero to auto jumps were at both ends
# [04:08] <nikos> ... do people thing we should have special transition rules for z-index:auto
# [04:08] <nikos> ... ?
# [04:08] <nikos> TabAtkins: I'd prefer not, I don't see how to do it properly
# [04:08] <nikos> dbaron: a special rule would mean that any intermediate interpolation that was not 100% value or the other would treat auto as zero
# [04:09] <nikos> dino: it looks to me like it's a bug
# [04:09] <nikos> ... what would you do otherwise?
# [04:09] <nikos> dbaron: current behaviour says if one value is auto you can't interpolate
# [04:09] <nikos> dino: think it's just a bug that webkit should fix
# [04:09] * Joins: ChrisLilley (clilley@public.cloak)
# [04:09] <nikos> ... we don't check that it's auto
# [04:10] <smfr> that might have compat risk for webkit but we should fix it (maybe with the non-prefixed transition, dino)
# [04:10] <nikos> dbaron: a few of the issues are a mix of feature requests for new things or things we've fixed
# [04:10] <nikos> ... so I'm inclined not to look at them
# [04:11] <nikos> ... if someone wants to help?
# [04:11] <nikos> RESOLUTION: Leave z-index as is
# [04:11] * heycam is now known as heycam|away
# [04:11] <nikos> dbaron: the one other issue filed is for more constraints specifying when computed values change
# [04:11] <nikos> ... e.g. when transitions start
# [04:11] <nikos> ... i've avoided specifying too much there
# [04:12] <nikos> ... don't want to make this a spec for the browser refresh cycle
# [04:12] <nikos> ... and would like to leave room for optimisation
# [04:12] * Joins: hyojin (~hyojin@public.cloak)
# [04:12] <nikos> ... there was a statement that it was specifically not specified
# [04:12] * heycam|away is now known as heycam
# [04:12] <nikos> ... 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
# [04:12] <nikos> ... I wrote prose this morning
# [04:12] <nikos> ... so there is a definition that leads to useful results
# [04:13] <nikos> ... and doesn't allow implementation to be conformant without doing anyhting
# [04:13] <nikos> s/anyhting/anything
# [04:13] <nikos> Florian: intent sounds useful
# [04:13] <nikos> dbaron: the big changes in this draft are mostly stuff we've discussed before
# [04:13] <nikos> ... more precise definition of cancelling and interrupting running transitions
# [04:14] <nikos> ... and the things we discussed in Paris about the details of interactions
# [04:14] <nikos> ... I haven't gotten a huge amount of feedback
# [04:14] <nikos> ... given the number of implementations I think we should go to CR
# [04:14] <nikos> ... and we'll get feedback from implementors
# [04:15] <nikos> RESOLUTION: CSS transitions can go to CR
# [04:15] <nikos> Florian: you're not currently in LC?
# [04:15] <nikos> dbaron: this is the new process
# [04:15] <nikos> ... so we can go straight to CR
# [04:16] <nikos> Topic: css-transforms: Specifying decomposition of scale
# [04:16] <stakagi> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Specifying_decomposition_of_scale
# [04:16] <nikos> stakagi: I've prepared a wiki page
# [04:16] <nikos> stakagi: I'd like to specify decomposition of scale
# [04:16] <nikos> ... the use case of scale are non scaling objects, and level of detail
# [04:16] <nikos> ... this scale is not scaleX or scaleY
# [04:17] <nikos> ... non scaling objects are a part of vector graphics
# [04:17] <nikos> ... of svg 2
# [04:17] <nikos> ... the svg working group decided to put non scaling object functionality in svg 2
# [04:17] <nikos> ... you can see a polyfill in the link on the wiki page
# [04:18] <nikos> ... and level of detail also determines standardisation of functionality
# [04:18] <nikos> ... there is a video to demonstrate this
# [04:18] <nikos> ... the scale value decomposed from the transform matrix is required for each function
# [04:18] <nikos> ... and such a scale value should be one scalar value
# [04:19] <nikos> ... which is always meaningful on all the affine transformation involving skew
# [04:19] <nikos> ... the chapters on decomposing 2d and 3d matrices for scaling are dependent on specific axis
# [04:19] <nikos> ... I'd like to specify a method that does not depend on a specific axis
# [04:20] <nikos> ... I would like to introduce this into that chapter
# [04:20] <nikos> ... each scale is based on the determinant of the matrix
# [04:20] <nikos> ... 2d decomposition is sqrt of determinant
# [04:20] <nikos> ... 3d is cube root
# [04:20] <nikos> ... decomposition of scale can be calculated based on these scales
# [04:21] <nikos> birtles: the specific proposal is to add an extra definition to css transforms
# [04:21] <nikos> ... of a scalar value for scale
# [04:21] <nikos> ... takagi-san has prepared a polyfill. In this he compares the definitions that are axis dependent with this version
# [04:22] <nikos> ... if you skew the shape you can see that the area of the shape changes dramatically
# [04:22] <nikos> ... if you use the scalar value you can avoid this
# [04:22] <nikos> heycam: we already have transform ref in the svg spec
# [04:22] <nikos> ... which undoes all transforms from one space to another
# [04:22] <nikos> ... never mind
# [04:23] <nikos> ChrisLilley: this is obviously correct - this is something we've needed
# [04:23] <ChrisLilley> http://www.w3.org/Graphics/ScalableReq
# [04:23] <nikos> ... we've achieved all requirements except level of detail
# [04:23] <nikos> ... we're talking about extreme zoom
# [04:23] <nikos> .... we need level of detail and it needs to work regardless of transformations
# [04:24] * Joins: tantek_ (~tantek@public.cloak)
# [04:24] <nikos> ... I support this
# [04:24] <nikos> birtles: the proposal is to add this definition of scale to the part of css transforms that defines decomposition of matrices
# [04:24] <nikos> ... not necessarily to use in css transforms, but able to be referenced
# [04:25] <nikos> ... don't think it requires behaviour of spec to change
# [04:25] <nikos> ... this seemed like the most appropriate place to define it
# [04:25] <nikos> krit: decomposition has multiple steps
# [04:25] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [04:25] * tantek_ is now known as tantek
# [04:25] * Rossen_away is now known as Rossen
# [04:25] <nikos> birtles: this would be another definition alongside the method that obtains a vector, that returns a scalr
# [04:26] <nikos> ... it doesn't replace the current definition
# [04:26] <nikos> birtles: we could possibly also add to the interpolation section. And in recomposition we can say multiply by these values
# [04:27] <nikos> dino: you'd never be able to interpolate between the two values
# [04:27] <nikos> heycam: are you saying existing definitions could be simplified by referencing this new definition?
# [04:27] <nikos> birtles: I don't think that's the suggestion
# [04:27] <nikos> 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
# [04:27] <nikos> ... and if you animate you should animate between these values
# [04:28] <nikos> heycam: going back to broader level of zoom media queries
# [04:28] <nikos> ... couple of years ago Ted was going to investigate different zoom use cases
# [04:28] <nikos> ... do you know if anything came of that?
# [04:28] <nikos> dino: don't know
# [04:28] <nikos> Florian: with zoom media queries we want to be really careful
# [04:28] <nikos> ... some things you don't want to expose
# [04:28] <nikos> ... e.g. pinch zoom
# [04:29] <nikos> heycam: I think to solve the use cases we may need a switch to control what pinch zoom does
# [04:29] <nikos> birtles: we talked about that but Takagi-san hasn't had a chance to come up with a proposal
# [04:29] <nikos> dino: this is only really going to have an impact if people are scaling with a different amount on different axis
# [04:29] <nikos> birtles: that's rigth
# [04:29] <nikos> s/rigth/right
# [04:30] <nikos> dino: how many people skew?
# [04:30] <nikos> heycam: I think Takagi-san recognised that in most cases it doesn't matter
# [04:30] <nikos> ... but we should provide the definition for cases when it does matter
# [04:30] <nikos> birtles: there's a formula in the wiki
# [04:31] <nikos> krit: we'd be putting it into the transform spec without any context
# [04:31] <nikos> ... does it need testing?
# [04:32] <nikos> heycam: just review it to make sure it's o
# [04:32] <nikos> ... ok
# [04:32] <nikos> ... then when another spec depends on it test that
# [04:32] <nikos> stakagi: we might use it in svg 2 and then we can test it tehre
# [04:32] <nikos> s/tehre/there
# [04:33] <nikos> heycam: Dirk, as editor how do you feel about it?
# [04:33] <nikos> krit: I need to look at the formula
# [04:33] <nikos> ... idea seems ok
# [04:33] <nikos> 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
# [04:33] <nikos> heycam: question is where should it live
# [04:34] <nikos> krit: best thing to do is to propose prose we can put into the spec
# [04:34] <nikos> ... as long as there's no requirement to test it
# [04:34] * Quits: jun (~jun@public.cloak) (jun)
# [04:34] <nikos> stakagi: I will send a pull request
# [04:34] * Joins: jun (~jun@public.cloak)
# [04:35] <nikos> RESOLUTION: Include Takagi-san's definition of linear scale in CSS transforms
# [04:36] <nikos> krit: Can I publish a new wd? last one was a long time ago
# [04:36] <ChrisLilley> how about putting that recently agreed change in there first
# [04:38] <nikos> ACTION: Takagi-san to propose specification text for new scalar value for CSS transforms
# [04:38] * trackbot is creating a new ACTION.
# [04:38] * RRSAgent records action 6
# [04:38] <trackbot> Error finding 'Takagi-san'. You can review and register nicknames at <http://www.w3.org/Graphics/fx/track/users>.
# [04:38] <nikos> ACTION: stakagi to propose specification text for new scalar value for CSS transforms
# [04:38] * trackbot is creating a new ACTION.
# [04:38] * RRSAgent records action 7
# [04:38] <trackbot> Created ACTION-91 - Propose specification text for new scalar value for css transforms [on Satoru Takagi - due 2015-02-18].
# [04:39] * TabAtkins Tav This example work for you? http://dev.w3.org/csswg/css-images-3/#the-image-rendering
# [04:39] <nikos> RESOLUTION: Publish new WD of CSS transforms
# [04:39] <nikos> s/Publish new WD of CSS transforms/Publish new WD of CSS transforms with Takagi-san's changes
# [04:39] <nikos> Topic: Web Animations status update
# [04:39] <birtles> http://people.mozilla.org/~bbirtles/pres/201502%20fxtf%20web-anim%20update/
# [04:40] <nikos> (Brian presents)
# [04:41] <nikos> 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?
# [04:42] <nikos> dino: is it ok to publish the WD with this section in it even though we may need to discuss it further?
# [04:42] <nikos> roc: did we get any specific feedback from MS?
# [04:42] <nikos> krit: there were competing proposals
# [04:42] <nikos> roc: there was just one minor issue I brought up
# [04:43] <nikos> krit: I think the spec has an issue noting that so it should be ok to publish a WD
# [04:43] <nikos> (and back to Brian's presentation)
# [04:44] <nikos> birtles: want to give an update and ask some questions
# [04:45] <nikos> ... started to ship in little pieces
# [04:45] * Joins: xidornq (~upsuper@public.cloak)
# [04:45] <nikos> ... Chrome and FF have started at opposite ends of the API
# [04:45] <nikos> ... and FF has some dev tools
# [04:45] <nikos> ... we've published two WDs so far and another to come soon
# [04:45] <nikos> ... diagram (slide 2) shows moving pieces
# [04:45] <nikos> ... been some simplification
# [04:46] <nikos> ... had motion path but that's been removed
# [04:46] <nikos> ... there's now a motion path module
# [04:46] <nikos> ... created by Dirk
# [04:46] <nikos> ... recently we also deferred grouping to a subsequent level
# [04:46] <nikos> ... it's useful but not critical
# [04:46] <nikos> ... diagram is now simpler - and I'd like to make it simpler still
# [04:46] <nikos> ... would like to merge Animation and Keyframe Effect
# [04:47] <nikos> ... Animations are the dynamic part
# [04:47] <nikos> ... Keyframe Effect is static
# [04:47] <nikos> ... this isn't in the spec yet
# [04:47] <nikos> ... there's some concern that this may make Keyframe Effect objects less shareable
# [04:47] <nikos> ... but this is the model I'm proposing
# [04:48] <nikos> ... it also makes the naming more straight forward
# [04:48] <nikos> ... A lot of people found Players confusing
# [04:48] <nikos> ... that's an update on where the spec is at now
# [04:48] <nikos> krit: different name for Keyframe Effect? Anything shorter?
# [04:49] <nikos> shane: we had Player and it was too generic - is Animation too generic?
# [04:49] <nikos> birtles: don't think so
# [04:49] <nikos> ... we already have the term
# [04:49] <nikos> dino: no fear of clobbering third party library that uses Animation?
# [04:49] <nikos> shane: something we need to do a little research on
# [04:50] <nikos> dino: what other effects do you have?
# [04:50] <nikos> birtles: only Keyframe Effects
# [04:50] <nikos> ... level 2 will have Group Effects and Sequence Effects
# [04:50] * Quits: xidorn (~upsuper@public.cloak) (Ping timeout: 180 seconds)
# [04:50] <nikos> ... still considering what to do with Custom Effects
# [04:50] <nikos> krit: how do you set up a Keyframe Effect?
# [04:50] * xidornq is now known as xidorn
# [04:51] <nikos> birtles: new KeyframeEffect
# [04:51] <nikos> shane: also element.animate
# [04:52] * Tav TabAtkins Yes! Still missing 'optimizeSpeed' should be interpreted as 'pixelated'
# [04:52] <nikos> heycam: I would find Group Effect a bit confusing
# [04:52] <nikos> ... effect doesn't seem like the right word there - don't have suggestions
# [04:52] * TabAtkins Tav: Ah, right. Fixing now.
# [04:52] <nikos> dino: could be concurrent effect
# [04:52] <nikos> shane: I find the name good - you're grouping a set of effects
# [04:53] <nikos> heycam: that should be an effects group then
# [04:53] <nikos> birtles: distinction is it's the static definition
# [04:53] <nikos> ... it's attached to an animation which is the dynamic part
# [04:53] <nikos> ChrisLilley: shouldn't it be grouped effect then?
# [04:53] <nikos> birtles: other APIs use 'set'
# [04:53] <nikos> birtles: we can think about names some more
# [04:54] <nikos> ... 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
# [04:55] <nikos> ... better to line up with css or keep short?
# [04:55] <nikos> ... two votes for keeping it short
# [04:55] <nikos> ChrisLilley: if it aligns with CSS it has to be exactly the same thing
# [04:55] <nikos> TabAtkins: it is
# [04:55] <nikos> shane: easing is much more of an industry standard than timing function
# [04:56] <nikos> ChrisLilley: fill on the other hand I've only ever seen in the context of SMIL
# [04:56] <nikos> krit: seen it used a lot in JS libraries
# [04:56] <nikos> ChrisLilley: iterations over animation-iteration-count is good
# [04:57] <nikos> ChrisLilley: could you put an issue in the spec saying calling out to script for easing will be possible in the future
# [04:58] <nikos> dino: we shouldn't really announce features
# [04:58] <nikos> ChrisLilley: True - but good to explain why it's not there
# [04:58] <nikos> birtles: couple of other questions
# [04:59] * Joins: gregwhitworth_ (~gregwhitworth@public.cloak)
# [04:59] <shane> https://docs.google.com/document/d/1f-KxMJwQ3f3OXSMvY-uQjpsy788BfyHlW9VoUWFvWQ4/edit#heading=h.b601rl56wy2f
# [05:00] <nikos> shane: First events and promises
# [05:00] <nikos> ... we switched from events to promises
# [05:00] <nikos> ... only used in two scenarios
# [05:01] <nikos> ... turns out that in different scenarios either events or promises can be useful
# [05:01] <nikos> ... in FF OS they've been doing things where you set up a transition to move between states of the UI
# [05:01] <nikos> ... and key on the end
# [05:01] <nikos> ... all sorts of reasons why that won't trigger
# [05:02] <nikos> ... so it's difficult to build a reliable system on top of that
# [05:02] <nikos> ... but with a promise you're guaranteed it will resolve or reject
# [05:02] <nikos> ... much easier to be reliable
# [05:02] <nikos> ... so a strong use case for promises
# [05:02] <nikos> ... but promises can be the wrong tool as well
# [05:03] <nikos> ... 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
# [05:03] <nikos> ... if you use promises every time you call play you need to set up the promise
# [05:03] <nikos> ... promises are one shot
# [05:03] <nikos> ... so in this case events are cleaner and easier than promises
# [05:03] <nikos> ... so could we have both?
# [05:04] <nikos> heycam: as long as you make sure that we have a consistent pattern in the order they are resolved and dispatched
# [05:04] <nikos> TabAtkins: I don't have an order specified so we should think about that
# [05:05] <nikos> dino: one of the best things about events is you can pass an object in to a listener
# [05:05] <nikos> RESOLUTION: Allow both events and promises in Web Animations
# [05:05] <nikos> shane: other thing I wanted to talk about
# [05:05] * Quits: gregwhitworth (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
# [05:05] <nikos> ... got an animation that's filling forward
# [05:05] <nikos> ... can't change the value of the property that is animated
# [05:06] <nikos> ... that's probably the single most complained about thing
# [05:06] <nikos> ... 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
# [05:07] <nikos> ... the other problem is that we can't clean up because animations may be deleted and we have to fall back
# [05:07] <nikos> ... so memory cost in some situations can be expensive
# [05:08] <nikos> ... 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
# [05:08] <nikos> heycam: would it be a layering violation if those values meant fill unless there is another animation on top of me?
# [05:09] <nikos> shane: I'd like to be able to say that fill only applies until there is a style change
# [05:09] <nikos> ... 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
# [05:10] <nikos> dbaron: what counts as a style change?
# [05:10] <nikos> shane: same as transitions
# [05:10] <nikos> dbaron: so any change to that property on that element
# [05:10] <nikos> dbaron: so this is different to css transitions
# [05:10] <nikos> birtles: yes, so can we do this? would it break the web?
# [05:10] <nikos> dbaron: yes it would
# [05:11] <dbaron> (Dean and Greg also said yes at the same time)
# [05:11] <nikos> shane: ok so it would be a separate thing then
# [05:11] <nikos> s/birtles: yes, so can we do this? would it break the web?/shane: yes, so can we do this? would it break the web?
# [05:11] <nikos> 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
# [05:12] <nikos> ChrisLilley: wanting it to stay where it is is a good result
# [05:12] <nikos> ... but there's two ways to do that
# [05:12] <nikos> ... one is to have a keyword that changes dom with final value
# [05:12] <nikos> ... other is to have an animation engine running that keeps the value there
# [05:12] <nikos> dbaron: I'm worried about things where other things change the computed value
# [05:13] <nikos> ... never mind
# [05:13] <nikos> heycam: one you get to the point where you're filling you want to have another mechanism for setting the fill value
# [05:13] <nikos> ... where is that mechanism?
# [05:13] <nikos> dino: why doesn't it become another keyword to fill
# [05:13] <nikos> ... that is an end event handler that sets the value
# [05:14] <nikos> shane: this is the simpler behaviour that will avoid programming errors so it should be the default
# [05:14] <nikos> heycam: regardless how you control it, not sure what the mechanism is for setting the value
# [05:15] <nikos> shane: in our implementation we have an animation stack where we apply all the style rules
# [05:15] <nikos> ... once we
# [05:15] <nikos> ... once we've applied the static styles we apply the animated styles on top - to override
# [05:15] <nikos> ... so that's where strongly held value is
# [05:15] <nikos> ... animations with fill don't say they need to be updated every frame
# [05:15] <nikos> ... transitions work a little differently
# [05:16] <nikos> ... this was the value I was transitioning to and the new value - if they're different we can stop
# [05:16] <nikos> heycam: I was thinking maybe it would be something like - for every element there's some level in the cascade
# [05:16] <nikos> ... with properties that can be set or not
# [05:16] <nikos> ... and when animation gets to fill but not strongly, it sets that value in the cascade
# [05:16] <nikos> ... which is beneath the animations
# [05:17] <nikos> heycam: what does setting the value mean .style.something = ?
# [05:17] <nikos> shane: yes
# [05:18] <nikos> heycam: I'm a little worried - how transitions trigger is difficult to get a handle on
# [05:18] <nikos> shane: if transitions didn't have similar behaviour I probably wouldn't want to go down this path
# [05:18] <nikos> ... once you're using web animations under the hood, transitions and animations should be the same thing
# [05:19] <nikos> shane: I'd also welcome suggestions for other novel solutions
# [05:19] <nikos> dbaron: it feels weird for a fill animation
# [05:19] <nikos> ... but it does feel there may be a short cut for setting the style to this and also run this animation
# [05:19] <nikos> ... or run the animation and while doing so set the style value to this
# [05:20] <nikos> shane: the issue is where to put that - you can't put it in the inline style
# [05:21] <nikos> 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
# [05:21] <nikos> shane: the problem with setting a value in the background is that there's no sensible place to set it
# [05:21] <nikos> dino: so your proposal is to still run the fill animation
# [05:21] <nikos> ... it's just implicitly cancellable by any change
# [05:21] <nikos> ... which is new behaviour
# [05:21] <nikos> shane: yes
# [05:21] <nikos> dino: I'd like to think about this
# [05:22] <nikos> ... I can see the need
# [05:22] * Joins: AndreyR_ (~AndreyR@public.cloak)
# [05:22] <nikos> shane: I just wanted to get a sense whether it was worth considering
# [05:22] <nikos> ... and that seems to be the case
# [05:22] <nikos> birtles: we've had requests in svg to have animations that update the dom
# [05:22] <nikos> dino: bit more obvious if it comes from an api rather than SMIL
# [05:24] <nikos> dino: maybe it's that you would always set via animations. So take the result of the last animation rather than having a fill
# [05:24] <nikos> dino: everything could be an animation
# [05:24] <nikos> cyril_: we had a related issue when converting flash to svg animations
# [05:25] <nikos> ... we had animations per layer in the flash display list
# [05:25] <nikos> ... wanted to get rid of the old animations in previous frames
# [05:25] <nikos> ... there was no way to signal
# [05:25] <nikos> ... in smil we could use an attribute something like restartnever
# [05:25] * Quits: AndreyR (~AndreyR@public.cloak) (Ping timeout: 180 seconds)
# [05:25] <nikos> ... as an indicator that you could do garbage collection
# [05:26] <nikos> shane: we have one more set of things to talk about
# [05:26] <cyril_> s/restartnever/restart=never/
# [05:26] <nikos> TabAtkins: some time ago Shane and I proposed adding to the family of transform properties a translate, rotate and scale property
# [05:26] <nikos> ... that get slotted into the use translate list at the end
# [05:27] <nikos> ... some were hostile, some liked it
# [05:27] <nikos> ... I think we should revisit this
# [05:27] <nikos> ... we have more precedent with motion path
# [05:27] <nikos> ... which exists as a property and a function
# [05:27] <nikos> ... for good reason - and those same reasons apply here
# [05:28] <nikos> shane: Jack Doyle's selling point is the can independently animate rotate, scale and translate
# [05:28] <nikos> ... a lot of his customers find it useful
# [05:28] <nikos> heycam: I worry it works well for separate translate and rotates
# [05:28] <nikos> ... as soon as you have something that doesn't decompose into at most these three types
# [05:28] <nikos> ... it breaks down
# [05:29] <nikos> ... so I'd prefer to see some mechanism that allows you to combine the values somewhow
# [05:29] <nikos> s/somewhow/somehow
# [05:29] <nikos> shane: for the simple case you're requiring people have knowledge of the ordering of transforms
# [05:29] <nikos> heycam: you have fixed order
# [05:30] <nikos> TabAtkins: there is a single correct order if you want them to act independently
# [05:30] <nikos> ... and it's not trivial
# [05:30] <nikos> shane: you can define that rigorously
# [05:30] <nikos> dino: right to some people
# [05:31] <nikos> ... it's not what everyone wants
# [05:31] <nikos> shane: we force people to think in terms of the scene
# [05:31] <nikos> ... so it makes sense to define it in a particular way
# [05:33] <nikos> birtles: we've got some pretty strong requests for this in the animation community
# [05:33] <nikos> dino: you can still do it - it's just a little cumbersome with additive animation
# [05:33] <nikos> shane: you can't
# [05:33] <nikos> ... with custom properties maybe
# [05:33] <nikos> ... with the web animations api I mean
# [05:33] <nikos> dino: you can't write an animation that independently animates translation, scale and rotation?
# [05:33] <nikos> birtles: you can do it
# [05:33] <nikos> ... it's hard
# [05:33] <nikos> dino: at the moment in css you do it with nested elements
# [05:33] <nikos> shane: I'll get back to you
# [05:35] <nikos> (shane gives an example that requires knowing how to decompose matrices)
# [05:36] <nikos> TabAtkins: is the argument all about whether you can tween in web animations?
# [05:36] <nikos> dino: I don't think so - if we do add these other properties, what's the fall back strategy?
# [05:36] <nikos> ... if I add these properties and also add transform because I want it to work in other browsers
# [05:36] <nikos> dino: you have properties that combine in a particular order
# [05:37] <nikos> TabAtkins: there's a lot of layout features that also work like this - flexbox for example
# [05:38] <nikos> ... you can't polyfill, you just have to wait for support
# [05:38] <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"
# [05:38] <birtles> demo at: http://codepen.io/GreenSock/full/kingu/
# [05:39] <nikos> birtles: from a use case point of view I think it's really useful
# [05:39] <nikos> dino: this is really a change to the transform spec, not animations
# [05:40] <nikos> dbaron: I guess I'm ok with it if there's a rule for how they all decompose
# [05:40] <dbaron> s/decompose/compose/
# [05:40] <nikos> dino: so if you did translate(10,10) transform="scale(2)" then it's not round tripable
# [05:41] <nikos> dbaron: it might be confusing to people if they do transition: transform
# [05:41] <nikos> ... that won't transition if they change translate
# [05:41] <nikos> TabAtkins: does that confuse people if they transition on transform and then change the perspective property it does not transition?
# [05:42] <birtles> also, for reference, this request comes up a lot: https://twitter.com/rachelnabors/status/518773879117197313
# [05:43] <nikos> 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
# [05:43] <nikos> ... the case for using both is a programming error and should be avoided
# [05:43] <nikos> ... so we want to add a simple model
# [05:43] <nikos> dino: my main issue is I'm not sure it's worth it
# [05:43] <nikos> ... I understand the issues people are hitting
# [05:44] <nikos> 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
# [05:45] <nikos> TabAtkins: I hear more conclusions that it would be worth having so we should take another look at it
# [05:45] <nikos> ... ideally I'd like to put it in and see if we get objections
# [05:46] <nikos> dmitry: what if I want to animate rotation and rotation?
# [05:46] <nikos> TabAtkins: use transform
# [05:46] <nikos> shane: if we put this in the spec and it turns out there's other ways of doing it we'll take it out
# [05:46] <nikos> ... so can we put it in the spec?
# [05:46] <nikos> ... in CSS transforms
# [05:47] <nikos> dbaron: in level 2?
# [05:47] <nikos> shane: I'd be happy with that
# [05:47] <nikos> RESOLUTION: We will add translate,rotate and scale properties in CSS transforms level 2
# [05:47] * ed css schmansforms?
# [05:48] * TabAtkins Yup.
# [05:48] * shane shmell shmeah
# [05:49] * Quits: kwkbtr (~kwkbtr@public.cloak) (Client closed connection)
# [05:53] * Quits: AndreyR_ (~AndreyR@public.cloak) (Ping timeout: 180 seconds)
# [05:53] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [05:55] * liam wonders if there's a break?
# [06:00] * Rossen is now known as Rossen_away
# [06:03] * Quits: jun (~jun@public.cloak) (jun)
# [06:03] <astearns> liam: yes
# [06:03] <liam> tx
# [06:11] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [06:17] * Joins: AndreyR (~AndreyR@public.cloak)
# [06:23] * Rossen_away is now known as Rossen
# [06:23] * Quits: AndreyR (~AndreyR@public.cloak) ("Page closed")
# [06:23] * Joins: AndreyR (~AndreyR@public.cloak)
# [06:24] * Joins: murakami (~murakami@public.cloak)
# [06:24] <cyril_> Scribe: Cyril
# [06:24] <cyril_> SCcribeNick: cyril_
# [06:25] <cyril_> Topic: ID-less referencing
# [06:25] <birtles> http://people.mozilla.org/~bbirtles/pres/referencing-proposal-2015/
# [06:25] * Joins: Florian (~Florian@public.cloak)
# [06:25] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [06:25] * Joins: Florian (~Florian@public.cloak)
# [06:25] * Joins: kwkbtr (~kwkbtr@public.cloak)
# [06:25] <cyril_> birtles: quick proposal about referencing elements from css properties without using id
# [06:25] <cyril_> ... the motivation is masking for example
# [06:26] <cyril_> ... you want to point to another element
# [06:26] <cyril_> ... but mash-ups can have conflicts
# [06:26] <cyril_> ... unique ids is a solution but that's a bit too much
# [06:26] <cyril_> ... readability, file size ... and a pain to generate from JS
# [06:27] <cyril_> ... semantically not great
# [06:27] <cyril_> ...it'd be better if we could nest mask in path
# [06:27] <cyril_> ChrisLilley: the downside is you can only have one child in some cases
# [06:28] <cyril_> birtles: we could try nesting
# [06:28] <cyril_> ... but that's not good for backward compatibility
# [06:28] <cyril_> ... I proposed a keyword
# [06:28] <cyril_> ... 'child' to say the first descendant
# [06:29] <cyril_> ... if you have multiple masks, child would mean the last one
# [06:29] <cyril_> ... would work for paint servers
# [06:29] <cyril_> ... one issue is both fill and stroke refer to the children
# [06:29] <cyril_> ... the proposal is to use a select syntax
# [06:30] <cyril_> Tav: you could also need a list: gradient and pattern as a fill
# [06:30] <cyril_> birtles: the proposal is to use selectors scoped to the subtree
# [06:30] <cyril_> ... that was removed from CSS masking to find a more generic solution
# [06:31] <cyril_> ChrisLilley: I don't see how it could be more generic than selector
# [06:31] <cyril_> ... the only constraint is the fact that it selects amongst the children
# [06:32] * Quits: smfr (~smfr@public.cloak) (smfr)
# [06:32] <cyril_> (link to an email on www-style)
# [06:33] <cyril_> heycam: using selectors you could have things depending on attribute values, structure of the tree
# [06:33] <cyril_> ... making it difficult to watch mutations in the tree
# [06:33] <cyril_> ... if the selector would be limited to children or element names
# [06:33] * liam gives birtles an XPath selector
# [06:33] <cyril_> ... it'd make it easier to track
# [06:34] <cyril_> fantasai: we have an outstanding issue in GCPM
# [06:35] <cyril_> ... that the element function in gpcm and CSS 4 don't agree
# [06:35] <cyril_> ... changing syntax is on the table
# [06:35] <cyril_> birtles: element() with an id doesn't help
# [06:36] <cyril_> heycam: concenrs are different with navigation
# [06:36] <cyril_> ... you don't watch for changes
# [06:37] <cyril_> ChrisLilley: previously it was not enough generic, now it is too generic
# [06:37] <cyril_> cyril_: why don't we restrict selectors to nth-child
# [06:38] <cyril_> TabAtkins: we could add full selectors in the future
# [06:38] <cyril_> ChrisLilley: I would rather use selectors and constrain it
# [06:39] <cyril_> TabAtkins: select(nth-child(2)) is longer than child(2)
# [06:39] <cyril_> ... what if you want the 2nd linearGradient here and not the 2nd child
# [06:39] <cyril_> birtles: if you allow element name and child
# [06:40] <cyril_> ... we could disambiguate by giving the element name
# [06:40] <cyril_> TabAtkins: I don't like remembering what arbitrary things I'm allowed to use
# [06:40] <cyril_> heycam: I don't see use cases for selecting things other than children
# [06:41] <cyril_> ... I don't like to write mask="select(mask[1])"
# [06:41] <cyril_> heycam: the gcpm function takes a custom identifier
# [06:42] <cyril_> krit: do we care if we have a different solution for both
# [06:42] <cyril_> ed: we could restrict the order in which you put children elements for fill and stroke
# [06:42] <cyril_> krit: you can have fill with multiple layers
# [06:43] <cyril_> TabAtkins: the child keyword does not allow that
# [06:43] <cyril_> krit: that's why it's not useful
# [06:43] <cyril_> TabAtkins: is that a huge deal if we restrict selectors to matching children
# [06:43] <cyril_> heycam: you'd still have to watch for class changes, ...
# [06:44] <cyril_> ... it's unlikely I'd be able to reuse the existing machinery for style changes
# [06:44] <cyril_> ... I'd like to see if Erik's model could work
# [06:45] <cyril_> ... it needs more thoughts
# [06:45] <cyril_> ed: do we expect people to use multiple fill and strokes
# [06:45] <cyril_> TabAtkins: we could solve the common case now (1 child per paint server) and expand later
# [06:45] <ed> s/do we expect people/do we expect that it will be common for people/
# [06:47] <cyril_> TabAtkins: fill="child child child" could be use the 3 first children to use for fill
# [06:47] <cyril_> heycam: we could use that for markers
# [06:47] <cyril_> ... but markers have zillions of properties
# [06:48] <cyril_> TabAtkins: I don't think we want to use paint order
# [06:49] <cyril_> ... the mental model isn't as intuitve
# [06:49] <cyril_> resolution: accept the 'child' keyword in all referencing properties
# [06:50] <cyril_> krit: do we define in it in the common spec ?
# [06:50] <cyril_> heycam: yes in the SVG 2 spec
# [06:51] <cyril_> ed: the order is we consume children for fill first and then for stroke
# [06:51] <cyril_> cyril_: what if the same paint server is used for fill and strok
# [06:51] <cyril_> TabAtkins: you have to repeat it
# [06:51] <cyril_> Tav: or give an id
# [06:51] <Tav> http://tavmjong.free.fr/SVG/PROPERTIES/index.html
# [06:51] <cyril_> Topic: Referencing properties
# [06:52] <cyril_> Tav: i've been working on the text part of svg
# [06:52] <cyril_> ... and one of the problems is that it references so many properties
# [06:52] <cyril_> ... the modules are in various stages of preparation
# [06:52] <cyril_> ... what do we allow to reference
# [06:53] <cyril_> ... for example writing modes redefines writing-mode a little bit differently
# [06:53] <cyril_> fantasai: text-decoration-fill would go in Level 4 of Text Decoration
# [06:54] <cyril_> krit: so you could put it in SVG
# [06:54] <cyril_> Tav: are we allowed to reference a WD ?
# [06:54] <cyril_> ChrisLilley: but you'll wait in CR
# [06:54] <cyril_> Tav: Shapes 2 is needed but in ED
# [06:55] <cyril_> astearns: but it's ready to be in WD
# [06:55] <cyril_> heycam: what's new ?
# [06:55] <cyril_> astearns: shape-margin, shape-inside, referencing svg shapes ...
# [06:56] <cyril_> ed: can we have a resolution to publish WD ?
# [06:56] * Quits: tantek (~tantek@public.cloak) (tantek)
# [06:56] <cyril_> fantasai: we probably have quorum for publishing
# [06:57] <cyril_> fantasai: adobe is ok with publishing, google is
# [06:57] <cyril_> dbaron: that seems fine
# [06:57] <cyril_> dino: 'im ok
# [06:58] <cyril_> resolved: CSS WG agrees to publish Shapes 2 as a FPWD
# [06:58] <cyril_> tav: I'm happy to have a agreement that I can reference those specs
# [06:59] <cyril_> fantasai: about baseline-shift
# [06:59] <cyril_> ... do you output it in the CSS form or SVG form ?
# [06:59] <cyril_> Tav: in the CSS form
# [06:59] <cyril_> heycam: I have a separate topic on that
# [07:00] <fantasai> Plan is to have a dominant-baseline property
# [07:00] <fantasai> and then a vertical-align property with longhand salignment-baselin and baseline-shift
# [07:01] <cyril_> Tav: how soon ?
# [07:01] <cyril_> fantasai: I can get you a very rough draft today
# [07:01] <cyril_> Tav: we need to do that in the SVG 2
# [07:01] * Quits: dino (~textual@public.cloak) ("My MacBook Pro has gone to sleep. ZZZzzz…")
# [07:01] <cyril_> heycam: you have a future model in mind, reduccing the number of properties by half, simplifying the model
# [07:02] <cyril_> ... in FF we implement only dominant-baseline
# [07:02] <cyril_> ... peopl have content that uses it to position text
# [07:03] <cyril_> heycam: webkit supports alignement baseline, dominant baseline and baseline shift
# [07:03] * TabAtkins has to leave for a bit, will be back in 20m or so.
# [07:03] <cyril_> ... the effect if you specify a-b and d-b is unclear
# [07:04] <cyril_> fantasai: the initial value of a-b should be auto and auto should look at the d-b property of the parent
# [07:04] <cyril_> dbaron: not a-b ?
# [07:04] <cyril_> heycam: b-shift has length + keywords: superscript ...
# [07:05] <cyril_> heycam: my overriding concenr is to make sure we just have what SVG needs without constraining your model
# [07:05] * dbaron waits for http://www.w3.org/TR/xsl/#area-alignment to load
# [07:05] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [07:05] <cyril_> ... if you're happy to write a minimal document that we can reference then we're fine
# [07:06] <cyril_> fantasai: I can have a document in a year
# [07:06] <cyril_> heycam: ok
# [07:07] <dbaron> there are some useful definitions in http://www.w3.org/TR/xsl/#vertical-align and http://www.w3.org/TR/xsl/#area-alignment
# [07:08] <cyril_> ... that has 4 properties instead of 3
# [07:08] <cyril_> heycam: the XSL properties were used at some point in the SVG spec and then tweaked
# [07:08] <cyril_> fantasai: what is in the SVG spec is what I might put in the CSS spec
# [07:10] <cyril_> (discussing new process)
# [07:12] <cyril_> heycam: the other part is what to do about the old writing-mode values and glyph orientation vertical stuff
# [07:12] <cyril_> ... fantasai seems to be of the opinion that there are interesting things even if not in the open web
# [07:12] * Joins: tantek (~tantek@public.cloak)
# [07:12] <cyril_> ... dirk showed some output of Photoshop for vertical text using writing mode TB
# [07:12] <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 ]
# [07:14] <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
# [07:14] <heycam> in writing modes spec, there are new keywords for writing-mode, and a text-orientation property for controlling glyph orientation
# [07:15] <cyril_> krit: glyph orientation horizontal and vertical have the same usage statistics
# [07:15] <cyril_> ... i would suggest we deprecate them but not remove them
# [07:15] <cyril_> heycam: I haven't seen bug reports about them, but I have about alignement-baseline
# [07:16] <cyril_> ChrisLilley: some people said that most fonts don't give that information
# [07:16] * Joins: tantek_ (~tantek@public.cloak)
# [07:19] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [07:19] * tantek_ is now known as tantek
# [07:22] <cyril_> heycam: I have enough information about the plan for those properties
# [07:22] <Tav> http://tavmjong.free.fr/SVG/TEXT_FLOWED/index.html
# [07:22] <cyril_> Topic: text in a shape
# [07:23] <cyril_> Tav: SVG 2 reintroduces text flow in a shape
# [07:23] <cyril_> ... the initial version 1.2 got supported only by Batik and Inkscape
# [07:24] <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.
# [07:26] <dbaron> fantasai: writing-mode has values like horizontal-tb and vertical-lr
# [07:26] <cyril_> fantasai: writing-mode has values that are horizontal-tb and vertical-lr and text-orientation: sideways-left, sideways-right
# [07:26] <dbaron> fantasai: text-orientation could change from sideways-left and sideways-left... could change to sideways-lr and sideways-rl
# [07:26] * Joins: glazou (~glazou@public.cloak)
# [07:26] <dbaron> heycam: why not sideways-tb etc.?
# [07:27] <dbaron> fantasai: text-orientation talks about orientation of glyphs -- where is top/bottom of line -- not where is start/end of line
# [07:27] * Quits: gregwhitworth_ (~gregwhitworth@public.cloak) ("Page closed")
# [07:27] <dbaron> fantasai: the correct text-orientation:sideways-* for horizontal scripts is the one that matches the writing-mode: vertical-*
# [07:28] <dbaron> heycam: question
# [07:28] <dbaron> fantasai: [diagram that's hard to minute because it's in vertical writing]
# [07:29] <dbaron> fantasai: Might be deployed content in Japan that relies on these things.
# [07:29] <cyril_> Tav: back to the text in shape topic
# [07:29] <liam> [ Tav -- http://www.w3.org/TR/xslfo20/#fo_extension-region and scroll up to figure 50 with the yellow hexagons ]
# [07:29] <cyril_> ... in 1.2T you could wrap into one box and another and another
# [07:29] <cyril_> ... could we retain that property ?
# [07:30] <cyril_> astearns: we've proposed several ways
# [07:30] <cyril_> ... Florian also proposed another method
# [07:30] <cyril_> Tav: I looked at regions and it seemed complicated for that
# [07:30] <cyril_> astearns: overflow fragments have to be siblings
# [07:30] <cyril_> ... not regions
# [07:31] <cyril_> ... I don't now what your requirements are
# [07:31] <cyril_> Tav: 3 references comma separated
# [07:31] <cyril_> heycam: in the old way, you had svg shapes in the document, child of some special flow document
# [07:31] <cyril_> ... and the text flows in then one by one, no automatic generation of shape
# [07:31] <cyril_> ... do you want that behavior ?
# [07:32] <cyril_> Tav: No, I don't want automatic generation of shapes
# [07:32] * Joins: Florian (~Florian@public.cloak)
# [07:32] <cyril_> astearns: and if it overflows ?
# [07:32] <cyril_> Tav: it goes nowhere
# [07:32] <cyril_> Rossen: you need regions the
# [07:32] <cyril_> astearns: the concepts are in the regions spec
# [07:33] <cyril_> Tav: a simple comma separated list of shapes would not work?
# [07:33] <cyril_> astearns: we did not want to add that syntax in shape-inside
# [07:33] <cyril_> ... that would need to be something for SVG to define
# [07:34] <cyril_> heycam: that goes on the text element
# [07:34] <cyril_> astearns: don't know if it needs to extend shape-inside or have a new shape-inside-list
# [07:35] * ed <text shape-inside="child">foobar<path .../></text>?
# [07:36] <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
# [07:37] <cyril_> Tav: I wanted to check the syntax
# [07:38] <cyril_> Rossen: the behavior in SVG 2 seems to combine 2 or 3 specs
# [07:38] <cyril_> Tav: the text doesn't flow in the 2 rect
# [07:38] <cyril_> Rossen: so you don't need regions
# [07:38] <cyril_> .... but you need exclusion
# [07:39] <cyril_> Tav: 2 separate text elements both shape-inside (different) but one has a shape-outside
# [07:39] <heycam> [this is pointing to the "An example of using 'shape-outside'" example currently in the spec]
# [07:39] <cyril_> astearns: shape-outside only apply to floats
# [07:39] <cyril_> Rossen: or regions
# [07:40] <cyril_> s/or regions/or exclusions/
# [07:40] <cyril_> astearns: you'd need wrap flow too
# [07:40] <cyril_> ... in CSS to get wrapping behavior you need floats or exclusions
# [07:41] <cyril_> ... it's adding one more property
# [07:41] <cyril_> ... it adds the ability to have the content overlapping or wrapping
# [07:42] <cyril_> Tav: I'm wondering if SVG needs that level of complexity
# [07:42] <cyril_> Rossen: but you are positioning with x and y
# [07:42] <cyril_> astearns: I think you need it
# [07:43] <cyril_> ed: have you considered having a child keyword for this as well to keep the shape insde the text
# [07:43] <cyril_> Tav: possible
# [07:43] <heycam> <text shape-inside="child">ABC DEF <circle .../></text>
# [07:43] <cyril_> ed: I don't think a rec is rendered currently in a text
# [07:44] <ed> s/rec/rect (or shape)/
# [07:44] <cyril_> Tav: and also having a text inside a rectangl
# [07:44] <cyril_> heycam: you think the syntax is more natural to have the text inside the rect
# [07:44] <cyril_> Tav: yes
# [07:47] * liam wonders how this fits in with SVG defs, if I want to do, shape-inside="#child"
# [07:47] * heycam would imagine it should work too
# [07:47] <AndreyR> Another topic form css agenda can we discuss issues? http://dev.w3.org/csswg/css-pseudo/#highlight-pseudos
# [07:49] <cyril_> Topic: FlexBox
# [07:49] <cyril_> fantasai: can we go to CR ?
# [07:49] <cyril_> Florian: what do we do about the order ?
# [07:49] <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
# [07:50] <cyril_> Florian: I'm not excited about opening new things
# [07:50] <cyril_> ... but the shorthand longhand thing made sense to me
# [07:50] <cyril_> fantasai: we don't have the person to discuss this
# [07:50] <cyril_> ... but I would like to publish things
# [07:51] <cyril_> Florian: I'm happy with publishing
# [07:51] <cyril_> Rossen: any objection ?
# [07:51] <cyril_> (silence)
# [07:51] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [07:51] <cyril_> dbaron: are there any big things that don't match what it used to do ?
# [07:51] <cyril_> fantasai: no
# [07:52] <cyril_> dbaron: sounds good then
# [07:52] <cyril_> resolved: Publish flexbox CR under the new process
# [07:53] <AndreyR> Topic http://dev.w3.org/csswg/css-pseudo/#highlight-pseudos [17:18] <cyril_> Topic: FlexBox
# [07:53] <cyril_> Topic: ::selection
# [07:53] * Joins: Florian (~Florian@public.cloak)
# [07:53] <cyril_> fantasai: there is an issue in the spec on how to select inactive selections
# [07:53] <cyril_> ... do we want to add another pseudo for that ?
# [07:53] <cyril_> ... I don't think that's a good idea
# [07:54] <cyril_> Florian: inactive selection ?
# [07:54] <cyril_> fantasai: select and then focus another window
# [07:54] <cyril_> Florian: that does not match selection, but nothing selects it
# [07:55] <cyril_> resolved: add ::inactive-selection to Pseudo Element Level 4
# [07:56] <ed> RRSAgent, make minutes
# [07:56] <RRSAgent> I have made the request to generate http://www.w3.org/2015/02/10-fx-minutes.html ed
# [07:59] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [08:00] * liam guessing a break? hmm, maybe adjournment
# [08:00] <ed> -- meeting adjourned --
# [08:00] * Joins: Florian (~Florian@public.cloak)
# [08:00] * liam thanks :)
# [08:02] <dbaron> next CSS teleconference is in 2 weeks and 10 hours
# [08:02] * heycam is now known as heycam|away
# [08:04] * ed will send out the minutes to public-fx
# [08:05] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [08:09] * Quits: glazou (~glazou@public.cloak) (glazou)
# [08:09] <krit> fantasai: http://wiki.apache.org/xmlgraphics-fop/LineLayout/AlignmentHandling
# [08:10] * Quits: kwkbtr (~kwkbtr@public.cloak) (Client closed connection)
# [08:11] <krit> fantasai: http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/svg/SVGTextLayoutEngineBaseline.cpp
# [08:12] * Quits: xidorn (~upsuper@public.cloak) (Client closed connection)
# [08:13] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [08:13] <liam> krit, yeah i don't know if fop supports otf these days
# [08:14] <liam> at one point i had a bunch of opentype feature support stuff in the FO draft but I'm not sure it made it into what we published for 2.0, and it wasn't compatible with john dagget's work on css fonts, so I doubt it got implemented
# [08:14] <liam> (jt predated the css-font otf stuff by a few months i tihnk)
# [08:15] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [08:15] <liam> hmm no
# [08:18] * Quits: cyril_ (~cyril@public.cloak) (Ping timeout: 180 seconds)
# [08:20] * Quits: roc (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [08:24] * Quits: Tav (~tbah@public.cloak) (Ping timeout: 180 seconds)
# [08:24] * Quits: hyojin (~hyojin@public.cloak) ("Leaving")
# [08:27] * Rossen is now known as Rossen_away
# [08:29] * Quits: tantek (~tantek@public.cloak) (tantek)
# [08:29] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [08:35] * Quits: ChrisLilley (clilley@public.cloak) (Ping timeout: 180 seconds)
# [08:36] * Quits: AndreyR (~AndreyR@public.cloak) (Ping timeout: 180 seconds)
# [08:43] * Joins: jun (~jun@public.cloak)
# [08:45] * Quits: jun (~jun@public.cloak) (jun)
# [08:45] * Joins: jun (~jun@public.cloak)
# [08:46] * Quits: jun (~jun@public.cloak) (jun)
# [08:47] * Joins: jun (~jun@public.cloak)
# [08:52] * Quits: jun (~jun@public.cloak) (jun)
# [10:49] * Quits: jet (~uid49872@public.cloak) ("Connection closed for inactivity")
# [11:05] * Joins: Florian (~Florian@public.cloak)
# [11:12] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [11:39] * Joins: jun (~jun@public.cloak)
# [12:20] * Quits: jun (~jun@public.cloak) (jun)
# [13:10] * Joins: Tav (~tbah@public.cloak)
# [13:15] * Joins: Florian (~Florian@public.cloak)
# [13:29] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [14:18] * Joins: ChrisLilley (clilley@public.cloak)
# [14:18] * Quits: ChrisLilley (clilley@public.cloak) ("Client combusted")
# [14:48] <krit> liam: Elika is updating the spec at the moment. I just send her all I have. :)
# [16:30] * Joins: Florian (~Florian@public.cloak)
# [16:37] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [17:56] * Quits: RRSAgent (rrsagent@public.cloak) (Request too long)
# [18:28] * leaverou is now known as leaverou_away
# [18:50] * leaverou_away is now known as leaverou
# [19:31] * leaverou is now known as leaverou_away
# [19:32] * leaverou_away is now known as leaverou
# [20:25] <liam> krit, i see
# [22:04] * Joins: Florian (~Florian@public.cloak)
# [22:26] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [22:29] * Joins: Florian (~Florian@public.cloak)
# [22:34] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [23:02] * Quits: Tav (~tbah@public.cloak) (Ping timeout: 180 seconds)
# [23:23] * Joins: tantek (~tantek@public.cloak)
# [23:26] * heycam|away is now known as heycam
# [23:29] * Joins: jet (~uid49872@public.cloak)
# [23:30] * Joins: stakagi (~stakagi@public.cloak)
# [23:33] * Joins: Tav (~tbah@public.cloak)
# [23:36] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [23:38] * Joins: tantek (~tantek@public.cloak)
# [23:48] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [23:55] * Joins: tantek (~tantek@public.cloak)
# Session Close: Thu Feb 12 00:00:00 2015

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn