15:55:55 <RRSAgent> RRSAgent has joined #css
15:55:55 <RRSAgent> logging to https://www.w3.org/2021/07/14-css-irc
15:55:58 <Zakim> RRSAgent, make logs Public
15:55:59 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:58:14 <smfr> smfr has joined #css
15:59:20 <bradk> bradk has joined #css
15:59:47 <fantasai> Scribenick: fantasai
16:00:50 <jfkthame> jfkthame has joined #css
16:01:11 <Morgan> Morgan has joined #css
16:01:32 <alisonmaher> alisonmaher has joined #css
16:01:38 <alisonmaher> present+
16:01:43 <miriam> present+
16:01:54 <smfr> present+
16:02:00 <TabAtkins> getting ahead a bit: elika and I haven't had time to meet yet to discuss #2 (the aspect ratio issue) - we'll be doing so tomorrow. we should bump this to next week.
16:02:03 <dandclark> present+
16:02:09 <astearns> OK, thanks
16:02:27 <cbiesinger> present+
16:02:28 <dbaron[m]> Preent+
16:02:31 <plinss> present+
16:03:03 <Rossen_> Rossen_ has joined #css
16:03:04 <bkardell_> present+
16:03:09 <Rossen_> present+
16:03:21 <Morgan> present+
16:03:30 <bmathwig> bmathwig has joined #css
16:03:36 <fantasai> astearns: pushing item 2 to next week
16:03:39 <astearns> https://lists.w3.org/Archives/Public/www-style/2021Jul/0007.html
16:03:42 <CSSWG_LogBot> CSSWG_LogBot has joined #css
16:03:48 <fantasai> astearns: adding request for css-color-5 WD
16:03:54 <fantasai> astearns: any other changes to agenda?
16:04:03 <jensimmons> jensimmons has joined #css
16:04:03 <fantasai> Topic: CSS Color 5
16:04:11 <fantasai> astearns: We'd agreed to publish after changes in for color-adjust
16:04:15 <fantasai> astearns: Those changes now in
16:04:19 <fantasai> astearns: Any objections to publishing?
16:04:32 <florian> present+
16:04:32 <fantasai> RESOLVED: update WD of css-color-5
16:04:34 <rachelandrew> present+
16:04:55 <bmathwig> present+
16:04:55 <fantasai> Topic: Agenda
16:04:56 <emilio> present+
16:05:01 <fantasai> Rossen_: ...
16:05:11 <fantasai> astearns: Two weeks from now we're having long-form vF2F meetings intead of the Wed call
16:05:23 <lea> lea has joined #css
16:05:23 <fantasai> astearns: People have started adding items to that agenda
16:05:37 <fantasai> astearns: Please look into what topics would be good to cover during those meetings and add to agenda
16:06:06 <fantasai> Rossen_: Also, there's a Color API meeting tomorrow. Seems everyone has agreed to move to 10am Pacific (except haven't heard from Pierre)
16:06:06 <dholbert> dholbert has joined #css
16:06:24 <fantasai> Rossen_: Lea, can you update the calendar?
16:06:34 <fantasai> lea: I don't have access, maybe ChrisL can do it?
16:06:44 <fantasai> Topic: Counter Styles
16:06:52 <fantasai> https://lists.w3.org/Archives/Public/www-style/2021Jul/0000.html
16:06:52 <astearns> https://lists.w3.org/Archives/Public/www-style/2021Jul/0000.html
16:07:14 <fantasai> astearns: Has changes list, Disposition of Comments, some HR responses, all described in link above
16:07:24 <fantasai> astearns: My only question is about tests, are there updated tests for the changes?
16:07:34 <chris> chris has joined #css
16:07:53 <fantasai> [silence]
16:08:10 <chris> present+
16:08:13 <fantasai> astearns: It would be nice, and will be needed to progress any further
16:08:19 <chris> looks good to me
16:08:22 <fantasai> astearns: Any other comments on this?
16:08:24 <fantasai> astearns: Any objections?
16:08:33 <fantasai> RESOLVED: Publish updated CR of css-counter-styles-3
16:08:38 <chris> so is this a CRS or CRD?
16:08:43 <fantasai> CRS
16:08:59 <fantasai> Topic: Cascade 5
16:09:02 <chris> fantasai you will do the transition request?
16:09:07 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6407
16:09:25 <fantasai> miriam: Question was about defining layers defined inside global conditions like @media
16:09:36 <fantasai> miriam: but open issue about non-global condition like container queries
16:09:40 <florian> s/fantasai you will do the transition request?//
16:09:46 <fantasai> miriam: Thread concluded should always affect layer order
16:09:56 <fantasai> TabAtkins: Looks good
16:10:07 <fantasai> emilio: How do auto-conditionals behave inside container queries?
16:10:19 <fantasai> emilio: Is there a real use case for this?
16:10:31 <fantasai> miriam: If you want some of the things in the container query to be layered or not
16:10:55 <TabAtkins> fantasai: the clarification here is that there's no particular use-case for the layer existing or not conditionally, but there is a use-case for having layered styles in there, so we ahve to define it
16:11:03 <fantasai> emilio: Unfortunate to have to traverse everything
16:11:14 <fantasai> emilio: when building data structure, when finding media/supports query that doesnt' match
16:11:17 <fantasai> emilio: just skip all the rules
16:11:27 <fantasai> emilio: but here you are forced to read all the rules on the page
16:11:42 <fantasai> miriam: you have to do that anyway, because container queries aren't global, you have to read them to understand the page
16:11:47 <fantasai> TabAtkins: I think emilio misunderstood
16:11:56 <fantasai> TabAtkins: in global conditionals, they are conditional
16:12:07 <fantasai> emilio: Oh, I thought we were reverting on that. No, this makes sense.
16:12:14 <fantasai> astearns: Other comments on this?
16:12:44 <fantasai> astearns: If layer is introduced in a container query rule, it always affects layer order, whether or not that query matches anything
16:12:52 <fantasai> miriam: more broadly, any non-global condition
16:12:56 <fantasai> astearns: Any other non-globls?
16:12:59 <fantasai> miriam: Not yet
16:13:17 <fantasai> astearns: Adding that as the reason for this requirement would probably help future spec development, so add editorially
16:13:38 <fantasai> RESOLVED: If a layer is introduced in a non-global conditional rule (such as a container query), it always affects the layer order, whether or not that query matches
16:13:45 <fantasai> Topic: Values and Units L4
16:14:07 <TabAtkins> ScribeNick: TabAtkins
16:14:11 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/4329#issuecomment-863677668
16:14:26 <TabAtkins> fantasai: Tab and I comitted the changes for our earlier resolution on these joint issues (this and next)
16:14:26 <dholbert> present+
16:14:28 <fantasai> https://github.com/w3c/csswg-drafts/issues/6113
16:14:30 <jfkthame> present+
16:14:38 <Rossen_> q
16:14:44 <TabAtkins> fantasai: we resolved to add viewport units to represent the "small" and "dynamic" viewport
16:14:53 <TabAtkins> fantasai: there are a couple open qustions still
16:15:01 <TabAtkins> fantasai: One was whether dynamic should be a unit or an env()
16:15:14 <TabAtkins> fantasai: We went for unit based on comments from Rachel Andrews that it would be easier to teach
16:15:24 <TabAtkins> fantasai: Main reason for env() was to deliberately make it more awkward to use.
16:15:38 <TabAtkins> fantasai: Right now tho, the draft is using units; we can reopen that discussion if people wish
16:15:58 <TabAtkins> fantasai: Other question is we have an unprefixed set of units (vw/etc) and two prefixed sets (svw/etc, dvw/etc)
16:16:13 <TabAtkins> fantasai: Do we want an explicit set of "larger" prefixed units for symmetry?
16:16:42 <TabAtkins> fantasai: And if we do that, should we allow the unprefixed values to do something smarter? Right now they're the larger viewport, but this causes some troubles and browsers might want to do something smarter.
16:16:53 <TabAtkins> fantasai: So do we want to give CSS some flexibility for the unprefixed units?
16:17:11 <TabAtkins> fantasai: So first quesiton to tackle: anyone want us to switch the dynamic units to being an env()?
16:17:28 <TabAtkins> jensimmons: I think it works well as a unit. Authors will need and use it, and having it be the same as the other units will make it much easier to use.
16:17:38 <florian> +1
16:17:40 <miriam> +1
16:17:42 <rachelandrew> +1
16:18:33 <TabAtkins> Rossen_: Do we ahve a particularly well-defined guidance on how and when to add value types vs env()? It woudl be unfortunate if we end up in a situation where scrollbar-width is in an env() but viewport-width is in a unit, etc
16:18:49 <TabAtkins> fantasai: We don't have this written down, but the basic principle is if you're likely to want multiples of this other than 1.
16:19:03 <TabAtkins> fantasai: Like for safe-area-inset, you don't want 30% of it, or 5x that.
16:19:22 <TabAtkins> fantasai: You might add some more length to it, some extra px or something, but very unlikely to want to multiply it by a number.
16:19:47 <TabAtkins> fantasai: But for viewport units it's very common to want 50vh/etc, so it makes more sense to be a unit where it's easier to do that
16:20:04 <TabAtkins> Rossen_: I can see how this could make sense from a usage pov
16:20:22 <masonf> masonf has joined #css
16:20:28 <TabAtkins> Rossen_: At the same time I could argue the inset should be a unit regardless of whether you'd want it to be x1 or not
16:20:30 <masonf> present+
16:20:47 <TabAtkins> florian: Other factor is if the value depends on where you are in the tree, it must be a unit. If it doesn't, either works.
16:20:50 <lea> present+
16:21:02 <TabAtkins> florian: For example, width of scrollbars cannot be an env() because it changes based on the unit you're applying it to.
16:21:17 <TabAtkins> emilio: Having units depend on computed values of properties is kinda sketchy...
16:21:40 <TabAtkins> florian: Sure, but still like having font-size expressed in an env() doesn't make sense, so you need em
16:21:45 <bmathwig> width of scrollbars can't change depending on element, it's fixed in most UA implementations
16:21:57 <TabAtkins> emilio: Sure, tho there's only two scrollbar widths. Could still be done as two env()s
16:22:23 <TabAtkins> plinss: I don't feel too strongly, but I'm a little concerned about proliferation of units.
16:22:23 <florian> bmathwig, see https://drafts.csswg.org/css-scrollbars/#scrollbar-width
16:22:43 <TabAtkins> plinss: If the non-unit syntax ends up unwieldy, we can work on that.
16:23:09 <TabAtkins> Rossen_: Basically same for me. I'd also like us to formulate a more general reasoning for when to use units vs env()
16:23:13 <bmathwig> auto | thin | none only applies to classical scrollbars and not overlay scrollbars that have zero-width in layout computations
16:23:16 <bradk> present+
16:23:39 <TabAtkins> Rossen_: But overall I don't object.
16:23:42 <bmathwig> Blink is moving towards overlay scrollbars on Windows in the next few months
16:23:49 <TabAtkins> fantasai: Okay so it sounds like we should resolve on dvh being units
16:24:09 <fantasai> bmathwig, that doesn't change the matter of the width of the scrollbar, only how much space it takes up in layout
16:24:14 <TabAtkins> RESOLVED: "dynamic" viewport does indeed use units, not env()
16:24:22 <TabAtkins> fantasai: So next is about unprefixed units.
16:24:35 <TabAtkins> fantasai: Do we want an explicit large-prefixed set to go with the others?
16:24:46 <bradk> bradk has joined #css
16:24:54 <TabAtkins> jensimmons: been a lot of convo on WK team last week about how these work
16:25:08 <TabAtkins> jensimmons: We feel very strongly there should be an lvh unit
16:25:40 <TabAtkins> jensimmons: And the vh unit should no longer be defined as longest length; it should instead be something more flexible that the UA can decide on based on what they're doing with their particular browser
16:25:41 <bmathwig> fantasai, very true
16:25:46 <lea> I'm all up for making vw/vh more useful, but how web compatible is this change?
16:26:03 <dholbert_> dholbert_ has joined #css
16:26:16 <TabAtkins> florian: I see why you'd want the flexibility for this, to provide best UX possible, I'm concerned about variance in behavior that would cause content to be off-screen in one browser, etc.
16:26:24 <TabAtkins> fantasai: tbf that's already happening today
16:26:39 <TabAtkins> jensimmons: Lea made a comment about webcompat, that's absolutely a concern
16:26:50 <lea> q?
16:27:02 <TabAtkins> jensimmons: I think having this be flexible so UA can make the best decision to present the fewest compat problems
16:27:20 <TabAtkins> jensimmons: And by giving authors the explicit lvh and others let them choose the right one for their website
16:27:33 <florian> I'm sold :)
16:27:39 <lea> +1 for this change from me
16:27:40 <TabAtkins> jensimmons: But browsers may need flexibility to redefine that vh itself based on individual pages
16:27:46 <fantasai> +1 from me also
16:27:59 <TabAtkins> emilio: I think any change to vh should probably be a [...? missed]
16:28:19 <TabAtkins> emilio: I think we want a definition in the spec we can implement interoperably
16:28:50 <emilio> s/be a ?/ consider compat, but...
16:28:52 <TabAtkins> fantasai: So I think we have agreement to add "large" viewport units, make vh/etc ambiguous at the moment (and gradually make it clear what this actually means)
16:29:10 <TabAtkins> fantasai: So for now we say it's UA-defined and it must fall in the range of svh and lvh
16:29:28 <TabAtkins> florian: Also a note that if any UA uses the flexibility to make it something other than the three explicit ones, come back to the group and spec it
16:29:42 <TabAtkins> emilio: Can we file an issue to explore the compat of vh/etc?
16:29:58 <TabAtkins> fantasai: We should also have an issue about what is the ICB in these cases, and that's probably the same
16:30:08 <florian> s/and spec it/so that we can see if it is something we could spec/
16:30:18 <fantasai> s/probably the same/probably should be the same as the unprefixed units/
16:30:45 <TabAtkins> jensimmons: I noticed in the discussion there was some discussion about the "l" standing for "layout viewport", but I like it better to be "longest"
16:31:09 <florian> +1 to s/d/l as the naming
16:31:10 <TabAtkins> fantasai: Earlier we were thinking we'd use an "l" prefix for the dynamic one. Now we're gonna do small/large for s/l, or short/long, whichever you prefer to talk about
16:31:21 <TabAtkins> RESOLVED: Add lvh as explicit "large viewport" unit
16:31:33 <TabAtkins> astearns: So second is about redefining vh
16:31:40 <TabAtkins> fantasai: Currently the spec is actually extremely vague
16:31:46 <TabAtkins> fantasai: it just says "it's the size of the viewport"
16:31:55 <TabAtkins> fantasai: So the resolution here would be to maintain the ambiguity
16:32:11 <TabAtkins> florian: Maintain ambiguity or explicitly say it's UA-defined?
16:32:15 <TabAtkins> fantasai: I'm fine with either
16:32:23 <TabAtkins> florian: I'd prefer UA-defined with the note i said earlier
16:32:32 <TabAtkins> florian: About UAs reporting to the WG if they do somethign creative
16:32:57 <TabAtkins> astearns: Any objections?
16:33:11 <fantasai> scribe+ TabAtkins
16:33:13 <TabAtkins> RESOLVED: vh/etc are deliberately UA-defined
16:33:47 <TabAtkins> fantasai: That should be it for this issue, tho we need to open that issue about the nuances of vh
16:34:09 <TabAtkins> astearns: I'd encourage people to file new issues for any further discussions, these issues got long and intertwined and it'll be easier with new issues
16:34:20 <fantasai> Topic: Publishing Values 4
16:34:23 <fantasai> https://drafts.csswg.org/css-values-4/#changes
16:34:34 <TabAtkins> fantasai: I'll fold in these edits we just agreed to
16:34:39 <TabAtkins> fantasai: But besides that we have a handful of changes
16:34:47 <TabAtkins> fantasai: So we need a resolution to publish
16:34:52 <TabAtkins> astearns: This just a regular WD?
16:34:55 <TabAtkins> fantasai: yup
16:35:03 <TabAtkins> astearns: Objections to pub?
16:35:15 <TabAtkins> RESOLVED: New WD of Values 4, after viewport units edits have been made
16:35:25 <fantasai> Topic: css-overflow-3
16:35:28 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/4791#issuecomment-862553085
16:35:54 <TabAtkins> fantasai: If an element has zero area in its border box, it doesn't directly contribute to scrollable overflow
16:36:07 <TabAtkins> fantasai: It can have indirect effects, if it increases the height of its parent box or something
16:36:20 <TabAtkins> fantasai: But the element *itself* doesn't appear to do anything in impls. Should we add that to the spec?
16:36:40 <TabAtkins> astearns: Seems reasonable
16:36:56 <TabAtkins> florian: Yes, both because interop is good to spec, and because authors really hate when invisible boxes have side-effects
16:37:04 <TabAtkins> astearns: Would be great to have these tested properly too
16:37:27 <bradk> bradk has joined #css
16:37:28 <TabAtkins> astearns: So proposed resolution is to specify that zero-area border-box elements do not directly contribute to scrollable overflow area
16:37:41 <TabAtkins> astearns: Objections?
16:37:57 <TabAtkins> RESOLVED: Elements with a zero-area border-box do not directly contribute to scrollable overflow area.
16:38:13 <fantasai> Topic: accent-color background colors and contrast
16:38:20 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6159#issuecomment-877023330
16:38:25 <fantasai> scribenick: fantasai
16:38:41 <fantasai> ??: tldr of issue is, the spec, as written today, takes one color for accent-color
16:38:54 <fantasai> ??: form controls drawn with that color need to make sure they have enough contrast with other parts
16:38:56 <astearns> s/??/masonf/
16:39:03 <fantasai> masonf: Opened issue to discuss
16:39:21 <fantasai> masonf: Depending on how implemented, if you change accent-color slightly, the contrasting pieces can change abruptly from light to dark color to maintain contrast
16:39:27 <fantasai> masonf: Where we are now is that we would prefer to just close the issue
16:39:36 <fantasai> masonf: The discussion has been, should we allow the developer to spec more than one color
16:39:47 <fantasai> masonf: and we went around about that last year, and don't want to open can of worms again
16:40:03 <fantasai> masonf: we think it'd be better for dev to be able to do that, but happy to just close issue and leave behavior up to UA
16:40:07 <florian> q+
16:40:15 <fantasai> emilio: Idk where the disagreement is...
16:40:29 <fantasai> emilio: What Chrome implements is that the switch to dark foreground color based on ??
16:40:42 <fantasai> emilio: Firefox does something similar, but not sensitive to color-scheme
16:40:49 <fantasai> emilio: It's different in some places
16:40:58 <fantasai> emilio: So I think specifying foreground/background pair would make sense here
16:41:00 <fantasai> emilio: but ...
16:41:13 <fantasai> masonf: The way we're currently implementing this, we have a set colors for light mode and dark mode
16:41:24 <fantasai> masonf: we calculate contrast ratio, and choose the one with most contrast
16:41:31 <fantasai> masonf: It seems to work ok
16:41:37 <fantasai> masonf: does guarantee minimum level of contrast
16:42:02 <fantasai> masonf: I think allowing specifying foreground+background color would be better
16:42:09 <fantasai> masonf: but the consensus previously was to allow UA to innovate on form controls
16:42:16 <fantasai> masonf: and allowing author to spec 2 colors would hamper that
16:42:33 <fantasai> emilio: why doesn't specify one color create a problem. 2 colors is more flexible
16:42:37 <astearns> ack florian
16:42:44 <fantasai> florian: Agree I don't want to reopen the entire conversation
16:42:48 <fantasai> florian: would like to stick to 1 color
16:42:54 <fantasai> florian: Agree that UA should pick however it want
16:43:05 <fantasai> florian: We might want to add a note reminding UAs that they don't have to pick *the most* contrasting color
16:43:16 <fantasai> florian: They could take into account e.g. color-scheme
16:43:22 <fantasai> florian: as long as enough contrast, have a choice of colors
16:43:30 <lea> Totally agree that accent-color should be 1 color
16:43:30 <fantasai> florian: but reopening question of one vs two, would prefer to avoid
16:43:39 <lea> q?
16:43:41 <fantasai> emilio: 1 color is going to be a mess compat wise
16:44:13 <fantasai> hober: To summarize, disagreement from what I remember, was not about having 1 or 2 colors in general
16:44:24 <fantasai> hober: was about how exact to specify how those two colors would be used
16:44:35 <fantasai> hober: which one should be foreground, which background, which pieces of which form elements should get which colors
16:44:51 <fantasai> hober: other side wanted to leave to UA, might be different plaform conventions or form styling that would lend themselves to using colors differently
16:45:11 <fantasai> emilio: I think it's silly to get stuck with one color
16:45:24 <fantasai> emilio: But then seems disagreement wasn't about one vs two colors
16:45:29 <fantasai> florian: multiple hours of disagrement
16:45:59 <fantasai> fantasai: There *are* two colors available to the UA. If 'color' is appropriate, you *can* use it.
16:46:14 <fantasai> emilio: I don't think that would work.
16:46:35 <tantek> tantek has joined #css
16:47:01 <RRSAgent> I'm logging.  Sorry, nothing found for 'link'
16:47:28 <fantasai> fantasai: We can't do this in general, because form controls have different conventions and some of them are a lot more complicated than checkboxes
16:47:28 <lea> q+ to say, is this trying to solve a non-problem? I understand the abruptness may be jarring if you are trying multiple colors like in these testcases, but as long as the UA selected colors have sufficient contrast, is it really a problem? Are people going to animate accent-color?
16:47:35 <fantasai> florian: This discussion has happened already.
16:47:54 <fantasai> astearns: Any objection to moving forward with one color
16:48:00 <fantasai> emilio: no. I just think it's a bad decision
16:48:04 <lea> q-
16:48:08 <fantasai> RESOLVED: Close issue, one color accent-color for now
16:48:17 <fantasai> Topic: Scrollbar Styling
16:48:28 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6349
16:48:29 <astearns> ack fantasai
16:48:30 <Zakim> fantasai, you wanted to mention calendar widgets
16:48:43 <fantasai> florian: Some confusion over the name of 'both'
16:48:52 <fantasai> florian: Set of edits landed after a side-meeting, renamed it to 'mirror'
16:49:00 <fantasai> florian: Some people said maybe it should be 'both-sides' or 'both-edges'
16:49:07 <fantasai> florian: All of them are clearer than what we have now
16:49:16 <fantasai> florian: Current ED went with mirror because both clearer and short
16:49:27 <fantasai> florian: Anyone have any comments?
16:49:41 <fantasai> astearns: Minor preference for a longer one
16:49:51 <fantasai> florian: I prefer one I went with, but wouldn't object to switching either
16:49:59 <TabAtkins> I'm fine with "mirror" after some thought
16:50:01 <TabAtkins> it's grown on me
16:50:05 <bmathwig> +1 for both-edges
16:50:09 <fantasai> astearns: I think both-sides or both-edges is clearer, because "mirroring what?"
16:50:22 <fantasai> miriam: Any chance that we want 'inline' as part of the name? in case want block later?
16:50:34 <fantasai> florian: Would add it as a second value
16:50:43 <fantasai> florian: e.g. stable stable, or stable mirror
16:50:51 <fantasai> florian: So I wouldn't include in the keyword
16:51:12 <astearns> ack fantasai
16:51:12 <Zakim> fantasai, you wanted to ask if we're moving this to css-scrollbars-1?
16:51:29 <fantasai> fantasai: Weren't we planning to move to scrollbars spec?
16:51:35 <fantasai> florian: Had a resolution for it
16:51:43 <tantek> present+
16:51:49 <fantasai> florian: But had some issues to work out, wanted to work out prior to moving
16:51:53 <fantasai> florian: but I think we're getting there
16:52:05 <fantasai> smfr: I like both-sides or both-edges
16:52:30 <rachelandrew> +1 for both-
16:52:41 <bradk> bradk has joined #css
16:52:51 <Rossen_> prefer both-
16:53:00 <tantek> slight pref for both-*
16:53:08 <fantasai> ??: -edge makes more sense because of the scrollbars
16:53:16 <fantasai> ??: some people when thinking of sides think only of left and right
16:53:18 <tantek> agreed with that reasoning for "edge"
16:53:30 <jfkthame> +1 for both-edges
16:53:30 <fantasai> astearns: sounds like we're leaning towards 'both-edges'
16:53:36 <fantasai> astearns: Anyone object?
16:53:45 <fantasai> RESOLVED: Rename to 'both-edges'
16:54:01 <fantasai> Topic: scrollbar-width inheritance
16:54:07 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/4799#issuecomment-877482191
16:54:22 <fantasai> florian: Suggestion to switch scrollbar-width to inherited
16:54:32 <fantasai> florian: for consistency with scrollbar-color and to make easier to style the whole page
16:54:42 <fantasai> florian: and I think we should not do that or exactly that reason
16:54:59 <TabAtkins> florian's argument in the thread makes sense to me, i'm fine with WONTFIX'ing this
16:55:06 <fantasai> florian: Primary use case for global scrollbar width is author preference, not author preference
16:55:17 <tantek> +1. disagreewith making scrollbar-width to inherited
16:55:22 <fantasai> florian: but author might know about certain widgeths or whatever that need a thinner scrollbar
16:55:24 <bmathwig> +1 on this Florian
16:55:31 <fantasai> florian: and that would be a reason for author control
16:55:34 <emilio> +1
16:55:35 <fantasai> florian: so I think should stay not inherited
16:55:37 <fantasai> +1
16:55:45 <tantek> also I disagree with the methodology of equating reasoning of -color with -width
16:55:50 <fantasai> RESOLVED: Close WONTFIX; scrollbar-width remains non-inherited
16:56:10 <TabAtkins> ScribeNick: TabAtkins
16:56:15 <fantasai> topic: scrollbar-color: light/dark
16:56:18 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6438
16:56:30 <TabAtkins> fantasai: When we first added sc4rollbar-color we didn't have color-scheme
16:56:48 <TabAtkins> fantasai: So we had keywords for light/dark so authors could request those if they just wanted to match their theme
16:57:07 <TabAtkins> fantasai: Since then we've added color-scheme which does this on a broader scale, and in particular shoudl automatically change the scrollbar colors
16:57:12 <emilio> +1
16:57:16 <TabAtkins> fantasai: And nobody's implemented light/dark anyway
16:57:16 <lea> +1
16:57:19 <bmathwig> +1
16:57:21 <florian> +1
16:57:21 <TabAtkins> fantasai: So proposal is to just drop these values
16:57:22 <emilio> q+
16:57:24 <TabAtkins> +1
16:57:24 <tantek> +100
16:57:30 <astearns> ack emilio
16:57:45 <TabAtkins> emilio: We don't implement color-scheme, but we do have darkening of scrollbars vs the background color
16:58:03 <TabAtkins> emilio: So perhaps shouldn't specify it should follow the color scheme
16:58:20 <TabAtkins> emilio: We currently get away with auto-darkening scrollbars on pages that don't use color-scheme
16:58:23 <tantek> this is a good point, there may be a compat need to keep 'dark'
16:58:46 <TabAtkins> florian: default value of color-scheme is "auto" anyway, we can make sure there's some flexibility there
16:59:07 <TabAtkins> tantek, there's zero implementation of 'dark', so by definition no compat need
16:59:14 <TabAtkins> astearns: Objections?
16:59:22 <tantek> TabAtkins: huh, ok then I misunderstood emilio
16:59:23 <TabAtkins> RESOLVED: drop the light/dark keywords from scrollbar-color
16:59:43 <emilio> tantek: firefox does darken scrollbars of scrollers with dark backgrounds
16:59:48 <TabAtkins> emilio was concerned about the auto value *requiring* the scrollbar to go light/dark depending on 'color-scheme'
17:00:03 <tantek> emilio, got it. so this is allowing that flexibility in 'auto'
17:00:05 <emilio> tantek: (assuming scrollbar-color: auto ofc)
17:00:07 <emilio> tantek: right
17:00:17 <astearns> topic: end
17:00:19 <tantek> great this seems like an ideal resolution of this
17:02:32 <astearns> zakim, end meeting
17:02:32 <Zakim> As of this point the attendees have been alisonmaher, miriam, smfr, dandclark, cbiesinger, plinss, bkardell_, Rossen_, Morgan, florian, rachelandrew, bmathwig, emilio, chris,
17:02:35 <Zakim> ... dholbert, jfkthame, masonf, lea, bradk, tantek
17:02:35 <Zakim> RRSAgent, please draft minutes v2
17:02:35 <RRSAgent> I have made the request to generate https://www.w3.org/2021/07/14-css-minutes.html Zakim
17:02:37 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
17:02:41 <Zakim> Zakim has left #css
18:39:49 <jensimmons> jensimmons has joined #css
19:48:35 <fantasai> TabAtkins: Transition request submitted for css-counter-styles-3 https://github.com/w3c/transitions/issues/353
19:52:25 <fantasai> miriam: want to add https://github.com/w3c/csswg-drafts/commit/e003e3ba06d248a6c82f9d1eb1cc7bbf5bfe882d to the changes list and republish cascade-5?
19:55:26 <TabAtkins> Thank you!
20:02:53 <jensimmons> jensimmons has joined #css
20:02:59 <projector> projector has joined #css
20:03:30 <leaverou> leaverou has joined #css
20:04:00 <Rossen> Rossen has joined #css
20:04:31 <shans> shans has joined #css
20:05:01 <sylvaing> sylvaing has joined #css
20:20:05 <fantasai> TabAtkins: Drafted up edits for the lv* units. Open question is, what should we call the unprefixed ones?
20:20:24 <fantasai> TabAtkins: I tried "default viewport size", but I don't like how both that and "dynamic viewport size" begin with 'd'
20:20:36 <fantasai> TabAtkins: so then I thought maybe "UA-default viewport size" ...
20:20:48 <fantasai> TabAtkins: but anyway, figured I'd ask you what you think :)
20:29:53 <astearns> Perhaps UA-defined viewport size?
21:01:51 <fantasai> to some extent, they're all UA-defined...
21:32:54 <antonp> antonp has joined #css
21:51:23 <dauwhe> dauwhe has joined #css
22:11:33 <ankh> ankh has joined #css
22:23:26 <dauwhe> dauwhe has joined #css
23:00:35 <TabAtkins> fantasai: You've got a note about large-viewport units being fixed, living in the UA-defined units section
23:00:45 <TabAtkins> i presume it needs to move
23:00:49 <TabAtkins> but otherwise looks good
23:37:20 <dauwhe> dauwhe has joined #css