22:08:45 <RRSAgent> RRSAgent has joined #fx
22:08:45 <RRSAgent> logging to http://www.w3.org/2015/02/10-fx-irc
22:08:54 <ed> RRSAgent, stay
22:11:22 <dbaron> dbaron has joined #fx
22:11:53 <ed> RRSAgent, make logs public
22:12:06 <ed> RRSAgent, this meeting spans midnight
22:12:58 <ed> Meeting: FXTF F2F, Sydney 2015
22:13:04 <ed> Chair: ed
22:14:25 <glazou> glazou has joined #fx
22:14:30 <liam> liam has joined #fx
22:14:39 <iank> iank has joined #fx
22:14:41 <Zakim> Zakim has joined #fx
22:14:56 <cyril> cyril has joined #fx
22:15:03 <glazou> Zakim, this meetings spans over midnight
22:15:03 <Zakim> I don't understand 'this meetings spans over midnight', glazou
22:15:24 <cyril> Zakim, this meeting spans over midnight
22:15:25 <Zakim> I don't understand 'this meeting spans over midnight', cyril
22:15:33 <nikos> nikos has joined #fx
22:15:43 <dino> dino has joined #fx
22:16:09 <cyril> RRSAgent, this meeting spans over midnight
22:16:09 <RRSAgent> I'm logging. I don't understand 'this meeting spans over midnight', cyril.  Try /msg RRSAgent help
22:16:19 <dbaron> RRSAgent, this meeting spans midnight
22:16:29 <heycam> RRSAgent, this is FXTF
22:16:29 <RRSAgent> I'm logging. I don't understand 'this is FXTF', heycam.  Try /msg RRSAgent help
22:16:43 <heycam> ScribeNick: heycam
22:16:44 <heycam> Scribe: Cameron
22:16:51 <plinss> zakim, this is fxtf
22:16:51 <Zakim> sorry, plinss, I do not see a conference named 'fxtf' in progress or scheduled at this time
22:17:18 <ed> Agenda: https://wiki.csswg.org/planning/sydney-2015 (Wednesday)
22:17:55 <heycam> Topic: css3-ui
22:18:07 <kwkbtr> kwkbtr has joined #fx
22:18:19 <gregwhitworth> gregwhitworth has joined #fx
22:18:26 <tantek> tantek has joined #fx
22:18:35 <Florian> Florian has joined #fx
22:22:54 <heycam> https://lists.w3.org/Archives/Public/www-style/2015Feb/0243.html
22:22:58 <tantek> hello
22:23:00 <tantek> https://lists.w3.org/Archives/Public/www-style/2015Feb/0243.html
22:23:15 <tantek> [css3-ui] box-sizing and replaced element intrinsic width and/or ratios
22:23:36 <tantek> regarding this issue: https://wiki.csswg.org/spec/css3-ui#issue-69
22:23:51 <heycam> tantek: the first email I posted a couple of test cases
22:24:16 <heycam> ... each has an HTML file and three SVG elements
22:24:33 <heycam> ... the first one we should bring up is the replaced element test case
22:24:34 <rbyers> rbyers has joined #fx
22:24:51 <heycam> ... it shows what happens in three different cases of embedding SVG as an image that has intrinsic width and ratio, or just intrinsic width, or just intrinsic ratio
22:24:58 <heycam> ... and what happens when you apply the max-height property to it
22:25:06 <heycam> ... shows interaction of CSS 2.1 width computations and embedding replaced SVG element
22:25:23 <heycam> ... I want to start with this example because it's all stuff that should "just work" across browsers, btu we found differences that merit questions
22:25:29 <heycam> ... before we decide what box-sizing should do in these cases
22:25:40 <roc> roc has joined #fx
22:25:41 <heycam> [florian projects replaced-element-001.html]
22:25:49 <Tav> Tav has joined #fx
22:26:00 <stakagi> stakagi has joined #fx
22:26:55 <stakagi> stakagi has joined #fx
22:26:57 <heycam> tantek: in doing these tests we didn't find any differences between Blink and Safari
22:27:27 <heycam> ... there are some interesting things going on here
22:27:28 <dbaron> dbaron has joined #fx
22:27:34 <heycam> ... I put the style rules that are taking place at the top
22:27:39 <heycam> ... that apply to each SVG element
22:27:46 <heycam> ... then the SVG markup inline so you can see what the source is
22:27:57 <heycam> ... my understanding is that the top row should all be yellow square
22:28:00 <heycam> ... 150x150 px
22:28:04 <heycam> ... it looks like IE is doing the wrong thing there
22:28:05 <murakami_> murakami_ has joined #fx
22:28:08 <heycam> ... by not maintaining the aspect ratio
22:28:11 <heycam> ... that's in the SVG file
22:28:18 <heycam> ... first, I want to verify that that's correct and that it's a bug in IE
22:28:26 <heycam> fantasai: so the specified width is 100px?
22:28:29 <heycam> tantek: no the intrinsic width is
22:28:35 <heycam> fantasai: and the specified width is not specified?
22:28:39 <heycam> tantek: correct
22:28:49 <heycam> dbaron: and it has a viewBox such that it has an intrisic ratio of 1:1
22:29:04 <heycam> Florian: and there is max-height: 100px that shouldn't take effect
22:29:10 <heycam> ... but if you look at IE it seems to be doing something
22:29:17 <heycam> ... both IE and safari are doing strange things on the bottom
22:29:51 <heycam> tantek: I want to check with SVG people that these cases are buggy in the browsers
22:30:00 <tantek> https://lists.w3.org/Archives/Public/www-style/2015Feb/0243.html
22:30:14 <SimonSapin> SimonSapin has joined #fx
22:30:57 <heycam> gregwhitworth: in Edge the top yellow one is fixed, the bottom one is the same as Firefox/Presto
22:31:01 <jun> jun has joined #fx
22:31:05 <heycam> Florian: so that confirms the IE cases I'm looking at are bugs
22:31:11 <heycam> ... IE11
22:31:20 <AndreyR_> AndreyR_ has joined #fx
22:31:27 <heycam> tantek: so latest IE11 and latest Safari are buggy in handling intrinsic ratio, but not intrinsic width/height
22:31:41 <heycam> ... and Chrome does the same as Safari, so Blink/WebKit must be the same
22:31:45 <heycam> dbaron: Safari is buggy on the third case
22:31:54 <fantasai> fantasai has joined #fx
22:32:06 <xidorn> xidorn has joined #fx
22:32:39 <smfr> smfr has joined #fx
22:32:41 <heycam> heycam: we had a big discussion about SVG sizing last year at a F2F
22:32:54 <heycam> ... I don't remember the details except that we resolved on Firefox's behaviour modulo some corner cases
22:33:27 <heycam> tantek: so Edge has these fixed, and I'm hoping that WebKit/Blink can fix the third sub-test
22:33:54 <heycam> ... so this isn't the actual issue I want to discuss; just want to get a baseline about which behaviour is correct
22:34:08 <heycam> ed: I think the behaviour on the left side is what we want
22:34:56 <heycam> krit: people who are very familiar with this topic are not in this room so I would like to consult them
22:35:58 <heycam> ACTION: Dirk to confirm that the Firefox/Presto behaviour of this SVG sizing test is correct and get back to Tantek
22:35:59 <trackbot> Created ACTION-87 - Confirm that the firefox/presto behaviour of this svg sizing test is correct and get back to tantek [on Dirk Schulze - due 2015-02-17].
22:36:28 <shane> shane has joined #fx
22:36:33 <heycam> tantek: so we'll switch to box-sizing-replaced-element-001.html
22:36:53 <tantek> second test here: https://lists.w3.org/Archives/Public/www-style/2015Feb/0243.html
22:36:53 <tantek> file name box-sizing-replaced-element-001.html
22:37:04 <heycam> tantek: what the box-sizing property allows you to do is change what width/height properties do
22:37:11 <heycam> ... you can make them include the borders and padding of the element
22:37:21 <heycam> ... so if you want to figure out the content width you would subtract the border/padding
22:37:30 <heycam> ... any question about box-sizing:border-box?
22:37:38 <heycam> ... (default behaviour is content-box)
22:37:54 <tantek> http://dev.w3.org/csswg/css-ui-3/#propdef-box-sizing
22:38:00 <tantek> tantek has left #fx
22:38:06 <tantek> tantek has joined #fx
22:38:13 <tantek> hello?
22:38:37 <heycam> tantek: in this one, because box-sizing is set to border-box, now the 40px solid transparent border kicks in, and cuts out from the max-height
22:38:49 <heycam> Florian: we still have an SVG file with an intrinsic width of 100 and a viewBox ratio of 1:1
22:38:55 <heycam> tantek: identical SVG files to the previous test
22:39:14 <heycam> ... the three subtests are in the same order as the previous test
22:39:15 <jet|aus> jet|aus has joined #fx
22:39:23 <heycam> dbaron: I think the firefox behaviour on the second subtest is clearly buggy
22:39:41 <heycam> ... I think we're applying to the box-sizing to the width that is coming from inside the SVG, which we should not be doing
22:39:50 <heycam> fantasai: are these embedded cases?
22:39:52 <heycam> Florian: SVG in <img>
22:40:10 <heycam> ... as far as we can tell Presto is doing the right thing here
22:40:19 <heycam> tantek: we think that is the desired result, so we want to check
22:40:21 <heycam> dbaron: I agree
22:40:29 <heycam> fantasai: should be equivalent to max-height:110px?
22:40:31 <heycam> Florian: max-height:70px
22:40:46 <heycam> tantek: on the first row we have IE and Safari agreeing on the wrong thing
22:40:57 <heycam> ... so we just want to confirm our assumption on which is right/wrong
22:41:08 <heycam> fantasai: one thing making it more confusing is that the content box height is different
22:41:20 <heycam> ... so if you put border:25px max-height:200px you should get the same result as the previous test
22:41:31 <heycam> ... the boundary of the width of the SVG is 100px, in the prev test you were above that, in this test you're below that
22:41:35 <heycam> ... so you're triggering different cases
22:41:47 <heycam> ... I think you should test in all cases above the trigger point, or all below the trigger point
22:41:57 <heycam> ... the behaviour differenes might be due to something other than max-height
22:42:19 <heycam> tantek: so we changed just one property to see what happens
22:42:26 <heycam> fantasai: the numbers you picked made it change more than one thing
22:42:30 <heycam> tantek: that was unintentional
22:42:38 <ed> s/ed: I think the behaviour on the left side is what we want/ed: I think the behaviour on the left side (Firefox and Presto) is what we want/
22:42:58 <heycam> gregwhitworth: Edge is matching Firefox here
22:43:41 <heycam> tantek: change the border to 25px max-height to 200px
22:43:47 <heycam> s/tantek/fantasai/
22:43:56 <heycam> fantasai: we should also test this situation, btw
22:44:11 <heycam> gregwhitworth: chrome is doing the same as firefox on my windows laptop
22:44:22 <heycam> ... v40
22:44:39 <heycam> ... so this may end up being an issue with them talking to our compositor
22:44:53 <heycam> ... right now on windows, firefox / edge ie / chrome have interop
22:44:58 <heycam> ... on the second case
22:45:04 <dbaron> Filed Gecko bug https://bugzilla.mozilla.org/show_bug.cgi?id=1131812
22:45:40 <heycam> dbaron: in the second case I believe we have some code that extracts a width that's specified embedded in an SVG, and applies that to the sizing outer of the img element
22:45:48 <heycam> ... because that's kind of how the sizing algorithm works
22:45:59 <heycam> ... so we're taking the width from the SVG, applying it to the img element, then applying box-sizing
22:46:09 <heycam> Florian: so doing the same thing as if the SVG was embedded inline in the HTML?
22:46:10 <heycam> dbaron: yes
22:46:34 <heycam> Florian: if that were the case the box would be 20px wide wouldn't it?
22:46:34 <heycam> ... and it looks more than that
22:46:41 <heycam> dbaron: yeah...
22:46:53 <tantek> new test with fantasai suggested changes: https://lists.w3.org/Archives/Public/www-style/2015Feb/0245.html
22:46:54 <gregwhitworth> Windows SVG Test: http://imgur.com/xbHMI0r
22:47:04 <heycam> dbaron: OK I'm not sure what's happening then. but I think it's buggy.
22:47:16 <heycam> tantek: I just sent the updated test that fantasai asked for to www-style
22:47:27 <tantek> file name box-sizing-replaced-element-002.html
22:48:03 <heycam> dbaron: this would be a lot easier if you emailed the individual files as attachments of the one email
22:49:15 <heycam> tantek: so now this test has fewer effective changes as -001.htm
22:50:16 <heycam> fantasai: so this test -002 now looks identical to the first thing we looked at
22:50:29 <heycam> gregwhitworth: IE edge matches Firefox/Presto here
22:50:40 <heycam> Florian: which is the same as Safari except for the third case
22:50:47 <heycam> ... so it's just a bug in Safari
22:51:03 <heycam> tantek: which is why we wanted to show you without box-sizing, to show the WebKit's handling of intrinsic ratio is buggy
22:52:00 <heycam> tantek: if we can agree here what behaviour we want florian and I will specify it
22:52:16 <heycam> Florian: once box-sizing gets involved, if we don't apply min/max width/height it's not explicit, but still not ambiguous
22:52:26 <heycam> ... but with min/max-width/height, we need to specify something
22:52:32 <heycam> ... I think Presto has reasonable behaviour
22:53:02 <heycam> krit: this is something we should clarify with SVG the correct behaviour
22:53:05 <heycam> Florian: what is missing on the SVG side?
22:53:16 <heycam> krit: at least consensus on how viewBox etc. should operate on an SVG in <img>
22:53:33 <heycam> Florian: is there anything other than SVG that can give an intrinsic width, ratio, but no height?
22:53:58 <heycam> Florian: the spec says if you have an intrinsic width, do this. if you have width and ratio, do this. ...
22:54:04 <heycam> tantek: CSS has explicit clauses for each of these cases
22:54:17 <heycam> krit: this is with intrisic width and ratio, but not intrinsic height?
22:54:18 <heycam> Florian: yes
22:54:24 <heycam> ... we haven't got to intrinsic height but no width yet
22:54:38 <heycam> krit: ok then the left two browsers are right
22:55:01 <heycam> cyril: in the cases where the square is a rectangle and not a square, do you know if there's a bug in the rendering of the SVG and the aspect ratio is not preserved...
22:55:17 <heycam> ... and the box is filled with the SVG content?
22:55:33 <heycam> dino: for all three we need a circle in the SVG to see whether the bottom one is being clipped or stretched
22:56:02 <heycam> Florian: so can we use something other than SVG for testing here?
22:56:03 <heycam> tantek: no
22:56:19 <heycam> dino: as Dirk is saying, it's not well defined. it also has its own rules for preserving aspect ratio internally inside its viewBox.
22:56:40 <heycam> tantek: we're trying to look at this from the point of view that implementations are converging, so we'd like to follow them
22:56:47 <heycam> dbaron: I think this is well defined now
22:56:49 <heycam> tantek: in SVG?
22:57:02 <heycam> fantasai: I remember the SVG WG saying that it's totally clear, or that they would fix it
22:57:09 <heycam> ... so either that didn't happen or someone's confused
22:57:16 <heycam> krit: in this case we also didn't discuss object-fit
22:57:22 <heycam> Florian: that's not involved yet. but we will discuss that later.
22:57:39 <heycam> krit: that is the case for inline SVG. for <img> we haven't had the discussion yet.
22:57:58 <heycam> ... we likely should have the same rules for inline and in <img>
22:58:10 <heycam> Florian: the way they start interacting with CSS is different
22:58:19 <heycam> tantek: the width attribute in inline is not intrinsic but specified
22:58:25 <heycam> ... so that's very different for these sizing computations
22:59:03 <fantasai> width/height in an inline SVG is both specified and intrinsic size
22:59:22 <fantasai> SVG specifies that it's the intrinsic size, and CSS specifies that it's the specified style
23:00:08 <Tav> http://tavmjong.free.fr/SVG/SCHILLER/html
23:00:34 <heycam> Tav: these are some tests I made from a few years ago, with SVG sizing in img, iframe, etc.
23:01:51 <heycam> dbaron: what are we trying to accomplish right now?
23:02:29 <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.
23:02:35 <heycam> ... if none of the browsers is doing the right then, then...
23:02:43 <heycam> dbaron: what are the questions about how to integrate box-sizing?
23:02:50 <heycam> Florian: as long as you don't involve max-height/width, it's easy
23:03:05 <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
23:03:15 <heycam> dbaron: I think that algorithm should be interpreted as working on content box sizes
23:03:23 <hyojin_> hyojin_ has joined #fx
23:03:29 <heycam> ... there might be other implementation bugs that are worth discussing separately
23:03:47 <heycam> ... I think the box-sizing spec update should be done because that's how it should work
23:04:09 <heycam> fantasai: is there any question in what you want to specify?
23:04:28 <heycam> Florian: unless someone strongly believes a non-Presto behaviour is right, no
23:04:50 <heycam> fantasai: that's fine
23:04:56 <heycam> tantek: we didn't expect this many bugs :-)
23:05:03 <heycam> dbaron: the SVG sizing stuff is pretty recently specced
23:06:48 <TabAtkins> Just found out the <iframe src=foo.svg> sizes itself to the SVG's intrinsic dimensions, rather than 300x150 like the spec says.
23:07:00 <TabAtkins> WTF explicitly changing sizing rules without telling the WG about it.
23:07:06 <TabAtkins> Sorry, *in Safari*.
23:07:17 <TabAtkins> dino: ^^^ ???
23:07:36 <heycam> gregwhitworth: on windows, the very first test is similarly buggy in firefox/presto/IE
23:07:55 <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
23:08:03 <fantasai> TabAtkins: Why do you think the spec says to make it 300x150?
23:08:12 <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, ...
23:08:16 <heycam> Florian: there is no constraint on the width
23:08:27 <cyril> email sent with updated svg tests (including a circle), please consider the second email (the first one had a wrong radius value)
23:08:31 <heycam> ... in the height dimension it shrinks down to 70
23:08:37 <heycam> tantek: there's no intrinsic ratio, so they're computed separately
23:08:37 <TabAtkins> fantasai: Because the spec doesn't specify where to take dimensions from for <iframe>?
23:08:44 <fantasai> It's a replaced element
23:08:46 <cyril> https://lists.w3.org/Archives/Public/www-style/2015Feb/0247.html
23:08:51 <fantasai> Just like an image
23:08:54 <heycam> Florian: this purple subtest has no intrinsic ratio
23:09:06 <heycam> ed: do you have enough to go on here?
23:09:27 <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.
23:10:14 <hober> fantasai++
23:10:19 <heycam> tantek: firefox sets the width to 47px, which is very odd
23:10:58 <heycam> gregwhitworth: since I don't know about SVG I'm completely ok with this
23:11:05 <heycam> dbaron: the weird Firefox behaviour is not related to box-sizing
23:11:21 <heycam> ... if I remove the box-sizing, remove the max-height, change the border, I get the same output
23:11:43 <heycam> dbaron: this might be coming from default sizing not being 300x150, for SVG
23:12:10 <heycam> dbaron: if you work through that long list of rules, the way max-height applies doesnt always preserve the intrinsic ratio
23:12:15 <heycam> Florian: on the second one there's no intrinsic ratio
23:12:19 <heycam> dbaron: or doesn't always preserve the things you want
23:12:29 <heycam> ... if I change the max-height to height, you get the expected behaviour
23:12:42 <heycam> ... I think therei s something in the spec rules that gives the 47px result
23:12:54 <heycam> fantasai: I think the only weird cases are when you're balancing conflicting requirements
23:13:06 <heycam> Florian: but in this case we're not over constrained
23:14:22 <heycam> fantasai: let's resolve the behaviour on we want, not on "what Presto does"
23:14:30 <heycam> SimonSapin: is this looking at CSS 2.1?
23:14:35 <heycam> tantek: yes, plus box-sizing
23:15:08 <SimonSapin> (as opposed to the CSS Images module)
23:15:35 <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).
23:15:50 <tantek> https://wiki.csswg.org/spec/css3-ui#issue-69
23:16:14 <heycam> Topic: Interaction between overflow, positioning and filters
23:16:25 <roc> http://fiddle.jshell.net/mkud1Lnm/1/
23:16:51 <heycam> roc: this is basically a spec issue, as to what should be rendered
23:16:55 <heycam> ... right now specs don't really say
23:17:01 <heycam> ... and it's tricky to fix, there's no obvious way to fix it
23:17:05 <fantasai> CSS2.1: “This property specifies the content width of boxes. ”
23:17:19 <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
23:17:23 <heycam> ... it has a filter on it, in this case a blur
23:17:25 <fantasai> CSS2.1 is very clear that it's talking about content widths.
23:17:26 <heycam> ... and a couple of elements inside
23:17:34 <dbaron> FWIW, I can explain where the 47px comes from
23:17:35 <heycam> ... one of the elements is position:fixed (but also happens with position:absolute)
23:17:47 <heycam> ... the positioned div is not supposed to be clipped by the element that has overflow:hidden
23:18:00 <heycam> ... but it's in a filter and some of the content of the filtered image should be clipped, while some shouldn't
23:18:04 <heycam> ... it's really unclear how to render this example
23:18:12 <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
23:18:15 <fantasai> dbaron, go ahead, I'm very curious :)
23:18:16 <heycam> ... if you bring it up in Chrome or Firefox, you get a rendering where both of the elments are clipped
23:18:27 <heycam> ... in particular the yellow one is clipped to the overflow:hidden element, but technically it shouldn't be
23:18:39 <cyril_> cyril_ has joined #fx
23:18:41 <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
23:18:46 <heycam> ... it's unclear what the visual result should be
23:19:05 <heycam> ... there's no way to preserve the behaviour that one of these elements is clipped, one is not, but they're filtered together
23:19:06 <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.
23:19:21 <heycam> ... the problem does not arise for opacity, that's because opacity commutes with clipping
23:19:30 <heycam> ... if you clip then opacity, it's the same as opacity then clip
23:19:32 <heycam> ... not true for general filters
23:19:45 <heycam> ... because opacity commutes, you can push it down, and get the results you'd expect
23:19:49 <heycam> ... but with filters you can't
23:20:09 <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
23:20:13 <heycam> ... the question is what to spec
23:20:25 <heycam> ... try to explain that behaviour, or we introduce some restrictions on the interactions between filters and overflow:hidden and positioning
23:20:28 <heycam> ... so that it's well defined
23:20:34 <heycam> ... is the problem clear?
23:21:09 <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
23:21:59 <Florian> Florian has joined #fx
23:22:09 <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
23:22:24 <heycam> ... that's option #0 (I didn't put that in my email)
23:22:37 <heycam> ... option #1 from my email is that filter is like transform, becomes a containing block for positioned elements
23:22:40 <heycam> ... so they can't escape from the filter
23:22:49 <heycam> ... so the current definition of overflow:hidden would mean it applies to them
23:23:02 <heycam> ... option #2 is you could say the filter doesn't affect the positioned descendant, it can escape the filter
23:23:16 <heycam> ... so filters only apply to things for which the filtered element is the containing block
23:23:20 <heycam> dino: so the yellow element would not be filtered
23:23:26 <heycam> roc: yes
23:23:52 <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
23:24:55 <heycam> dino: simon prefers filtering winning over the overflow
23:25:02 <heycam> ... so stacking context is more important overflow
23:25:11 <heycam> ... so not the choice where yellow div is not filtered
23:25:14 <heycam> roc: I'm for option #1
23:25:28 <heycam> ... if we can make filters a container for positioned descendants
23:25:33 <heycam> ... there's some web compat risk, not a whole lot
23:26:29 <heycam> heycam: would you often want positioned things inside filtered elements? maybe not.
23:26:37 <heycam> dino: simon says sucks opacity and filters are not treated the same
23:26:48 <heycam> roc: it does kind of suck
23:26:54 <heycam> ... I don't have any alternative to that
23:27:00 <heycam> dino: with blending, we don't have the same issue?
23:27:05 <heycam> roc: no, because blending commutes with clipping
23:27:17 <heycam> ... if you have an opacity:0 pixel, blending can't turn that into something that is not opacity:0
23:27:53 <heycam> krit: not yet
23:28:00 <heycam> roc: if we add all the porter duff modes then it would be an issue
23:28:06 <heycam> ... we could change blend modes now, to force the same behaviour
23:28:10 <heycam> ... that would guard us in the future
23:28:16 <heycam> Tav: option #1 makes sense to me
23:28:31 <heycam> dino: I agree with making blending operate the same, and doing that now
23:29:11 <heycam> roc: we've been talking about adding an escape hatch for transforms
23:29:17 <heycam> ... so transforms are not a positioning container
23:29:28 <heycam> ... if we do that we could have keyword on transforms
23:29:39 <heycam> krit: all blend modes we implement use src-over compositing
23:30:16 <heycam> krit: I don't think we want to combine blend modes with other compositing modes
23:30:39 <heycam> roc: if we introduce other compositing modes, will it be in mix-blend-mode or a different property?
23:30:42 <heycam> nikos: suggested to be in a separate property
23:30:54 <heycam> roc: in that case we don't need to add restrictions for mix-blend-mode now
23:31:25 <heycam> ... so that new property would need to create a container for positioned elements
23:31:59 <heycam> ... so we won't change mix-blend-mode behaviour, but will do it for filters
23:32:21 <heycam> heycam: you could restrict this filter behaviour for only some predefined filter keywords
23:32:29 <heycam> roc: I don't feel like we want to do somethign taht complicated
23:32:40 <smfr> heycam: ick, what if you animate between them?
23:33:05 <heycam>   smfr indeed, the position of elements could change when you change the filter behaviour
23:33:39 <heycam> RESOLUTION: non-none values of filter induce a containing block for all positioned descendants
23:34:01 <heycam> ACTION: Erik to make non-none values of filter induce a containing block for all positioned descendants
23:34:02 <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].
23:34:15 <heycam> -- 15 min break, back at 10:49 --
23:37:34 <hyojin__> hyojin__ has joined #fx
23:49:20 <sgalineau> sgalineau has joined #fx
23:57:51 <smfr> sgalineau: it’s break time
23:58:00 <smfr> sgalineau: scones and cream
23:58:01 <sgalineau> doh. carry on :)
00:00:20 <sgalineau> smfr: scones are very important.
00:00:48 <smfr> background: jam 100% 100%, cream 200% 200%;
00:01:00 <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
00:02:32 <sgalineau> you had me at boutique beer
00:03:09 <sgalineau> smfr: overflow: visible?
00:03:42 <liam> sgalineau: overflow: burp
00:03:50 <hober> fx
00:03:53 <liam> wait, is that for scones or beer? :)
00:06:38 <stakagi> stakagi has joined #fx
00:07:08 <shane> beer scone spiders - why not have both?
00:07:12 <heycam> Topic: Canceling and interrupting transitions
00:07:16 <heycam> https://lists.w3.org/Archives/Public/www-style/2014Dec/0150.html
00:08:28 <kwkbtr> kwkbtr has joined #fx
00:08:42 <jun> jun has joined #fx
00:08:54 <heycam> dbaron: let's postpone until after lunch
00:09:32 <heycam> Topic: Filter Effects CR
00:10:11 <Rossen> Rossen has joined #fx
00:10:25 <krit> https://github.com/w3c/fxtf-drafts/blob/master/filters/issues-lc-2015.html
00:10:34 <heycam> krit: this is the disposition of comments document
00:11:22 <plinss> http://dev.w3.org/fxtf/filters/issues-lc-2015.html
00:11:46 <heycam> krit: we have some open issues still in the spec
00:11:53 <heycam> ... one of them is error handling in general with filter effects
00:12:16 <krit> http://fiddle.jshell.net/ev10jtmp/3/
00:12:34 <heycam> ... here's a test for error handling
00:12:43 <heycam> ... the filter property can take a url, which references a <filter> element
00:12:48 <heycam> ... what happens if the url is invalid
00:12:57 <dbaron> or alternatively http://drafts.fxtf.org/filters/issues-lc-2015.html
00:13:00 <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
00:13:03 <heycam> ... that's standard CSS behaviour
00:13:16 <heycam> ... what if it's valid syntax but does not reference a filter, or the ID doesn't exist
00:13:21 <heycam> ... behaviour is different between browsers
00:13:27 <heycam> ... SVG 1.1 said that the filtered element disappears
00:13:39 <heycam> ... there were objections that this might not be the preferred behaviour
00:13:56 <heycam> ... firefox does what SVG 1.1 says, so if you apply filter:url(#badID) then it makes the object disappear
00:14:03 <heycam> ... other browsers ignore the filter
00:14:34 <heycam> heycam: I think Firefox should display the element normally, i.e. ignore the filter
00:15:08 <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
00:15:39 <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
00:15:44 <heycam> ... e.g. <feGaussianBlur in="invalid">
00:16:01 <heycam> ... SVG 1.1 makes the whole filtered element disappear
00:16:06 <heycam> ... WebKit does that, as Firefox does
00:16:10 <heycam> ... Blink does something different
00:16:51 <heycam> krit: or you could reference the previous filter effect (i.e. default in="" value) or default SourceGraphic
00:17:02 <heycam> dino: or make the primitive use transparent black as input
00:17:04 <heycam> roc: yes
00:17:18 <heycam> krit: if you make a mistake in the filter chain, it's not going to give you a result you want
00:17:56 <heycam> krit: if you reference a filter input that doesn't exist, that could kill the whole processing of the filter
00:18:05 <liam> [having the element not rendered means you can't easily right-click on it and "inspect" to debug the problem]
00:18:54 <heycam> krit: I don't think we should just make transparent black for that primitive's input
00:18:57 <heycam> Tav: I agree with that
00:19:12 <heycam> nikos: making just one primitive's input transparent black can help you understand where the error is
00:19:34 <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
00:19:39 <heycam> krit: which would be the previous filter effect
00:19:56 <heycam> heycam: I'm fine with disabling the filter
00:20:18 <heycam> RESOLUTION: If a filter primitive references an invalid input, then the whole filter is disabled and the element is rendered normally.
00:20:37 <krit> http://dev.w3.org/fxtf/filters/issues-lc-2015.html#issue-6
00:20:38 <heycam> krit: next, issue #6
00:21:02 <heycam> ... if someone uses currentColor in feColorMatrix, what is it?
00:22:50 <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
00:23:05 <heycam> Tav: we have context-fill
00:23:36 <heycam> ... we decided to make that work in all referencing elements, like filter, pattern, etc.
00:24:09 <heycam> krit: I'd like to delay putting anything in the filters spec for this
00:24:14 <heycam> ed: I think that's fine with me
00:24:35 <heycam> heycam: happy to do that later
00:25:08 <heycam> RESOLUTION: Defer context-fill usage in Filter-specific properties until level 2 of Filters.
00:25:11 <krit> file:///Users/dschulze/Documents/fxtf-drafts/filters/issues-lc-2015.html#issue-8
00:25:18 <heycam> ... next is issue #8
00:25:36 <heycam> ... luminance has fixed colour matrix values. in most places they have 3 digits after the dot, in some places they have 4
00:25:45 <heycam> ... the request was to have 4 digits everywhere, instead of just 3
00:26:23 <krit> http://dev.w3.org/fxtf/filters/#element-attrdef-values
00:27:12 <heycam> heycam: so it's using 4 digits in the luminance matrix, but 3 in the other types
00:27:20 <heycam> krit: any objection to using 4 digits everywhere?
00:27:24 <heycam> (none heard)
00:27:50 <heycam> RESOLUTION: The feColorMatrix pre-defined matrices should all use 4 digits after the decimal point.
00:28:09 <heycam> krit: next, issue #11
00:28:10 <krit> file:///Users/dschulze/Documents/fxtf-drafts/filters/issues-lc-2015.html#issue-11
00:28:28 <astearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27464
00:28:41 <heycam> ... if you have objectBoundingBox units, and you try to use say 47em, what does that mean?
00:29:17 <heycam> ... not clear what element the ems are resolved to px
00:29:59 <heycam> heycam: I guess they should be resolved against the font-size of the element they're on
00:30:15 <heycam> ed: not sure if this needs to be mentioned in the spec
00:30:34 <heycam> ... could put a note that these values will give useless results [as they're much > 1]
00:31:43 <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.
00:31:54 <heycam> (unless you use very small em values of course)
00:32:00 <liam> [the note should explain why, as there are cases where it works]
00:32:16 <krit> http://dev.w3.org/fxtf/filters/issues-lc-2015.html#issue-12
00:32:20 <liam> (yes - I think that's not uncommon)
00:32:20 <heycam> krit: finally, issue #12
00:32:25 <heycam> ... I thought we already discussed this and decided
00:32:47 <heycam> Tav: specularExponent is used in two different places
00:32:57 <heycam> ... just adding a note to say that two uses of this are different
00:33:02 <heycam> krit: I think I made that change already
00:33:43 <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?
00:35:01 <heycam> ed: any objections to publishing as CR after the edits are done?
00:35:03 <heycam> (none heard)
00:35:15 <heycam> RESOLUTION: Publish a CR of Filters spec (under the new process).
00:35:27 <heycam> Topic: CSS Blending PR
00:35:33 <heycam> krit: I'm speaking for Rik who can't be here
00:35:46 <heycam> ... we already had a resolution to PR at TPAC, but there was one issue that forced us to have another CR
00:35:51 <heycam> ... there haven't been any complaints since then
00:36:05 <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
00:36:14 <heycam> ChrisL: implementation report with two passes for everything?
00:36:26 <heycam> krit: we do have 2 implementaitons for each feature and Rik is preparing that implementation report
00:37:34 <heycam> ChrisL: shouldn't need a resolution of the WG
00:37:48 <heycam> Florian: we could resolve that we think the test suite is sufficiently extensive
00:37:54 <heycam> ... that passing it is meaningful
00:37:59 <heycam> ... and then we you pass it everything is fine
00:38:13 <heycam> ChrisL: what's the test coverage like?
00:38:17 <heycam> Tav: including SVG?
00:38:23 <heycam> krit: yes we have tests covering each section
00:39:07 <krit> http://test.csswg.org/suites/compositing-1_dev/nightly-unstable/report/
00:39:33 <heycam> krit: the other part of the test suite are the canvas tests that were published with philip's test suite
00:40:28 <heycam> krit: what do the CR exit criteria say?
00:40:33 <heycam> s/krit/ChrisL/
00:41:10 <plinss> http://www.w3.org/TR/compositing-1/#cr-exit-criteria
00:42:10 <heycam> ChrisL: the SotD section says that CR must last until at least March 17
00:43:46 <ChrisL> ChrisL has joined #fx
00:44:03 <heycam> Tav: you have some SVG specific tests, but you don't test each of these things in both HTML and SVG?
00:44:59 <Zakim> Zakim has left #fx
00:45:16 <heycam> Tav: it'd be nice if each of these actually linked to the tests
00:45:20 <plinss> http://test.csswg.org/harness/results/compositing-1_dev/grouped/
00:46:02 <heycam> krit: I will ask Rik to provide the necessary documents
00:46:08 <heycam> ChrisL: it looks like they're all HTML tests?
00:46:58 <heycam> Tav: I am concerned we're not testing enough applying to SVG elements
00:47:11 <heycam> ChrisL: there are some broken links too
00:49:12 <ChrisL> links like ../support/* should be support/*
00:49:18 <heycam> Tav: would be good for pure SVG documents so I can provide results for Inkscape
00:50:10 <heycam> ACTION: Dirk to ask Rik to produce SVG versions of the blending tests.
00:50:10 <trackbot> Created ACTION-89 - Ask rik to produce svg versions of the blending tests. [on Dirk Schulze - due 2015-02-18].
00:51:01 <cyril_> scribe: Cyril
00:51:05 <cyril_> scribeNick: cyril
00:51:16 <cyril_> Topic: Colored font palette control
00:51:28 <cyril_> heycam: I sent an email to www-style about this
00:51:37 <heycam> https://lists.w3.org/Archives/Public/www-style/2015Feb/0211.html
00:51:48 <cyril_> heycam: in the latest version of hte OpenType spec
00:52:03 <cyril_> ... which reached a stage where only editorial changes can be made
00:52:16 <cyril_> ... there is 3 types of colourful glyphs:
00:52:22 <cyril_> ... bitmap format like PNG
00:52:36 <cyril_> ... vector format reusing existing glyf and cff table glyphs
00:52:45 <cyril_> ChrisL: was it extended to CFF ?
00:52:50 <cyril_> heycam: it was an assumption
00:52:53 <cyril_> ... might not be
00:53:04 <cyril_> ... and the 3rd option is embedded SVG document
00:53:22 <cyril_> ... in the last 2 options they have the option of using a palette
00:53:31 <cyril_> ... in fact for option 2 it is mandatory
00:53:43 <cyril_> ... for SVG glyphs it is an option by using CSS variables
00:53:53 <cyril_> ... some CSS variiables are defined automatically
00:54:03 <cyril_> ... in the font you can define a number of palettes
00:54:13 <cyril_> ... but there is no way to select the palette you want
00:54:25 <cyril_> ... or provide your own custom palette
00:54:43 <cyril_> ... I thought it moght be a good thing to allow
00:54:51 <cyril_> ... my email has an actual proposal
00:55:12 <cyril_> ... for selecting which palette, there would be a new property font-palette referencing the palette by a name
00:55:16 <cyril_> ... there is no name in the font
00:55:34 <cyril_> ... the idea would be to map indices to names for a particular font
00:55:49 <cyril_> ... you don't want to set ffont-palette: 3 and then depend on the font
00:56:17 <cyril_> dino: I think for these fonts, you know what you're doing
00:56:47 <cyril_> ChrisL: we don't know what fonts you have on the machine or what fonts are downloaded
00:57:50 <cyril_> roc: there is an issue with editable content, it is easy for users to add characters that are not in the font
00:58:11 <cyril_> ... and you can have fallback to system fonts and that might not be what you want
00:58:31 <liam> [that's true for any font, including woff]
00:58:35 <ChrisL> we already have that issue with font feature selection, where feature numbers are not portable across different fonts
00:58:43 <cyril_> dino: the theory is that if you specify the palette you end up with a font that has the right palette ?
00:59:28 <cyril_> heycam: jdaggett was of the opinion that it should go in font feature values
00:59:43 <cyril_> dino: it's not a big deal but it might be longer to specify
01:00:12 <cyril_> ... people might end up with names 'one', 'two' ... for the palettes
01:00:53 <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]
01:01:01 <cyril_> heycam: if people were happy with disabling palette selection if you use a fallback selection, I'll be happy
01:01:14 <cyril_> dino: tab's suggestion is good too
01:01:35 <cyril_> ... you can use palette name but if the name is a number that's the index then
01:02:34 <cyril_> roc: we could disable fallback for now and add it later
01:02:36 <cyril_> TabAtkins: reasonnable
01:03:06 <cyril_> heycam: do people think this should be in the next level of the font spec ?
01:03:30 <cyril_> ChrisL: it doesn't make sense to put in the current level because it's stable
01:03:42 <cyril_> heycam: what about adding font palette selection to level 4
01:04:03 <cyril_> ... and it uses an index to begin with and font fallback disables selection
01:04:10 <tantek> tantek has joined #fx
01:04:12 <cyril_> ... and later we can add a more detailed feature
01:04:14 <cyril_> TabAtkins: yes
01:04:39 <cyril_> resolution: add font palette selection to CSS Fonts level 4
01:05:08 <cyril_> action: jdaggett to add font palette selection to CSS Fonts level 4
01:05:09 <trackbot> Error finding 'jdaggett'. You can review and register nicknames at <http://www.w3.org/Graphics/fx/track/users>.
01:05:38 <cyril_> heycam: the next step, if we want to, is to specify custom palette values
01:06:04 <cyril_> ... for my example (in the email), the font creator would provide different fonts
01:06:20 <cyril_> ... it's normal to have a choice to select the palette
01:06:39 <cyril_> ... in my optional proposal #2, I added something similar
01:06:55 <cyril_> ... adds a @font-palette
01:07:13 <cyril_> TabAtkins: I don't think we need the indirection of the @font-palette
01:07:42 <cyril_> ... we can use directly the font property to specify the color palette
01:07:54 <cyril_> ... for colors, giving a name is useful
01:08:36 <cyril_> ChrisL: people asked a long time ago to be able to name colors
01:10:05 <cyril_> heycam: I'm happy with not having the named palettes and not having the @font-palette rule
01:10:51 <cyril_> ... does the order of the names and colors in the font-palette property have to match the indices ?
01:10:53 <cyril_> TabAtkins: no
01:11:26 <cyril_> heycam: what happens if you miss out one of the palette entries ?
01:11:40 <cyril_> ChrisL: you default to transparent black ?
01:11:49 <cyril_> TabAtkins: no simply black
01:11:58 <cyril_> ChrisL: I agree I made a big mistake here
01:12:36 <cyril_> heycam: do we agree we want the feature ?
01:12:39 <cyril_> Tav: yes
01:12:49 <cyril_> TabAtkins: why don't overload the color property ?
01:13:09 <cyril_> ... you might to use a palette function
01:13:26 <cyril_> heycam: what does fill=currentColor on a shape if you have that ?
01:14:05 <cyril_> ChrisL: color can be used for other usages: stroke, fill, ...
01:14:10 <cyril_> TabAtkins: yes
01:14:33 <cyril_> ChrisL: not objecting but concerned about how it would evolve
01:14:48 <cyril_> TabAtkins: so if palette is not used, we could default to using the color value
01:15:16 <cyril_> ed: is it possible to use a palette and override some colors ?
01:15:37 <cyril_> ChrisL: palette is a preset, you can override it all
01:16:02 <cyril_> ... we've had that discussion on gradients, overriding some stops, but it's not used
01:16:59 <cyril_> (chris digresses on Web audio)
01:17:23 <glazou> glazou has joined #fx
01:17:29 <cyril_> resolution: we add custom palette support without the @font-palette rule
01:17:37 <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;"
01:17:58 <cyril_> heycam: we'll still name the individual palette entries inside font-feature values
01:18:13 <cyril_> heycam: the final part in my email, proposal 3
01:18:35 <cyril_> ... you can specify if one of the predefined palette is appropriate for dark, light, both or neither background
01:18:47 <cyril_> ... emoji fonts have dark versions and light version
01:19:02 <cyril_> ... i'm suggesting adding keywords to select the version
01:19:10 <cyril_> TabAtkins: +1
01:20:02 <cyril_> ... I'm suggesting to name it according to the system it is supposed to be used: lightSomething, darkSomehting
01:20:28 <cyril_> heycam: you probably always want to use the highcontrast one without analysing the background color
01:20:37 <cyril_> ... I'm ok with starting with just light and dark
01:20:42 <cyril_> .. do people agree ?
01:20:44 <cyril_> ChrisL: yes
01:21:17 <cyril_> resolution: font-palette property will have light and dark keywords to select the first light or dark annotated palette in the font
01:21:25 <TabAtkins> s/so if palette is not used/so if you omit some palette index names/
01:21:43 <cyril_> heycam: I'd like to bring a little issue regarding css variables
01:22:27 <cyril_> ... I tried to implement css variables and palettes
01:23:18 <cyril_> ... (explaining something about caching)
01:23:41 <cyril_> ... we could need a non-variable way to indicate palette
01:23:50 <cyril_> ... I don't know if we can do that
01:23:59 <cyril_> ... It's a bit late in the open type process
01:24:10 <cyril_> ... but we might have this problem in other contexts
01:24:57 <cyril_> TabAtkins: for svg fonts, I see the problem
01:25:12 <cyril_> ... but using variables in UA specific way is a viloation of the spec anyway
01:25:34 <cyril_> heycam: it's probably possible to detect that the palette variables are used in a sensible way
01:25:54 <cyril_> ... but I'm concerned more about the general pattern
01:26:17 <cyril_> ... like a stroke-width controllable by variables
01:27:16 <heycam> Scribe: Cameron
01:27:18 <heycam> ScribeNick: heycam
01:27:21 <heycam> Topic: text-rendering
01:27:31 <heycam> roc: this is a google request
01:27:48 <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
01:27:55 <heycam> ... the width of the string in css px changes when you zoom in/out of the page
01:28:02 <heycam> ... turns out this is true in all pages, including chrome in some situations
01:28:08 <heycam> ... the reason is because of font hinting, in this case
01:28:10 <heycam> ... there are some other issues
01:28:23 <heycam> ... with vertical metrics it can also occur if you round line height to pixels
01:28:31 <heycam> ... they saw this as a bug, though I don't think it is a bug
01:28:40 <heycam> ... generally you do want to hint on windows, as you want to match OS text rasterisation
01:29:13 <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
01:29:20 <heycam> ... and render that font with no regard to what the device resolution is
01:29:32 <heycam> ... then if we do that consistently we can make text rendering device resolution independent
01:29:42 <heycam> ... as you zoom in/out you'd get the same metrics
01:29:45 <heycam> ... apparently chrome has or will do this
01:30:00 <heycam> ChrisL: that seems consistent with what geometricPrecision was designed for
01:30:08 <heycam> roc: if we do this, then the spec should make this a requirement
01:30:31 <heycam> roc: this would apply to HTML and SVG
01:30:35 <heycam> Rossen: when you zoom, what do you mean?
01:30:41 <heycam> ... user zoom in firefox?
01:30:45 <heycam> roc: a full page zoom that causes a layout
01:30:55 <heycam> ... so for any layout-changing zoom
01:31:05 <heycam> ... (non-layout-changing zoom already doesn't affect text metrics)
01:31:24 <heycam> Rossen: so this would affect high dpi devices, you're opting in to some level of zoom?
01:31:31 <heycam> roc: right now you can get different layout on high/lo dpi
01:31:39 <heycam> ... this would make those layouts consistent with each other
01:31:39 <heycam> ... and across the web
01:31:49 <heycam> ... we could make layouts fully consistent across browsers, at least text width
01:31:58 <heycam> Rossen: I think Ted and Matt Rakow want to make that happen
01:32:18 <heycam> roc: in Firefox I would make text metrics incl advance widths depend only on the content of the OpenType font
01:32:25 <heycam> ... the problem is platform APIs apply rounding in different situations
01:32:31 <heycam> ... I'd like to bypass that and just get data from the font
01:32:37 <heycam> Rossen: do you have any test cases we could look at?
01:32:45 <heycam> roc: I'll send you one
01:32:57 <heycam> ... I should mention that our plan is to continue to render glyphs with subpixel AA where possible
01:33:02 <heycam> ... eventhough we're not doing any hinting
01:33:10 <heycam> ... this doesn't mean we need to turn off subpixel AA
01:33:16 <heycam> ... it's a layout issue, not glyph rendering issue
01:33:18 <heycam> ... sounds OK?
01:33:20 <heycam> ChrisL: yes
01:33:22 <heycam> dino: yes
01:34:31 <heycam> RESOLUTION: text-rendering:geometricPrecision will require that font metrics and text measurement will be independent of the device resolution
01:34:43 <heycam> ... and zoom level
01:35:01 <heycam> ACTION: Cameron to make text-rendering:geometricPrecision change
01:35:01 <trackbot> Created ACTION-90 - Make text-rendering:geometricprecision change [on Cameron McCormack - due 2015-02-18].
01:35:30 <heycam> -- lunch break, 90 mins --
01:36:35 <jun> jun has joined #fx
01:40:23 <shepazu_> shepazu_ has joined #fx
02:00:27 <ChrisL> ChrisL has joined #fx
02:00:42 <ChrisLilley> ChrisLilley has joined #fx
02:15:15 <koji> koji has joined #fx
02:38:07 <hyojin> hyojin has joined #fx
02:50:17 <stakagi> stakagi has joined #fx
02:53:12 <jun> jun has joined #fx
03:01:48 <kwkbtr> kwkbtr has joined #fx
03:02:04 <Florian> Florian has joined #fx
03:02:05 <AndreyR> AndreyR has joined #fx
03:03:32 <murakami> murakami has joined #fx
03:03:52 <tantek> tantek has joined #fx
03:03:52 <nikos> scribenick: nikos
03:03:57 <nikos> scribe: Nikos
03:04:01 <nikos> Topic: Canceling and interrupting transitions
03:04:22 <nikos> dbaron: There have been some relatively large edits since the WD - but only stuff that implementors would care about
03:04:32 <nikos> ... such as cancelling and interrupting transitions
03:05:01 <nikos> ... I think I'm ready to take the spec to new new process CR
03:05:06 <nikos> ... there's a bunch of issues in bugzilla
03:05:16 <nikos> ... I made some minor edits and there's a few we should talk about
03:05:24 <nikos> ... anything that's a new feature is marked to defer to level 2
03:05:37 <nikos> ... there are a few that are about animating specific value types
03:05:44 <nikos> ... like images and gradientss
03:05:49 <nikos> ... those should be deferred to css images
03:05:55 <nikos> s/gradientss/gradients
03:06:18 <nikos> dbaron: one question is whether there should be transition rules defined for z-index:auto
03:06:20 <dbaron> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16265
03:06:38 <nikos> ... apparently testing showed that a bunch of engines do transitions between z-index:auto and numbers
03:06:49 <nikos> ... this may or may not just be a bug related to treating the value as zero
03:07:33 <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
03:07:39 <nikos> ... and a jump at the end
03:07:54 <nikos> ... apparently zero to auto jumps were at both ends
03:08:02 <nikos> ... do people thing we should have special transition rules for z-index:auto
03:08:04 <nikos> ... ?
03:08:12 <nikos> TabAtkins: I'd prefer not, I don't see how to do it properly
03:08:33 <nikos> dbaron: a special rule would mean that any intermediate interpolation that was not 100% value or the other would treat auto as zero
03:09:02 <nikos> dino: it looks to me like it's a bug
03:09:06 <nikos> ... what would you do otherwise?
03:09:22 <nikos> dbaron: current behaviour says if one value is auto you can't interpolate
03:09:29 <nikos> dino: think it's just a bug that webkit should fix
03:09:30 <ChrisLilley> ChrisLilley has joined #fx
03:09:34 <nikos> ... we don't check that it's auto
03:10:01 <smfr> that might have compat risk for webkit but we should fix it (maybe with the non-prefixed transition, dino)