15:55:25 RRSAgent has joined #css 15:55:25 logging to https://www.w3.org/2018/06/20-css-irc 15:55:27 RRSAgent, make logs public 15:55:27 Zakim has joined #css 15:55:29 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 15:55:29 Date: 20 June 2018 15:55:41 jensimmons has joined #css 15:55:46 zheng_xu has joined #css 15:56:09 tgraham has joined #css 15:56:14 present+ dael 15:56:19 ScribeNick: dael 15:56:26 present+ 15:57:09 ndev has joined #css 15:57:58 rachelandrew has joined #css 15:58:03 present+ 15:58:52 present+ 15:59:29 bgirard has joined #css 16:00:13 smfr has joined #css 16:00:18 present+ 16:00:19 present+ 16:00:21 tmichel has joined #css 16:00:25 present+ 16:00:30 Rossen_ has joined #css 16:00:44 present+ 16:00:44 present+ 16:00:57 alex_antennahouse has joined #css 16:01:06 present+ antonp 16:01:07 present+ 16:01:15 astearns: We'll give people a couple more minutes to call in 16:01:23 present+ alex_antennahouse 16:01:59 franremy has joined #css 16:02:15 present+ 16:02:17 present+ 16:02:19 present+ 16:02:26 present+ 16:02:35 rik has joined #css 16:02:35 present+ 16:02:49 astearns: We'll skip items 6, 8, and 10 on the agenda 16:02:58 astearns: Anything anyone would like to add or change? 16:03:04 fantasai: Did you mean 9 instead of 8? 16:03:07 present+ 16:03:14 myles has joined #css 16:03:18 astearns: You said 6 and 10 16:03:28 fantasai: Yes. For 9 we wanted Oriel. 16:03:35 s/Oriel/Oriol/ 16:03:38 astearns: Oh, I'm sorry. it is 6 9 and 10 to skip 16:03:50 Topic: Dropping "synthesizing super/sub-scripts" requirement 16:03:57 github: https://github.com/w3c/csswg-drafts/issues/2796 16:04:05 present+ myles 16:04:55 chris: Let me give a DoC link 16:04:59 https://drafts.csswg.org/issues?spec=css-fonts-3&doc=pr-2018 16:05:23 present+ 16:05:24 chris: One remaining issue. There's an advisement in the spec if you have open type font that has some... 16:06:15 What issue is this? 16:06:22 chris: If it has some open type features for sub scripts and super scripts but doesn't cover all glyphs the spec advises not to use and to synth them. No one does that and it's at risk in CR. As it's at risk and there's not impl interest I opened issue to downgrade to should or may. 16:06:27 https://drafts.csswg.org/issues?spec=css-fonts-3&doc=pr-2018#issue-9 16:06:29 chris: There was some obj, florian not happy 16:06:53 florian: My concerns is since the glyphs supported won't line up it may be semantically confusing. None-lined up may be multi level superscript. 16:07:08 chris: THat's possible. The example was choosen to be particularly bad. 16:07:52 chris: This isn't a new issue. The advice to switch off the real superscript and sub script is well intentioned but not impl. We could defer the entire thing to L4. We didn't get consensus around changing html stylesheet 16:08:06 fantasai: THis isn't the reason for html stylesheet. THat's because can't do many levels subscript 16:08:08 chris: agree 16:08:30 florian: I agree that just because this is bad we don't have an good answer. I don't want to block and if downgrade to should is what we can do that's what we have 16:08:40 chris: We have downgrade to may, should, or move to L4. I prefer should. 16:08:52 florian: We should put pressure as well as doing should. 16:08:55 ack liam 16:08:56 liam, you wanted to ask how that works with content-editable when you add the first unsupported character 16:09:23 liam: I wanted to point out it's not an edge case. content editable the user adds an unsupported character. It's an edge case, but it has to work. 16:09:48 chris: Yes, it would mean previously superscript char would have to be rendered differently. But I'm not aware of anyone doing it. 16:09:52 florian: I'm okay with this. 16:10:01 astearns: Obj to change to should in L3 and pushing for it in L4 16:10:14 fantasai: As long as it's clear you have to synth individual super and sub script 16:10:16 chris: Yes 16:10:25 RESOLVED: change to should in L3 and pushing for it in L4 16:10:34 Topic: Request transition to Proposed Recommendation 16:10:42 astearns: Last issue done. Test suite passes? 16:10:58 https://test.csswg.org/harness/results/css-fonts-3_dev/grouped/filter/1/ 16:11:00 chris: There's one non-passing test and that's [missed] and that feature is only in L4. We are good to go. 16:11:13 astearns: Objections to request transition to proposed rec to fonts L3? 16:11:26 https://github.com/w3c/csswg-drafts/commit/1a5b9bcb0a2aac317c08f95bb63d6158d22eb862 16:11:27 fantasai: Looking at edits. Looks like they're not correct 16:11:38 fantasai: ^ second switch from must to should shouldn't be changed afaict 16:11:45 chris: Let me look 16:12:02 chris: You're correct. I'll fix 16:12:10 fantasai: As long as that's fixed I"m fine. 16:12:24 astearns: Objections with that change? 16:12:43 florian: Do we have a report detailing the tests or jsut a statement tests are fine? An impl report. 16:12:54 chris: Yeah. [missed] If you remove filter 16:13:00 https://test.csswg.org/harness/results/css-fonts-3_dev/grouped/ 16:13:01 astearns: chris put the link in IRC 16:13:05 fantasai: One more question 16:13:12 bradk has joined #css 16:13:21 chris: There's 475 tests that pass from before. Do people see that? 16:14:31 present+ 16:14:35 fantasai: The 3rd change from must to should [reads] I'm trying to understand what it's about. I think it's that font metrics for supr and sub script don't match actual glyphs and if you apply text decoration it'll be misplaced if you use those metrics. But in a proper font where the metrics match correctly you don't want to synth you want to use actual glyphs 16:15:04 fantasai: I think that one should be a may. If the UA can detect there won't be a problem it should ideally use non-synth. I think it was incorrect as a must in the first place 16:15:29 chris: Another thing when we get to this in L4 with optical sizing the font itself can change its size. I want to re-open this on fonts 4. 16:15:38 fantasai: Yeah, but I think go to a may in this level should be fine. 16:15:40 chris: Okay. 16:15:50 astearns: Anyone concerned? 16:15:59 astearns: Okay, let's do that 16:16:08 astearns: Any additional changes? 16:16:20 bradk has joined #css 16:16:32 astearns: With the two changes, objections to proposed rec for fonts L3? 16:16:40 Chris, you probably want to move your comment about the GH issue up to the actual change 16:16:43 also 16:16:48 RESOLVED: Request transition to proposed rec for Fonts L3 16:17:09 welcome! 16:17:13 astearns: Congrats and thanks chris for the work getting the test suite up to snuff and everything tidied away 16:17:16 topic: end 16:17:21 florian: Where are we with UI? 16:17:28 chris: [missed] Thursday 16:17:52 and waiting for your response florian on the other spec 16:18:00 Topic: Containing block of filter, plus effect when applied to the root element 16:18:07 github: https://github.com/w3c/fxtf-drafts/issues/11#issuecomment-360240933 16:18:37 chrish: I believe we skipped this last week because dbaron wasn't there. Is that correct? 16:18:57 astearns: It was because you weren't. If we have you and krit we can discuss 16:19:24 chrishtr: We resolved in same issue to make filter containing block for all elements except when filter is on root. Reason for carve out is to avoid breaking fixed pos elemetns 16:19:25 present+ 16:19:50 chrishtr: Example is applying an a11y filter on entire webpage and you don't want that to break fixedpos, just be more readable. 16:20:39 chrishtr: as currently stands root element is nto the containing block for fixed pos elements. Means scroll of the fixed position element escapes the filter. Problem because in general it doesn't really make sense to have clips and scrolls escape filters because they can move pixels and it becomes strange or impossible to impl. 16:21:19 chrishtr: I proposed that filter on the root gets applied after scroll and clip but before scrollbars. Can still aplly filter to the whole page, but it will apply clip and scroll correctly and scrollbar is on top. 16:21:28 chrishtr: Any feedback on this? 16:21:51 smfr: Sounds fine. I thinkt hat means the filte ron the root prop to the canvas 16:22:14 chrishtr: Right, last week it was details of how it applies to the canvas and this is making sure it pushes up to canvas and not apply before scroll and clip 16:22:25 bradk: Don't quite understand the scrollbar comment. 16:22:41 chrishtr: Only root scrollbars of the frame. Scrollbars of root frame would never be able to eb filtered 16:22:53 bradk: Why is that bad compared to other scrollbars? 16:23:03 bradk: Would ti be good if I'm reversing screen? 16:23:35 chrishtr: In some use cases I don't think it is. Root of a UA thing the web page should effect. Scrollbars in page are an effect of the page. It's a gray area but makes sense to carve out. 16:23:41 rbyers: No strong feeling, but seems odd. 16:24:19 chrishtr: Applies to iframes as well. If you had it on the root of the iframe it wouldn't be filtered. I don't feel super strongly but it seems good to not let content mess up the root scrollbar of the page 16:24:47 Rossen_: I want to make sure I get proposal. currently filters will establish a stacking context as well as containing blocka nd being containing block for fixed pos? 16:25:06 chrishtr: Unless it's on the root of the page. Proposal is in addition w apply filter after scrolla nd clip 16:25:14 Rossen_: Initial containing block in this case? 16:25:20 chrishtr: I don't think it's changed. 16:26:22 PR under discussion: https://github.com/w3c/fxtf-drafts/pull/263/files 16:26:23 Rossen_: Way we defined so far is this is the root containing block which in your description...that's what confuses me...currently if nothing becomes a containing block the initial one will be the containing block. IT's defined as it being the root cotnaining block. You're trying to reverse that which means to me something above containing block or I'm missing something. 16:26:32 dgrogan has joined #css 16:26:33 tantek has joined #css 16:26:40 chrishtr: I dont think this changes containing blocks, just order in which things apply. 16:27:27 fantasai: I'm trying to understand what we're doing. Seems changes are very aggressive and I don't understand why it's a good thing. THere's several things...first, we're making anything with a filter be acontaining block for abspos and fixedpos elements. And the filter is fixed for viewport in the same way as a background is fixed. 16:27:37 smfr: I don't think that's true 16:27:44 smfr: It's only if filter is on the root 16:27:45 zcorpan has joined #css 16:27:46 fantasai: Yeah. 16:28:39 fantasai: So if I want a filter for the entire page and not this weird layered thing I can't do that. But that seems what I'd want most of the time. THe filter being a fixed thing that doesn't move it re-filters every time I scroll and the page could shimmer as I scroll. Seems weird 16:29:06 fantasai: Also don't understand why making it fixed pos containing block. I think we did that for transforms because figuring out static pos is confusing, but I don't know why doing that for filters 16:29:32 Rossen_: And more confusing because if you have filters become containing block for fixed post and you have opacity it would trap. This whole thing is kind of messy. 16:29:47 chrishtr: WG already resolved ot make filter a containing block except for on root. 16:29:51 krit: And it's in the spec. 16:30:55 chrishtr: This is an adjustment. 2nd, why should it be a containing block: Because otherwise the drawing algo to the screen is ill defined. Filter can move pixel and so can't commute with a clip. There's also a perf reason with compositing and GPU accl. THat's one of the main reasons transform is containing block 16:31:09 fantasai: Does clipping clip abspos element whose ancestor is a container? 16:31:30 chrishtr: Follows containing block chair. ANd that's the problem. That's what leads to these obnoxious cases 16:31:32 tantek_ has joined #css 16:31:42 s/post and you have opacity it would trap/pos and opacity for example is a containing block but not for fixed/ 16:31:57 16:32:12 fantasai: I Have an element with clip applied. Inside element there is a child that's abspos and the containing block is an ancestor of the element with clip. If I use overflow then the abspos is not clipped. But if I use clip what happens? 16:32:21 s/blocka nd/block and/ 16:32:24 chrishtr: Then clip:rect will clip. Or clip path 16:32:33 fantasai: But if I say overflow:hidden no clip? 16:32:37 chrishtr: Correct. 16:32:45 fantasai: Seems weird. 16:32:59 chrishtr: Containing blocka nd overflow clip and scroll are weird and unfortunate. 16:33:07 smfr: That's a fundimental design mistake with CSS 16:33:26 chrishtr: And this discussion is a result of that. Making filter containing block is one of a series of changes we need to make it make sense 16:34:12 fantasai: My view is when I'm applying a graphical effect to an element I expect it to be everything in the element. Seems odd at a higher level. Fixed pos being effected seems odd to me. Seems weird that I want to apply a filter would change layout. 16:34:16 chrishtr: yep 16:34:32 fantasai: Random set of properties that effect look of something in a subtle way, but these ones effect layout. 16:34:47 chrishtr: Yep. consiquence that they apply to whole subtree but containng block is defined elsewhere 16:34:54 smfr: How does this work with opacity? 16:35:06 chrishtr: It doesn't effect px so it can be special cased. 16:35:24 fantasai: Why can't filter applyt containing block chain and not subtree? Wouldn't that solve it? 16:35:58 chrishtr: Leads to other problems. I wrote a bunch of design docs on ideas like that and it's just really difficult to resolve these issues. The contaning block thing is different then subtree for stacking context. 16:36:13 chrishtr: THe WG resolved the thing o nthe containing block. Best not to re-litegate. 16:36:25 Rossen_: We resolve and revisit. So that we resolved doesn't mean we can't rediscuss. 16:36:28 chrishtr: Okay 16:37:11 astearns: On the other hand since the thing under discussion depends on that resolutiona nd is required for that previous resolution we could resolve on this because it makes current spec consistent and then revisit containing block bit 16:37:32 krit: Even then there's do we want entire page with filter o jsut what's on the viewport. Has impact on things like blur. 16:37:53 chrishtr: If you want filter to apply to fixedpos descendents you need to define how that works. 16:38:06 fantasai: And in a large part of cases without fixed pos it'll be strange and unexpected. 16:38:51 fantasai: What kind of filters do people use? A whole bunch. Do you expect recalc as yous scroll? Page will shift as you scroll. WHen I look at a page and it's a thing I expect it to be a static thing that shifts under viewport. With a filter it doesn't do that. 16:39:18 chrishtr: An invert filter. You won't be able to tell. Only a blur where you can see. Blur is the problematic and is illdeefined otherwise 16:39:44 TabAtkins: For blur to do what you want fantasai you have to render the entire page to a texture and then clip what's in your viewport. THat's untennitable. 16:39:50 fantasai: That is what I'd expect 16:39:59 TabAtkins: It's impossible to do in a reasonable way 16:40:18 Oriol has joined #css 16:40:27 fantasai: If you define root to not do that then authors who don't want shimmer as you scroll they'll apply to the descendant of the root and you're in the same place for per. 16:40:34 s/per/perf/ 16:40:39 smfr: It's important to try and define filter for the way you want [missed] 16:41:25 chrishtr: Suppose you apply scroll after blur, what does that mean? A filter is applied atomically to a texture. Then you have two textures, one for fixed and one for not. For me it's not perf, it also leads to simpler compositing algo. 16:42:57 fantasai: If I had fixed pos elements on my page and I decided to blur the entire page I would expect that the entire page, everything under fixed pos, would be blurred all at once. If you imaging viewport as a cutour in a cardboard and the paper is under as you movet he cardboard it's all blurred. And the fixed position things on the cardboard I would have applied the blur. If there was a red boarder at the top of the footer it would bleed over the page. 16:43:03 fantasai: As an author that's what I would expect 16:43:33 chrishtr: The problem is fixed pos content isn't fully separated because containing block and stacking context aren't related. z index and interwave with rest of page. 16:43:55 krit: I'm not sure we're getting to a conclusion. Should we discuss at Sydney F2F? I dont' be there but maybe all parties discussing. 16:44:09 chrishtr: I won't be there, but I'm okay with others talking at F2F 16:44:13 smfr: I won't be there 16:44:49 fantasai: I'd rather get common cases to work and if necessary change how we do stacking rather then do something that's not what people expect to preserve current rules of stacking context. 16:44:56 smfr: Sounds like [missed] not clarification 16:45:08 s/[missed]/like a complexification of the current rules/ 16:45:15 s/clarification/simplification/ 16:45:17 krit: Impl mostly do what spec says. It would be interweved on the page, not composited. 16:46:18 fantasai: I haven't looked at stacking context rules in details. Yes they're interweved, but how many pages do that? not meany. You can say if there's a filter on the root we don't interweave anymore. Most pages won't see that but then you can have the filters applied in the way authors would expect. 16:47:00 astearns: I suggest we take discussion back to github and bring up use cases. We've talked generally about kinds of pages authors would want, but concrete examples would be helpful. Of fixed pos and interweaving. Have thos in mind as we come to discuss again 16:47:03 chrishtr: Okay 16:47:15 astearns: Thanks for taking us through this chrishtr. We'll come back to this. 16:47:24 Topic: Presentation attribute as start or end value of a CSS transition 16:47:31 github: https://github.com/w3c/csswg-drafts/issues/2684 16:48:10 krit: In SVG we have the transform attribute which is a presentation attr which mean sit contributes to css pipeline and we can set a transform and it would interfere in hierarchy with itself. 16:48:43 krit: If we have a transform with a list and define a transition on the same element, should it take transofrm into account or just ignore? I'm asking for ignore. 2 browsers do that and 2 take it into account. 16:48:43 https://codepen.io/krit/pen/XqvqyG?editors=1100 16:48:48 krit: codepen^ 16:49:27 krit: You can see that there's a transform on the rect and a transition in css. For webkit you see it transforms and then transforms. blink and edge take the transform from the transform attr and then transition to the value. 16:50:08 krit: I'd like to ignore as that makes the most sense. So can a transform attr contribute as a start or end value? 16:50:22 krit: I'm asking for edge or blink behavior. 16:50:42 astearns: Conserns with standardizing on blink or edge? 16:50:56 smfr: Good to match other presentation attributes 16:51:16 LGTM 16:51:16 astearns: And there's a Mozilla comment saying it's because they haven't made transform a presentation element yet 16:51:27 RESOLVED: use edge behavior 16:51:50 krit: Syntax and some transform are different then on css. Example is rotate which is 1 value in css, 3 in SVG. 16:52:34 zcorpan has joined #css 16:52:40 krit: If we have a transition from a transform presentation attribute with 3 value rotate to css, css would not understand. Edge here ignores the origin so the element jumps and then contiues. Blink composes from one matrix to another 16:52:51 krit: Webkit and FF ignore. 16:53:09 krit: Proposal would be to make this rotate with 3 values to a matrix and do matrix decomposition 16:53:21 astearns: This is an edge case b/c 3 value isn't used much? 16:53:26 rrsagent, here 16:53:26 See https://www.w3.org/2018/06/20-css-irc#T16-53-26 16:53:34 krit: Yes. Edge case because css does not have 3 value so it's not often used. 16:54:13 smfr: Unfortunate that you fall back to matrix for something that's a rotate...you'll never do rotate [missed] turning into rotate translate 16:54:39 krit: You could change rotate to a rotate translate, but that could be worse becuase it doesn't match any transform function. So we'd still fallback 16:55:08 present+ 16:55:20 (I support the rotate(3-arg) being incompatible with anything.) 16:55:22 krit: Proposal is if there's a rotate with 3 values and have a transition it gets composed to a matrix and we have matrix decomposition for a animation 16:55:40 smfr: No alternate proposal and I don't object. It's okay, it's just that if author is trying to rotate we will fallback 16:55:54 krit: Can we agree on matix decomposition? 16:56:05 astearns: Objections to make this rotate with 3 values to a matrix and do matrix decomposition 16:56:06 ok I guess 16:56:17 tantek_ has joined #css 16:56:17 RESOLVED: make this rotate with 3 values transition to a matrix and do matrix decomposition 16:56:32 Topic: the used value for border-box 16:56:39 github: https://github.com/w3c/csswg-drafts/issues/999#issuecomment-391431901 16:57:35 krit: transform-box has a couple fo defined boxed. Issue is we have mapping defined for fill and stroke fallbacks. THe mapping between html and svg boxes it request more values to supported value of transform-box. border-box on svg fallsback to stroke-box but we don't have that exposed. 16:57:40 zcorpan_ has joined #css 16:57:55 krit: Proposal is every fallback we define would also be definable on transform. We'd add content box and stroke box 16:58:02 smfr: Which spec will define the boxes? 16:58:12 krit: Each spec defines mapping. 16:58:27 fantasai: It would be fine to import the mapping to transform spec as it's more mature then fill/stroke 16:58:53 krit: Currently transform and masking do what we defined for fill/stroke. We're adding the keywords for the spec behavior so users can spec directly 16:59:07 astearns: Concerns with adding these values? 16:59:10 fantasai: sgtm 16:59:22 smfr: I think I'm okay with [missed] 17:00:02 astearns: Sounded like smfr if okay but is not sure transforms is right place for dfinitions 17:00:12 fantasai: Not sure where else. I guess fill/stroke is fine 17:00:25 s/fine/fine, but it's a very early-stage WD/ 17:00:26 krit: That's why masking and transform already define it, but they do it the same way 17:00:46 astearns: Given things move in different velocities we may defer to fill and stroke in a future transforms 17:00:56 astearns: Objections to add these keywords to transform-box property? 17:01:03 RESOLVED: add these keywords to transform-box property 17:01:06 topic: end 17:01:24 https://wiki.csswg.org/planning/sydney-2018 17:01:27 astearns: Thanks everyone and we'll talk next week. If you're not on wiki for Houdini and CSS and you're coming, please add yourself. 17:04:05 trackbot, end meeting 17:04:05 Zakim, list attendees 17:04:05 As of this point the attendees have been dael, astearns, zheng_xu, plinss, florian, fantasai, rachelandrew, Rossen_, antenna, antonp, jensimmons, alex_antennahouse, tgraham, 17:04:08 ... melanierichards, gregwhitworth, chrishtr, TabAtkins, chris, myles, krit, bradk, leaverou, liam, tantek 17:04:13 RRSAgent, please draft minutes 17:04:13 I have made the request to generate https://www.w3.org/2018/06/20-css-minutes.html trackbot 17:04:14 RRSAgent, bye 17:04:14 I see no action items