15:58:03 <RRSAgent> RRSAgent has joined #css
15:58:03 <RRSAgent> logging to https://www.w3.org/2021/06/09-css-irc
15:58:05 <Zakim> RRSAgent, make logs Public
15:58:06 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:58:11 <Rossen_> present+
15:58:29 <Morgan> present+
15:58:39 <dael> dael has joined #css
15:59:09 <miriam> present+
15:59:32 <dael> present+
15:59:36 <dael> ScribeNick: dael
15:59:48 <argyle> present+
16:00:07 <jfkthame> present+
16:00:17 <Gottfried> Gottfried has joined #css
16:00:23 <florian> present+
16:00:30 <dael> Rossen: We'll start in a couple minutes
16:00:40 <rachelandrew> present+
16:00:53 <alisonmaher> alisonmaher has joined #css
16:01:00 <alisonmaher> present+
16:01:23 <smfr> smfr has joined #css
16:01:24 <dael> Rossen: We'll give another minute and get going
16:01:36 <smfr> present+
16:02:17 <dholbert> present+
16:02:19 <dael> Rossen: It is 2 minutes past the hour, let's get going
16:02:28 <TYLin> present+
16:02:35 <dlibby> dlibby has joined #css
16:02:37 <dael> Rossen: As usual, I wanted to ask for any extra agenda items or agenda changes we want to do
16:02:51 <dlibby> present+
16:03:05 <dael> Rossen: Waiting on last minute agenda changes
16:03:10 <jensimmons> present+
16:03:11 <dael> Rossen: Let's assume there are none
16:03:20 <futhark> futhark has joined #css
16:03:23 <chrishtr> present+
16:03:25 <dael> Topic: [css-overflow-4] scrollbar-gutter is too complex
16:03:27 <cbiesinger> present+
16:03:36 <dael> Github: https://github.com/w3c/csswg-drafts/issues/4674
16:03:41 <futhark> present+
16:03:53 <dael> Rossen: Update of the breakout that took place last week
16:04:07 <TabAtkins> present+
16:04:19 <chris> chris has joined #css
16:04:25 <dael> Rossen: It also had spec text added to capture what was decided and discussed
16:04:28 <chris> present+
16:04:45 <dael> Rossen: I wanted to give chrishtr or florian a few minutes to recap and then see if we need resolutions
16:04:59 <GameMaker> GameMaker has joined #css
16:05:01 <dael> florian: WE had a meeting for about an hour
16:05:03 <GameMaker> present+
16:05:26 <dael> florian: Talked about scrollbar-gutter, figured out extent of use cases which are possible to address. Also focus on subset of values ew can be sure are good to ship soon
16:05:40 <dael> florian: Make sure we don't paint into a corner with incorrecct subset
16:06:00 <dael> florian: Stable is auto and stable values with a twist of making stable apply to overflow:hidden state as well
16:06:11 <oriol> oriol has joined #css
16:06:14 <dael> florian: With that addition auto and stable are the core subset to serve the main use case
16:06:25 <leaverou_> leaverou_ has joined #css
16:06:46 <dael> florian: The both value to apply to both sides is least controversial. Everything else has not been deleted but moved to non-normative appendix of things being explored.
16:07:18 <dael> florian: No radical redesign to what has been moved. Discussion during the call could leave to radical changes, but not there yet. Just moved off.
16:07:52 <dael> florian: One extra thing I did after the call is we had come complaints names were hard to figure out. I thought both value was tricky. For now, named to mirror to hopefully be more explicit
16:07:59 <dael> florian: We can bikeshed if you don't like
16:08:18 <Rossen_> q
16:08:44 <dael> florian: Spec now includes overflow:hidden, both named to mirror. Everything moved to appendix. Since remaining properties can only do anything to scroll containers applies to line has been changed from all elemetns to scroll container
16:08:50 <sanketj> sanketj has joined #css
16:09:03 <dael> florian: When we extend to the cases in the appendix may that will relax but not defined narrow
16:09:15 <florian> https://drafts.csswg.org/css-overflow-4/#scrollbar-gutter-property
16:09:20 <dael> florian: All this is in place. If that sounds good we leave spec as if. If it doesn't we have to make changes
16:09:24 <florian> https://drafts.csswg.org/css-overflow-4/#sbg-ext
16:09:25 <dael> florian: Main body of text ^
16:09:30 <dael> florian: Appendix ^
16:09:33 <hober> present+
16:09:38 <dael> Rossen_: Thanks florian
16:09:53 <oriol> present+
16:10:28 <dael> Rossen_: Given the extensive changes and discussion during the breakout I wanted to ask if there were any comments at the moment. If not we can use summary and links to propose any changes and then come back to resolve next week
16:10:31 <bkardell_> bkardell_ has joined #css
16:10:42 <TabAtkins> +1 to the changes
16:10:48 <leaverou_> present+
16:10:51 <chrishtr> q+
16:10:52 <bkardell_> present+
16:11:00 <dbaron[m]> Present+
16:11:03 <dael> florian: I will do a bit of triage o nthe rest of the spec to see where we're at. If nothing blocking I may ask for a new WD which could be occation to bless or reject
16:11:10 <Rossen_> ack chrishtr
16:11:19 <dael> chrishtr: I didn't fully understand Rossen_, suggesting delay to next week for resolution?
16:11:45 <dael> Rossen_: Inviting people to engage in comment now or given extent of changes we can give it a week for review. Is there are reason we can't wait?
16:11:57 <dael> chrishtr: Don't see reason to wait. It has been 2 weeks since breakout call
16:12:07 <dael> Rossen_: Trying to see if people have strong reasons to require the extra time
16:12:14 <plinss> present+
16:12:20 <dael> chrishtr: If anyone has such a concern we can wait. It didn't anticipate one
16:12:45 <dael> fremy: If everyone in call was fine with changes I think it will be okay. Would be great to know exact changes we will resolve on
16:13:17 <dael> Rossen_: That's my point, a lot of people missing on breakout call. They need full context before we can resolve. florian did a great job of summarizing, but it's not the details
16:13:35 <dael> florian: Other option is assume it's fine and let people raise issues with no deadline on that
16:14:03 <dael> Rossen_: Back to the WG and everyone interested. Does anyone need extra time to review the changes reflected in the spec? Or are we fine accepting now?
16:14:15 <dael> fremy: WOuld like to review, but fine to accept now and raise issues later
16:14:19 <dael> Rossen_: Okay. Anyone else?
16:15:02 <dael> Rossen_: Not hearing any strong reasons to delay the acceptance of the changes. Objections to accept the edited changes as described by florian ?
16:15:16 <dael> RESOLVED: accept the edited changes as described by florian
16:15:53 <dael> Rossen_: For those who need time to review, please open issues. And other part is naming of the new values which I'm sure we can come back to
16:16:18 <dael> florian: A heads up that stuff in the appendix is expected to change. I have ideas, but it's explicitly marked as unstable and no one is trying to ship that part
16:16:28 <dael> Topic: [css-color-adjust] Re-add only to mean "don't auto-adjust me", per WebKit's behavior
16:16:37 <dael> github: https://github.com/w3c/csswg-drafts/issues/5089
16:16:59 <TabAtkins> https://drafts.csswg.org/css-color-adjust/#color-scheme-override
16:17:24 <dael> TabAtkins: AS discussed earlier we want to re-add auto to turn off auto adjustingment. Means spec had to recongize. Edits are in and approved by smfr which is only browser currently doing auto adjusting.
16:17:35 <dael> TabAtkins: If people are cool we can accept edits. Also happy to adjust if there are concerns
16:17:36 <Rossen_> https://github.com/w3c/csswg-drafts/issues/5089#issuecomment-844525850
16:17:47 <dael> Rossen_: Proposal ^
16:17:51 <chrishtr> Looks good to me!
16:18:06 <dael> TabAtkins: Yes, end of comment is what went into spec
16:18:46 <dael> Rossen_: Assuming people have been able to read, additional comments or obj to accept changes and add only keyword?
16:18:58 <dael> RESOLVED: Accept changes and add only keyword
16:19:05 <dael> Topic: [css-color-adjust] viewport propagation of forced-color-adjust
16:19:13 <dael> github: https://github.com/w3c/csswg-drafts/issues/6307
16:19:18 <melanierichards> present+
16:19:23 <bradk> bradk has joined #css
16:19:38 <dael> alisonmaher: Currently prop from root and body to viewport. Since we force colors at used value time we can get wrong if don't prop forced-color-adjust to viewport
16:19:41 <bradk> present+
16:20:09 <dael> alisonmaher: We previously resolved not to prop any new properties from body to viewport but wondering if we should have an acception here so forced color does prop when set on body
16:20:18 <dael> TabAtkins: I see argument for it.
16:20:49 <dael> TabAtkins: As not a direct implementer I can't say if it's cool to add one more to the list, but I can see why it's confusing to figure out when color comes off body
16:21:21 <dael> Rossen_: Effect of not doing it? You may have bg of viewport that's different than forced?
16:21:45 <a-ja> a-ja has joined #css
16:21:53 <dael> alisonmaher: Set forced-color:adjust to none and want bg to be another color we would end up forcing the viewport bg color b/c it's not none at viewport. Wouldn't get bg color at the viewport
16:22:16 <futhark> q+
16:22:21 <dael> fantasai: Two comments. Seems bad practice to set forced-color-adjust none on body. Seems a bit user hostile to say I don't care what you want
16:22:56 <dael> fantasai: If concern is tweak color of bg we have similar problem with color scheme. If we prop one we should prop both. Not sure we should; we should encourage people to set in html
16:23:12 <dael> alisonmaher: If we were to do it for forced-color-adjust doing it for color-scheme would make sense as well
16:23:33 <Rossen_> ack futhark
16:23:52 <dael> futhark: I was thinking that is it really we should prop the property to viewport and not we should take into acocunt when prop. When try and prop bg we look at display value and if it's display:none it's not prop. Maybe similar
16:24:14 <Gottfried> Gottfried has joined #css
16:24:15 <dael> alisonmaher: Yeah, when look at f-c-s at used value time we could end up forcing hte prop value of viewport no matter what.
16:24:34 <dael> s/f-c-s/forced-color-adjust
16:25:35 <dael> Rossen_: Are options to leave as-is and use this as a soft mechanism to discourage such usage patterns by authors? otoh we can still add that same question applies to do we add back color scheme to the list
16:26:23 <dael> alisonmaher: Those are two options. One use case from author to set a bg color for svg image which are similar to root and viewport prop. To fix that we would need to prop from root to viewport. Hoping can resolve on prop from root. If doing for root might makes sense to do from body as well
16:26:39 <dael> Rossen_: Other opinions?
16:27:03 <dael> fantasai: If we're doing from root make sense to do from body as well statement doesn't make sense. Have lot of properties that prop from root but not body so don't think that holds
16:27:24 <dael> alisonmaher: If feel we shouldn't do from body I'm okay with that. Root piece is major thing looking for. Can see author confusion but wouldn't object
16:27:32 <emilio> +1 for doing it just for the root
16:27:45 <dael> fantasai: A bunch of scrolling properties that don't prop from body. We locked down to some css 2 properties
16:27:57 <fantasai> s/from body/from body even though overflow does/
16:28:22 <dael> Rossen_: Not hearing disagreement about root. Sounds reasonable. Convo seems to support adding to root. For body we've been making steady attempts to min exposure that's prop.
16:28:36 <dael> Rossen_: Sounds like current consensus is around adding to root but not body.
16:28:39 <dael> alisonmaher: That works
16:28:47 <dael> Rossen_: Other thoughts?
16:29:00 <dael> Rossen_: Obj to adding forced-color-adjust propagation to apply to root
16:29:14 <dael> RESOLvED: Add forced-color-adjust propagation to apply to root
16:29:23 <oriol> Note in https://github.com/w3c/csswg-drafts/issues/6079#issuecomment-816307011 we resolved "No future properties should propagate from <body> to the ICB"
16:29:26 <dael> Topic: [css-color-adjust-1] Spec currently breaks use of currentColor for SVG icons in WHCM
16:29:34 <dael> github: https://github.com/w3c/csswg-drafts/issues/6310
16:30:15 <dael> alisonmaher: This is around handling currentColor. AmeliaBR noted that SVG icons will not inherit appropriate forced-color through currentColor.
16:30:55 <dael> alisonmaher: 2 solutions. 1 undo the resolution to use forced colors at used value time. 2) intoduce a color only value that only adjusted color. Make that default for SVGs. b/c color only effects svg through currentColor works well for icon
16:31:18 <TabAtkins> q+
16:31:31 <dael> alisonmaher: Only possible unexpected is an svg ancestor set forced-color to none the svg would still set to currentCOlor. This seems rare so in favor of color-only. Looking for other opinions
16:31:43 <Rossen_> ack TabAtkins
16:32:11 <dael> TabAtkins: Definitely need to fix this. Only consideration to fix issue you raised could the value act as none if inheritied value is none but act as color if it's auto.
16:32:19 <dael> TabAtkins: Then it still works as expected
16:32:34 <dael> alisonmaher: Good idea. Will need to look into how to impl but could be good way to handle
16:32:40 <dael> TabAtkins: Seems reasonable to add, I'm in value
16:32:46 <dael> s/value/favor
16:33:16 <dael> Rossen_: Prop to fix the issue through a spec clarification and not adding color-only value?
16:33:52 <dael> TabAtkins: NO, still add value. The value acts as alisonmaher and AmeliaBR spec in auto case. If inherited is none it would act as none. It would automatically opt-out
16:33:55 <dael> Rossen_: I see
16:34:04 <dael> Rossen_: Other opinions or suggestions?
16:34:27 <dael> Rossen_: alisonmaher do you want a resolution now? Or do you prefer to go back and figure out if implementable?
16:34:44 <dael> alisonmaher: Can resolve and come back if impl is tricky. Seems adding color-only value we can resolve on
16:35:02 <dael> Rossen_: Objections to add color-only value as described in the issue and clarified by TabAtkins
16:35:09 <dael> RESOLVED: add color-only value as described in the issue and clarified by TabAtkins
16:35:19 <dael> Topic: [css-variables] Whitespace-trimming and custom properties.
16:35:26 <dael> github: https://github.com/w3c/csswg-drafts/issues/6345
16:35:54 <dael> emilio: This one; we resolved a while ago on trimming whitespace from decorations. TabAtkins pointed out some examples invalid in impl should be valid.
16:36:28 <dael> emilio: For system prop fallback there's no trimming. Felt odd when impl that if you're using fallback in computed you get whitespace but if the fallback you have a variable it's stringed.
16:36:40 <TabAtkins> q+
16:36:45 <dael> emilio: Trimming whitespace from fallback functions would be simpliest. I think in general makes sense
16:37:01 <dael> Rossen_: Feedback?
16:37:09 <leaverou_> q?
16:37:29 <Rossen_> ack TabAtkins
16:37:49 <dael> TabAtkins: Yes, we absolutely should. That this doesn't work is accident of css rules for comma omission. You have to omit comna when not separating but this is the case where lack of a thing can be a thing. Need something in var to set the exception that you can set a comma
16:37:55 <dael> emilio: fwiw it's very easy to impl
16:38:07 <dael> Rossen_: Other feedback? leaverou_ you're in issue?
16:38:16 <dael> leaverou_: I added my thoughts to issue. I support that change
16:38:17 <TabAtkins> `foo(--a,)` is currently syntacitcally invalid, and that is good for everything *but* `var()`
16:38:27 <dael> Rossen_: Obj to adding the spec proposal?
16:38:45 <dael> Resolved: Accept the proposal
16:38:53 <dael> Topic: should it be possible for an element with contain:paint to be part of a transform-style:preserve-3d scene?
16:39:03 <dael> github: https://github.com/w3c/csswg-drafts/issues/6202
16:39:46 <dael> TabAtkins: The summary is when you have a preserve3d transform nothing prevents a contain:paint participate in the 3d scene.
16:40:02 <dael> TabAtkins: A bunch of properties restricted to force it to become flat so children are container
16:40:10 <dael> TabAtkins: contain:paint should work the same
16:40:26 <smfr> overflow does NOT create a graphical group
16:40:35 <dael> TabAtkins: Spec also allows overflow-clip to have children leave element entirely and florian pointed out that doesn't make sense.
16:40:41 <smfr> q+
16:40:53 <dael> TabAtkins: If we're having overflow:contain-paint to cause flattening we should have them both
16:41:20 <dael> TabAtkins: Prop: add contain-paint to list of grouping properties that force it to be flat. Remove clip value form exceptions so it also causes it to be flat
16:41:37 <dael> smfr: I think this is right thing. I think contain-paint causes stacking but should flatten
16:41:49 <dael> smfr: I think TabAtkins said non-visbile overflow creates stacking?
16:41:54 <Rossen_> ack smfr
16:42:06 <dael> TabAtkins: Overflow-clip is on list of values that don't cause flattening. Feels weird. I think it should
16:42:13 <chrishtr> agree that clip and contain:paint should cause flattenign
16:42:13 <dael> smfr: That's fine. I agree with proposal
16:42:22 <TabAtkins> s/overflow-clip/overflow:clip/
16:42:24 <dael> dbaron[m]: I agree as well
16:42:33 <dael> Rossen_: Other feedback or objections?
16:42:51 <dael> smfr: Prop to make coverflow:clip a grouping property. Impl it creates stacking context?
16:42:54 <dael> florian: DOn't think so
16:42:58 <dael> smfr: Think it does
16:43:39 <dael> dbaron[m]: We do have that grouping prop create stacking context. That said, I wrote a test a few weeks ago to see what rbowsers made group. Tested with transform flattening and mixed blend and got entirely different results in all browsers.
16:43:53 <dael> dbaron[m]: Given that I think we don't have a good sense of grouping
16:44:06 <dael> smfr: Testing with opacity or filters might have given more consistent
16:44:19 <dael> smfr: I don't want to separate grouping from stacking context. Would create complexity
16:44:29 <dael> florian: I don't think the grouping are defined to create stacking
16:44:48 <dael> dbaron[m]: Don't have a spec for this. I did have understanding that the set of things grouping is subset of things that create stacking
16:45:01 <dael> TabAtkins: Happy to remove overflow:clip part and just do contain-paint
16:45:05 <dbaron[m]> the test I'm talking about was https://dbaron.org/css/test/2018/stacking-context-z-order
16:45:27 <dael> smfr: contain-paint can imply overflow:clip. Would love overflow properties that create stacking, but that ship has sailed
16:45:47 <dael> Rossen_: TabAtkins just resolve on contain:paint and leave overflow:clip for now?
16:45:50 <dael> TabAtkins: Yes
16:46:05 <dael> Rossen_: That's the proposal. thoughts or objections?
16:46:45 <dael> florian: Thought; maybe misunderstanding. Seems it's not necessary for overflow:clip to flatten a 3d transform b/c can position in 3d model. If when it's time to paint the projection is outside area you paint you clip
16:47:00 <dael> smfr: Please don't make clipping a thing we nee din 3d scenes
16:47:05 <smfr> q+
16:47:16 <dael> Rossen_: Great convo that should happen when additional investigation of overflow:clip takes place
16:47:45 <dael> smfr: If we resolve on this do we need to resolve on if will-change contains side effects. From dbaron[m] chart it does nto have stacking.
16:47:51 <dael> TabAtkins: Can you open as separate issue?
16:47:52 <dael> smfr: Yes
16:48:08 <dael> Rossen_: not hearing objection sot contain:paint
16:48:15 <dbaron[m]> I think will-change's definition is pretty clear about what's supposed to happen...
16:48:21 <dael> RESOLVED: add contain:paint to list of grouping properties
16:48:31 <dael> Rossen_: Anything else on this?
16:48:39 <dael> Topic: [mediaqueries] display mode media feature
16:48:48 <dael> github: https://github.com/w3c/csswg-drafts/issues/6343
16:48:59 <dael> florian: Media feature in a non MQ spec. Should it move?
16:49:29 <dael> florian: Currently in [missed] spec. Let's you tell if app is in full screen or normal context or if it has minimal UI
16:49:50 <dael> florian: That exists. I think shipped in everything. I think we should adopt it
16:49:56 <Rossen_> q?
16:49:59 <Rossen_> ack smfr
16:50:15 <dael> TabAtkins: Since it's been shipped it's stable. Happy to pull in. Should at least mention, but I think we can pull in
16:50:21 <TabAtkins> s/[missed]/App Manifest/
16:50:29 <dael> Rossen_: florian have you been engaged to make sure this is their intent?
16:50:34 <dael> florian: Request is coming from them
16:50:49 <dael> Rossen_: Objections to adopt this as a part of MQ
16:50:54 <dael> RESOLVED: adopt this as a part of MQ
16:51:02 <dael> Topic: [css-sizing] Removing intrinsic aspect-ratio from an image
16:51:11 <dael> github: https://github.com/w3c/csswg-drafts/issues/6257
16:51:34 <dael> TabAtkins: This was agenda+ in an earlier week and discussed. Label wasn't removed. Was that intentional?
16:51:53 <dael> TabAtkins: Still active discussion in issue. Wanted to make sure something to discuss here.
16:52:04 <dael> dbaron[m]: bot's rule is it only removes if there's a resolution
16:52:28 <dael> Rossen_: Right. Since not resolved it's been kept there. Happy to push it back to GH for discussion
16:52:32 <dael> github: none
16:52:39 <dael> Topic:  [css-sizing-3] compressible elements with aspect ratio
16:52:48 <dael> github: https://github.com/w3c/csswg-drafts/issues/6341
16:53:34 <dael> fantasai: iank_ noted we allow compressable to compress when have % width or max width. WE floor with explicit min size.
16:53:52 <Rossen_> q?
16:53:59 <dael> fantasai: Suggested things with a-r might want to consider min in other dimension. a-r and a min height might wantt to floor compression of width
16:54:15 <dael> fantasai: Wanted to ask WG if we want to spec that in Sizing 3. No one impl but iank_ wants to try
16:54:19 <dael> iank_: I think FF may impl it
16:54:28 <dael> iank_: in some cases.
16:54:39 <dael> Rossen_: What is % resolved in this case?
16:54:52 <dael> fantasai: Case where they don't resolve. Want min content contribution of the item.
16:55:12 <dael> fantasai: Usually we use natural size. When have % width we allow compress to close to 0. Exists for compat
16:55:33 <dael> Rossen_: Want to resolve the min width calc base on min-height b/c we have a-r
16:55:41 <dael> Rossen_: And if min height is also %?
16:55:47 <dael> fantasai: Wouldn't transfer anything, I think
16:55:58 <dael> Rossen_: And we would fav or over min-width that's spec
16:56:05 <dael> fantasai: I think we would honor spec min-width
16:56:14 <dael> fantasai: iank_ thoughts on that
16:56:24 <iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9399
16:56:27 <dael> iank_: It would take the maximum if min width and height are spec and don't agree
16:56:48 <dael> iank_: % would resolve if they can, similar to today. Can get cases where %height will resolve. Link to case^
16:57:02 <dael> iank_: You can see image is distorted. Doesn't have to be
16:57:44 <dael> Rossen_: My take is in general this make sense. Too many details. I think it would benefit if we tried to capture a short table of interaction and expected resolution
16:57:58 <dael> Rossen_: And expected values as to if % or spec and which wins
16:58:12 <dael> Rossen_: Would this be something iank_ you want to take on?
16:58:38 <dael> iank_: I can create a simple table. Should be straight forward. Order already resolves % if we can so straight forward
16:58:47 <dael> Rossen_: Cool. We can bring it next week and resolve
16:59:09 <dael> Topic: anything fast?
16:59:23 <dael> Rossen_: I'll give everyone some seconds back
16:59:31 <dael> Rossen_: We'll start from these issues next week
16:59:40 <chris> Issues 15 and 16 have been resolved meantime
16:59:59 <dael> Rossen_: Thank you for calling. Have a great rest of your week
17:01:20 <Rossen_> Zakim, end meeting
17:01:20 <Zakim> As of this point the attendees have been Rossen_, Morgan, miriam, dael, argyle, jfkthame, florian, rachelandrew, alisonmaher, smfr, dholbert, TYLin, dlibby, jensimmons, chrishtr,
17:01:23 <Zakim> ... cbiesinger, futhark, TabAtkins, chris, GameMaker, hober, oriol, leaverou_, bkardell_, dbaron[m], plinss, melanierichards, bradk
17:01:23 <Zakim> RRSAgent, please draft minutes v2
17:01:23 <RRSAgent> I have made the request to generate https://www.w3.org/2021/06/09-css-minutes.html Zakim
17:01:25 <Zakim> I am happy to have been of service, Rossen_; please remember to excuse RRSAgent.  Goodbye
17:01:29 <Zakim> Zakim has left #css
17:51:40 <AndroUser> AndroUser has joined #css
18:17:08 <jensimmons> jensimmons has joined #css
18:19:02 <a-ja> a-ja has joined #css
18:30:44 <Gottfried> Gottfried has joined #css
18:51:47 <Gottfried> Gottfried has joined #css
19:55:35 <dholbert> dholbert has joined #css
21:49:04 <dauwhe> dauwhe has joined #css
22:09:30 <jensimmons> jensimmons has joined #css
22:13:05 <dauwhe> dauwhe has joined #css
22:27:52 <fantasai> cbiesinger: Can you help with https://github.com/w3c/csswg-drafts/issues/5843 ?
22:28:43 <cbiesinger> uhh
22:28:51 <cbiesinger> good question
22:29:05 <cbiesinger> can you ping dgrogan for now? I'm pretty busy with other things
22:29:13 <cbiesinger> such as a release blocker, right now :(
22:29:16 <fantasai> :(
22:29:20 <fantasai> good luc
22:29:22 <fantasai> k
22:29:32 <cbiesinger> thanks
22:29:52 <cbiesinger> turns out it's bad if select dropdowns appear half a page away and twice as big as they should
22:38:44 <tantek> tantek has joined #css
22:41:59 <dauwhe> dauwhe has joined #css
22:44:28 <astearns> if they show up far away from where they should be, then at least a larger target compensates a bit
22:48:26 <cbiesinger> heh
23:20:12 <dauwhe> dauwhe has joined #css
23:33:55 <dauwhe> dauwhe has joined #css
23:44:55 <jensimmons> jensimmons has joined #css
23:45:12 <dauwhe> dauwhe has joined #css
23:45:16 <dauwhe> dauwhe has joined #css