16:01:07 <RRSAgent> RRSAgent has joined #css
16:01:11 <RRSAgent> logging to https://www.w3.org/2023/02/15-css-irc
16:01:11 <Zakim> RRSAgent, make logs Public
16:01:12 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:02:19 <emilio> present+
16:02:43 <ydaniv> present+
16:04:42 <emilio> ScribeNick: emilio
16:04:45 <dbaron> Present+
16:05:12 <github-bot> Topic: [css-overflow-3] Standardize `overlay` as a synonym for `auto`
16:05:26 <rachelandrew> present+
16:05:44 <fantasai> scribe+
16:08:08 <fantasai> emilio: Was skeptical at first, because I thought only Safari had overlay scrollbars
16:08:15 <fantasai> emilio: but also have classic scrollbars in OS preferences
16:08:22 <fantasai> emilio: so I think aliasing to auto is better
16:08:29 <fantasai> emilio: chrome folks also wanted to do it
16:08:32 <fantasai> emilio: helpful for compat
16:08:44 <fantasai> emilio: only annoyance is it doesn't do what it says
16:08:58 <fantasai> emilio: but we already discussed that tweaking overlay vs non-overlay should be user choice, not author choice
16:09:18 <fantasai> astearns: smfr, anything to add about aliasing 'overflow: overlay' to 'overflow: auto' ?
16:09:35 <fantasai> smfr: I'm in favor. We agree that it should be user choice rather than author choice
16:09:45 <fantasai> smfr: overlay vs non-overlay escaping onto the Web was a mistake
16:10:11 <fantasai> astearns: Proposed to specify 'overflow: overlay' as alias
16:10:13 <smfr> smfr has joined #css
16:10:23 <fantasai> fantasai: legacy name alias?
16:10:27 <fantasai> emilio: Yeah, I think that would be best
16:10:34 <fantasai> https://www.w3.org/TR/css-cascade-5/#legacy-name-alias
16:11:20 <fantasai> s/legacy name alias/legacy value alias/
16:11:22 <fantasai> https://www.w3.org/TR/css-cascade-5/#value-aliasing
16:11:26 <oriol> oriol has joined #css
16:11:35 <fantasai> RESOLVED: overlay is legacy value alias for 'overflow: auto'
16:12:25 <github-bot> Topic: [css-images-4][css-overflow-3] How do `object-overflow` and `object-view-box` interact with `overflow` and `overflow-clip-margin`?
16:12:52 <emilio> fantasai: lots of discussion after the OP
16:13:10 <emilio> ... we decided to extend overflow application to replaced elements
16:13:20 <emilio> ... and make their overflow ink other than scrollable
16:13:33 <emilio> ... then decided that scrollable overflow values behaved as clip
16:13:45 <emilio> ... and host lang defines this
16:14:03 <emilio> ... issue is that replaced elements can or not be replaced depending on whether they load or not
16:14:12 <emilio> ... same for `content: url()`
16:14:30 <emilio> ... so you might get alt text clipped or not
16:14:46 <emilio> ... so proposed a new initial value
16:15:03 <emilio> ... but oriol pointed that that is unfortunate
16:15:21 <emilio> ... so proposal is to make the new value remain auto but return something else in gCS
16:15:35 <emilio> oriol: I think kushal's proposal to handle it with two properties looks nice
16:15:56 <emilio> ... new initial value or doing different things depending on whether the element is replaced or not seems like a workaround and it might not be worth it
16:16:05 <emilio> ... I have an additional proposal using three properties in the issue
16:16:14 <emilio> ... we'd re-add object-overflow
16:16:29 <emilio> ... I think by adding it these interactions / corner-cases can be explained by the third property
16:16:35 <emilio> ... I think only inconsistency would be svg
16:16:43 <emilio> ... which currently aren't clipped but are replaced
16:16:50 <TabAtkins> present+
16:16:54 <emilio> ... but this can be a simple rule in the UA sheet
16:17:00 <miriam> present+
16:17:09 <smfr> present+
16:17:18 <emilio> dbaron: is the svg behavior consistent between svg-in-document and svg-as-image?
16:17:28 <emilio> fantasai: svg-as-image definitely clips by default
16:17:43 <emilio> dbaron: maybe svg and markup is a different case from images anyways
16:18:00 <emilio> fantasai: I think so, I think you might want to apply it to <svg> elements in the UA sheet
16:18:24 <emilio> dbaron: maybe object-overflow shouldn't apply to svg elements within the document
16:18:51 <emilio> astearns: so object-overflow was something that was introduced then removed?
16:19:04 <emilio> fantasai: yeah we tried to make overflow work instead, but I think there are some problems with that
16:19:44 <emilio> dbaron: I believe there's some connection to the view-transitions work here?
16:19:50 <emilio> ... Suspect that's why kushal was interested
16:20:02 <fantasai> emilio: Concern with making overflow just work
16:20:11 <ydaniv> embedded SVG has overflow hidden rule in the UA, and it can be overriden
16:20:13 <fantasai> emilio: ther'es other cases where it doesn't create a scrollable element, is the concern just backwards compat?
16:20:27 <emilio> fantasai: not just that
16:20:55 <emilio> ... the problem is that whether an element is replaced or not (and thus whether it should clip by default) depends on other stuff
16:21:19 <emilio> ... so we can't make it just a simple UA sheet rule etc
16:21:41 <emilio> ... and if you use CSS to turn something into a replaced element you'd get visible which might not be what authors expect
16:21:44 <fantasai> s/stuff/stuff that can't be selected against/
16:22:03 <fantasai> emilio: at least for everything but the 'content' case, I think it could be addressed with CSS?
16:22:11 <fantasai> emilio: we have internal pseudo-classes for images that are broken
16:22:21 <fantasai> emilio: so we could conditionally apply the new overflow value, clip vs visible, based on that pseudo element
16:22:27 <fantasai> emilio: still problematic for 'content' though
16:22:36 <fantasai> emilio: idk if that's a huge issue? not sure it's used a lot
16:22:51 <fantasai> emilio: might be able to get away with it
16:23:02 <fantasai> emilio: authors can set clip themselves
16:23:08 <fantasai> fantasai: yes, but it's weird if it doesn't clip!
16:23:23 <fantasai> emilio: you want img/svg/etc to have overflow:clip by default in the UA sheet
16:23:29 <fantasai> emilio: and ... then the weird case is content
16:23:41 <fantasai> emilio: but could make broken images be visible again using pseudos
16:24:17 <fantasai> emilio: also, overflow doesn't apply to inline boxes so they'd be visible
16:24:21 <fantasai> fantasai: not all images are 'display: inline'
16:24:55 <emilio> astearns: so emilio suggests that with the existing properties UA sheet could express it
16:25:11 <emilio> ... but there'd be no facility for replaced element fallback
16:25:24 <astearns> s/facility/author facility/
16:25:25 <emilio> ydaniv: People override overflow on SVG elements
16:25:32 <emilio> ... and it works
16:25:42 <emilio> fantasai: I think using a UA sheet might be complicated from an author's point
16:26:06 <emilio> ... and the other two other alternatives (new initial value or splitting into another property) would be easy to understand
16:26:32 <emilio> astearns: would it be easy to start with the magic initial value and add the new property if that's not sufficient?
16:26:56 <emilio> fantasai: we could though it'd be weird to have two different things doing the same thing
16:26:58 <emilio> q+
16:27:25 <emilio> oriol: there was also the problem that it's not just about whether overflow should clip but also what the initial clipping area is
16:27:35 <emilio> ... I don't recall how this model was addressing this problem
16:27:50 <emilio> ... But by adding a third property that'd be more reasonable
16:27:52 <astearns> ack emilio
16:27:54 <emilio> fantasai: agree
16:28:17 <fantasai> emilio: if we add a magic initial value for 'overflow' and 'overflow-clip-box' as well
16:28:38 <fantasai> emilio: but not expose it to content, make the resolved value (getComputedStyle) would be the used value
16:28:57 <fantasai> emilio: wouldn't that basically address the issue, without introducing new magic for authors?
16:28:59 <SebastianZ> SebastianZ has joined #css
16:29:09 <fantasai> emilio: if authors say 'overflow: visible', that just works
16:29:38 <fantasai> emilio: then authors don't need to worry about it, and I don't think it'd be harder to implement
16:29:45 <fantasai> emilio: maybe it's harder to understand
16:29:55 <fantasai> emilio: we don't need a good name for magic auto, because it's not exposed to authors
16:30:01 <fantasai> fantasai: we could just call it 'noral'
16:30:04 <fantasai> s/noral/normal/
16:30:23 <emilio> astearns: so the magic is that it's a value that authors don't use and never see because gCS lies
16:30:25 <flackr> present+
16:31:04 <emilio> fantasai: so to recap 3 options... Selectors in UA sheet, magic initial value that disappears in gCS, and separate properties
16:31:23 <emilio> ... I think either could work the questions is what's better
16:31:43 <emilio> astearns: kushal seemed fine with the magic value, did they express opinion on the extra property?
16:32:13 <emilio> ... Maybe go back to the issue but restrict to the magic value or extra property options?
16:32:42 <fantasai> emilio: I think the magic value would be nicer for authors
16:32:53 <fantasai> emilio: things just work as you specify stuff
16:32:58 <fantasai> emilio: but it may benefit from some experimentation
16:33:09 <astearns> ack fantasai
16:33:32 <emilio> fantasai: I think the major thing to consider is "do you as an author want to control overflow application independently for a single element independent on whether it ends up replaced or not"
16:33:48 <emilio> ... do I want to set overflow differently depending on whether or not it ends up being replaced
16:34:18 <emilio> ... let's say I do overflow: auto on an <object> but take the same layout space
16:34:34 <emilio> ... then the replaced element would get a different value either
16:35:05 <emilio> ... if we decide having the values in sync is fine then we can do a single property
16:35:15 <fantasai> ... if not, then we need separate values
16:35:28 <fantasai> emilio: why is overflow special compared to replaced/non-replaced? We could expose that via pseudo-classes
16:35:40 <fantasai> emilio: that also allows changing any other property
16:35:56 <fantasai> emilio: If we decide that use case is valuable, we have issues on file for exposing whether an image is broken or not etc.
16:36:21 <fantasai> astearns: My intuition matches Emilio's, wanting to apply different things depending on state isn't worth a separate property in this case
16:36:28 <fantasai> astearns: but only lightly in that camp, could go either way
16:36:52 <fantasai> astearns: So if people want to resolve on having a magic initial value and work that through, happy to do that, but maybe better to take it back to the issue
16:36:54 <emilio> astearns: if people want to resolve on magic initial value and work that through, but might be better to take it back to the issue on these specific questions
16:37:20 <emilio> fantasai: I'd be also fine with leaving it open but drafting the initial value in overflow-4
16:37:28 <emilio> ... and posting a comment on the issue
16:37:35 <emilio> astearns: would you volunteer to do that?
16:37:38 <emilio> fantasai: yes
16:37:48 <emilio> ACTION: fantasai to draft the magic value in overflow-4
16:38:07 <emilio> and leave the issue open and use it to drive future discussions
16:38:36 <emilio> github-bot: topic: https://github.com/w3c/csswg-drafts/issues/7434
16:38:36 <github-bot> emilio, Sorry, I don't understand that command.  Try 'help'.
16:38:41 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/7434
16:38:41 <github-bot> Topic: [css-overflow-3] how do overflow: clip/hidden combinations interact with rounded borders?
16:38:41 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7434.
16:39:17 <emilio> dbaron: I missed oriol's last comment, but I think it's relatively simple
16:39:30 <emilio> ... I noticed that the spec allows overflow to be clip in one axis but visible in other axis
16:39:40 <emilio> ... which is something that was introduced when clip was introduced
16:39:53 <emilio> ... when we introduced clip the question is how it interacts with rounding of borders
16:40:16 <emilio> ... I thought the simple question is that you clip in one axis but not on the other border radius has no effect
16:40:35 <emilio> ... oriol posted screenshots, and I'm not sure browsers are doing this new clip and visible behavior
16:41:20 <emilio> oriol: the behavior in browsers is... webkit has a bug where content is not painted... Chromium if it has overflow: visible clip as just clip only with non-zero radius
16:41:26 <emilio> ... so not continuous
16:41:45 <emilio> ... firefox applies the rounded clip to the bounding rectangle of the overflowing content
16:41:55 <emilio> ... In this particular case it looks kind of nice but it can be strange
16:42:07 <emilio> ... I think I'm leaning towards dbaron's proposal
16:42:13 <fantasai> +1 to dbaron's proposal
16:42:33 <flackr> +1 to dbaron's proposal, it makes sense that allowing visible overflow in the off-axis means there's no rounding
16:42:33 <emilio> smfr: I think I agree. The WebKit bug was fixed and now we behave like Chromium but I think that's just bugs, I'm ok with dbaron's proposal
16:43:02 <emilio> proposed resolution is that when clip and visible are specified, border radius has no effect
16:43:15 <fantasai> (on the content)
16:43:23 <fantasai> emilio: what if some corners have no radius and others do?
16:43:27 <dbaron> s/has no effect/doesn't cause rounded clipping of the contents/
16:44:04 <emilio> dbaron: we're not talking about whether border-radius has an effect, but whether it clips the contents
16:44:04 <ydaniv> ydaniv has joined #css
16:44:24 <emilio> ... border-radius with overflow: visible has an effect but doesn't clip
16:44:59 <emilio> ... my argument is that if you're not clipping in one axis you shouldn't clip to the border radius
16:45:11 <emilio> smfr: so basically everything should render as the first Firefox screenshot right?
16:45:23 <emilio> ... is that right if there's no content to clip?
16:45:49 <tantek> tantek has joined #css
16:45:54 <emilio> smfr: I'd like to see a test-case with something that overflows only on one side but doesn't fill the content box
16:46:01 <emilio> dbaron: I don't think any engine does what the spec says to me
16:46:27 <emilio> dbaron: oh wait, FF does it
16:47:06 <emilio> dbaron: I'll paste a modified test-case in the issue
16:47:50 <emilio> dbaron: https://github.com/w3c/csswg-drafts/issues/7434#issuecomment-1431669370
16:48:02 <emilio> dbaron: I think it should match up with what FF is doing on the later one
16:48:12 <emilio> ... because the inset rules for the clipping cause that to not have any rounding
16:49:16 <fantasai> emilio: I think I'm fine with dbaron's proposal
16:49:22 <fantasai> emilio: could do something more complicated, but unclear it would be useful
16:49:43 <TabAtkins> ok lol i finally looked at firefox's behavior with dbaron's increased overflow, that's silly
16:49:52 <TabAtkins> i see why that would happen but still
16:50:35 <emilio> Proposed resolution: border radius doesn't round the clipping region when mixing overflow: visible and clip
16:50:57 <emilio> dbaron: I should probably clarify that this is just a bugfix in the spec because nobody thought about it
16:51:04 <emilio> ... but I don't think there's any other sensible behavior here
16:52:33 <emilio> smfr: if you look in Firefox at the penultimate box on the last test-case I just posted (where I just shift the box) is that what you're proposing?
16:53:26 <emilio> astearns: so with this resolution we'd still round the border but the overflowing element isn't clipped
16:54:51 <ydaniv> ydaniv has joined #css
16:55:11 <PaulG> PaulG has joined #css
16:55:16 <PaulG> present+
16:55:22 <fantasai> fantasai: afaict, all we're proposing here is that the border/background/etc are still rounded as normal, we just don't clip the content to the radius when there's overflow in one axis
16:55:28 <fantasai> (or both axes)
16:55:45 <fantasai> fantasai: this seems fine, what's the confusion?
16:56:10 <Rossen_> Rossen_ has joined #css
16:56:31 <Rossen_> present+
16:56:31 <emilio> smfr: I just want to confirm that in my latest test-case FF is correct, except for the rounding on the left side
16:56:36 <emilio> dbaron: rithg
16:56:39 <emilio> right*
16:56:42 <emilio> smfr: sounds good
16:56:45 <emilio> +1 as well
16:56:56 <emilio> RESOLVED: border radius doesn't round the clipping region when mixing overflow: visible and clip
16:57:43 <emilio> github-bot: topic https://github.com/w3c/csswg-drafts/issues/8381
16:57:43 <github-bot> Topic: [css-overflow-4] overflow-clip-margin longhands
16:57:43 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8381.
16:58:14 <emilio> fantasai: question is how does the shorthand looks like
16:58:22 <emilio> ... one is to use different delimiter as grid
16:58:26 <emilio> ... another is to have box then up to four lengths
16:58:32 <emilio> ... then /missed/
16:58:43 <TabAtkins> I support option 2 (single box keyword, 1-4 lengths)
16:58:58 <emilio> ... oriol proposed 1-to-4 lengths-and-box
16:59:15 <emilio> fantasai: I prefer oriol proposal, then (2)
16:59:36 <emilio> TabAtkins: seems to be the one that matches up most cleanly what people want to do
17:00:00 <emilio> ... single kw and multiple length addresses most cases
17:00:22 <argyle> argyle has joined #css
17:00:22 <emilio> fantasai: (4) allows you to do one kw but also multiple
17:00:29 <emilio> ... full expansion might be unusual but you don't have to use it
17:00:39 <emilio> ... and it allows all of them
17:00:47 <emilio> astearns: all combinations are allowed in the longhands
17:01:17 <emilio> astearns: oriol, are you ok with (2) or wanna argue for (4)
17:01:32 <emilio> oriol: no strong opinion, would be fine with (2) or even just restricting to 1kw + length
17:01:42 <lea> lea has joined #css
17:01:44 <jfkthame> jfkthame has joined #css
17:01:54 <emilio> proposal is to start with one keyword, we can always expand if needed
17:01:58 <emilio> RESOLVED: Go with (2) for now
17:02:57 <astearns> topic: end of breakout
17:02:57 <emeyer> emeyer has joined #css
17:02:59 <emeyer> present+
17:03:15 <masonf> masonf has joined #css
17:03:30 <argyle> present+
17:03:41 <oriol> present+
17:04:07 <jfkthame> present+
17:04:32 <Rossen_> Rossen_ has changed the topic to: agenda for feb 15: https://lists.w3.org/Archives/Public/www-style/2023Feb/0007.html
17:04:50 <TabAtkins> ScribeNick: TabAtkins
17:04:57 <emilio> present+
17:05:52 <plinss> present+
17:06:11 <alisonmaher> alisonmaher has joined #css
17:06:11 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/1053
17:06:11 <github-bot> Topic: [css3-positioning] position:sticky should create a stacking context
17:06:11 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/1053.
17:06:27 <smfr> present+
17:06:28 <alisonmaher> present+
17:06:31 <TabAtkins> github-bot, end topic
17:06:42 <fantasai> Topic: Administrative
17:06:44 <TabAtkins> Rossen_: As said on the private list, no actual f2f for now.
17:07:09 <TabAtkins> Rossen_: Instead the proposal is to have two 2hr calls for two consecutive weeks, spaced by a day. Wed 2hr, like today, and the same on Friday.
17:07:12 <dbaron> I'll be late because I had to reboot my computer to quit zoom
17:07:21 <TabAtkins> Rossen_: Unless there are alternatives or strong reasons to not do it, we'll schedule that.
17:07:46 <TabAtkins> Rossen_: Gonna be mid-March, either 8/10/15/17 or 15/17/22/24
17:07:53 <Rossen_> q?
17:07:56 <Rossen_> ack fantasai
17:08:05 <TabAtkins> fantasai: Does it make sense to do Friday? That's late for Europe and Japan on a Friday...
17:08:19 <TabAtkins> Rossen_: Yeah, the alternative of not having a day between meetings would make it harder for more folks.
17:08:32 <TabAtkins> Rossen_: Other chance is not do Wednesday, do Tue/Thu instead
17:08:52 <dbaron> Present+
17:08:52 <miriam> present+
17:08:57 <fantasai> TabAtkins: why not Monday Wed?
17:09:03 <lea> present+
17:09:06 <ydaniv> present+
17:09:09 <fantasai> TabAtkins: I don't have a strong opinion either way, but seems odd not to consider it
17:09:14 <dbaron> I agree that Friday is problematic for many folks.
17:09:19 <dbaron> (was going to raise that as well)
17:09:38 <TabAtkins> Rossen_: Let's agree on having two 2hr calls on two consecutive weeks. We'll dial in the exact dates asap on the private list
17:09:51 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/1053
17:09:51 <github-bot> Topic: [css3-positioning] position:sticky should create a stacking context
17:09:51 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/1053.
17:10:16 <TabAtkins> fantasai: Simon raised an issue a while ago that stickypos should make as tacking context, like fixpos
17:10:20 <Rossen_> q?
17:10:50 <TabAtkins> Rossen_: Is there a reason it's not already a stacking context?
17:10:58 <TabAtkins> smfr: WebKit's been shipping that way for a long time
17:11:33 <fantasai> TabAtkins: previously, wasn't necessary
17:11:44 <fantasai> TabAtkins: but now in chromium it is
17:11:47 <rachelandrew> present+
17:11:52 <fantasai> TabAtkins: wanted to check that we're okay with the change to the spec
17:12:05 <TabAtkins> Oh sorry, stickypos stacking context isn't in the spec; fixpos is. So we will still need to make an edit.
17:12:08 <TabAtkins> Rossen_: Objections?
17:12:17 <tantek> present+
17:12:19 <TabAtkins> RESOLVED: stickypos makes a stacking context, just like fixpos
17:12:32 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/8040
17:12:32 <github-bot> Topic: [css-position-3] Containing block of dialog fixed position children
17:12:32 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8040.
17:12:35 <chrishtr> present+
17:13:01 <TabAtkins> smfr: If you have fixpos inside a dialog, and dialog is on top layer, what's the containing block of the fixpos?
17:13:11 <TabAtkins> smfr: Dialog can be abspos *or* fixpos itself
17:13:21 <TabAtkins> smfr: If dialog is abspos, what's the fixpos behavior when the user scrolls the document?
17:13:38 <TabAtkins> smfr: If dialog has a transformed ancestor, does that affect the containing block for the fixpos descendent?
17:13:54 <TabAtkins> smfr: Both of these are impacted by whether the dialog itself is a CB for the fixpos
17:13:58 <Rossen_> q?
17:14:00 <TabAtkins> smfr: The top layer is kinda viewport-like
17:14:31 <fantasai> chrishtr: Is there interop on this or not?
17:14:37 <fantasai> scribe+
17:14:53 <fantasai> emilio: I think we don't enforce dialog to be a fixedpos dialog, but we want to
17:14:59 <fantasai> emilio: the containing block chain is pretty weird otherwise
17:15:13 <chrishtr> I don't think chromium makes dialog a containing block either
17:15:14 <fantasai> emilio: or at least we need to spec that any fixedpos inside the top layer are also in the top layer
17:15:36 <fantasai> emilio: otherwise, breaks the assumption that the containing block ... the in-flow content is laid out before the fixedpos
17:15:53 <fantasai> emilio: so unclear how the hypothetical positoins work if you don't at least define that they go in the top layer as well
17:16:03 <fantasai> emilio: in that case might want to make the dialog a containing block as well, much easier
17:16:14 <fantasai> emilio: don't see the point to have a fixedpos and not want it in teh top layer
17:16:23 <TabAtkins> fantasai: I think making it in the top laye rmakes sense
17:16:32 <TabAtkins> fantasai: I can imagine that you might not want the dialog to be a fixpos CB
17:16:33 <Rossen_> ack fantasai
17:16:47 <TabAtkins> fantasai: because you might actually want something outside the dialog wrt the viewport, while ahving the dialog open. can def imagine that
17:17:13 <TabAtkins> emilio: At that point we've given a special way to put something in the top layer...
17:17:23 <fantasai> TabAtkins: what's the concern about puttin gin the top layer? dialog is already there
17:17:38 <TabAtkins> emilio: It might be fine, I need to think more about ti
17:17:43 <bkardell_> bkardell_ has joined #css
17:17:43 <TabAtkins> chrishtr: Seems like it'll be okay to me
17:18:19 <TabAtkins> chrishtr: The fixpos goes in the top layer, and if the dialog scrolls the fixpos won't scroll with it
17:18:33 <TabAtkins> chrishtr: That seems doable and not problematic; I assume that's how browsers would automatically work
17:18:35 <bkardell_> present+
17:18:45 <TabAtkins> smfr: What do you mean by "in the top layer"?
17:18:47 <TabAtkins> chrishtr: z-order
17:19:03 <TabAtkins> smfr: This is about CB, not painting order
17:19:35 <TabAtkins> chrishtr: Right, if the fixpos has a transformed ancestor within the dialog, that'll trap the fixpos as normal. If the transformed ancestor is outside the dialog, it won't affect it - it's specified as reparenting in the rendering tree.
17:19:51 <TabAtkins> smfr: So if you ahve a nested set of position:fixed do they all go in the top layer?
17:20:00 <masonf> q?
17:20:04 <TabAtkins> chrishtr: top layer is just reparenting and stacking context, it doesn't affect the CB
17:20:12 <TabAtkins> chrishtr: Maybe we should make some demos and come back to the group
17:20:22 <TabAtkins> Rossen_: sounds reasonable
17:20:43 <TabAtkins> Rossen_: k let's collect some examples in the issue
17:21:03 <TabAtkins> emilio: I think there's consensus that a transformed ancestor of the dialog isn't a CB for the fixpos, due to the reparenting.
17:21:50 <TabAtkins> proposed resolution: Clarify that due to the box-tree reparenting, an ancestor outside the dialog can't be a fixpos CB for children of the dialog
17:22:25 <emilio> +1
17:22:28 <fantasai> wfm
17:22:42 <fantasai> s/children/descendants/
17:22:52 <masonf> +1
17:22:54 <chrishtr> +1
17:23:02 <TabAtkins> RESOLVED: Clarify that due to the box-tree reparenting, an ancestor outside the dialog can't be a fixpos CB for children of the dialog
17:23:24 <JonDavis> JonDavis has joined #css
17:23:27 <TabAtkins> (Still unresolved: what exactly the CB of a fixpos descendant of the dialog is.)
17:24:46 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/6900
17:24:46 <github-bot> Topic: Republishing Tasks Permathread
17:24:46 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6900.
17:24:59 <TabAtkins> fantasai: We'd like to publish Position 3 with the stickypos change we just resolved.
17:25:06 <TabAtkins> fantasai: Also publish Box Alignment
17:25:17 <TabAtkins> fantasai: Some of the issues we fixed crossed between these specs.
17:25:29 <TabAtkins> Rossen_: Objections for new WD of Position 3 and Align 3?
17:25:31 <fantasai> https://drafts.csswg.org/css-position-3/#changes
17:26:01 <TabAtkins> fantasai: We did a substantial number of fixes to the staticpos section, I'd definitely encourage people to look at that.
17:26:27 <fantasai> https://drafts.csswg.org/css-position-3/#abspos-insets
17:26:31 <TabAtkins> fantasai: Right now we still have an old-style "two versions" of the spec - rewritten and non-rewritten. Probably want to drop the non-rewritten soon, so if people can review the rewritten is correct it woudl be great
17:26:44 <TabAtkins> fantasai: Particularly #abspos-insets, most of the changes are in that section
17:27:05 <fantasai> https://drafts.csswg.org/css-position-3/#abspos-layout is also a major part of the replacement (but less changes lately)
17:27:32 <TabAtkins> fantasai: So rquesting to repub, and hopefully in next repub we can drop the old section
17:27:38 <TabAtkins> Rossen_: Not hearing objections
17:27:39 <astearns> +1 to publish
17:27:47 <TabAtkins> RESOLVED: Publish new WD of Position 3 and Align 3.
17:27:58 <fantasai> https://drafts.csswg.org/css-align-3/#changes
17:28:50 <TabAtkins> Rossen_: no objectiosn to Align 3 pub
17:29:07 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/7937
17:29:07 <github-bot> Topic: [css-color-6] Let's finally settle contrast-color() syntax
17:29:07 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7937.
17:30:28 <TabAtkins> lea: The primary problem we couldn't settle on was what to call foreground/background. We reoslved to distinguish them in the syntax but couldn't decide on names
17:30:46 <TabAtkins> lea: foreground/background too long, fg/bg too cryptic, others suggested front/back, fore/back
17:30:51 <TabAtkins> lea: There's a table of the options
17:31:34 <TabAtkins> lea: And should we have a default if the keyword isn't specified? Probably with bg as the base color, which'll be the most common case? Or should we require the keyword?
17:31:46 <TabAtkins> fantasai: I think I'm strongly in favor of it being mandatory, so people will pay attention
17:32:12 <TabAtkins> lea: advantage of making it options is that only the fg word actually matters so we can just pick a good name there. can also be longer since it's not typed as much
17:32:30 <TabAtkins> argyle: That's my proposal - make it optional and make the fg keyword short and easy.
17:32:58 <argyle> https://observablehq.com/@argyleink/contrast-color
17:33:12 <TabAtkins> argyle: This is the interactive explianer, syntax is right under the demo
17:33:23 <argyle> https://www.irccloud.com/pastebin/mO4ENSCC/
17:34:03 <lea> s/and make the fg keyword short and easy./and have the whole foreground keyword, since it's the exception/
17:35:07 <TabAtkins> [gonna have argyleink present]
17:36:07 <TabAtkins> Rossen_: If you need to present visually, our next zoom meeting will be next month
17:36:16 <TabAtkins> [more presentation chatter]
17:37:29 <TabAtkins> argyle: Bunch of examples in this observable document later
17:37:42 <TabAtkins> argyle: The current spec isn't far off from excellent, i think, so my important bits in myc ounter proposal:
17:38:20 <TabAtkins> argyle: First, doesn't require a color list
17:38:33 <TabAtkins> argyle: Lot of presenting to devs and using it myself, i often dont' care about the final color
17:38:50 <TabAtkins> argyle: It'll find the first color that passes for you, in the same hue, in whatever contrast algo you're using
17:39:03 <TabAtkins> argyle: Further my proposal builds in the contrast MQ pref
17:39:32 <TabAtkins> argyle: So if the user prefers more contrast and the page is rendered without a color list, or an explicit contrast pref in the function, the browser will take the user's preference by default.
17:39:48 <TabAtkins> argyle: This potentially eliminates several MQs for authors to have to worry about
17:40:19 <TabAtkins> argyle: If an author *does* write a specific target score - "Weber 2" or whatever - they're actually potentially excluding users.
17:40:54 <TabAtkins> argyle: So if someone does want to handhold the contrast today, they have to write several MQs to set things correctly in several circumstances. My proposal folds it all in by default.
17:41:13 <TabAtkins> argyle: Color list is still important, if you *do* want it, but you don't need it a lot of the time.
17:41:41 <TabAtkins> argyle: As said earlier, it defaults to "background". You can click it to foreground and see it change the syntax to include the keyword.
17:41:58 <TabAtkins> argyle: In most caess I've done I'm starting from a background, it's just the most common.
17:42:07 <TabAtkins> argyle: Also have a "max" contrast target
17:42:14 <astearns> "color: contrast-color(#eee / max);"
17:42:25 <TabAtkins> argyle: If I just pass a starting color it'll get the max-contrast color (white or black)
17:42:33 <lea> q?
17:42:36 <TabAtkins> argyle: There's also options matching the contrast MQ - "more" or "less"
17:42:46 <TabAtkins> argyle: Without having to specify exactly a contrast algo.
17:43:06 <TabAtkins> argyle: The contrast algo is auto by default, i know that's controversial
17:43:08 <argyle> https://codepen.io/argyleink/pen/RwgzJXV
17:43:10 <TabAtkins> argyle: Here's a demo
17:43:23 <TabAtkins> argyle: I'm writing a codepen with light/dark and low/medium/high contrast
17:43:33 <TabAtkins> argyle: You should be immediately overwhelmed
17:43:37 <TabAtkins> argyle: Just a lot to write
17:43:41 <argyle> https://codepen.io/argyleink/pen/eYKmMmN
17:43:49 <TabAtkins> argyle: This demo is what I've seen people instead already do
17:44:22 <TabAtkins> argyle: Hand-managing oklch deltas in each MQ. Slightly automated, better than WCAG 2 but not perfect. But it works today and gets light/dark and low/medium/high contrasts
17:44:31 <TabAtkins> argyle: My proposal today would make both of those demos a one-liner.
17:44:46 <TabAtkins> argyle: Looks at user pref and auto-discovers what colors they should get
17:44:47 <argyle> contrast-color(Canvas)
17:45:02 <TabAtkins> argyle: This one-liner gives you light/dark and low/med/high contrast
17:45:11 <lea> q+
17:45:16 <TabAtkins> argyle: Current proposal requires authors to write a longer function, and repeat it several times.
17:45:42 <TabAtkins> argyle: so "auto" as the algo complements the author's desire for not having to make a choice. browser can just do what's bet.
17:45:51 <TabAtkins> argyle: If there's no auto target there's no way to give up choice
17:46:17 <TabAtkins> argyle: So to summarize, my proposal doesn't require a color list, defaults to background, offers less/more/max contrast keywords, has an auto contrast keyword
17:46:32 <TabAtkins> argyle: It starts simple, *can* do everything currently in the spec, but doesn't require all the complexity immediately.
17:46:58 <Rossen_> ack lea
17:47:17 <TabAtkins> lea: We all like sensible defaults, but there were several issues with default algorithm that were discussed ad nauseum
17:47:38 <TabAtkins> lea: WCAG 2.0, the current default, is just bad. There are better algos, but there are patent/licensing issues
17:48:00 <TabAtkins> lea: In our experiments in Color.js the other contrast algos listed in the proposal don't actually give good results either
17:48:03 <TabAtkins> lea: So I don't think they're needed
17:48:12 <TabAtkins> lea: I like the idea of integrating this with the preferred contrast MQ
17:48:24 <TabAtkins> lea: Unclear what it does exactly - same keywords, or does the MQ value actually affect the function?
17:48:53 <TabAtkins> lea: minor comment - i find the identifiers side-by-side kinda hard to read, like "abca max"
17:49:23 <TabAtkins> lea: Nothing making it clear that they're tied together - current syntax makes the algos functions so you're sure the args are realted
17:49:35 <TabAtkins> lea: Also not sure what "more"/"less" correspond to mechanically
17:49:47 <TabAtkins> lea: I do like the idea of having background be the default
17:50:00 <TabAtkins> lea: Not sure we need "backgroudn" keyword at all then
17:50:22 <TabAtkins> argyle: yeah, wcag2 is bad, apca3 is still not producing good results yet, still a few years out
17:50:30 <TabAtkins> argyle: If we wait for optimal it'll never ship
17:50:50 <TabAtkins> argyle: I think auto sets it up to grow and for users, if they have a pref, they can specify it
17:51:00 <TabAtkins> argyle: I think most people won't even look past wcag2 being bad
17:51:04 <lea> q+ to say several members were skeptical about having an auto algorithm that could change. Worries we'll be stuck with it forever because authors will depend on the results not changing
17:51:12 <TabAtkins> argyle: so it's hard for us
17:51:27 <TabAtkins> argyle: Say apca comes out and is stable, firefox flips to taht, it woudl b eneat to see it upgrade over time
17:51:39 <TabAtkins> argyle: I just don't like baking in a bad choice
17:51:51 <TabAtkins> argyle: I also agree nobody really knows about the other algos, yeah
17:52:07 <TabAtkins> argyle: So MQ syntax, what is more/less? I had to invent this in my demo - what is more/less in each algo?
17:52:21 <TabAtkins> argyle: I have a table in my proposal mapping them to particular values in each algo.
17:52:24 <lea> Btw our experiments with these other algos (for black/white only): https://colorjs.io/apps/blackwhite/
17:52:41 <TabAtkins> argyle: we'll have to figure this out anyway, for the MQ
17:53:00 <TabAtkins> +1 to the simple keywords that correspond to *some* reasonable values for the algos, I really like that
17:53:08 <argyle> contrast-color(#eee / max apca)
17:53:09 <TabAtkins> argyle: You commented that this looks a little weird
17:53:24 <TabAtkins> argyle: I think this reads really nice personally
17:53:29 <TabAtkins> argyle: I want max contrast from apca
17:53:37 <lea> q+ just remembered, there's also the issue of allowing multiple algos (e.g. a good one + wcag for legal requirements), this syntax cannot grow to accommodate that since params and algos are on the same level
17:53:53 <TabAtkins> argyle: If you do change the algo to something else, you're saying "here's my bg color, here's the target score"
17:54:08 <TabAtkins> argyle: --and hopefully you alway suse auto, anything else can exclude users with particular prefs--
17:54:12 <Rossen_> q?
17:54:20 <lea> I also like "more" or "less"
17:54:57 <TabAtkins> lea: I wrote in IRC what i was gonna say
17:55:00 <TabAtkins> lea: In prev discussions several WG members wer eskeptical about an auto algorithm that can change
17:55:08 <TabAtkins> lea: We'll freeze in practice anyway
17:56:00 <TabAtkins> lea: The other issue is that we might want to allow multiple algos that all need to pass - specify a "good" algo but also a "legally required" algo. Current syntax doesn't accommodate this, since the algo specifiers are on the same level as the algo name itself
17:56:06 <argyle> contrast-color(#eee / 60 lstar)
17:56:11 <TabAtkins> lea: I do like the more/less keywords fwiw
17:56:42 <lea> q?
17:57:02 <TabAtkins> argyle: You're right, I can't do multiple algos right now - "60 lstar, and 4 wcag"
17:57:02 <Rossen_> ack lea
17:57:02 <Zakim> lea, you wanted to say several members were skeptical about having an auto algorithm that could change. Worries we'll be stuck with it forever because authors will depend on the
17:57:04 <Zakim> ... results not changing
17:57:20 <lea> contrast-color(#eee / 60 lstar 5.4 wcag2) makes no sense
17:57:38 <TabAtkins> fantasai: I think this exploration was v helpful
17:57:51 <TabAtkins> fantasai: I do think there are problems with the proposal
17:57:52 <lea> +1 to this exploration being v helpful!
17:58:00 <TabAtkins> fantasai: Really do need to keep the target amount a functional argument
17:58:05 <TabAtkins> fantasai: Both good for reading and for parsing
17:58:40 <TabAtkins> fantasai: functional notation lets us extend the new algos with whatever we need without ambiguity
17:58:47 <argyle> functional notation is an easy change
17:58:52 <TabAtkins> fantasai: i have concerns about auto picking colors to minimum acceptable contrast
17:58:57 <lea> (note that functional notation can also have an argument-less syntax, where we omit the ())
17:59:02 <TabAtkins> fantasai: "pick the right contrast" is usually not the minimum acceptable
17:59:25 <TabAtkins> (we can also have some simple args to the "default" algo not require mentioning the algo)
17:59:49 <TabAtkins> [whoops, missed]
18:00:05 <TabAtkins> fantasai: if we do color ranges, should probably have ability to do ranges of any color, not just the bg hue
18:00:12 <TabAtkins> fantasai: maybe default it to the bg hue
18:00:23 <TabAtkins> fantasai: BAck to syntax, you're having a color, then a slash, then a list of colors
18:00:42 <TabAtkins> fantasai: some disagreement in earlier proposals about where the algo goes, i find your syntax choice interesting and think it reads nicely
18:01:08 <TabAtkins> fantasai: wrt fg/bg i'm pretty strongly against allowing one of them to be defaulted. i do think that needs to be an explicit choice
18:01:10 <fantasai> https://github.com/w3c/csswg-drafts/issues/7937#issuecomment-1431751840
18:01:28 <TabAtkins> fantasai: but I think we can do that without being too wordy if we put it into the function name - contrast-foreground() and contrast-background()
18:01:51 <TabAtkins> fantasai: And I think we need to tackle these problems individually
18:01:57 <TabAtkins> fantasai: auto algo? No, we already resolved that.
18:02:03 <lea> unclear if contrast-foreground(red) is declaring that red is the foreground or asking for a foreground color where red is the background
18:02:06 <TabAtkins> fantasai: function algos? etc. we can address those one by one.
18:02:18 <argyle> thx y'all, sorry that def wasnt 5m
18:02:18 <TabAtkins> Yeah I think that's confusing too
18:02:32 <lea> argyle: nothing syntax related ever is 5m :)
18:02:32 <TabAtkins> (re: Lea's comment)
18:02:41 <TabAtkins> Rossen_: We'll continue discussing in issue.
18:03:00 <TabAtkins> github-bot, end topic
18:03:14 <emeyer> emeyer has left #css
18:03:39 <Rossen_> Zakim, end meeting
18:03:39 <Zakim> As of this point the attendees have been emilio, ydaniv, dbaron, rachelandrew, TabAtkins, miriam, smfr, flackr, PaulG, Rossen_, emeyer, argyle, oriol, jfkthame, plinss,
18:03:42 <Zakim> ... alisonmaher, lea, tantek, chrishtr, bkardell_
18:03:42 <Zakim> RRSAgent, please draft minutes v2
18:03:44 <RRSAgent> I have made the request to generate https://www.w3.org/2023/02/15-css-minutes.html Zakim
18:03:51 <Zakim> I am happy to have been of service, Rossen_; please remember to excuse RRSAgent.  Goodbye
18:03:51 <Zakim> Zakim has left #css
18:03:54 <lea> I think I'm pretty strongly in favor of defaulting to background. Authors are already typing a lot with the contrast algos etc, we don't need them to be typing the common case over and over
18:04:24 <lea> (not to mention that only APCA right now even distinguishes the two)
18:05:09 <lea> argyle: you might want to add the grammar somewhere in your demo?
19:20:34 <argyle> worth sharing too, this is a tool a popular designer created for contrast https://www.learnui.design/tools/accessible-color-generator.html, to show more examples of how folks are tackling this while they wait
20:38:18 <projector> projector has joined #css
20:38:48 <leaverou> leaverou has joined #css
20:39:18 <Rossen> Rossen has joined #css
20:39:49 <shans> shans has joined #css
20:40:19 <sylvaing> sylvaing has joined #css
22:34:04 <Linux_Kerio> Linux_Kerio has joined #css