22:58:56 <RRSAgent> RRSAgent has joined #css
22:59:01 <RRSAgent> logging to https://www.w3.org/2024/04/03-css-irc
22:59:01 <Zakim> RRSAgent, make logs Public
22:59:02 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
23:00:05 <kbabbitt> kbabbitt has joined #css
23:01:12 <eeeps> eeeps has joined #css
23:02:06 <masonf> masonf has joined #css
23:02:18 <kbabbitt> present+
23:03:38 <dholbert> present+
23:04:07 <fantasai> scribenick: fantasai
23:04:26 <schenney> schenney has joined #css
23:04:54 <sanketj_> sanketj_ has joined #css
23:04:57 <luke> present+
23:04:58 <fantasai> Topic: Administrivial
23:05:03 <dandclark> present+
23:05:28 <fantasai> astearns: If you're planning to attend June F2F in person, and want to stay at the recommended hotel, please indicate in the wiki
23:05:32 <miriam> present+
23:05:40 <fantasai> -> https://wiki.csswg.org/planning/galicia-2024
23:05:53 <fantasai> astearns: Igalia plans to request a discounted room block, needs to know who to ask for
23:05:59 <fantasai> astearns: Any other items for the agenda?
23:06:00 <sanketj_> present+
23:06:07 <github-bot> Topic: [cssom-view] Specify document.caretPositionFromPoint in shadow DOM scenario
23:06:42 <vmpstr> present+
23:06:49 <eeeps> present+
23:07:39 <masonf> present+
23:07:41 <fantasai> Liu: This API is defined in cssom-view, and spec doesn't have a definition for behavior in shadow DOM
23:07:51 <fantasai> Liu: Existing behavior is [missed]
23:07:59 <fantasai> Liu: Other alternatives are to not pierce shadow DOM
23:08:07 <TC3> TC3 has joined #css
23:08:17 <fantasai> Liu: Another approach is to add a new parameter with set of shadow roots, and will return positio inside the shadow roots
23:08:31 <fantasai> Liu: Gathered feedback from community, and preference is to add parameter and only pierce the specified shadow roots
23:08:38 <fantasai> Liu: If this is acceptable, should we adopt?
23:09:10 <fantasai> Liu: Firefox's implementation is that the API can pierce the shadow tree, and tree can be open or closed shadow tree
23:09:59 <fantasai> mfreed: I'm definitely not a fan of revealing contents of shadow trees, particularly closed ones
23:10:12 <fantasai> mfreed: I heard proposed to use getComposedRanges behavior, where if you don't know about the shadow tree you get the shadow host
23:10:22 <dandclark> present+
23:10:26 <dandclark> q+
23:10:37 <sanketj_> q+
23:10:41 <fantasai> astearns: I'm not familiar with these APIs. Is getComposedRanges same pattern as what's proposed here?
23:10:57 <fantasai> mfreed: Yes. parameters to say which you know about, and it will pierce those, and give you host for those that you don't
23:11:01 <astearns> ack dandclark
23:11:09 <fantasai> dandclark: getComposedRanges spec link dropped in the issue doesn't take a parameter
23:11:15 <fantasai> dandclark: do browsers implement something else?
23:11:25 <fantasai> mfreed: It's only implemented in WebKit, definitely not in Blink yet
23:11:48 <fantasai> astearns: Looking at WebIDL there's a parameter, just not in description
23:12:00 <fantasai> dandclark: OK
23:12:00 <edwardlsy> edwardlsy has joined #css
23:12:08 <astearns> ack sanketj_
23:12:09 <dholbert> q+
23:12:46 <fantasai> sanketj_: Seems that Firefox is only one that pierces closed shadow tree, so getComposedRanges addresses that, so +1
23:12:54 <astearns> ack dholbert
23:13:23 <fantasai> dholbert: With this version of the API, that takes list of shadow roots to pierce, if web developer listed every shadow root in their page they would get existing Firefox behavior?
23:13:58 <fantasai> mfreed: yes, but not possible if you don't have reference to the shadow root you can't provide it
23:14:07 <fantasai> mfreed: so e.g. closed shadow root, unless you set it up, you can't get it
23:14:48 <fantasai> astearns: wrt the spec descriptions, the descriptions don't mention parameters, but the algorithms do process them
23:15:06 <fantasai> astearns: Sounds like we're ready to resolve? Any additional comments?
23:15:35 <fantasai> astearns: Proposed resolution is that caretPositionFromPoint can follow the getComposedRanges behavior and have a shadowRoots parameter
23:16:06 <fantasai> RESOLVED: add shadowRoots parameter to caretPositionFromPoint, same as getComposedRanges
23:16:21 <github-bot> Topic: [css-images-4] Should `contain-intrinsic-size` affect `object-fit`?
23:16:39 <TabAtkins1> argh, be there one sec
23:16:51 <fantasai> EricP: object-fit uses the natural size, but there are two natural aspect ratios we care about
23:17:14 <fantasai> EricP: there's the actual natural aspect ratio of the object, and the one we use in layout (affected by contain-intrinsic-size)
23:17:42 <fantasai> EricP: wanted to do auto sizes for ? and were using contain-intrinsic-size
23:17:52 <fantasai> EricP: If you don't do that, you will load every resource in srcset, very bad
23:18:16 <fantasai> EricP: When shipped in Chrome Beta, a number of sites were also using sizes=auto and those images became distorted
23:18:36 <fantasai> EricP: We thought maybe set contain-intrinsic-size in UA stylesheet
23:18:58 <fantasai> EricP: But realized maybe we need two concepts, the intrinsic size for layout vs the intrinsic size for drawing
23:19:21 <vmpstr> q+
23:19:36 <miriam> q+
23:19:39 <TabAtkins> +1 to being explicit in both sites
23:19:52 <astearns> ack vmpstr
23:19:52 <fantasai> EricP: object-fit is looking at the actual intrinsic size, contain is for layout only
23:20:14 <fantasai> vmpstr: Is object-fit the only property that should be affected by actual natural size?
23:21:01 <fantasai> miriam: I'm thinking in the reverse way, the containment features should only remove the natural sizing for layout purposes
23:21:09 <schenney> q+
23:21:19 <fantasai> miriam: the answer is, anything not about laying out the box should respect the natural size
23:21:22 <fantasai> +1
23:21:30 <florian> +1 to miriam
23:21:34 <astearns> ack miriam
23:21:47 <schenney> q-
23:21:50 <fantasai> miriam: This also solves some other problems we've had in the past, where no way to remove the aspect ratio of the image and give it a new one
23:21:54 <fantasai> -> https://www.w3.org/TR/css-sizing-4/#aspect-ratio
23:22:05 <fantasai> miriam: hard to have the image contribute some dimensions without contributing its aspect ratio or nothing
23:22:24 <fantasai> miriam: we discussed awhile back, and ian made a proposal similar here, basically that containment should only contain for purposes of layout, nothing else
23:22:29 <astearns> ack fantasai
23:23:03 <dholbert> scribe+ dandclark
23:23:30 <dandclark> fantasai: When we the aspect ratio prop we added the concept of preferred aspect ratio, which is different from natural aspect ratio. Can we hook into that concept? Agree contain shouldn't hook into natural aspect ratio.
23:23:43 <eeeps> q+
23:24:01 <astearns> ack eeeps
23:24:26 <dandclark> eeeps: I do think we need aspect ratio, and width, and height. Ratio alone isn't enough for modes like object fit scale down
23:25:08 <fantasai> astearns: so can we update the proposed resolution to use natural vs preferred aspect ratio terms?
23:26:12 <dandclark> fantasai: Let's specify what we're trying to get here, and Tab and I can deal with the vocab aspects of it. We're trying to say that contain removes natural aspect ratio for purposes of [missed]. Tab and I can figure out what that means in specs.
23:26:23 <fantasai> s/[missed]/sizing/
23:26:58 <fantasai> PROPOSED: `contain` removes the natural aspect ratio / width / height only for the purposes of sizing and layout
23:27:28 <fantasai> dholbert: maybe clarify that it doesn't impact how object-fit works
23:27:51 <dandclark> fantasai: For sizing and layout of the box, and i.e. object fit is not affected
23:27:55 <fantasai> PROPOSED: `contain` removes the natural aspect ratio / width / height only for the purposes of sizing and layout of the box (and object-fit is therefore not affected)
23:27:55 <flackr> present+
23:28:20 <fantasai> astearns: Sounds like we're in agreement, might need some wordsmithing to put in the specs
23:28:23 <fantasai> astearns: any objections?
23:28:31 <fantasai> RESOLVED: `contain` removes the natural aspect ratio / width / height only for the purposes of sizing and layout of the box (and object-fit is therefore not affected)
23:28:38 <fantasai> astearns: Any other notes for the minutes?
23:28:48 <fantasai> miriam: notes in the linked issues
23:28:59 <fantasai> Topic: Scrollbars
23:29:02 <luke> q+
23:29:18 <florian> q+
23:29:24 <github-bot> Subtopic: [css-scrollbars] Interaction between scrollbar-color and scrollbar-width with ::-webkit-scrollbar
23:29:32 <astearns> ack luke
23:29:54 <fantasai> luke: I implemented the scrollbar properties in Chrome
23:30:10 <fantasai> luke: These properties, as implemented in Chrome, take precedence over the legacy -webkit-scrollbar styling
23:30:30 <fantasai> luke: That decision was kindof arbitrary, but based on feeling that the standard properties should take precedence even though it's not the same properti
23:30:47 <fantasai> luke: There's no specced behavior, would be good to get something in the spec wrt specifics
23:30:52 <fantasai> luke: at least wrt precedence
23:31:05 <astearns> ack florian
23:31:31 <fantasai> florian: Agree. When we drafted up the spec, we made an explicit decision not to spec those pseudos
23:31:40 <luke> q+
23:31:40 <fantasai> florian: it is a question of what to do when they are specified
23:32:00 <fantasai> florian: Proposed that if the new properties have anything other than their initial value, then the old ones don't work
23:32:07 <fantasai> florian: gives a good migration path
23:32:10 <fantasai> florian: limited effect
23:32:13 <fantasai> florian: easy to test
23:32:25 <fantasai> florian: and doesn't require saying anything special about how the legacy things work
23:32:25 <astearns> ack luke
23:32:45 <fantasai> luke: Interop has only included scrollbar-width, not scrollbar-color
23:32:59 <fantasai> luke: reason is that scrollbar-color is harder for WebKit to implement
23:33:05 <florian> q+
23:33:09 <fantasai> luke: but it means that webkit would have scrollbar-width but not scrollbar-color
23:33:28 <astearns> ack florian
23:33:37 <fantasai> luke: I would lean towards either one replaces the pseudos
23:33:58 <fantasai> florian: Agree, and I don't think we can distinguish between altering colors or width
23:34:11 <fantasai> florian: if you try to use a standard property that happens to not be implemented, then it wouldn't have an effect
23:34:18 <fantasai> florian: but using either or both should replace
23:34:30 <fantasai> astearns: smfr's comment is either as well
23:35:23 <fantasai> PROPOSED: If either scrollbar-width or scrollbar-color are anything other than initial values, then we ignore legacy -webkit-scroll pseudos
23:35:27 <luke> +1
23:35:40 <fantasai> RESOLVED: If either scrollbar-width or scrollbar-color are anything other than initial values, then we ignore legacy -webkit-scroll pseudos
23:35:52 <github-bot> Subtopic: [css-scrollbars] Is the track visible in overlay scrollbars?
23:36:01 <luke> q+
23:36:11 <fantasai> florian: Authors have no control, and can't figure out, if they have classic or overlay scrollbars
23:36:29 <fantasai> florian: when setting scrollbar colors, we require that they set two colors, and expect them to pick colors with good contrast
23:36:38 <fantasai> florian: what happens with overlay scrollbars is tricky: is the track even shown?
23:36:54 <fantasai> florian: what current browsers seem to do is, at rest, neither scrollbar thumb nor track shows at all
23:37:08 <fantasai> florian: if you start scrolling e.g. by flicking mousewheel or trackpad, then the thumb shows but not the track
23:37:16 <fantasai> florian: if you start interacting with scrollbars, then both show
23:37:26 <fantasai> florian: I think that's what all browsers do, but it's not specified
23:37:45 <fantasai> florian: If it's unspecified or undependable whether track is shown, how can we expect the author to pick good colors?
23:38:00 <fantasai> florian: if element backround and track are very different colors it's hard to ensure good contrast
23:38:40 <fantasai> florian: Browsers show track always for classic scrollbars, and sometimes for overlay
23:38:51 <fantasai> florian: If you use e.g. brightly colored track with pale thumb, it's usable for classic
23:39:01 <fantasai> florian: but can't see it well when not showing the track
23:39:15 <fantasai> florian: We could require that track is always shown
23:39:31 <fantasai> florian: or allow the UA to ensure good contrast when the track is not shown
23:40:02 <fantasai> florian: There's many complaints about this, I'm not sure entirely what is the best idea
23:40:05 <astearns> ack luke
23:40:22 <fantasai> luke: I don't think we can force-render the track in overlay mode
23:40:31 <fantasai> luke: it's OS-dependent how scrollbars behave
23:40:46 <fantasai> luke: one of the benefits of the standard scrollbar properties is keeping with the OS conventions
23:41:14 <fantasai> luke: Case where thumb is rendering and track isn't, the UA could step in and change the color
23:41:31 <fantasai> luke: spec allows some leeway already
23:41:57 <fantasai> luke: worth specifying, since we have an issue here
23:42:05 <schenney> q+
23:42:18 <fantasai> astearns: One option is to put something in the spec noting this case, if track not rendering then UA must ensure that the thumb is visible
23:42:23 <fantasai> astearns: and leave how that happens up to the UA
23:42:29 <fantasai> florian: That would be good
23:42:50 <fantasai> florian: true that UA has leeway in how to use colors, but not a spec violation to manage contrast -- currently claim it's the author's job to do it
23:42:55 <dholbert> q+
23:42:57 <fantasai> luke: One issue is touch devices, particularly mobile
23:43:05 <fantasai> luke: behavior of scrollbar on a phone is quite different than on a desktop
23:43:16 <fantasai> luke: on a phone, scroll indicator is not super useful, not something you're actively interacting with
23:43:28 <fantasai> luke: the mechanism is the touchscreen, and in those cases the UA might not need to do too much
23:43:40 <fantasai> florian: There are cases on desktop as well where you don't show anything
23:43:59 <fantasai> florian: but if you're trying to show, even as an indicator that you're not interacting with, still want to see it
23:44:05 <fantasai> florian: so "make it visible somehow" is relevant on mobile as well
23:44:13 <fantasai> florian: to the extent you're trying to show it at all
23:44:16 <astearns> ack schenney
23:44:36 <fantasai> schenney: with selection colors we said the UA shouldn't modify them
23:44:55 <fantasai> schenney: hesitant to say that UA can tweak colors here, because authors then can't specify definitively
23:45:24 <fantasai> schenney: hesitant to encourage UAs to change the colors
23:45:32 <luke> luke has joined #css
23:45:35 <fantasai> florian: With ::selection, author gets their background and their foreground
23:45:43 <fantasai> florian: if they get both colors but one of them is tweaked, then there's a problem
23:45:49 <luke> q+
23:45:57 <fantasai> florian: but here we're in situation where they will get only one of their colors
23:46:03 <flackr> q+
23:46:09 <fantasai> florian: in that situation, they're not getting both colors that they expect, then UA needs to do something
23:46:18 <fantasai> florian: goal is the same: to maintain good contrast
23:46:26 <fantasai> florian: mechanics are different
23:46:47 <fantasai> schenney: true, the situation is different
23:47:21 <fantasai> astearns: I could see a UA deciding, for this case where they're not going to render the track, to render the thumb with the specified color with some kind of outline of the track color
23:47:32 <fantasai> astearns: but I wouldn't want to specify that, since that wouldn't be appropriate on all OSes
23:47:40 <astearns> ack dholbert
23:48:03 <fantasai> dholbert: wanted to ask, if white background and white scrollbar thumb, and expecting it to render on some other color
23:48:13 <fantasai> dholbert: unsure if browser can make that visible without some guidance
23:48:25 <fantasai> dholbert: focus ring is reasonable idea to the extent that it fits with the look and feel of scrollbars
23:48:26 <florian> q?
23:48:46 <fantasai> dholbert: might increase contrast slightly if there's some to begin with, but if the colors are identical... I'm stuck to think what's a good way to handle it
23:49:00 <astearns> ack luke
23:49:15 <fantasai> luke: Agree, if property specifies color, should just use that color
23:49:25 <fantasai> luke: at the same time have case with e.g. accent-color where it can change how things are rendered
23:49:39 <florian> q+
23:49:42 <fantasai> luke: we do have algorithm to come up with contrasting glyph
23:49:54 <fantasai> luke: idk if specified or just largely interoperable incidentaly
23:50:09 <fantasai> luke: but could come up with some kind of algorithm for colors
23:50:09 <masonf> q+
23:50:22 <fantasai> luke: I know WebKit in particular leaves scrollbars to platform SDK, can't even change colors
23:50:38 <fantasai> luke: do think it's worthwhile specifying that browsers should deal with this case
23:50:43 <fantasai> luke: even if we can't come up with a must
23:50:52 <astearns> ack flackr
23:51:07 <fantasai> flackr: I'm concerned, in cases where we know the background color it applies
23:51:16 <fantasai> flackr: but default is that most things have transparent background
23:51:22 <fantasai> flackr: so paint on top of ... something
23:51:41 <fantasai> flackr: do browsers then have to figure out what's underneath?
23:52:00 <fantasai> astearns: [example of passing through a zone of color] Do you have to change the color as you go?
23:52:03 <astearns> ack florian
23:52:16 <fantasai> florian: comparison with accent-color doesn't work, because you specify a single color
23:52:27 <fantasai> florian: which is applied to something with geometry
23:52:47 <fantasai> florian: and UAs often do [something], and one of these lines at least will be visible
23:52:57 <fantasai> florian: situation is different. Scrollbars now don't have multiple colors, they're flat
23:53:07 <fantasai> florian: also specifying a pair of colors
23:53:16 <fantasai> florian: can't really respect "the thing" because we're ignoring half of it
23:53:32 <fantasai> florian: given we say authors are responsible for contrast, if the UA ignores half of what author is saying sometimes
23:53:40 <fantasai> florian: then UA must do something to ensure contrast
23:53:49 <fantasai> florian: things we could do:
23:54:01 <fantasai> florian: * ignore the author colors in thumb-only mode entirely
23:54:07 <luke> Yeah that's not a bad idea actually, treat it as auto value in that case
23:54:08 <fantasai> florian: or * [missed next example]
23:54:19 <fantasai> florian: or do some kind of pixel inversion
23:54:25 <fantasai> florian: or tint the color based on what's below it
23:54:35 <fantasai> florian: I don't think we should specify any of them, but require something
23:54:40 <fantasai> florian: which one you pick might be different based on OS
23:54:54 <fantasai> florian: but leaving case where author did something reasonable, but scrollbar is entirely invisible, doesn't seem OK
23:55:39 <fantasai> astearns: concern I have with dropping both colors and going with platform defaults is that there may be cases where designer does have a good contrasting color
23:55:50 <fantasai> astearns: it should be only if the specified color doesn't provide sufficient contrast
23:55:59 <fantasai> florian: what sufficient contrast is is UA defined, no clear boundaries
23:56:36 <dandclark> fantasai: The problem is that the UA can't easily tell what the color is because it's often transparent. Could be many different things. So don't know if that's particularly doable to check the contrast with what you can't see.
23:56:45 <fantasai> florian: allowed to make it conditional, but don't have to require it
23:57:07 <astearns> ack masonf
23:57:22 <fantasai> mfreed: Wrt accent-color, spec doesn't require an algorithm, just requires maintaining contrast
23:57:34 <fantasai> mfreed: algorithm in Blink/Gecko is probably the same because we worked together
23:57:59 <fantasai> luke: if we just drop the fun color, in iOS/Android you never draw the track
23:58:04 <florian> q+
23:58:14 <fantasai> luke: so I think it does need to be conditional on something
23:58:19 <astearns> ack florian
23:58:27 <fantasai> florian: I don't think we would require you to ignore the thumb color, just have to make it visible somehow
23:58:43 <fantasai> florian: This is not "do this particular thing", just "do something"
23:59:41 <fantasai> astearns: We could put a SHOULD requirement, if you're not showing the track and you either can determine that the specified thumb color would not have sufficient contrast or you cannot determine the contrast, then browsers should ignore the specified thumb color
23:59:56 <fantasai> florian: uncomfortable with SHOULD
23:59:59 <dandclark> fantasai: We don't have good answers here.
00:00:34 <fantasai> florian: there is a good answer, just paint the track
00:00:39 <fantasai> flackr: or paint a contrasting outline
00:01:06 <fantasai> florian: either it's solveable, so shoud be MUST, or it's not, in which case we need a better idea
00:01:26 <dandclark> fantasai: Do we want to allow UA to use the track color instead of thumb color?
00:01:38 <fantasai> florian: sure why not
00:01:44 <fantasai> luke: that might not guarantee contrast
00:01:49 <fantasai> luke: shouldn't disallow from doing that
00:01:57 <fantasai> astearns: we're over time, take back to issue
00:01:57 <Penny> Penny has joined #css
00:02:05 <fantasai> astearns: see if there is some sort of MUST processing that we can agree on
00:02:09 <fantasai> astearns: I don't think we're there yet
00:03:08 <TC3> TC3 has left #css
00:03:17 <astearns> github-bot: end topic
00:10:28 <astearns> zakim, end meeting
00:10:28 <Zakim> As of this point the attendees have been kbabbitt, dholbert, luke, dandclark, miriam, sanketj_, vmpstr, eeeps, masonf, TabAtkins, flackr
00:10:30 <Zakim> RRSAgent, please draft minutes v2
00:10:32 <RRSAgent> I have made the request to generate https://www.w3.org/2024/04/03-css-minutes.html Zakim
00:10:39 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
00:10:39 <Zakim> Zakim has left #css
01:50:56 <projector> projector has joined #css
01:51:26 <leaverou> leaverou has joined #css
01:51:57 <Rossen> Rossen has joined #css
01:52:27 <shans> shans has joined #css
01:52:57 <sylvaing> sylvaing has joined #css