IRC log of css on 2018-06-20

Timestamps are in UTC.

15:55:25 [RRSAgent]: RRSAgent has joined #css
15:55:25 [RRSAgent]: logging to https://www.w3.org/2018/06/20-css-irc
15:55:27 [trackbot]: RRSAgent, make logs public
15:55:27 [Zakim]: Zakim has joined #css
15:55:29 [trackbot]: Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:55:29 [trackbot]: Date: 20 June 2018
15:55:41 [jensimmons]: jensimmons has joined #css
15:55:46 [zheng_xu]: zheng_xu has joined #css
15:56:09 [tgraham]: tgraham has joined #css
15:56:14 [dael]: present+ dael
15:56:19 [dael]: ScribeNick: dael
15:56:26 [astearns]: present+
15:57:09 [ndev]: ndev has joined #css
15:57:58 [rachelandrew]: rachelandrew has joined #css
15:58:03 [zheng_xu]: present+
15:58:52 [plinss]: present+
15:59:29 [bgirard]: bgirard has joined #css
16:00:13 [smfr]: smfr has joined #css
16:00:18 [florian]: present+
16:00:19 [fantasai]: present+
16:00:21 [tmichel]: tmichel has joined #css
16:00:25 [rachelandrew]: present+
16:00:30 [Rossen_]: Rossen_ has joined #css
16:00:44 [Rossen_]: present+
16:00:44 [antenna]: present+
16:00:57 [alex_antennahouse]: alex_antennahouse has joined #css
16:01:06 [antonp]: present+ antonp
16:01:07 [jensimmons]: present+
16:01:15 [dael]: astearns: We'll give people a couple more minutes to call in
16:01:23 [alex_antennahouse]: present+ alex_antennahouse
16:01:59 [franremy]: franremy has joined #css
16:02:15 [tgraham]: present+
16:02:17 [melanierichards]: present+
16:02:19 [gregwhitworth]: present+
16:02:26 [chrishtr]: present+
16:02:35 [rik]: rik has joined #css
16:02:35 [TabAtkins]: present+
16:02:49 [dael]: astearns: We'll skip items 6, 8, and 10 on the agenda
16:02:58 [dael]: astearns: Anything anyone would like to add or change?
16:03:04 [dael]: fantasai: Did you mean 9 instead of 8?
16:03:07 [chris]: present+
16:03:14 [myles]: myles has joined #css
16:03:18 [dael]: astearns: You said 6 and 10
16:03:28 [dael]: fantasai: Yes. For 9 we wanted Oriel.
16:03:35 [fantasai]: s/Oriel/Oriol/
16:03:38 [dael]: astearns: Oh, I'm sorry. it is 6 9 and 10 to skip
16:03:50 [dael]: Topic: Dropping "synthesizing super/sub-scripts" requirement
16:03:57 [dael]: github: https://github.com/w3c/csswg-drafts/issues/2796
16:04:05 [myles]: present+ myles
16:04:55 [dael]: chris: Let me give a DoC link
16:04:59 [chris]: https://drafts.csswg.org/issues?spec=css-fonts-3&doc=pr-2018
16:05:23 [krit]: present+
16:05:24 [dael]: chris: One remaining issue. There's an advisement in the spec if you have open type font that has some...
16:06:15 [fantasai]: What issue is this?
16:06:22 [dael]: 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 [fantasai]: https://drafts.csswg.org/issues?spec=css-fonts-3&doc=pr-2018#issue-9
16:06:29 [dael]: chris: There was some obj, florian not happy
16:06:53 [dael]: 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 [dael]: chris: THat's possible. The example was choosen to be particularly bad.
16:07:52 [dael]: 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 [dael]: fantasai: THis isn't the reason for html stylesheet. THat's because can't do many levels subscript
16:08:08 [dael]: chris: agree
16:08:30 [dael]: 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 [dael]: chris: We have downgrade to may, should, or move to L4. I prefer should.
16:08:52 [dael]: florian: We should put pressure as well as doing should.
16:08:55 [astearns]: ack liam
16:08:56 [Zakim]: liam, you wanted to ask how that works with content-editable when you add the first unsupported character
16:09:23 [dael]: 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 [dael]: 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 [dael]: florian: I'm okay with this.
16:10:01 [dael]: astearns: Obj to change to should in L3 and pushing for it in L4
16:10:14 [dael]: fantasai: As long as it's clear you have to synth individual super and sub script
16:10:16 [dael]: chris: Yes
16:10:25 [dael]: RESOLVED: change to should in L3 and pushing for it in L4
16:10:34 [dael]: Topic: Request transition to Proposed Recommendation
16:10:42 [dael]: astearns: Last issue done. Test suite passes?
16:10:58 [chris]: https://test.csswg.org/harness/results/css-fonts-3_dev/grouped/filter/1/
16:11:00 [dael]: 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 [dael]: astearns: Objections to request transition to proposed rec to fonts L3?
16:11:26 [fantasai]: https://github.com/w3c/csswg-drafts/commit/1a5b9bcb0a2aac317c08f95bb63d6158d22eb862
16:11:27 [dael]: fantasai: Looking at edits. Looks like they're not correct
16:11:38 [dael]: fantasai: ^ second switch from must to should shouldn't be changed afaict
16:11:45 [dael]: chris: Let me look
16:12:02 [dael]: chris: You're correct. I'll fix
16:12:10 [dael]: fantasai: As long as that's fixed I"m fine.
16:12:24 [dael]: astearns: Objections with that change?
16:12:43 [dael]: florian: Do we have a report detailing the tests or jsut a statement tests are fine? An impl report.
16:12:54 [dael]: chris: Yeah. [missed] If you remove filter
16:13:00 [chris]: https://test.csswg.org/harness/results/css-fonts-3_dev/grouped/
16:13:01 [dael]: astearns: chris put the link in IRC
16:13:05 [dael]: fantasai: One more question
16:13:12 [bradk]: bradk has joined #css
16:13:21 [dael]: chris: There's 475 tests that pass from before. Do people see that?
16:14:31 [bradk]: present+
16:14:35 [dael]: 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 [dael]: 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 [dael]: 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 [dael]: fantasai: Yeah, but I think go to a may in this level should be fine.
16:15:40 [dael]: chris: Okay.
16:15:50 [dael]: astearns: Anyone concerned?
16:15:59 [dael]: astearns: Okay, let's do that
16:16:08 [dael]: astearns: Any additional changes?
16:16:20 [bradk]: bradk has joined #css
16:16:32 [dael]: astearns: With the two changes, objections to proposed rec for fonts L3?
16:16:40 [fantasai]: Chris, you probably want to move your comment about the GH issue up to the actual change
16:16:43 [fantasai]: also
16:16:48 [dael]: RESOLVED: Request transition to proposed rec for Fonts L3
16:17:09 [chris]: welcome!
16:17:13 [dael]: astearns: Congrats and thanks chris for the work getting the test suite up to snuff and everything tidied away
16:17:16 [dael]: topic: end
16:17:21 [dael]: florian: Where are we with UI?
16:17:28 [dael]: chris: [missed] Thursday
16:17:52 [chris]: and waiting for your response florian on the other spec
16:18:00 [dael]: Topic: Containing block of filter, plus effect when applied to the root element
16:18:07 [dael]: github: https://github.com/w3c/fxtf-drafts/issues/11#issuecomment-360240933
16:18:37 [dael]: chrish: I believe we skipped this last week because dbaron wasn't there. Is that correct?
16:18:57 [dael]: astearns: It was because you weren't. If we have you and krit we can discuss
16:19:24 [dael]: 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 [leaverou]: present+
16:19:50 [dael]: 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 [dael]: 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 [dael]: 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 [dael]: chrishtr: Any feedback on this?
16:21:51 [dael]: smfr: Sounds fine. I thinkt hat means the filte ron the root prop to the canvas
16:22:14 [dael]: 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 [dael]: bradk: Don't quite understand the scrollbar comment.
16:22:41 [dael]: chrishtr: Only root scrollbars of the frame. Scrollbars of root frame would never be able to eb filtered
16:22:53 [dael]: bradk: Why is that bad compared to other scrollbars?
16:23:03 [dael]: bradk: Would ti be good if I'm reversing screen?
16:23:35 [dael]: 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 [dael]: rbyers: No strong feeling, but seems odd.
16:24:19 [dael]: 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 [dael]: 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 [dael]: chrishtr: Unless it's on the root of the page. Proposal is in addition w apply filter after scrolla nd clip
16:25:14 [dael]: Rossen_: Initial containing block in this case?
16:25:20 [dael]: chrishtr: I don't think it's changed.
16:26:22 [astearns]: PR under discussion: https://github.com/w3c/fxtf-drafts/pull/263/files
16:26:23 [dael]: 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]: dgrogan has joined #css
16:26:33 [tantek]: tantek has joined #css
16:26:40 [dael]: chrishtr: I dont think this changes containing blocks, just order in which things apply.
16:27:27 [dael]: 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 [dael]: smfr: I don't think that's true
16:27:44 [dael]: smfr: It's only if filter is on the root
16:27:45 [zcorpan]: zcorpan has joined #css
16:27:46 [dael]: fantasai: Yeah.
16:28:39 [dael]: 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 [dael]: 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 [dael]: 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 [dael]: chrishtr: WG already resolved ot make filter a containing block except for on root.
16:29:51 [dael]: krit: And it's in the spec.
16:30:55 [dael]: 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 [dael]: fantasai: Does clipping clip abspos element whose ancestor is a container?
16:31:30 [dael]: chrishtr: Follows containing block chair. ANd that's the problem. That's what leads to these obnoxious cases
16:31:32 [tantek_]: tantek_ has joined #css
16:31:42 [Rossen_]: 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 [TabAtkins]: <relpos><clip><abspos/></clip></relpos>
16:32:12 [dael]: 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 [Rossen_]: s/blocka nd/block and/
16:32:24 [dael]: chrishtr: Then clip:rect will clip. Or clip path
16:32:33 [dael]: fantasai: But if I say overflow:hidden no clip?
16:32:37 [dael]: chrishtr: Correct.
16:32:45 [dael]: fantasai: Seems weird.
16:32:59 [dael]: chrishtr: Containing blocka nd overflow clip and scroll are weird and unfortunate.
16:33:07 [dael]: smfr: That's a fundimental design mistake with CSS
16:33:26 [dael]: 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 [dael]: 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 [dael]: chrishtr: yep
16:34:32 [dael]: fantasai: Random set of properties that effect look of something in a subtle way, but these ones effect layout.
16:34:47 [dael]: chrishtr: Yep. consiquence that they apply to whole subtree but containng block is defined elsewhere
16:34:54 [dael]: smfr: How does this work with opacity?
16:35:06 [dael]: chrishtr: It doesn't effect px so it can be special cased.
16:35:24 [dael]: fantasai: Why can't filter applyt containing block chain and not subtree? Wouldn't that solve it?
16:35:58 [dael]: 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 [dael]: chrishtr: THe WG resolved the thing o nthe containing block. Best not to re-litegate.
16:36:25 [dael]: Rossen_: We resolve and revisit. So that we resolved doesn't mean we can't rediscuss.
16:36:28 [dael]: chrishtr: Okay
16:37:11 [dael]: 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 [dael]: 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 [dael]: chrishtr: If you want filter to apply to fixedpos descendents you need to define how that works.
16:38:06 [dael]: fantasai: And in a large part of cases without fixed pos it'll be strange and unexpected.
16:38:51 [dael]: 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 [dael]: 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 [dael]: 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 [dael]: fantasai: That is what I'd expect
16:39:59 [dael]: TabAtkins: It's impossible to do in a reasonable way
16:40:18 [Oriol]: Oriol has joined #css
16:40:27 [dael]: 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 [fantasai]: s/per/perf/
16:40:39 [dael]: smfr: It's important to try and define filter for the way you want [missed]
16:41:25 [dael]: 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 [dael]: 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 [dael]: fantasai: As an author that's what I would expect
16:43:33 [dael]: 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 [dael]: 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 [dael]: chrishtr: I won't be there, but I'm okay with others talking at F2F
16:44:13 [dael]: smfr: I won't be there
16:44:49 [dael]: 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 [dael]: smfr: Sounds like [missed] not clarification
16:45:08 [fantasai]: s/[missed]/like a complexification of the current rules/
16:45:15 [fantasai]: s/clarification/simplification/
16:45:17 [dael]: krit: Impl mostly do what spec says. It would be interweved on the page, not composited.
16:46:18 [dael]: 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 [dael]: 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 [dael]: chrishtr: Okay
16:47:15 [dael]: astearns: Thanks for taking us through this chrishtr. We'll come back to this.
16:47:24 [dael]: Topic: Presentation attribute as start or end value of a CSS transition
16:47:31 [dael]: github: https://github.com/w3c/csswg-drafts/issues/2684
16:48:10 [dael]: 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 [dael]: 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 [krit]: https://codepen.io/krit/pen/XqvqyG?editors=1100
16:48:48 [dael]: krit: codepen^
16:49:27 [dael]: 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 [dael]: 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 [dael]: krit: I'm asking for edge or blink behavior.
16:50:42 [dael]: astearns: Conserns with standardizing on blink or edge?
16:50:56 [dael]: smfr: Good to match other presentation attributes
16:51:16 [chris]: LGTM
16:51:16 [dael]: astearns: And there's a Mozilla comment saying it's because they haven't made transform a presentation element yet
16:51:27 [dael]: RESOLVED: use edge behavior
16:51:50 [dael]: 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]: zcorpan has joined #css
16:52:40 [dael]: 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 [dael]: krit: Webkit and FF ignore.
16:53:09 [dael]: krit: Proposal would be to make this rotate with 3 values to a matrix and do matrix decomposition
16:53:21 [dael]: astearns: This is an edge case b/c 3 value isn't used much?
16:53:26 [chris]: rrsagent, here
16:53:26 [RRSAgent]: See https://www.w3.org/2018/06/20-css-irc#T16-53-26
16:53:34 [dael]: krit: Yes. Edge case because css does not have 3 value so it's not often used.
16:54:13 [dael]: 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 [dael]: 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 [liam]: present+
16:55:20 [TabAtkins]: (I support the rotate(3-arg) being incompatible with anything.)
16:55:22 [dael]: 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 [dael]: 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 [dael]: krit: Can we agree on matix decomposition?
16:56:05 [dael]: astearns: Objections to make this rotate with 3 values to a matrix and do matrix decomposition
16:56:06 [chris]: ok I guess
16:56:17 [tantek_]: tantek_ has joined #css
16:56:17 [dael]: RESOLVED: make this rotate with 3 values transition to a matrix and do matrix decomposition
16:56:32 [dael]: Topic: the used value for border-box
16:56:39 [dael]: github: https://github.com/w3c/csswg-drafts/issues/999#issuecomment-391431901
16:57:35 [dael]: 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_]: zcorpan_ has joined #css
16:57:55 [dael]: krit: Proposal is every fallback we define would also be definable on transform. We'd add content box and stroke box
16:58:02 [dael]: smfr: Which spec will define the boxes?
16:58:12 [dael]: krit: Each spec defines mapping.
16:58:27 [dael]: fantasai: It would be fine to import the mapping to transform spec as it's more mature then fill/stroke
16:58:53 [dael]: 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 [dael]: astearns: Concerns with adding these values?
16:59:10 [dael]: fantasai: sgtm
16:59:22 [dael]: smfr: I think I'm okay with [missed]
17:00:02 [dael]: astearns: Sounded like smfr if okay but is not sure transforms is right place for dfinitions
17:00:12 [dael]: fantasai: Not sure where else. I guess fill/stroke is fine
17:00:25 [fantasai]: s/fine/fine, but it's a very early-stage WD/
17:00:26 [dael]: krit: That's why masking and transform already define it, but they do it the same way
17:00:46 [dael]: astearns: Given things move in different velocities we may defer to fill and stroke in a future transforms
17:00:56 [dael]: astearns: Objections to add these keywords to transform-box property?
17:01:03 [dael]: RESOLVED: add these keywords to transform-box property
17:01:06 [dael]: topic: end
17:01:24 [fantasai]: https://wiki.csswg.org/planning/sydney-2018
17:01:27 [dael]: 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 [astearns]: trackbot, end meeting
17:04:05 [trackbot]: Zakim, list attendees
17:04:05 [Zakim]: 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 [Zakim]: ... melanierichards, gregwhitworth, chrishtr, TabAtkins, chris, myles, krit, bradk, leaverou, liam, tantek
17:04:13 [trackbot]: RRSAgent, please draft minutes
17:04:13 [RRSAgent]: I have made the request to generate https://www.w3.org/2018/06/20-css-minutes.html trackbot
17:04:14 [trackbot]: RRSAgent, bye
17:04:14 [RRSAgent]: I see no action items