Meeting minutes
Administrivial
astearns: If you're planning to attend June F2F in person, and want to stay at the recommended hotel, please indicate in the wiki
https://
astearns: Igalia plans to request a discounted room block, needs to know who to ask for
astearns: Any other items for the agenda?
[cssom-view] Specify document.caretPositionFromPoint in shadow DOM scenario
Liu: This API is defined in cssom-view, and spec doesn't have a definition for behavior in shadow DOM
Liu: Existing behavior is [missed]
Liu: Other alternatives are to not pierce shadow DOM
Liu: Another approach is to add a new parameter with set of shadow roots, and will return positio inside the shadow roots
Liu: Gathered feedback from community, and preference is to add parameter and only pierce the specified shadow roots
Liu: If this is acceptable, should we adopt?
Liu: Firefox's implementation is that the API can pierce the shadow tree, and tree can be open or closed shadow tree
mfreed: I'm definitely not a fan of revealing contents of shadow trees, particularly closed ones
mfreed: I heard proposed to use getComposedRanges behavior, where if you don't know about the shadow tree you get the shadow host
astearns: I'm not familiar with these APIs. Is getComposedRanges same pattern as what's proposed here?
mfreed: Yes. parameters to say which you know about, and it will pierce those, and give you host for those that you don't
dandclark: getComposedRanges spec link dropped in the issue doesn't take a parameter
dandclark: do browsers implement something else?
mfreed: It's only implemented in WebKit, definitely not in Blink yet
astearns: Looking at WebIDL there's a parameter, just not in description
dandclark: OK
sanketj_: Seems that Firefox is only one that pierces closed shadow tree, so getComposedRanges addresses that, so +1
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?
mfreed: yes, but not possible if you don't have reference to the shadow root you can't provide it
mfreed: so e.g. closed shadow root, unless you set it up, you can't get it
astearns: wrt the spec descriptions, the descriptions don't mention parameters, but the algorithms do process them
astearns: Sounds like we're ready to resolve? Any additional comments?
astearns: Proposed resolution is that caretPositionFromPoint can follow the getComposedRanges behavior and have a shadowRoots parameter
RESOLUTION: add shadowRoots parameter to caretPositionFromPoint, same as getComposedRanges
[css-images-4] Should `contain-intrinsic-size` affect `object-fit`?
<TabAtkins1> argh, be there one sec
EricP: object-fit uses the natural size, but there are two natural aspect ratios we care about
EricP: there's the actual natural aspect ratio of the object, and the one we use in layout (affected by contain-intrinsic-size)
EricP: wanted to do auto sizes for ? and were using contain-intrinsic-size
EricP: If you don't do that, you will load every resource in srcset, very bad
EricP: When shipped in Chrome Beta, a number of sites were also using sizes=auto and those images became distorted
EricP: We thought maybe set contain-intrinsic-size in UA stylesheet
EricP: But realized maybe we need two concepts, the intrinsic size for layout vs the intrinsic size for drawing
<TabAtkins> +1 to being explicit in both sites
EricP: object-fit is looking at the actual intrinsic size, contain is for layout only
vmpstr: Is object-fit the only property that should be affected by actual natural size?
miriam: I'm thinking in the reverse way, the containment features should only remove the natural sizing for layout purposes
miriam: the answer is, anything not about laying out the box should respect the natural size
+1
<florian> +1 to miriam
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
https://
miriam: hard to have the image contribute some dimensions without contributing its aspect ratio or nothing
miriam: we discussed awhile back, and ian made a proposal similar here, basically that containment should only contain for purposes of layout, nothing else
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.
eeeps: I do think we need aspect ratio, and width, and height. Ratio alone isn't enough for modes like object fit scale down
astearns: so can we update the proposed resolution to use natural vs preferred aspect ratio terms?
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 sizing. Tab and I can figure out what that means in specs.
PROPOSED: `contain` removes the natural aspect ratio / width / height only for the purposes of sizing and layout
dholbert: maybe clarify that it doesn't impact how object-fit works
fantasai: For sizing and layout of the box, and i.e. object fit is not affected
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)
astearns: Sounds like we're in agreement, might need some wordsmithing to put in the specs
astearns: any objections?
RESOLUTION: `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)
astearns: Any other notes for the minutes?
miriam: notes in the linked issues
Scrollbars
[css-scrollbars] Interaction between scrollbar-color and scrollbar-width with ::-webkit-scrollbar
luke: I implemented the scrollbar properties in Chrome
luke: These properties, as implemented in Chrome, take precedence over the legacy -webkit-scrollbar styling
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
luke: There's no specced behavior, would be good to get something in the spec wrt specifics
luke: at least wrt precedence
florian: Agree. When we drafted up the spec, we made an explicit decision not to spec those pseudos
florian: it is a question of what to do when they are specified
florian: Proposed that if the new properties have anything other than their initial value, then the old ones don't work
florian: gives a good migration path
florian: limited effect
florian: easy to test
florian: and doesn't require saying anything special about how the legacy things work
luke: Interop has only included scrollbar-width, not scrollbar-color
luke: reason is that scrollbar-color is harder for WebKit to implement
luke: but it means that webkit would have scrollbar-width but not scrollbar-color
luke: I would lean towards either one replaces the pseudos
florian: Agree, and I don't think we can distinguish between altering colors or width
florian: if you try to use a standard property that happens to not be implemented, then it wouldn't have an effect
florian: but using either or both should replace
astearns: smfr's comment is either as well
PROPOSED: If either scrollbar-width or scrollbar-color are anything other than initial values, then we ignore legacy -webkit-scroll pseudos
<luke> +1
RESOLUTION: If either scrollbar-width or scrollbar-color are anything other than initial values, then we ignore legacy -webkit-scroll pseudos
[css-scrollbars] Is the track visible in overlay scrollbars?
florian: Authors have no control, and can't figure out, if they have classic or overlay scrollbars
florian: when setting scrollbar colors, we require that they set two colors, and expect them to pick colors with good contrast
florian: what happens with overlay scrollbars is tricky: is the track even shown?
florian: what current browsers seem to do is, at rest, neither scrollbar thumb nor track shows at all
florian: if you start scrolling e.g. by flicking mousewheel or trackpad, then the thumb shows but not the track
florian: if you start interacting with scrollbars, then both show
florian: I think that's what all browsers do, but it's not specified
florian: If it's unspecified or undependable whether track is shown, how can we expect the author to pick good colors?
florian: if element backround and track are very different colors it's hard to ensure good contrast
florian: Browsers show track always for classic scrollbars, and sometimes for overlay
florian: If you use e.g. brightly colored track with pale thumb, it's usable for classic
florian: but can't see it well when not showing the track
florian: We could require that track is always shown
florian: or allow the UA to ensure good contrast when the track is not shown
florian: There's many complaints about this, I'm not sure entirely what is the best idea
luke: I don't think we can force-render the track in overlay mode
luke: it's OS-dependent how scrollbars behave
luke: one of the benefits of the standard scrollbar properties is keeping with the OS conventions
luke: Case where thumb is rendering and track isn't, the UA could step in and change the color
luke: spec allows some leeway already
luke: worth specifying, since we have an issue here
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
astearns: and leave how that happens up to the UA
florian: That would be good
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
luke: One issue is touch devices, particularly mobile
luke: behavior of scrollbar on a phone is quite different than on a desktop
luke: on a phone, scroll indicator is not super useful, not something you're actively interacting with
luke: the mechanism is the touchscreen, and in those cases the UA might not need to do too much
florian: There are cases on desktop as well where you don't show anything
florian: but if you're trying to show, even as an indicator that you're not interacting with, still want to see it
florian: so "make it visible somehow" is relevant on mobile as well
florian: to the extent you're trying to show it at all
schenney: with selection colors we said the UA shouldn't modify them
schenney: hesitant to say that UA can tweak colors here, because authors then can't specify definitively
schenney: hesitant to encourage UAs to change the colors
florian: With ::selection, author gets their background and their foreground
florian: if they get both colors but one of them is tweaked, then there's a problem
florian: but here we're in situation where they will get only one of their colors
florian: in that situation, they're not getting both colors that they expect, then UA needs to do something
florian: goal is the same: to maintain good contrast
florian: mechanics are different
schenney: true, the situation is different
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
astearns: but I wouldn't want to specify that, since that wouldn't be appropriate on all OSes
dholbert: wanted to ask, if white background and white scrollbar thumb, and expecting it to render on some other color
dholbert: unsure if browser can make that visible without some guidance
dholbert: focus ring is reasonable idea to the extent that it fits with the look and feel of scrollbars
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
luke: Agree, if property specifies color, should just use that color
luke: at the same time have case with e.g. accent-color where it can change how things are rendered
luke: we do have algorithm to come up with contrasting glyph
luke: idk if specified or just largely interoperable incidentaly
luke: but could come up with some kind of algorithm for colors
luke: I know WebKit in particular leaves scrollbars to platform SDK, can't even change colors
luke: do think it's worthwhile specifying that browsers should deal with this case
luke: even if we can't come up with a must
flackr: I'm concerned, in cases where we know the background color it applies
flackr: but default is that most things have transparent background
flackr: so paint on top of ... something
flackr: do browsers then have to figure out what's underneath?
astearns: [example of passing through a zone of color] Do you have to change the color as you go?
florian: comparison with accent-color doesn't work, because you specify a single color
florian: which is applied to something with geometry
florian: and UAs often do [something], and one of these lines at least will be visible
florian: situation is different. Scrollbars now don't have multiple colors, they're flat
florian: also specifying a pair of colors
florian: can't really respect "the thing" because we're ignoring half of it
florian: given we say authors are responsible for contrast, if the UA ignores half of what author is saying sometimes
florian: then UA must do something to ensure contrast
florian: things we could do:
florian: * ignore the author colors in thumb-only mode entirely
<luke> Yeah that's not a bad idea actually, treat it as auto value in that case
florian: or * [missed next example]
florian: or do some kind of pixel inversion
florian: or tint the color based on what's below it
florian: I don't think we should specify any of them, but require something
florian: which one you pick might be different based on OS
florian: but leaving case where author did something reasonable, but scrollbar is entirely invisible, doesn't seem OK
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
astearns: it should be only if the specified color doesn't provide sufficient contrast
florian: what sufficient contrast is is UA defined, no clear boundaries
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.
florian: allowed to make it conditional, but don't have to require it
mfreed: Wrt accent-color, spec doesn't require an algorithm, just requires maintaining contrast
mfreed: algorithm in Blink/Gecko is probably the same because we worked together
luke: if we just drop the fun color, in iOS/Android you never draw the track
luke: so I think it does need to be conditional on something
florian: I don't think we would require you to ignore the thumb color, just have to make it visible somehow
florian: This is not "do this particular thing", just "do something"
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
florian: uncomfortable with SHOULD
fantasai: We don't have good answers here.
florian: there is a good answer, just paint the track
flackr: or paint a contrasting outline
florian: either it's solveable, so shoud be MUST, or it's not, in which case we need a better idea
fantasai: Do we want to allow UA to use the track color instead of thumb color?
florian: sure why not
luke: that might not guarantee contrast
luke: shouldn't disallow from doing that
astearns: we're over time, take back to issue
astearns: see if there is some sort of MUST processing that we can agree on
astearns: I don't think we're there yet
<astearns> github-bot: end topic