16:07:00 <RRSAgent> RRSAgent has joined #css
16:07:05 <RRSAgent> logging to https://www.w3.org/2025/01/29-css-irc
16:07:05 <Zakim> RRSAgent, make logs Public
16:07:06 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:08:11 <alisonmaher> alisonmaher has joined #css
16:08:21 <alisonmaher> present+
16:09:03 <emilio> present+
16:09:07 <emilio> scribenick emilio
16:09:17 <bramus> present+
16:09:37 <kschmi> kschmi has joined #css
16:09:41 <noamr> present+
16:10:01 <astearns> we are finding that the Apple desks do not allow Apple power adapters to plug in to them
16:10:42 <kizu> present+
16:10:44 <kbabbitt> present+
16:10:50 <ydaniv> ydaniv has joined #css
16:11:05 <rachelandrew> present+
16:11:22 <jfkthame> present+
16:11:27 <ydaniv> present+
16:12:42 <kschmi> present+
16:13:07 <miriam> present+
16:14:37 <dbaron> Present+
16:18:32 <noamr> There was the `@sheet` proposal on the morning agenda (https://github.com/w3c/csswg-drafts/issues/11509), Simon didn't express specific interest in it. Should we use some of the early session to discuss that perhaps if we're out of working mode topics?
16:18:38 <ntim> ntim has joined #css
16:18:48 <ntim> ntim has left #css
16:19:06 <ntim> ntim has joined #css
16:19:12 <ntim> present+
16:19:32 <argyle> present+
16:19:59 <oriol> present+
16:20:06 <emilio> topic: @sheet
16:20:15 <kschmi> https://docs.google.com/presentation/d/1zE9NgFltry9Qor6ajT695wZiN74zEpydtc1oEbzlhOw/edit#slide=id.p
16:20:19 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/11509
16:20:19 <github-bot> Topic: Proposal: CSS @sheet
16:20:19 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11509.
16:20:27 <emilio> slides: https://docs.google.com/presentation/d/1zE9NgFltry9Qor6ajT695wZiN74zEpydtc1oEbzlhOw/edit#slide=id.p
16:20:57 <bts> bts has joined #css
16:21:38 <emilio> kschmi: justin proposed this in 2020
16:21:51 <emilio> ... great discussion in 2023 where there was a resolution to add it to css-cascade
16:21:56 <emilio> ... and we have some suggestions to expand it
16:22:04 <ydaniv> ydaniv has joined #css
16:22:08 <emilio> ... so I want to touch on those
16:22:23 <emilio> ... quick recap
16:22:24 <astearns> new explainer: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/AtSheet/explainer.md
16:22:30 <emilio> ... main initial goal is bundling
16:22:41 <emilio> ... non-obvious is that this is not obvious but this helps compression rations
16:23:02 <emilio> ... if you can combine more things into one file dictionaries you get more hit
16:23:18 <weinig> weinig has joined #css
16:23:18 <aluhrs> aluhrs has joined #Css
16:23:20 <emilio> ... some testing gives 0.4% compression improvements, so not massive but not nothing
16:23:27 <castastrophe> castastrophe has joined #css
16:23:42 <emilio> ... the important thing I want to go through is that there's a solution for sharing inline styles with declarative shadow DOM
16:23:48 <emilio> ... core concept was resolved in 2023
16:24:01 <emilio> ... where we allowed to reference fragments
16:24:09 <emilio> ... not yet in the cascade spec
16:24:19 <emilio> ... so that was the original proposal
16:24:41 <emilio> ... so you have an `@sheet` block with an identifier and you can import them with a constructable stylesheet
16:24:55 <jensimmons> jensimmons has joined #css
16:24:55 <emilio> ... so that's kinda the bundling scenario. The CSS bits are a pre-requisite
16:25:08 <emilio> ... but we can't get the JS part until CSS adds the syntax
16:25:24 <emilio> ... so `<link rel=foo.css#fragment>` and also `@import`
16:25:30 <emilio> ... so it can cache the file and only make one request
16:25:43 <emilio> q+
16:26:01 <emilio> ... hasn't been spec'd yet, but I think that's worth doing independently
16:26:16 <emilio> ... but the extension is why doesn't this work for same-page URL
16:26:20 <noamr> q+
16:26:40 <emilio> ... so plain fragments would work on inline styles
16:26:46 <fantasai> scribe+
16:26:53 <bramus> scribe+
16:27:03 <matthieud> matthieud has joined #css
16:27:03 <astearns> ack emilio
16:27:06 <fantasai> emilio: 2 things that come to mind
16:27:23 <fantasai> emilio: 1. Why is this CSS-specific, in the sense that other resources ... including fragments and stuff
16:27:32 <fantasai> emilio: This introduces quite a divergence in how we interpret URLs
16:27:51 <fantasai> emilio: What you're proposing feels a bit weird because a plain fragment URL usually references the same document
16:28:01 <fantasai> emilio: I guess we do have some precedent for some fragment-only URLs being a bit special
16:28:28 <fantasai> emilio: One thing I'm concerned about, how does this behave-- if a browser doesn't implement it, the browser pulls the whole stylesheet and ignores it
16:28:35 <matthieud> q+
16:28:36 <fantasai> emilio: it would import nested stylesheets
16:28:47 <fantasai> emilio: feels like a more explicit mechanism here would be nice, but maybe we can live with this?
16:28:54 <fantasai> emilio: I'm a bit worried about feature detection and fallbacks
16:29:01 <fantasai> scribe-
16:29:06 <astearns> q+ justin
16:29:11 <weinig> weinig has joined #css
16:29:48 <astearns> ack noamr
16:30:01 <miriam> We allow `supports()` in imports
16:30:02 <bramus> noamr: When i see the # i expect it to be an id
16:30:16 <bramus> … mixes html and css too much
16:30:32 <justinf> justinf has joined #css
16:30:41 <bramus> … would prefer so,meting that has a sheet attr on link
16:30:42 <tuankiet645> tuankiet645 has joined #css
16:30:49 <bramus> … and other modifier to import, we have one for layer
16:31:00 <bramus> … in general would be careful to use hasehs for sth that is not dom id
16:31:03 <bramus> … confuses things
16:31:08 <florian> q?
16:31:26 <kschmi0> kschmi0 has joined #css
16:31:41 <bramus> kurt: fragment already acceptd in prior discussion
16:31:47 <bramus> … mgiht need to be revisited
16:32:06 <bramus> … if fragment does work, much like acnhors you dont need a URL it means local
16:32:06 <florian> q+
16:32:08 <bramus> … this is building on that
16:32:24 <bramus> … there’s a precedent: if there is no file assume it is in the same doc
16:32:31 <bramus> … only thing doing that is anchors, which is excepction to a lot of things
16:32:41 <bramus> … if we do revisit fragment for this scenario, then we need to revisit for this
16:32:55 <bramus> … other syntax or attr … would feel inconsistsent to not do this
16:33:07 <bramus> noamr: wnated to say that it is different
16:33:20 <bramus> … fragmetns and svg clip path and shapes – there are precedents but they refer to the dom id
16:33:26 <bramus> … no prob with multidoc
16:33:38 <astearns> ack dbaron
16:33:51 <bramus> dbaron: from a URL design perspective the meaning of a fragment is generally specific to the mime-type of th resource
16:33:54 <fantasai> +1 dbaron
16:34:04 <bramus> … the idea that in a css file to refer to an @sheet can be sensible
16:34:07 <justinf> +1 as well
16:34:18 <bramus> … and in an HTML file they already refer to IDs and we should be very careful about changing that
16:34:35 <bramus> … I could imagine with an @sheet inside a style element, and then use the id of the style element
16:34:38 <justinf> fragments without a preceding URL refer to something in the HTML document already
16:34:49 <bramus> … one of the design principles here is the meaning of fragment in a URL is specificy to the mime-type
16:34:50 <emilio> q+
16:34:52 <bramus> kurt: makes sense
16:35:02 <bramus> … we do have a .css file in this example
16:35:16 <bramus> … but there is HTML and there is a mismatch witht he mimetype
16:35:19 <ydaniv> q+
16:35:20 <bramus> … great point
16:35:28 <noamr> +1, exactly, I have no problem with it inside CSS files
16:35:29 <Aluhrs> Aluhrs has joined #Css
16:35:30 <astearns> ack matthieud
16:35:39 <bramus> matthieud: answer for emilio about old browser
16:35:51 <bramus> … that dnt udnerstand @sheet
16:36:03 <castastrophe> q+
16:36:26 <bramus> … how to resolve the rules inteh block
16:36:31 <emilio> ... So re. what happens for all browsers, are we going to lose all the rules
16:36:38 <bramus> … same solution with @layer can be applied
16:36:43 <emilio> ... but we could make like @layer where anything after is considered part of it
16:37:01 <emilio> ... so this looks a lot about @layer
16:37:11 <emilio> ... just with no notion of priority\
16:37:40 <fantasai> emilio: Concern is not only with what's in the block
16:37:46 <bramus> emilio: concern is not only what happens with contents of the blocks but older browser dont have concept of importing parts of a stylesheet
16:37:51 <bramus> … external parts would apply
16:37:59 <bramus> matthieud: doesnt work for ???
16:38:04 <bramus> emilio: but doesnt work for link either
16:38:10 <ydaniv> q-
16:38:13 <emilio> s/???/@import
16:38:28 <astearns> acj justinf
16:38:38 <emilio> ack justin
16:38:56 <emilio> justinf: Wanna comment on the fragment thing
16:39:02 <matthieud> I would have like an answer about the @layer vs @sheet though ?
16:39:09 <emilio> ... has been touched that the impolicit URL is the HTML document url
16:39:24 <emilio> ... being able to do about dom vs. stylesheet
16:39:38 <emilio> ... on the DSD case there could be multiple sheets
16:39:47 <emilio> ... and in order to do this we have to have a central resource
16:39:54 <emilio> ... and I'd be a bit wary of this
16:40:21 <emilio> ... there's also a question of external stylesheets with nested @sheets
16:40:33 <emilio> ... it's something I'd want to avoid, we're trying to avoid global resources like custom element names or what not
16:40:39 <emilio> ... so I wouldn't add another one
16:40:46 <astearns> ack florian
16:41:04 <emilio> florian: narrowly on this specific slide, as long as @sheet is something that exists I agree it'd be nice to use it on inline styles
16:41:14 <noamr> For the `#` - it can be `#:~:sheet=the-sheet-name` like text fragments
16:41:25 <emilio> ... slightly more generally I think this is quite complex and we need to move into the discussion of what this does for shadow dom
16:41:42 <emilio> ... yeah it's convenient to have one file with preprocessing
16:42:06 <emilio> ... http/2 deals with some of the multiple request complexity
16:42:08 <astearns> ack emilio
16:42:10 <justinf> for shadow DOM basic bundling is sufficient, IMO
16:42:20 <florian> s/use it on inline styles/use it on inline style elements
16:42:23 <emilio> ... so outside of shadow dom I don't see a lot of use for this
16:42:44 <bramus> emilio: agree with florian that main use case feels … basically about shadow dom. if you have no, you can bundle and call it a day
16:42:50 <bramus> … want to try a counter proposal tha tmight work
16:42:59 <bramus> … and doesnt need to add anything new
16:43:01 <bramus> … except 1 thing
16:43:18 <bramus> … what you really want is @import but without separate request to import into shadow dom
16:43:32 <bramus> … talked about removing constructbile stylesheet restircition in adoptable ones
16:43:49 <bramus> … if you have data-uri @import that you could import into SD you kinda get this behavior
16:44:01 <bramus> … not user friendly, but if use case is bundlers then they can prolly manage
16:44:19 <bramus> … idea would be to get the @import stylesheet and shadowroot.adopted.push(…)
16:44:33 <bramus> … and if you dont want that to aply to the doc, you could isable with a non-mathcing media in the elem
16:44:33 <justinf> q+
16:44:42 <bramus> … we have a lot of similar pieces that would be nice
16:44:55 <bramus> …  if use cases are narrow, e.g shadow dom and bundling
16:45:01 <bramus> … then you might be able to get away with this
16:45:07 <bramus> … has that been explored?
16:45:11 <bramus> q?
16:45:14 <noamr> noamr has joined #css
16:45:19 <justinf> isn't that unwinding the whole proposal, including the previous resolutions?
16:45:26 <emilio> yes
16:45:33 <astearns> ack castastrophe
16:45:37 <smfr> smfr has joined #css
16:45:40 <smfr> present+
16:45:42 <justinf> `@sheet` seems a lot simpler than data URI and changes to import to me
16:45:42 <emilio> castastrophe: just a question, trying to picture things in the design systems space
16:45:59 <emilio> ... how would you import multiple sheets, multiple `<link>` or `@import`?
16:46:17 <emilio> kschmi: yeah you'd need multiple sheets or @import or both
16:46:23 <astearns> ack justinf
16:46:38 <emilio> justinf: Responding to emilio or florian... The basic @sheet to me is very simple
16:46:54 <emilio> ... there's no way currently to include an inert chunk of CSS
16:47:00 <emilio> ... turns out you can with @supports
16:47:20 <emilio> ... but @import + data uri + ... feels a lot more complex than @sheet
16:47:36 <emilio> ... The additional complexity is adding ways to reference these from inline styles
16:47:55 <emilio> ... I don't think that complexity applies to that part of the proposal
16:48:13 <emilio> FWIW `@import url("data...") not all;` doesn't seem /terribly/ complex to me
16:48:34 <emilio> kschmi: so re. shadow dom
16:48:36 <justinf> but then you need that `@import()` to 1) be inert, and 2) be importable as a separate sheet
16:49:10 <emilio> ... current mechanism are duplicate `<link rel>` or inline styles or script-based adoptedStyleSheets
16:49:19 <emilio> ... so for declarative shadow DOM is not great
16:49:56 <emilio> ... If we support the standalone fragment we can support it for declarative shadow dom
16:50:05 <emilio> ... that's kinda why this is relevant to DSD
16:50:12 <emilio> ... solves that messy problem r/n
16:50:29 <noamr> q+
16:50:39 <emilio> ... big question justinf is concerned about is scoping
16:50:48 <justinf> q+
16:50:53 <emilio> ... which is an issue, might be the same as inheriting from parent
16:51:00 <dholbert> dholbert has joined #css
16:51:04 <emilio> ... lots of open issues, we have an explainer in MSEdgeExplainers
16:51:19 <emilio> ... big list of open issues, but key problem we're solving is inline styles with declarative shadow dom
16:51:28 <emilio> ... another solution for this would be declarative CSS modules
16:51:36 <jensimmons> jensimmons has joined #css
16:51:54 <emilio> ... `<script type=css-module>` and `adoptedstylesheets=""`
16:52:03 <emilio> ... TAG pointed to `@sheet`
16:52:12 <emilio> ... seems this still has more issues
16:52:39 <emilio> ... If we could get this standalone fragment thing would be nice
16:52:57 <emilio> ... both seem good proposals, but I think there's a big demand to solve this
16:53:27 <emilio> ... so there's shared goals, but they can solve the same problem
16:53:43 <emilio> ... curious to see what the WG and developers prefer
16:54:01 <emilio> ... that was more or less it
16:54:03 <emilio> q+
16:54:13 <emilio> ack noamr
16:54:24 <kbabbitt> kbabbitt has joined #css
16:54:32 <justinf> noam +1
16:54:34 <emilio> noamr: When I see this whole thing I see it like an HTML problem and not a CSS problem
16:54:57 <emilio> ... You can fix this with shadow DOM if you have a fragment refer to an ID in your document
16:55:04 <emilio> ... it seems also a problem with script importing
16:55:17 <fantasai> s/ID/ID of a <style> or <link> element/
16:55:18 <emilio> ... maybe we can present this at WHATNOT
16:55:22 <fantasai> +1 noamr
16:55:37 <emilio> ... But I wonder if there are commonalities to importing style and script
16:55:51 <emilio> ... and there are solutions that could require less work
16:56:16 <emilio> kschmi: Yeah if there was a way like svg fragment you're right we wouldn't need @sheet for this
16:56:23 <justinf> the only issue with IDs with DSD is that we need a *global* ID to cross shadow root boundaries. But that's a DOM issue
16:56:24 <emilio> ... We could have an attribute
16:56:33 <emilio> noamr: you'd add a link pointing to the ID
16:56:34 <castastrophe> q+
16:56:40 <astearns> ack justinf
16:56:56 <emilio> justinf: re. the scoping, one of the reasons I was shaking my head with scoping
16:57:38 <emilio> ... we want to render instances, in a way that the root needs to hold the stylesheet of component a, but you don't want to emit them until you've found the first
16:57:45 <emilio> ... so I think we need some sort of global resource
16:58:02 <emilio> ... but I'd be very careful about choosing what global resource
16:58:24 <noamr> for bundling, you can have an external HTML file that has multiple <style> elements with IDs and you refer to them
16:58:24 <emilio> ... but I agree with noamr that this is kind of an HTML issue, because IDs don't propagate across shadow boundaries
16:58:40 <bramus> emilio: wanted to ask whether other subresources have same nees
16:58:51 <bramus> … but tha t is what noam ended up asking
16:58:52 <astearns> ack emilio
16:58:56 <astearns> ac castastrophe
16:59:01 <astearns> ack castastrophe
16:59:12 <emilio> castastrophe: had a question about @sheet, the syntax makes me think that if I wanted to override a sheet namespace I would be able to
16:59:22 <emilio> ... with the fragment syntax it makes me feel like you can't
16:59:40 <emilio> ... if I declare another ID in the DOM it doesn't override the first
16:59:44 <emilio> ... what is the behavior here?
16:59:58 <emilio> kschmi: That's one of the open questions
17:00:07 <florian> q+
17:00:09 <emilio> ... @layer would add to it
17:00:19 <astearns> ack fantasai
17:00:21 <astearns> ack florian
17:00:23 <weinig> weinig has joined #css
17:00:23 <emilio> florian: I find the shadow dom use case very compelling
17:00:29 <emilio> ... more compelling than the other use cases
17:00:48 <emilio> ... if we agree to solve it with @sheet it motivates solving some of the `@sheet`s
17:01:00 <emilio> ... issues
17:01:08 <emilio> ... the way @sheet is imported seems problematic
17:01:25 <emilio> ... browsers doing different things for `url(#foo)` seems like a problem
17:01:38 <emilio> ... the overriding is question is a challenge as well
17:01:42 <castastrophe> q+
17:01:49 <emilio> ... the shadow dom use case seems the most compelling, the other ones seem nice
17:02:09 <emilio> ... if we decide to solve the shadow dom use case some other way, not sure we want `@sheet`
17:02:11 <justinf> this difference in behavior with legacy browser is always the case... I'm personally hoping that @sheet support can coincide with CSS imports support in Webkit and Gecko so that if you can import a stylehsheet you can also import an `@sheet`
17:02:38 <emilio> kschmi: Great points, I think the original proposal was about importing / bundling
17:02:46 <noamr> justinf: I think hash-fragments, e.g. in same-document links, cross shadow boundaries?
17:03:04 <emilio> justinf: this is an addon to JS import asserts in CSS modules
17:03:19 <emilio> ... you have a lot of JS modules which depend on small fragments on CSS
17:03:22 <kschmi> kschmi has joined #css
17:03:47 <emilio> ... but bundlers don't know how to deal with bundling CSS there
17:03:58 <emilio> ... that was my main motivation, you end up with lots of small CSS files otherwise
17:04:20 <emilio> ... was kinda hoping that if @sheet is simple enough it'd ship along CSS imports in webkit / gecko
17:04:40 <miriam> q+
17:04:41 <emilio> ... happens to be a simple polyfill for transforming to @import
17:04:51 <astearns> ack castastrophe
17:04:58 <justinf> transforming to @supports, not @import
17:05:15 <emilio> castastrophe: I see where you're coming from florian
17:05:29 <bkardell_> bkardell_ has joined #css
17:05:30 <emilio> ... if we solve it for webcomponents my preference would be to solve it for native DOM solutions as well
17:05:33 <bramus> Big +1
17:05:51 <emilio> ... I'm doing so much transforming of code between the two systems, so it'd be nice to allow authors to just write it once
17:05:59 <astearns> ack miriam
17:06:05 <kbabbitt> kbabbitt has joined #css
17:06:07 <justinf> btw, CSS imports is mainly a feature that makes CSS more usable from JS defined components... it doesn't need to be web components or shadow DOM
17:06:12 <emilio> miriam: high level syntax thought, there was some mention of syntax looking similar to @layer, but funcitonality is entirely different
17:06:23 <emilio> ... I think it overlaps more with @scope
17:06:30 <justinf> q+
17:06:32 <noamr> +1
17:06:32 <bkardell_> present+
17:06:35 <emilio> q+
17:06:47 <emilio> kschmi: Yeah the way I think about @sheet is a separate file
17:06:58 <matthieud> actually yes I agree, @scope is closer to this than @layer
17:06:59 <emilio> ... @layer is a different cascade layer, and that's why you can have multiple layers and so on
17:07:12 <emilio> ... @sheet is only one definition per sheet, that kinda helps my mental model a bit
17:07:29 <emilio> matthieud: I agree that @scope is closer than @layer
17:07:32 <emilio> ack justinf
17:07:35 <astearns> ack justinf
17:07:58 <emilio> justinf: Wanted to comment, I wanted to make sure that this is not always associated with shadow dom and webcomponents
17:08:16 <emilio> ... having a way to import this seems useful for non-shadow-dom related use cases as well
17:08:26 <emilio> ... so I'm hoping this would be much broader
17:08:29 <bramus> (FWIW: I believe @layer was only mentioned in relation to what browsers do when they don’t support it: they discard the entire block.)
17:08:31 <emilio> ack emilio
17:08:37 <astearns> ack emilio
17:08:55 <bramus> emilio: want to suggest that if we are doing this we could bypass a lot of the fragment issues if we allow importing using a different syntad
17:09:03 <emilio> @import sheet(name)
17:09:05 <bramus> s/syntad/syntax
17:09:21 <bramus> emilio: that bypasses a lot of the questions about what the fragment means
17:09:22 <castastrophe> or both? @import url() sheet()
17:09:29 <florian> +1
17:09:37 <bramus> justinf: still seems to have the global namespace
17:09:40 <weinig> (not sure if this has been mentioned, or how relevant it is, but there is a some written thoughts on fragments here -> https://www.w3.org/TR/fragid-best-practices/)
17:09:42 <bramus> emilio: that’s kinda ???
17:10:08 <emilio> castastrophe: +1 to emilio, you could combine it with url and specify different sheets from that URL
17:10:16 <bramus> emilio: that wouldn have global namespace issues
17:10:25 <bramus> … because you arkimporting this sheet from that url
17:10:28 <alexis_menard> alexis_menard has joined #css
17:10:37 <bramus> justinf: depends on … declarative dom use case (missed)
17:10:56 <bramus> emilio: guess you could with  no URL you import the document or some smaller thing
17:11:17 <bramus> … if you ignore the improt and inline style hting, it still works for declarative shadow dom
17:11:23 <noamr> Perhaps "importing from inline" and "partially importing from a sheet" don't require the same solution?
17:11:26 <bramus> … do `@import url() sheet()`
17:11:33 <bramus> justinf: if you can do that, solves 99% of ht eproblems
17:11:48 <bramus> … if you can bundle all, you can do ahead of time and import later
17:12:22 <noamr> q+
17:12:26 <justinf> q+
17:12:27 <bramus> kurt: challenge with file specific syntax is what justin was saying – need to support same doc styles
17:12:35 <astearns> Zakim, close queue
17:12:35 <Zakim> ok, astearns, the speaker queue is closed
17:12:38 <bramus> … you want a high per site to paint auickly with styles
17:12:43 <bramus> … best option is not an external file
17:12:48 <bramus> … that is feedback i got from devs
17:13:00 <bramus> … "sure separte file is nice, but inline in html is powerful for first paint"
17:13:09 <astearns> ack noamr
17:13:18 <emilio> `<style>@import url(..) sheet(..)</style>`
17:13:31 <bramus> noamr: seems like different problem?
17:13:33 <weinig> weinig has joined #css
17:13:46 <astearns> ack justinf
17:14:15 <emilio> justinf: wanted to clarify on `<stlye>`. In a server component case you don't have all the components, they depend on the page
17:14:23 <emilio> ... something like an amazon product page is a canonical example
17:14:39 <emilio> ... could render millions of components
17:14:55 <emilio> ... I don't think any external file solution deals with that
17:14:57 <bramus> emilio: they are not exclusive
17:15:16 <bramus> … as noam was saying, having a specific syntax to import sheets and being able to import from an inline style seem like differnet
17:15:18 <bramus> justinf: agree
17:15:24 <bramus> … would love to see capabitliy in html
17:15:26 <bramus> emilio: ok
17:15:31 <bramus> … then we are in agreement
17:15:39 <bramus> florian: you emilio are proposing to solve with css syntax, not html
17:15:52 <bramus> emilio: i was proposing to have specific syntax for importing style sheet from a file
17:16:01 <bramus> … tha tdoes not avoid adding that fro m???
17:16:22 <bramus> florian: if you have @import url() sheet() it imports tehs eet fro,m the url
17:16:27 <bramus> … if you omit the url, its from the current file
17:16:36 <bramus> … if the curernt file is the html, then that is where you try and go find it
17:16:48 <bramus> emilio: or you could impor from url(#something) to refer to that style or link
17:16:53 <castastrophe> q+
17:17:07 <bramus> florian: the syntax you proposed not only is useful but fully replaces need for link rel=stylesheet and makes it not an html problem
17:17:13 <bramus> emilio: still need to define how to target a partciular element
17:17:17 <noamr> import url("#my-inline-style") sheet(my-sheet)
17:17:29 <bramus> castastrophe: if you are inside sd with import, do you have timport @import from sd or from parent?
17:17:33 <bramus> … does not exist right now
17:17:45 <bramus> noamr: url fragment are not ???
17:17:56 <bramus> astearns: should prolly close this for now
17:18:01 <emilio> noamr: URL fragments do cross shadow boundaries, like `<a href="#foo">` doesn't look only inside its shadow tree
17:18:08 <bramus> … was mentionedthat this should be presented at whatnot
17:18:11 <bramus> … kurt, can you do that?
17:18:14 <bramus> kurt: yes
17:18:23 <bramus> astearns: and then we ahve issue of @sheet not being a spec
17:18:31 <bramus> … would you kurt be intereste to be an editor for that?
17:18:33 <bramus> kurt: yes
17:18:41 <emilio> s/kurt/kschmi/
17:18:53 <smfr> smfr has joined #css
17:19:08 <bramus> astearns: So I proposed to add kschmi as editor for css-cascade-7 to spec that
17:19:24 <bramus> … start with what we have not, and then extend to shadow dom and othe ruse cases and bring back to the group
17:19:42 <bramus> kschmi: sgtm
17:19:52 <bramus> TabAtkins: the number?
17:20:05 <bramus> astearns: taking that from fantasai that @scope is prolly done and to take 6 to CR
17:20:17 <bramus> TabAtkins: if 6 is ready for cr and 5 is in cr, then merge scope into 5
17:20:27 <bramus> … dont like many numbers, especially when its only 1 feature per number
17:21:18 <bramus> fantasai: we should get 4 in rec bc layers are shipping and 6 should move to cr and merge down contents of 5 into 6
17:21:41 <bramus> PROPOSED RESOLUTION: Add kurt as editor of css-cascade and work with current editors to figure out the number
17:21:56 <bramus> florian: IUC we resolved on adding @sheet syntax itself, but not on the importing part
17:22:10 <bramus> … regardless we have had enough debate about that that we should add an inline issue in the spec
17:22:14 <bramus> … that its a moving target
17:22:20 <bramus> astearns: editor’s discretion
17:22:35 <bramus> RESOLVED: Add kurt as editor of css-cascade
17:22:35 <BFeigel> BFeigel has joined #CSS
17:22:49 <bramus> astearns: let’s move on to shape issues
17:23:00 <justinf> thank you everyone!
17:23:05 <fantasai> Topic: Shape
17:23:17 <fantasai> s/Shape/Shapes/
17:23:26 <argyle> squircle!!
17:23:27 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/10993
17:23:27 <github-bot> Topic: [css-shapes-2][css-borders-4] corner-shape support for superellipsis
17:23:27 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10993.
17:23:48 <emilio> smfr: there's a proposal to add a squircle function / different types of corner treatments
17:23:56 <emilio> ... there's also bevels / etc
17:24:16 <emilio> ... but more recently there's been a proposal of `superellipse` function
17:24:24 <emilio> ... which would allow those and also things in between
17:24:31 <emilio> ... including squircle
17:24:43 <emilio> ... wanted to give some background and some reservations I have about it
17:24:50 <emilio> ... this demo is using border-radius
17:25:18 <emilio> ... this is existing border-radius
17:25:21 <noamr> https://noamr.github.io/squircle-testbed/
17:25:52 <emilio> ... the "Apple rounded rect" is also a regular bezier point but with more control points
17:26:40 <emilio> ... There's some tricky cases with overlapping corners
17:27:38 <emilio> ... superellipse is this function that for a k=0 gets you bevel, with different ks you can get different joins
17:27:48 <emilio> ... with different ks you can get something like the squircle
17:27:55 <emilio> ... but now you got multiple parameters to change
17:28:04 <emilio> ... border-radius and the k
17:28:35 <emilio> ... it's not clear for authors which combination they'd choose
17:28:36 <weinig> weinig has joined #css
17:28:38 <TabAtkins> q+
17:28:43 <emilio> ... The other thing is that it's generated iteratively
17:28:52 <astearns> zakim, open queue
17:28:52 <Zakim> ok, astearns, the speaker queue is open
17:28:54 <TabAtkins> q+
17:29:01 <noamr> q+
17:29:02 <emilio> ... not using bezier curves, so not very efficient to render unless you approximate it using bezier curves
17:29:12 <astearns> ack noamr
17:29:27 <emilio> noamr: The proposal was also to add a squircle keyboard
17:29:40 <emilio> ... agreed with the perf concern
17:29:57 <emilio> ... specially stroking, filing should be fine with shaders
17:30:33 <emilio> ... for that reason I'm more inclined towards the apple-style continuous rect rather than superellipse
17:30:52 <astearns> ack TabAtkins
17:30:53 <emilio> ... on the other side I'd like more expresiveness for authors if we can solve the efficiency problem
17:31:11 <emilio> TabAtkins: in your later comments you said that to do a squircle you'd need both k and border-radius
17:31:21 <emilio> ... how does that work with just a squircle corner shape
17:31:38 <emilio> ... presumably the flat segment is specified by border radius
17:32:05 <emilio> smfr: yeah we apply the squircle only to the rounded corner area
17:32:15 <emilio> TabAtkins: ok so this is a different curve than superellipse
17:32:27 <weinig> q+
17:32:52 <emilio> TabAtkins: so in your preferred solution you have a small border radius with a separate knob
17:32:56 <emilio> smfr: right
17:33:03 <florian> q+
17:33:04 <emilio> TabAtkins: so this seems to be two parameters as well right?
17:33:13 <emilio> smfr: Only one parameter, which is border-radius
17:33:32 <emilio> TabAtkins: is it just because the squircle is a fixed pos?
17:33:38 <emilio> smfr: pretty much
17:34:14 <emilio> TabAtkins: it seems for fserb's proposal the squircle thing would just be a fixed k=4 right? So seems similar?
17:34:34 <emilio> ... so if you're using the fixed squircle shape you have only one free parameter
17:34:51 <emilio> ... the computational issues are a thing, but the parameterization seems fine to me?
17:35:04 <emilio> smfr: depends on how we want to expose this to CSS
17:35:15 <emilio> ... so adding squircle / bevel with keywords or something more flexible
17:35:32 <emilio> TabAtkins: I think fserb's proposal was to add keywords that computed to the superellipse parameters
17:35:42 <emilio> ... but I don't understand the calculus of the different params here
17:35:46 <emilio> ... so that might trump it
17:35:51 <astearns> ack weinig
17:36:13 <emilio> weinig: Is there any standardization in the design community outside apple / google that we could use here?
17:36:39 <emilio> smfr: I think there's a figma thing where they were looking at the apple one, but depends on which camp we're on
17:36:52 <emilio> weinig: Is there a built-in superellipse in illustrator on something?
17:36:56 <emilio> s/on/or
17:37:15 <emilio> smfr: not sure illustrator but figma and so do
17:37:33 <emilio> ... there's also the question of what authors want, just apple/google squircle or something else
17:37:57 <emilio> weinig: I don't think we want to hardcode the apple one, it could change in the future or what not
17:38:10 <emilio> smfr: I agree we don't want a single keyword that just gives you exactly the apple one
17:38:18 <emilio> ... we're fine with authors having to tweak border-radius or what not
17:39:00 <schenney> q+
17:39:08 <emilio> smfr: For IP reasons we don't want a single keyword that gives you the apple shape, but we're fine giving the corner treatment
17:39:33 <emilio> weinig: that makes sense, was trying to see what the non-app-icon use from authors would be generally useful
17:39:34 <noamr> q+
17:39:44 <emilio> smfr: And agree on let's not lock in on the current rounded icon format
17:39:46 <astearns> ack florian
17:40:17 <emilio> florian: what I like about fserb's proposal is that it gives keywords for things authors really want, and an underlying system
17:40:21 <emilio> ... to explore other bits
17:40:36 <emilio> ... not in a position to talk about performance, but I hope it can be fixed
17:40:56 <emilio> ... there are more knobs that your demo doesn't show (like each corner separately)
17:41:06 <astearns> ack schenney
17:41:30 <emilio> schenney: wanted to point out that animation is not being discussed yet, but an animation would lean towards a functional notation
17:41:32 <florian> s/like each corner separately/like each corner separately, or each side of each corner…
17:41:48 <emilio> smfr: agree, I think it's going to be possible to approximate superellipses with beziers
17:41:52 <kizu> q+
17:42:01 <emilio> ... I think it's tractable. Certainly more convenient with the k param
17:42:04 <astearns> ack noamr
17:42:04 <TabAtkins> q+
17:42:05 <joshtumath> joshtumath has joined #css
17:42:31 <emilio> noamr: From the perspective of how to bring this to the masses, I'd suggest to start with the continuous one and then build on top
17:42:47 <emilio> ... then try to figure out approximation of superellipse or what not
17:42:56 <emilio> ... thoughts?
17:43:08 <emilio> smfr: I agree we could do keywords first
17:43:23 <emilio> ... we'd have to think about animations
17:43:27 <emilio> ... maybe just discrete for now
17:43:31 <emilio> kizu: +1 to florian
17:43:31 <astearns> ack kizu
17:43:42 <kizu> https://github.com/w3c/csswg-drafts/issues/6980
17:43:43 <emilio> ... both the superellipsis and a set of keywords
17:43:57 <weinig> (likely the blog post from Figma smfr mentioned -> https://www.figma.com/blog/desperately-seeking-squircles/ )
17:44:15 <emilio> ... issue above has lots of comments about that
17:44:37 <florian> q+ to ask how bad is the performance problem
17:44:48 <astearns> ack TabAtkins
17:44:48 <emilio> ... so yeah would be good to have the functional version to create something more interesting
17:45:03 <emilio> TabAtkins: if the idea is that a superellipse does get decent results but is computationally intractable
17:45:20 <emilio> ... can we allow a degree of approximation in the spec so that you're allowed to approximate
17:45:31 <emilio> ... I think that is not very controversial
17:45:44 <emilio> ... so if beziers are tractable then we can just allow that
17:45:59 <emilio> smfr: I think that's fine, I just haven't done the math to approximate the conversion yet
17:46:13 <emilio> weinig: at the lower level most graphics libs are already doing approximations of these things
17:46:25 <emilio> ... I think there's unlikely to be a sever penalty
17:47:01 <emilio> TabAtkins: anything more rounded than a bevel needs an extra check for overlapping curves
17:47:16 <emilio> smfr: Right, we already have some constraints on rounded rects
17:47:45 <emilio> TabAtkins: right, but the border-radius overlap is trivial
17:48:13 <schenney> q+
17:48:23 <emilio> smfr: Yeah for the simple case we can probably check the rects
17:48:27 <emilio> ... maybe too restrictive
17:48:56 <emilio> smfr: [draws something]
17:49:02 <emilio> smfr: people want to do [that]
17:49:04 <astearns> ack florian
17:49:04 <Zakim> florian, you wanted to ask how bad is the performance problem
17:49:11 <TabAtkins> example is: border-radius of 0 100% 0 100%
17:49:23 <emilio> florian: unfortunate that fserb isn't here
17:49:28 <noamr> q+
17:49:35 <smfr> smfr has joined #css
17:49:35 <emilio> ... curious, were you talking about approximating any k with bezier?
17:49:41 <emilio> ... or just some k values?
17:49:47 <emilio> ... if the former that's great
17:50:15 <emilio> ... I think for superellipse() fserb had a reasonable implementation
17:50:22 <astearns> ack schenney
17:50:30 <emilio> smfr: Haven't tried generic k -> bezier conversion
17:50:43 <emilio> schenney: it's not so much whether you can but how expensive the approximation is
17:51:00 <emilio> ... even now with the existing rounded corners I'm 99% sure that there are still issues in browsers with border-width
17:51:09 <emilio> ... so the interaction with border-width makes this trickier
17:51:32 <emilio> ... certain border widths + radius cause this to be tricky, so would be good to consider it
17:51:34 <emilio> smfr: agreed
17:51:35 <astearns> ack noamr
17:51:59 <emilio> noamr: we're not going to solve the computational issue in this meeting. Perhaps we should limit this to determine that we want the parametric superellipse() if achievable
17:52:16 <emilio> ... have a rough CSS syntax for it and we can adjust based on implementability
17:52:43 <emilio> astearns: was thinking of an even smaller step of starting with keywords, described in terms of superellipse
17:52:57 <emilio> TabAtkins: that doesn't allow for smooth transitions in the future
17:52:57 <smfr> q+
17:53:16 <emilio> astearns: if we're defining keywords in base of the superellipse, don't you get that?
17:53:30 <emilio> TabAtkins: but the interpolation wouldn't be expressable until we get the function version
17:53:40 <emilio> smfr: unless we do mix() function magic...
17:53:41 <astearns> ack smfr
17:53:57 <emilio> ... before resolving corner-shape, we probably want to decide whether we want border-shap
17:54:14 <emilio> ... because they have interactive functionality
17:54:32 <emilio> astearns: #6997?
17:54:58 <emilio> smfr: yeah, would be nice to get leaverou's opinion about this too
17:56:12 <weinig> weinig has joined #css
17:56:24 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/6997
17:56:24 <github-bot> Topic: [css-shapes-2][css-borders-4] Add a way to change an element's shape
17:56:24 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6997.
17:57:04 <emilio> noamr: I can give a bit of a recap
17:57:22 <emilio> ... we resolved at TPAC on having a draft for border-shape
17:57:29 <fserb> fserb has joined #css
17:57:30 <emilio> ... I started working on that and discovered some questions
17:57:35 <fserb> fserb has joined #css
17:57:38 <emilio> ... one of them is how it relates to corner-shape
17:57:47 <emilio> ... other one is how it works with border-width etc
17:57:57 <fserb> present+
17:57:57 <emilio> ... so wanted smfr to demo what he has
17:58:03 <emilio> ... and then talk demos
17:58:25 <fserb> fserb has joined #css
17:58:28 <emilio> smfr: [shows prototype]
17:58:56 <emilio> ... uses border-shape with the recent `shape()` function
17:59:05 <emilio> ... so it effectively takes over the rendering of the rounded rect
17:59:11 <emilio> ... and replace it with effectively two shapes
17:59:18 <emilio> ... one for the inside of the rect, one for the outside
17:59:31 <emilio> ... actually first outside, second inside
18:00:00 <emilio> ... it uses two different beziers, and it shows background-clip: border-area, and also box-shadow which both follow those shapes
18:00:15 <emilio> ... the way I think about this is replacing the rendering of the radius
18:00:21 <emilio> s/radius/border/
18:00:43 <emilio> ... it follows the same rules regarding clipping of the content etc, just like border-radius
18:00:48 <emilio> ... that's the two-shape version of this
18:01:01 <emilio> ... [switches demo]
18:01:22 <emilio> ... this one is the one-shape version, with a hole
18:01:55 <ccameron> ccameron has joined #css
18:01:56 <noamr> q+
18:02:05 <emilio> ... I think I used border-top-width for the line width
18:02:40 <emilio> ... but single-shape has issues re. that interaction
18:02:49 <emilio> ... a separate draft of mine just specifies effectively a stroke width
18:02:53 <emilio> ... interpolating seems hard
18:03:10 <emilio> ... also this is purely decorative. Affects clipping and ink overflow, but layout still uses the general box model
18:03:13 <emilio> q+
18:03:40 <emilio> ... what that means is that you might specify shape that allow the inside edge to project outside of the border-box
18:03:53 <emilio> ... which exposes things like extra background area or what not which are a bit weird
18:04:03 <TabAtkins> q+
18:04:28 <astearns> ack noamr
18:04:37 <emilio> ... one other thing I wanted to mention the connection between this and corner-shape is that this breaks assumptions
18:04:49 <emilio> noamr: one of the oddities is how it interacts with border-width
18:05:13 <emilio> ... with border-radius it kinda works
18:05:18 <emilio> ... so that's one oddity of this
18:05:35 <emilio> ... if your shape is kinda boxy you probably want your border-width to affect it
18:05:45 <emilio> ... I think border-width would be a default you can override
18:05:49 <emilio> ... same with border-color
18:06:11 <emilio> ... my thinking was that this could behave like a mask going through the borders
18:06:17 <noamr> https://github.com/w3c/csswg-drafts/issues/6997#issuecomment-2389134315
18:06:37 <emilio> ... would be a simple solution but not what people would want
18:06:38 <fserb> q+
18:06:48 <emilio> ... I think this should be separate from corner-shape
18:06:55 <emilio> ... we should restrict corner-shape to rectangles
18:07:02 <emilio> ... where we can use it with border-radius
18:07:15 <emilio> ... and this would smooth your radius rather than something that controls shape
18:07:24 <emilio> ... would be good to separate it at least in the beginning
18:07:43 <emilio> ... and we'd leave the interaction problems for later
18:08:03 <bramus> emilio: i was wwondering if this corrected border matches stuff how border-image works today
18:08:10 <bramus> … not sure how border-image and border-radius interact
18:08:12 <bramus> … feels similar
18:08:21 <bramus> … in the sense that b-i disregards b-w and layout
18:08:25 <bramus> … would be good to be consistent witht hat
18:08:27 <florian> q+
18:08:32 <astearns> ack emilio
18:08:39 <bramus> … can find some answers to the weird questions here
18:08:47 <astearns> ack TabAtkins
18:08:57 <emilio> TabAtkins: generally agree with emilio, border-image does use border-width for the area but you can override
18:09:16 <emilio> ... we should approach this to keep this simple, the geometry should be overridden by shape, which is what simon is suggesting as well
18:09:21 <jensimmons> jensimmons has joined #css
18:09:25 <emilio> ... supportive of not paying attention to color or width as much as possible
18:09:38 <emilio> ... had some suggestions but not fully fledges
18:09:42 <jensimmons> present+
18:09:56 <emilio> ... having some way of specifying variable colors along the path seems nicer than trying to interpolate based on existing border properties
18:10:00 <schenney> +1 to Tab's color/width idea.
18:10:08 <schenney> Interpolate between points.
18:10:11 <emilio> smfr: sounds hard, not sure if svg has a way of changing colors along the path
18:10:16 <emilio> ... nice suggestion
18:10:33 <emilio> TabAtkins: what about variable width stroke?
18:10:51 <emilio> smfr: you need to use multiple paths for that
18:10:54 <emilio> TabAtkins: that's kind of annoying
18:10:58 <dholbert> present+
18:11:11 <emilio> ... quite a jump from border-radius to some two-path
18:11:28 <RRSAgent> I have made the request to generate https://www.w3.org/2025/01/29-css-minutes.html fantasai
18:11:36 <schenney> q+
18:11:36 <emilio> weinig: PostScript model is a bit old, updating it might be reasonable
18:11:44 <emilio> ... sticking just to pdfs had in late 90s got us pretty hard
18:11:52 <emilio> ... pushing that seems reasonable
18:11:54 <astearns> s/hard/far/
18:12:13 <emilio> ... we can build the paths and draw new stuff
18:12:21 <emilio> ... would just be slow
18:12:42 <emilio> ... doesn't mean that we need to be constrained, we should be able to push that
18:13:04 <emilio> ... we know how to do the conversion from border-radius to multiple paths
18:13:30 <emilio> TabAtkins: I agree that as long as it's not unusably slow we should be able to do this, authors would just have to wait for animation use cases
18:13:44 <emilio> fserb: two things
18:13:47 <astearns> ack fserb
18:14:07 <emilio> ... first, I think I tend to agree with Tab that it might be possible to given one shape and automatically build the two things
18:14:15 <emilio> ... it is probably possible
18:14:30 <emilio> ... need to be careful about where it begins
18:14:40 <emilio> ... I don't think we need more infrastructure from low level graphics APIs for this
18:15:05 <emilio> ... if we have a good way of determining how the inner shape works from the outer and a width
18:15:16 <emilio> smfr: I think some shapes might be pretty hard, like shapes with loops and what not
18:15:31 <emilio> fserb: I think that works less for colors than for width
18:15:39 <emilio> ... I don't know what colors mean on a shap
18:15:52 <emilio> ... I think leaverou wanted to do quadrants, but even that seems a bit sketchy
18:15:54 <TabAtkins> (i'm fine with abandoning gradient stroke)
18:15:59 <emilio> ... but would be nice to try this for border
18:16:26 <emilio> ... easy way is to lose some of those other properties, but maybe we regret this
18:16:29 <noamr> q+
18:16:47 <emilio> ... Maybe it's worth trying to connect border-width to this, even if it's probably hard
18:16:47 <astearns> ack florian
18:16:55 <fantasai> +1 fserb
18:17:04 <emilio> florian: back to an earlier point, the fact that this would be disconnected from layout border-width
18:17:10 <emilio> ... it might be seen as a feature
18:17:30 <emilio> ... controlling the layout so taht it doesn't interact with the border seems useful
18:17:38 <emilio> ... so defaulting stroke to top
18:17:39 <TabAtkins> yeah, taking the default width/color from border-top seems fine
18:17:46 <emilio> ... and using left/right/bottom for layout adjustments seems nice
18:17:54 <astearns> ack schenney
18:17:55 <weinig> weinig has joined #css
18:17:55 <emilio> ... maybe weird but convenient
18:17:56 <fantasai> or average all the colors? :)
18:18:16 <emilio> schenney: so in your original demo, where would scrollbars be if you had overflow: scroll?
18:18:22 <TabAtkins> scrollbar-path: shape(...)
18:18:32 <emilio> noamr: The problem with scrollbars is the same for border-radius, it appears on top
18:18:38 <emilio> ... ugly, but needed for a11y
18:18:44 <florian> scrollbar-path ?
18:18:52 <emilio> ... this conversation about the border stuff being this default makes sense
18:19:14 <emilio> schenney: so we're leaning towards making this not affect the layout right?
18:19:15 <emilio> correct
18:19:32 <emilio> smfr: Firefox applies extra constraints to border radius for scrollbars
18:19:41 <emilio> ... maybe the spec could allow that for border-shape too
18:19:47 <astearns> ack noamr
18:19:55 <emilio> noamr: wanted to go back to separate it from corner-shape
18:20:08 <emilio> ... so keep corner-shape for boxes, and border-shape for other stuff
18:20:51 <noamr> q+
18:20:56 <florian> q+
18:21:00 <emilio> smfr: so do we want to merge corner-shape and border-shape or keeping separate?
18:21:03 <TabAtkins> would prefer separate
18:21:07 <astearns> ack noamr
18:21:12 <fserb> +1 separate
18:21:22 <TabAtkins> q+
18:21:30 <emilio> noamr: one argument against combining is that corner-shape interacts with border-radius
18:22:02 <astearns> ack florian
18:22:04 <emilio> smfr: you could also see a border-shape that's mostly rounded as an enhancement on border-radius
18:22:41 <emilio> florian: so border-shape: auto uses the rest, and otherwise you override
18:22:49 <ydaniv> q+
18:22:50 <emilio> emilio: but you have two props at that point already
18:22:51 <emilio> q+
18:23:05 <bramus> emilio: dont think that is exclusive
18:23:13 <bramus> … if you keep the on the same property you can still define sth like that
18:23:22 <bramus> … if corner shape is superellipse then you account for border radius and take over
18:23:37 <bramus> florian: could be worng that corner shape thing has not 1 value but 1, 2,4 …
18:23:43 <bramus> … it has longhands to go along with this
18:23:48 <bramus> … whcih border-shape does not
18:23:56 <bramus> … its 4 props (or more) rolled into 1
18:24:01 <bramus> … where border-shape is 1 thing
18:24:04 <bramus> emilio: that’[s a good argument
18:24:10 <astearns> ack TabAtkins
18:24:14 <emilio> TabAtkins: pretty strong to keep them separate
18:24:26 <emilio> ... as it was brought up, generic paths have a lot of complexity
18:24:33 <emilio> ... that prevents us from making assumptions
18:24:50 <emilio> ... well defined corner shapes don't have those constraints, and we can use border-width etc
18:25:06 <emilio> ... so I think corner-shape should be on the general thing, and the path version should do its own thing on top
18:25:07 <astearns> ack ydaniv
18:25:16 <emilio> ydaniv: we could consider reversing the names, conceptually
18:25:28 <emilio> ... having a shape as the shorthand and border / corner as longhands
18:25:33 <emilio> ... maybe think how they interact
18:25:44 <emilio> ... may make it more complicated tho
18:25:50 <astearns> ack emilio
18:26:29 <emilio> astearns: so leaning about separate properties?
18:26:35 <emilio> smfr: yeah, modulo bikeshedding name
18:26:56 <emilio> noamr: yeah I think last bikeshed was border-shape, but we can always change it in the future
18:27:54 <emilio> border-shape: <shape> <shape>?; + strokes TBD (top border width default + override)
18:27:58 <astearns> ack fantasai
18:28:15 <emilio> fantasai: I agree we should have border-{width,color} in
18:28:22 <emilio> ... I think the border shorthand... ?
18:28:45 <emilio> ... what's the plan for corner-shape?
18:28:53 <Linux_Kerio> Linux_Kerio has joined #css
18:29:18 <emilio> fantasai: for color we might want the border-top-left color, or block-start, or averaging all the four colors
18:29:24 <emilio> ... all slightly awkward
18:29:27 <TabAtkins> block-start, definitely. i don't think averaging will produce anything meaningful. ^_^
18:29:30 <emilio> astearns: maybe separate issue?
18:29:31 <fantasai> s|colors|colors/widths|
18:30:23 <emilio> noamr: details I need is (1) corner-shape is different
18:30:40 <emilio> PROPOSED: corner-shape and border-shape are independent properties
18:31:14 <fantasai> none sgtm
18:31:18 <emilio> PROPOSED: border-shape overrides corner-shape/border-radius and co
18:31:24 <fserb> sgtm
18:32:30 <emilio> RESOLVED: corner-shape and border-shape are independent properties
18:32:46 <hober> present+
18:33:23 <emilio> ack fantasai
18:33:30 <astearns> ack fantasai
18:33:37 <emilio> fantasai: I think necessarily one has to override the other, and border-shape needs to override the other
18:33:52 <emilio> ... we could create a shorthand for both border and corner shape
18:34:04 <emilio> ... I don't see how we could have both applying at the same time
18:34:10 <noamr> that shorthand would have to also have border-radius
18:34:14 <fantasai> yes
18:34:28 <bramus> emilio: consensus is that you cant have both appplied at th esame time and you cannot make them be the same property if you want corner-shape to be a shorthand
18:34:40 <bramus> florian: yes, and we could have a super shorthand but can discuss separately
18:34:51 <bramus> fantasai: yes, what i am saying
18:35:01 <bramus> emilio: should also discuss things like them being reset or not by the shorthand
18:35:07 <bramus> astearns: a super shorthand sound scary :)
18:35:41 <emilio> RESOLVED: border-shape overrides corner-shape / border-radius
18:35:54 <bramus> emilio: should we resolve on it not affecting layout too?
18:35:58 <bramus> astearns: yes
18:36:10 <bramus> PROPOSED RESOLUTION: border-shape is a non-layout affecting property
18:36:15 <bramus> RESOLVED: border-shape is a non-layout affecting property
18:36:16 <emilio> PROPOSED: border-shape doesn't affect layout, only ink overflow and graphic effects like clipping and shadows
18:36:31 <bramus> astearns: other things to discuss?
18:36:47 <bramus> noamr: the derfault stroke and color are taken from the existing border props. can say tbd which property exactly
18:36:48 <emilio> PRPOSED: default stroke width / color get taken from existing border props
18:36:57 <emilio> which ones TBD
18:37:17 <emilio> smfr: maybe TBD is ok but I think it's fine to do the diagonal color joint in the issue
18:37:26 <emilio> RESOLVED: default stroke width / color get taken from existing border props, specifics TBD
18:37:42 <smfr> smfr has joined #css
18:37:52 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/10993
18:37:52 <github-bot> Topic: [css-shapes-2][css-borders-4] corner-shape support for superellipsis
18:37:52 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10993.
18:38:36 <emilio> PROPOSED: Add corner-shape with superellipsis() in some form
18:38:57 <emilio> florian: [summarizes prev discussion for fserb]
18:39:12 <alisonmaher> alisonmaher has joined #css
18:39:21 <ccameron> ccameron has joined #css
18:40:02 <emilio> fserb: is this because of how I implemented it on the demo or...?
18:40:50 <emilio> smfr: q is whehter the iterative solution can be approximated to a bezier
18:41:04 <emilio> fserb: I think so because you have the parameterized distance
18:41:09 <emilio> ... can work on it a little bit
18:41:15 <emilio> ... doesn't have to be as awful as in the demo
18:41:25 <emilio> smfr: that sounds promising
18:41:57 <emilio> PROPOSED: Add corner-shape with superellipsis() in some form, maybe keywords
18:42:05 <emilio> noamr: maybe continuous to approx the apple curve
18:42:08 <fserb> q+
18:42:15 <emilio> florian: unsure if that's needed given our discussion and k=4 being really close
18:42:28 <emilio> smfr: do we have resolutions for bevel / scoop / etc?
18:42:39 <emilio> astearns: we didn't resolve on anything yet
18:43:08 <bramus> emilio: does not mean tha tif you add the keywords then add the function
18:43:13 <bramus> florian: ?? compat problems
18:43:21 <bramus> emilio: already ??? between discrete values
18:43:30 <emilio> smfr: seems premature to add superellipse() if we don't have the basic keywords yet
18:43:40 <noamr> +1 to starting with keywords
18:43:47 <emilio> florian: but if you do it then you can't animate
18:43:52 <astearns> ack fserb
18:44:01 <emilio> emilio: but you'd be able to once you introduce the functional version
18:44:31 <emilio> fserb: I think we should have both but it'd be weird to have only the keywords
18:44:33 <noamr> any reason not to have both in the spec?
18:45:00 <emilio> ... I think we should introduce the obvious keywords, but we should also have the superellipse() one
18:45:35 <emilio> astearns: I think even if we only have those keywords we should define those in terms of superellipse()
18:45:52 <emilio> fserb: unrelated, did we discuss about what happens about intersecting borders inside?
18:46:14 <emilio> ... are we going to tweak border-width / radius to avoid it?
18:46:25 <emilio> smfr: we decided we'd add constraints, but handwaved
18:46:51 <bramus> emilio: should we propose that as a resolution? add restirctions to prevent some things.
18:47:15 <fserb> +1
18:47:19 <emilio> florian: I'd prefer to add corner-shape: superellipse() + some keywords based on superellipse()
18:47:32 <emilio> noamr: should we resolve on the specific keywords?
18:47:47 <emilio> astearns: fine with editor discrection
18:47:58 <astearns> ack fantasai
18:48:04 <emilio> fantasai: there are keywords in the draft that map to this
18:48:10 <emilio> astearns: can you list them?
18:48:37 <emilio> smfr: probably bevel / scoop / notch / round?
18:48:40 <bramus> emilio: is the initial value round?
18:48:49 <bramus> … with this proposal we make it interact with border-radius
18:48:52 <noamr> + squircle
18:49:02 <fserb> scoop = -round ?
18:49:47 <emilio> PROPOSAL: Add corner-shape: superellipse(k) and bevel / scoop / notch / round / squircle based on it, maybe continuous in the future
18:50:07 <fserb> \o/
18:50:08 <castastrophe> castastrophe has joined #css
18:50:08 <emilio> RESOLVED: Add corner-shape: superellipse(k) and bevel / scoop / notch / round / squircle based on it, maybe continuous in the future
18:51:06 <emilio> PROPOSED: Add restrictions to avoid intersecting borders with scoop-like borders
18:51:41 <emilio> PROPOSED: Add restrictions to avoid intersecting borders with scoop-like corners, specifics TBD
18:51:47 <emilio> RESOLVED: Add restrictions to avoid intersecting borders with scoop-like corners, specifics TBD
18:52:31 <emilio> florian: current draft has angle rather than bevel
18:52:37 <emilio> TabAtkins: editor discretion seems fine
18:52:42 <emilio> [general agreement]
18:53:12 <emilio> emilio: Initial value should be round so that border-radius does the right thing right?
18:54:03 <bramus> emilio: can we define none in terms of superelipse?
18:54:04 <emilio> noamr: maybe none for when there's nothing going on with the corners
18:54:08 <bramus> smfr: yes
18:54:20 <emilio> smfr: that's a bit different from animating radius
18:54:44 <bramus> florian: are we also resolving that we have between 1 and 4 keywords and that they ??? a notch here and a rounded corner there
18:54:46 <emilio> noamr: it'd be superellipse(calc(inf))
18:54:49 <bramus> …or do we worry about that later?
18:54:50 <emilio> RESOLVED: Initial value of corner-shape is round
18:55:14 <bramus> noamr: have corner-shape for corners spearately following model of border-radius
18:55:23 <bramus> emilio: so corner-top-=left-shape and so on?
18:55:30 <bramus> florian: same thing as border-radius
18:55:45 <bramus> emilio: makes me sad that the prop deos not start with border-
18:55:55 <bramus> florian: what makes me sad is that border-radius is not corner-radius
18:55:59 <bramus> ntim: can add an alias
18:56:14 <emilio> PROPOSED: corner-shape has longhands like border-radius
18:56:21 <ntim> ntim: like we did for font-stretch/font-width
18:56:35 <emilio> weinig: Spec has a corners shorthand, but no need to discuss it
18:56:41 <emilio> RESOLVED: corner-shape has longhands like border-radius
18:57:56 <jfkthame> present-
18:57:59 <astearns> topic: break
18:58:38 <schenney> FYI I need to collect kids. Please don't cover pseudo issues related to highlights until I'm back.
18:58:46 <schenney> ABout an hour.
19:06:00 <jfkthame> jfkthame has joined #css
19:18:33 <kschmi> kschmi has joined #css
19:20:50 <alisonmaher> alisonmaher has joined #css
19:21:27 <smfr> smfr has joined #css
19:22:37 <TabAtkins> ScribeNick: TabAtkins
19:23:30 <TabAtkins> topic: https://github.com/w3c/csswg-drafts/issues/9573
19:23:32 <ydaniv> ydaniv has joined #css
19:23:38 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/9573
19:23:38 <github-bot> Topic: [css-values] Pseudo-elements shouldn't defer sibling-index() and sibling-count() to its ultimate originating element
19:23:38 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9573.
19:23:54 <noamr> noamr has joined #css
19:24:07 <alexis_menard> alexis_menard has joined #css
19:24:21 <TabAtkins> oriol: Cuirrently spec says when you use sibling-index()/count() on pseudo-element, it refers to the ultimate originating element
19:24:21 <kizu> kizu has joined #css
19:24:21 <jensimmons> jensimmons has joined #css
19:24:34 <TabAtkins> oriol: this seems confusing for things like ::slotted(), because they point to a real element
19:24:39 <TabAtkins> oriol: seems werid
19:25:00 <TabAtkins> oriol: For things like ::before/after, could be more reasonble to use an index smaller/larger than the real children
19:25:14 <TabAtkins> oriol: Tho defining it this way could be hard
19:25:33 <TabAtkins> oriol: Proposal in the issue is to let the function accept a selector, and it provides an index among matching elements
19:26:01 <TabAtkins> oriol: If missing, assuming a `*` selector, so pseudos don't match (and we'd use the current spec behavior when used *on* a pseudo-element)
19:26:02 <bramus> q+
19:26:16 <TabAtkins> oriol: think this might be self-consistent and useful
19:26:24 <TabAtkins> oriol: Emilio also mentioned ::part()
19:26:31 <emilio> q+
19:26:31 <TabAtkins> oriol: ideas?
19:26:34 <TabAtkins> q+
19:26:38 <astearns> ack bramus
19:27:01 <TabAtkins> bramus: Using sibling-index() on ::before/::after doesn't really make sense? That's why we used the index from the orignating element
19:27:14 <TabAtkins> oriol: Are you asserting it doesn't make sense, or asking?
19:27:16 <kizu> q+
19:27:26 <TabAtkins> bramus: Don't think it makes sense to have to return something on those.
19:28:04 <TabAtkins> oriol: so one idea is that if the elemnt doesn't match the provided selector, it's IACVT, so that would match the "doesn't make sense" part
19:28:25 <TabAtkins> oriol: It avoids tying it to the ultimate originating element, which fixes ::part()/::slotted()
19:28:45 <TabAtkins> bramus: side question, do we have parity with the :nth-child() numbers?
19:28:55 <TabAtkins> TabAtkins: yup, same 1-indexing
19:29:32 <TabAtkins> bramus: If you have an element matched by :nth-child(3), and slot it, would it get 3 from sibling-index()?
19:29:44 <TabAtkins> oriol: There's another issue about whether it counts in the light tree or flat tree, I think that's what you are questioning
19:29:45 <astearns> ack emilio
19:30:14 <TabAtkins> emilio: I brought up ::part() because I think we don't want to expose the DOM structure of parts. I think for ::slotted() it's probably fine ot use the real index of the element
19:30:49 <TabAtkins> emilio: But yeah, unsure how we want to do it. Making a value depend on the selector used is weird.... maybe tie it to the tree the style and element are in?
19:31:05 <TabAtkins> emilio: But yeah, I think we need some way to say the index of an element isn't exposed.
19:31:21 <TabAtkins> emilio: fantasai did bring up the use-case for ::marker or ::before referring to the originating element is pretty clear
19:31:35 <TabAtkins> (similar to using counters)
19:31:43 <fantasai> ::before { content: "Item " sibling-index() " of " sibling-count(); }
19:31:51 <TabAtkins> emilio: But yeah we need a clear distinction between generated pseudos, part-like pseudos, and ::part() and ::slotted() specifically
19:31:55 <astearns> ack TabAtkins
19:32:20 <emilio> TabAtkins: Agree that for ::before / ::marker, deferring to originating element has some good cases
19:32:21 <bramus> TabAtkins: I agree that for before and marker deferring to the originating element has good use cases
19:32:28 <emilio> ... also that we don't want to expose them for ::part()
19:32:30 <bramus> … for part we dont, for th esame reason … dont expose underlying dom structure
19:32:34 <emilio> ... for ::slotted() seems fine
19:32:36 <bramus> … for slotted perfectly fine, that is not intentially hidden info
19:33:04 <dbaron> Present+ (again)
19:33:05 <bramus> … so emilio you said it is tricky and weir dto have a value of a fn return a value depending on how you selected it
19:33:18 <bramus> … does that make it difficult for part or ???
19:33:34 <bramus> s/???/or are styles given toa part kept separately
19:33:45 <bramus> emilio: as an impl detail they get stored espearetly bc you look them up separately
19:33:54 <bramus> … but the weird thing is that you could have a rule like
19:33:58 <emilio> div, :host::part(foo) { ... }
19:34:02 <astearns> s/espearetly/separately
19:34:09 <bramus> … they could both match
19:34:18 <bramus> … and its weird to have that do a diff thing
19:34:24 <bramus> … suggestiont  look at the tree where the rules come from
19:34:43 <bramus> … you need to know the identifer stuff and that is more reasonable thing to use rather than whcih selector hahppened to match
19:34:45 <bramus> TabAtkins: agree
19:34:58 <bramus> … if the style if coming form a higher tree than the el its on it would not work, as part would not expose antyhthing
19:35:04 <bramus> … in same tree is fine
19:35:24 <bramus> … if its the inverse when styles are coming froma  lower shadow than the el like slotted
19:35:28 <bramus> … then its also fine
19:35:53 <bramus> emilio: so dbaron metnioned being concerned to carry that info
19:36:01 <bramus> … we already to that for some info eg global names
19:36:19 <bramus> … for example font-family in shadow tree - need so know where the value came from
19:36:34 <bramus> dbaron: i think noamr knows how that works
19:36:36 <astearns> ack kizu
19:36:46 <TabAtkins> kizu: +1 to using originating element for ::before/after
19:36:55 <TabAtkins> kizu: might be some use-cases for siblings of ::after
19:36:55 <kizu> https://github.com/w3c/csswg-drafts/issues/11068
19:37:05 <TabAtkins> kizu: that's a separate proposal i've made
19:37:13 <TabAtkins> kizu: children-count() rather than sibling-count()
19:37:29 <TabAtkins> kizu: But this would cover the use-case where you have ::after participate as a sibling
19:37:42 <TabAtkins> kizu: But generally just using th eoriginating element for the sibling count makes sense
19:37:44 <TabAtkins> q+
19:37:51 <astearns> ack TabAtkins
19:37:59 <bramus> TabAtkins: utlimately the part info hiding is kinda just best effort
19:38:25 <bramus> … if too much trouble to try and hide that base on style vs eleme origin, i think its fine to expose the true sibling-* for a part element
19:38:38 <bramus> ntim: waht does real sibling count mean>
19:38:46 <bramus> TabAtkins: the part lives in a tree
19:38:51 <bramus> ntim: does it include shadow siblings>
19:38:55 <bramus> emilio: yes
19:39:13 <bramus> TabAtkins: we expose some bits of the shadow structure anyway, worst case inehrientace does. this is all best effort
19:39:28 <bramus> … we want to reduce the dependence on structure authors hsouldn not rely on
19:39:40 <bramus> emilio: i’d prefer not exposing it
19:39:43 <bramus> ntim: same
19:39:57 <bramus> astearns: i think we have consensus on an aspirational consensus
19:40:35 <bramus> TabAtkins: proposal is to continue to use current spec text sfor most pseudos. for part-like ones we conditioanlly expose or not the real index based on the relative ordering of the trees so that part does not expose but slotted does
19:40:41 <bramus> astearns: so only change is for part
19:40:46 <bramus> TabAtkins: part-like pseudos
19:41:05 <bramus> ntim: if we modify treeo f pseudos to add a new pseudos, that would break?
19:41:17 <bramus> TabAtkins: only referring to part-like which have a real element backing them
19:41:22 <bramus> … not the other pseudos
19:41:31 <bramus> ntim: so always be 1?
19:41:57 <bramus> TabAtkins: no, if you used slotted to select and then you use sibling-index in a prop it gets the actual index of the slotted element, as if you were selecting the element normally
19:42:05 <bramus> ntim: what is the relation with part-like pseudos?
19:42:08 <schenney6> schenney6 has joined #css
19:42:12 <bramus> TabAtkins: spec right now says any pseudo
19:42:20 <bramus> … to refer to the original element
19:42:38 <bramus> … this would change it so that in the slotted case you get th eslotted element’s index but part would ocntinue to hide it
19:42:42 <bramus> ntim: so only slotted changes?
19:42:52 <bramus> emilio: no, we need to decied what exactly gets returned when we hide it
19:42:55 <bramus> … 0 is fine
19:42:59 <bramus> TabAtkins: yeah, something
19:43:10 <bramus> emilio: that is changing
19:43:18 <bramus> … slotted also changes
19:43:28 <bramus> … and before, after, marker don}t change
19:43:33 <bramus> … but this is not shipping so fine
19:43:41 <bramus> ntim: for all part-like pseudos we return 0?
19:43:57 <bramus> TabAtkins: no, depends on the tree position of the style and the element being styled
19:44:12 <bramus> … so if th eprop comes from a higher tree the eleme is in a deepr shadow tree we suppress
19:44:20 <bramus> … other way around its fine and we expos that
19:44:31 <astearns> ack dbaron
19:44:52 <bramus> dbaron: i think we wantt o allow it through only if styles come from the same or descendant scope
19:44:55 <bramus> TabAtkins: YES
19:45:14 <bramus> dbaron: distinction between element scope and any descendant scopes which allow the index vs all other scopes that hide it
19:45:17 <bramus> emilio: agree
19:45:25 <bramus> ntim: so what if you use it on details-content
19:45:30 <bramus> TabAtkins: gets hidden, real element
19:45:41 <bramus> emilio: ???
19:45:49 <bramus> TabAtkins: details-content is identical to a part
19:46:28 <bramus> astearns: so we have consensus that the current spec …
19:46:35 <bramus> TabAtkins: current spec is fine for non-part-like pseudos
19:46:53 <bramus> … for part-like pseudos we only expose sibling info if the style is coming from the same or a descendant tree scope of the element
19:46:59 <bramus> astearns: and if that is not the case?
19:47:06 <bramus> TabAtkins: zero or IACVT or sth like that
19:47:12 <dbaron> (and we're sure "not the case" shouldn't be "like other pseudos"?)
19:47:18 <bramus> astearns: other questions about this?
19:47:24 <TabAtkins> might be
19:47:42 <kschmi> kschmi has joined #css
19:47:45 <bramus> dbaron: what was reasoning for not falling back to behavior for other pseudos where we dont expose?
19:47:53 <bramus> emilio: potentialy multiple hosts, bu tits tricky
19:48:01 <bramus> TabAtkins: use the utlimate originaating element
19:48:08 <kbabbitt> kbabbitt has joined #css
19:48:11 <bramus> TabAtkins: oh, but that depends  on the selector
19:48:13 <bramus> dbaron: yes, tricky
19:48:26 <bramus> astearns: objects to resolving?
19:48:34 <bramus> s/objects/objections
19:48:40 <jensimmons> jensimmons has joined #css
19:48:56 <bramus> RESOLVED: only expose sibling info for part-like pseudos if the style is coming from the same or a descendant tree scope of the element
19:49:15 <bramus> TabAtkins: element-backed pseudos instead of part-like
19:49:57 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/9413
19:49:58 <github-bot> Topic: [css-pseudo-4] Allow intervening space and no-break space in ::first-letter, preceding the letter
19:49:58 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9413.
19:50:20 <TabAtkins> fantasai: there's a request that if you have ::first-letter and it's predeced by punctuation, we allow there to be spaces/nbsp between the punct and ::first-letter
19:50:30 <TabAtkins> fantasai: plenty of examples where there's leading punctuation and then the first letter
19:50:34 <TabAtkins> fantasai: i thinkt his makes sense
19:50:45 <TabAtkins> florian: i concur it's useful, is it webcompatible?
19:50:53 <TabAtkins> fantasai: yeah, it's actually what's implemented right now
19:50:59 <smfr> smfr has joined #css
19:51:02 <TabAtkins> astearns: so resolution is to allow intervening space in this case
19:51:18 <TabAtkins> RESOLVED: Allow spaces between initial punctuation and the ::first-letter
19:51:37 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11282
19:51:37 <github-bot> Topic: [css-viewport-1] [all?] Figure out if / how we want to integrate with webdriver and other similar specs.
19:51:37 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11282.
19:52:11 <TabAtkins> alexis_menard: issue came up when working on viewport-segment and the segments JS property
19:52:18 <TabAtkins> alexis_menard: issue was, how do we test this?
19:52:24 <TabAtkins> alexis_menard: the feature is dependent on hardware
19:52:31 <TabAtkins> alexis_menard: we usually use webdriver and emulate the hardware
19:52:42 <TabAtkins> alexis_menard: here, i needed webdriver extensions to simulate screen topology
19:52:51 <TabAtkins> alexis_menard: i have a PR to add these extensions
19:53:01 <TabAtkins> alexis_menard: got reviewed by the webdriver people, they were happy with the change
19:53:07 <TabAtkins> alexis_menard: but question is, where to put them?
19:53:11 <lea> lea has joined #css
19:53:17 <TabAtkins> alexis_menard: seems CSS has never put webdriver details into specs
19:53:23 <TabAtkins> alexis_menard: Looks like there's no official guidance anywhere
19:53:40 <TabAtkins> alexis_menard: some specs like posture, webbluetooth, etc all define webdriver in their spec
19:53:44 <TabAtkins> alexis_menard: webusb define in a separate spec
19:53:50 <TabAtkins> alexis_menard: webxr defines in an explainer
19:54:08 <TabAtkins> alexis_menard: so we thought it might be good to have a decision for all of css
19:54:14 <TabAtkins> alexis_menard: more cases will arrive in the future
19:54:18 <TabAtkins> alexis_menard: so where do we put the extensions?
19:54:19 <TabAtkins> q+
19:54:39 <TabAtkins> TabAtkins: Yeah let's jsut put them in the spec, an appendix is fine
19:54:42 <bramus> +1
19:54:42 <TabAtkins> astearns: contrary opinions?
19:54:44 <kbabbitt> sgtm
19:54:57 <TabAtkins> astearns: so proposed resolution is allow webdriver extensions in our specs, in appendixes.
19:55:15 <TabAtkins> RESOLVED: WebDriver extensions for CSS features go into the corresponding CSS spec, in an appendix.
19:57:35 <bramus> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11000
19:57:35 <github-bot> Topic: [css-scoping][selectors] `:root` should resolve to `:host` in shadow trees
19:57:35 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11000.
19:57:53 <kizu> kizu has joined #css
19:58:01 <emilio> q+
19:58:03 <bramus> TabAtkins: lea mentioen that you the `:scope` resolves to `:root`. within shadow roots tha tis not useful, shoudl resolve to `:host`
19:58:07 <emilio> ack TabAtkins
19:58:21 <bramus> … because `:root` never matches
19:58:30 <astearns> ack TabAtkins
19:58:32 <bramus> … that way you can use same styles inside and outside shadow tree
19:58:34 <astearns> ack emilio
19:58:35 <bramus> emilio: compat concerns
19:58:44 <bramus> … there is usefulness to have `:root` and `:host` be different
19:58:53 <dbaron> I'm unsure whether we want the possibly-implied change to the way highlight pseudos work.
19:58:56 <bramus> … e.g. in the firefox fronted we use SD a lot
19:59:07 <bramus> … and the stylesheets end up being global styles too
19:59:17 <bramus> … dont want those to be overridden on very shadow root
19:59:25 <bramus> TabAtkins: would not overrid ehwen defined on `:root`
19:59:52 <bramus> … was wrong: proposal is to have `:scope` resolve to `:host` elem in shadow tree, rather than root.
20:00:00 <bramus> emilio: makes more sense
20:00:14 <miriam> +1
20:00:21 <bramus> PROPOSED RESOLUTION: Have  have `:scope` resolve to `:host`  rather than `:root` in shadow tree
20:00:37 <bramus> RESOLVED: Have  have `:scope` resolve to `:host`  rather than `:root` in shadow tree
20:00:44 <bramus> TabAtkins: (missed)
20:01:01 <dbaron> TabAtkins: there was a second issue raised about changing :root but as emilio points out that might cause problems
20:01:02 <bramus> emilio: extra q: does this affect parent selector? (&)
20:01:09 <bramus> … which is defined to match `:scope`
20:01:18 <bramus> TabAtkins: yes, i suspect it will
20:01:36 <bramus> topic: lunch
20:02:55 <TabAtkins> (There's a sub-issue in this issue about having :root in a shadow tree match :host instead, but there's more concerns with that, so I left it out.)
20:05:58 <jfkthame> jfkthame has joined #css
20:08:33 <TabAtkins> Okay we haven't found the catering, moving back to the meeting room to hopefully find someone with a clue
20:25:49 <schenney> schenney has joined #css
21:06:36 <alisonmaher> alisonmaher has joined #css
21:08:19 <kbabbitt> kbabbitt has joined #css
21:08:27 <kbabbitt> present+
21:10:02 <kbabbitt> scribenick: kbabbitt
21:11:00 <kbabbitt> github-bot, topic: https://github.com/w3c/csswg-drafts/issues/11011
21:11:00 <github-bot> kbabbitt, Sorry, I don't understand that command.  Try 'help'.
21:11:07 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11011
21:11:07 <github-bot> Topic: [css-pseudo] `color-scheme` should be an allowed property for highlight pseudos
21:11:07 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11011.
21:11:14 <castastrophe> castastrophe has joined #css
21:11:55 <lea> present+
21:12:06 <castastrophe> present+
21:12:17 <ydaniv> ydaniv has joined #css
21:12:25 <kbabbitt> fantasai: for highlight pseudos we have 2 wasy of applying properties
21:12:26 <kbabbitt> ...
21:12:37 <bramus> list of props: https://drafts.csswg.org/css-pseudo-4/#highlight-styling
21:12:41 <kbabbitt> ... props specified on highlight pseudo element eg. color, ...
21:12:47 <kbabbitt> ... and props we take from the originating element
21:12:52 <kbabbitt> ....e..g font properties
21:12:57 <emeyer> emeyer has joined #css
21:13:13 <kbabbitt> ... for this issue, we should decide are we taking this value directly off highlight pseudo?
21:13:22 <kbabbitt> ... in which case it inherits through pseudo's ancestry
21:13:28 <kbabbitt> ... or are we taking from originating element
21:13:44 <kbabbitt> ... for forced-color adjust and color scheme  I think we want from originating element
21:13:46 <bramus> +1
21:13:50 <kbabbitt> ... then that will match unterlying element
21:13:51 <dbaron> +1
21:14:04 <kbabbitt> astearns: in my read of stephen's comment he would agree
21:14:14 <kbabbitt> schenney: yes I agree
21:14:31 <kbabbitt> fantasai: forced-color-adjust should behave same as color-scheme
21:14:50 <emeyer> present+
21:14:54 <kbabbitt> Proposed: Add forced-color-adjust and color-scheme to set of properties that work with highlight pseudo, taking value from originating element
21:15:04 <kbabbitt> bramus: forced is already on that list
21:15:13 <lea> +1
21:15:16 <kbabbitt> astearns: objections?
21:15:30 <kbabbitt> bramus: color-scheme is already listed
21:15:41 <lea> I don't see why we may NOT want to allow these
21:15:53 <kbabbitt> RESOLVED: Add forced-color-adjust and color-scheme to set of properties that work with highlight pseudo, taking value from originating element
21:16:22 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10562
21:16:22 <github-bot> Topic: [css-mixins] Should `result` be mandatory in `@function`?
21:16:22 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10562.
21:16:37 <kbabbitt> TabAtkins: the question raised here is should the result descriptor be mandatory in @function rule
21:16:43 <kbabbitt> ... result describes what function returns
21:17:06 <kbabbitt> ... is it strictly required to have it, or can it be omitted with reasonable default behavior
21:17:14 <kbabbitt> ... thread is leaning towards it should be optional
21:17:20 <kbabbitt> ...IACVT if there isn't one
21:17:27 <kbabbitt> ... matches up with other languages concepts of optional
21:17:39 <kbabbitt> ... at the moment you have to indirect through a custom property to use this value instead if IACVT
21:17:44 <kbabbitt> ... we have other proposals to make that easier
21:17:54 <kbabbitt> ... unless there's a great reason to require it, we think it's fine to let it be omitted
21:18:03 <kbabbitt> ... and have it be IACVG when that hits
21:18:09 <kizu> +1 to be optional
21:18:11 <kbabbitt> s/IACVG/IACVT/
21:18:15 <lea> q?
21:18:15 <miriam> +1
21:18:16 <lea> q+
21:18:16 <kbabbitt> astearns: other opinions/questions?
21:18:30 <astearns> ack lea
21:18:50 <kbabbitt> lea: if result is mandatory does that mean rule is tropped at parse iyme if it's missing?
21:18:53 <kbabbitt> TabAtkins: yes
21:19:01 <kbabbitt> lea: might be use cases to add later? could just have dummy one
21:19:11 <kbabbitt> Proposed: result is optional in @function
21:19:18 <kbabbitt> RESOLVED: result is optional in @function
21:19:43 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11455
21:19:43 <github-bot> Topic: [css-values-5][css-mixins-1] Add an if-test for local variables
21:19:43 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11455.
21:20:05 <kbabbitt> TabAtkins: andruud asked how should we allow you to test the value of arguments for a cuntion
21:20:18 <kbabbitt> ... using the if function which is already in values-5 there's a style test that will let you use custom properties
21:20:22 <kbabbitt> ... and resolve if they match particular value
21:20:30 <kbabbitt> ... but it wasn't super clear whether that should also work for function arguments
21:20:37 <kbabbitt> ... or if we should have a new form for if()
21:20:53 <kbabbitt> ... I argued that the design of how arguments work inside @function is intentionally to shadow custom properties
21:21:01 <kbabbitt> ... basically one list of -- names that var can access
21:21:05 <kbabbitt> ... and find nearerst thing that defines it
21:21:12 <weinig> weinig has joined #css
21:21:18 <kbabbitt> ... it would be weird if if() could pierec that shadowing
21:21:25 <kbabbitt> ... so we don't need to do anything special
21:21:34 <kbabbitt> ... andruud found that reasonable in private discussion
21:22:10 <kbabbitt> ... so unless someone has a great argument for testing custom prop on element that you can't otherwise access, i.e. if you use a var for  custom property name ....
21:22:33 <kizu> +1
21:22:35 <kbabbitt> ... then we'll resolve as said in thread where style test in function sees areguments as well as custom props
21:22:35 <lea> q?
21:22:38 <lea> q+
21:22:46 <astearns> ack lea
21:22:57 <kbabbitt> lea: in another issue we discussed expanding conditions of if to allow bare parens comparisons etc.
21:23:01 <kbabbitt> ... could this also fit there?
21:23:12 <kbabbitt> ... instead of adding more syntax, reference params with bare syntax
21:23:19 <kbabbitt> ... this also comes up with relative colors
21:23:26 <kbabbitt> ... want if() to evaluate on what color components are
21:23:46 <kbabbitt> TabAtkins: my preference is to not add any additional syntax, just reuse existing stuff from if()
21:23:48 <kbabbitt> ... which is style test
21:24:00 <kbabbitt> ... if we have shorter ways to write style test they;d appply here as well
21:24:11 <kbabbitt> lea: makes sense as long as we do add shorter ways
21:24:19 <miriam> +1
21:24:20 <kizu> q+
21:24:30 <astearns> ack kizu
21:24:35 <kbabbitt> kizu: there might be ways we could want to do this but not as part of style comparison
21:24:41 <kbabbitt> ... if we define local variable with something
21:24:44 <kbabbitt> ... or argument with soething
21:24:49 <kbabbitt> ... we could still want to get outer variable
21:25:00 <kbabbitt> ... different issue, we could resolve ???
21:25:20 <kbabbitt> ... different from this when you use condition or style, it's reasonable from author perspective to consider local variables, outer vars the same
21:25:51 <kbabbitt> Proposed: Style test of if() function sees function arguments shadowing custom properties
21:26:09 <kbabbitt> fantasai: which one is in shadow?
21:26:10 <ChrisL> present+
21:26:21 <kbabbitt> TabAtkins: if you have custom prop defined on element it's by default visible
21:26:29 <kbabbitt> ... but if function variable has same name you get that
21:26:37 <kbabbitt> fantasai: makes sense but not clear in resolution
21:27:07 <kbabbitt> ... a shadow can either be obscuring something or following it
21:27:14 <kbabbitt> TabAtkins: accept whatever verbage you want there
21:27:17 <schenney> schenney has joined #css
21:27:20 <kbabbitt> ... shadowing is standard term for it
21:27:30 <kbabbitt> ... I won't say it like that in spec, will use different verbage there
21:27:37 <kbabbitt> astearns: function arguments...
21:27:45 <dbaron> function arguments shadow custom properties?
21:28:20 <fantasai> PROPOSED: Style test of if() function see function arguments, falling back to custom properties?
21:28:27 <kbabbitt> RESOLVED: Style test of if() function sees function arguments shadowing custom properties
21:29:01 <kbabbitt> TabAtkins: meta: we want to prioritize @function rule for implementation
21:29:09 <kbabbitt> ... more attention to it would be great
21:29:28 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11317
21:29:29 <github-bot> Topic: [css-pseudo] Allow custom Properties in ::selection pseudos (revisited)
21:29:29 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11317.
21:29:44 <kbabbitt> schenney: on our 3rd attempt for highlight inheritance in chrome
21:29:52 <kbabbitt> ... TabAtkins and lea pointed out that we want custom props on highlights
21:30:06 <kbabbitt> ... previous resoution was no custom props on highlights, inherit from originating element
21:30:17 <kbabbitt> ... think it's a no brainer we should allow custom props on pseudo highlights
21:30:27 <kbabbitt> ... then there's a question of how we inherit
21:30:30 <kbabbitt> ... 2 possibilities
21:30:41 <kbabbitt> fantasai: let's do in one go
21:30:47 <jensimmons> jensimmons has joined #css
21:30:55 <kbabbitt> schenney: the simplest way to implement is to use existing model for inheritance
21:30:59 <kbabbitt> ... in highlight pseudoes
21:31:05 <kbabbitt> ... inherit through originating element chain
21:31:13 <kbabbitt> ... look first on highlight then on originating element
21:31:18 <kbabbitt> ... which inherits through remaining element cain
21:31:31 <kbabbitt> ... inherit custom properties for highlights through originating element chain
21:31:39 <kbabbitt> fantasai: but not regular propertes
21:31:41 <kbabbitt> schenney: yes
21:31:48 <kbabbitt> ... simple to implement, matches previous behavior
21:32:01 <kbabbitt> ...downside is that custom props have diff inheritance model from every other property allowed on highlights
21:32:13 <kbabbitt> ... alternative method allows inherit both through highlight chain and originating chain
21:32:40 <kbabbitt> ... inherit from highlight chain, and on top of that from originating element
21:32:46 <kbabbitt> ... and then any properties on highlight itself
21:32:51 <kbabbitt> .. downside is hard to state, pain to debug
21:32:57 <kbabbitt> ... not all browser can implement efficiently]
21:33:12 <kbabbitt> ... upside is that it allows authors to put custom props on highlight without knowing they're special
21:33:27 <kbabbitt> ... whereas inherit from origin requires additional explanation
21:33:38 <kbabbitt> ... from that perspective I like the fact we can transition to both methods existing at same time
21:33:43 <kbabbitt> ... but ack that it's messy
21:33:59 <kbabbitt> ... should we go for simplicity but annoyance to developers vs complexity with both methods
21:34:01 <TabAtkins> q+
21:34:07 <astearns> ack fantasai
21:34:09 <kbabbitt> fantasai: say I set color: customcolor
21:34:27 <kbabbitt> ... and then customcolor is set to blue ... on a highlight pseudo
21:34:34 <fantasai> span::selection { color: var(--customcolor); }
21:34:51 <fantasai> p::selection { --customcolor: blue; }
21:34:58 <fantasai> span { --customcolor: red; }
21:35:11 <kbabbitt> fantasai: now the question is what color is the selection/
21:35:18 <kbabbitt> ... from author perspective both red and blue are reasonable
21:35:25 <kbabbitt> ... we've set custom-color close to where we're using it
21:35:33 <kbabbitt> ... we've also set it differently on selection element
21:35:47 <kbabbitt> ... you're proposing a priority between these two, will that make sense to everyone?
21:35:52 <kbabbitt> ... even when there's an ancestor in between?
21:35:56 <kbabbitt> schenney: yes. so...
21:36:07 <kbabbitt> ... people who have been working before the originating element will have priority
21:36:15 <kbabbitt> ... people coiming new, prent will have priority
21:36:19 <kbabbitt> ... agree each is equally valid
21:36:32 <kbabbitt> ... inherit from parent, then originating, then span, so color will be red
21:36:38 <kbabbitt> ... reason for this is it supports back compat use case
21:36:45 <kbabbitt> ... if there's any ambiguity
21:36:55 <kbabbitt> ... you've hit the footgun where it's unclear when we inherit from both
21:36:59 <kbabbitt> ... I'd expet people to use one or other
21:37:03 <fantasai> p::selection { --customcolor: blue; }
21:37:03 <kizu> q+
21:37:05 <kbabbitt> ... if they use both, colors should match up
21:37:07 <fantasai> p { --customcolor: red; }
21:37:19 <kbabbitt> fantasai: in first example [in irc] you'd get red?
21:37:22 <dbaron> (It seems a bit weird if --customcolor inherits differently from color.)
21:37:23 <kbabbitt> schenney: yes
21:37:29 <kbabbitt> fantasai: second example also red?
21:37:31 <kbabbitt> schenney: no blue\
21:37:39 <kbabbitt> [crosstalk]
21:37:56 <kbabbitt> fantasai: no dispute that text not inside span is blue
21:38:07 <kbabbitt> ... part inside span is red or blue?
21:38:14 <kbabbitt> .. because span's value for custom color is read
21:38:20 <kbabbitt> schenney: yes
21:38:22 <kbabbitt> ... it would be read
21:38:26 <kbabbitt> s/read/red/
21:38:34 <kbabbitt> ... originating will override inheritance
21:38:53 <kbabbitt> ... from a back compat perspective we want to inherit from originating element chain and be done
21:39:00 <kbabbitt> ... these questions don't arise which is good
21:39:06 <kbabbitt> ... we'd have to give advice to authors
21:39:19 <kbabbitt> ... custom properties in highlight are distinct from other custom props
21:39:28 <kbabbitt> ... pseudos need to have same values as elements
21:39:38 <kbabbitt> ... andruud is for just inherit through originating element chain
21:39:43 <kbabbitt> ...because it avoids complexity
21:39:49 <kbabbitt> ... which is why I implemented it that way in Chromium
21:40:05 <florian> q+
21:40:08 <kbabbitt> ... purely the feature I'm thinking about
21:40:14 <astearns> ack TabAtkins
21:40:19 <kbabbitt> TabAtkins: with andruud on just use originating element
21:40:30 <florian> q-
21:40:33 <kbabbitt> ... zipper concept you're describing is not possible under current def of inheritance
21:40:43 <kbabbitt> ... a prop always has an inherited value from a particular spot
21:40:51 <kbabbitt> ... we'd have to invent a new concept which is possible
21:41:00 <kbabbitt> ... but sticking with current model is favorable if it can be avoided
21:41:00 <astearns> ack kizu
21:41:06 <kbabbitt> kizu: don't think it will matter in practice
21:41:12 <kbabbitt> ...maybe author will expect things to behave the same
21:41:32 <kbabbitt> ... the way you inhert through highlight elements makes sense since you don't want color to match backgruond
21:41:52 <kbabbitt> ... but I don't think this will matter in practice
21:41:59 <kbabbitt> ... what will be simpler should be okay
21:42:05 <kbabbitt> ... not a point of confusion because not a common use case
21:42:11 <astearns> ack fantasai
21:42:24 <kbabbitt> fantasai: it could make sense to allow a custom prop to be set on highlight and then use directly on same highlight pseudo
21:42:37 <kbabbitt> ... but this double inheritance is weird and will cause problems
21:42:44 <kbabbitt> ... won't match what people expet
21:42:49 <kbabbitt> schenney: that's option 1
21:43:01 <kbabbitt> ...only resolution needed there is allow custom props on highlight pseudos
21:43:06 <kbabbitt> ... which I'm totally fine wityh
21:43:15 <kbabbitt> Proposed: allow custom properties on highlight pseudos
21:43:21 <kbabbitt> RESOLVED: allow custom properties on highlight pseudos
21:43:33 <fantasai> PROPOSED: Allow custom properties on highlight pseudoes; custom properties continue to inherit from the originating element
21:43:37 <fantasai> RESOLVED: Allow custom properties on highlight pseudoes; custom properties continue to inherit from the originating element
21:43:46 <kbabbitt> github-bot: take up https://github.com/w3c/csswg-drafts/issues/7647
21:43:46 <github-bot> Topic: [css-highlight-api] Should pseudo-classes work with Custom Highlights
21:43:46 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7647.
21:44:09 <kbabbitt> schenney: point made is taht you may want difference selection or highlight
21:44:12 <kbabbitt> ... if element is hovered vs not
21:44:21 <kbabbitt> ... or matched in any other selector that modifies state based on actions
21:44:32 <kbabbitt> ... proposal is to allow some syntax e.g. article::highlight::hover
21:44:35 <lea> q?
21:44:36 <kbabbitt> ... which is currently not allowed
21:44:39 <TabAtkins> this is in fact already allowed <https://drafts.csswg.org/selectors/#pseudo-element-states>
21:44:43 <kbabbitt> ... comments o n issue that this is a good idea
21:44:47 <kbabbitt> ... propose using standard syntax
21:44:50 <TabAtkins> q+
21:44:55 <kbabbitt> ... article::highlight::hover
21:45:03 <kbabbitt> ... don't know if we need to restrict the set or not
21:45:09 <kbabbitt> ... but support the idea, it has clear use cases
21:45:10 <emilio> q+
21:45:13 <astearns> ack TabAtkins
21:45:14 <fantasai> https://www.w3.org/TR/selectors-4/#pseudo-element-states
21:45:16 <kbabbitt> TabAtkins: this is already allowed by spec
21:45:25 <fantasai> "A pseudo-element may be immediately followed by any combination of the user action pseudo-classes, in which case the pseudo-element is represented only when it is in the corresponding state. Whether these pseudo-classes can match on the pseudo-element depends on the pseudo-class and pseudo-element’s definitions: unless otherwise-specified, none of these pseudo-classes will match on the pseudo-element."
21:45:29 <kbabbitt> ... selectors spec says that user action pseudos are allowed after any pseudo element
21:45:46 <emilio> q+ later
21:45:46 <kbabbitt> plus combination pseudos e.g. where
21:45:51 <emilio> ack emilio
21:45:58 <kbabbitt> s/plus/TabAtkins: plus/
21:46:04 <kbabbitt> ... so this should already work
21:46:13 <astearns> ack fantasai
21:46:13 <Zakim> fantasai, you wanted to correct TabAtkins  ;)
21:46:15 <schenney> q+
21:46:26 <kbabbitt> fantasai: to be more precise, we currently say that user action pseudo classes are valid
21:46:36 <kbabbitt> ... but whether they match needs to be defined in pseudo elem definition
21:46:47 <kbabbitt> emilio: these pseudos don't have boxes per se
21:46:49 <kbabbitt> TabAtkins: true
21:46:55 <astearns> ack emilio
21:46:55 <florian> q
21:47:01 <florian> q?
21:47:06 <kbabbitt> emilio: what is the expected behavior when ... assuming you make this work...
21:47:15 <kbabbitt> ... when you hover over a highlight that may look contiguous but not be in the DOM
21:47:26 <kbabbitt> ... you expect hover to apply to whole highlight, to fragment hovered...
21:47:38 <kbabbitt> ... e.g. in spell check I'd expect each region to be individually hoverable
21:47:47 <kbabbitt> ... so hovering over one word woud onlyupdate style on that word
21:47:55 <kbabbitt> TabAtkins: those are separate pseudos
21:47:59 <kbabbitt> emilio: but same highlight
21:48:03 <kbabbitt> schenney: that's second part of issue
21:48:12 <kbabbitt> ... highlight with a particular name applied to multiple ragnes
21:48:23 <kbabbitt> ... e.g. code highlighting, variable highlight applied to all variables
21:48:33 <kbabbitt> ... want to control whether hover affects one or all
21:48:37 <kbabbitt> ... use cases for both
21:48:44 <bramus> q?
21:48:48 <kbabbitt> ... there is a proposal for adding another pseudo called range
21:48:49 <jensimmons> jensimmons has joined #css
21:48:53 <kbabbitt> ... highlight::hover::range
21:48:58 <kbabbitt> ... woudl apply to highlight everything
21:49:06 <kbabbitt> ... without ::range would just affect the one being hovered
21:49:08 <kbabbitt> TabAtkins: other way around
21:49:18 <kbabbitt> schenney: that's also in there and we should consider
21:49:29 <kbabbitt> emilio: if you're doing visual selection you may have multiple ranges
21:49:38 <kbabbitt> ... I'm not sure how it would work for the use case you described
21:49:49 <kbabbitt> ... when you hover over a variable, you want all uses of that variable to be highlighted
21:49:52 <kbabbitt> ... but not all uses of all variables
21:49:57 <kbabbitt> ... would you have one highlight for each token?
21:49:59 <kbabbitt> schenney: good point
21:50:05 <kbabbitt> emilio: so that use case wouldn't be solved
21:50:15 <kbabbitt> florian: you could have a separate highlight per variable
21:50:18 <TabAtkins> like, in "foo[bar<i>baz</i>]" (where [] indicates the highlight), that's two *fragments* but presumably one *highlight* and one *range*, right?
21:50:20 <kbabbitt> emilio: but then you'd need separate styles
21:50:30 <kbabbitt> florian: might be how you set it up if that's what you want to do
21:50:46 <kbabbitt> schenney: you could go to js if you need this more complex behavior
21:50:53 <kbabbitt> emilio: but you'd need some sort of toggle for this to work
21:50:57 <kbabbitt> ... idea is that dom is just plain text
21:51:03 <kbabbitt> ... so you can't just put classes around it
21:51:16 <bramus> q+
21:51:17 <kbabbitt> ... to me it seems like enough questions that proposal should be refined
21:51:41 <astearns> ack schenney
21:51:55 <kbabbitt> schenney: I would be fine resolving that we implement and update spec necessary to support selection::hover
21:52:02 <kbabbitt> ... with separate issue for what to do with highlights
21:52:11 <kbabbitt> bramus: regarding last use case emilio mentioned:
21:52:11 <astearns> ack bramus
21:52:20 <kbabbitt> ... a while ago we discussed incubating custom highlight pointer events
21:52:29 <TabAtkins> yeah, the ::range idea from <https://github.com/w3c/csswg-drafts/issues/7647#issuecomment-2442125272> doens't seem unreasonable to me
21:52:32 <kbabbitt> ... could solve this, detect if yore hovering a highlight
21:52:42 <kbabbitt> emilio: I think we added or decided on adding some elementFromPoint kind of API
21:52:56 <kbabbitt> ...main question is: when you have a single ... you need some sort of logical range concept
21:53:06 <kbabbitt> ... or at the very least, if you have a single DOM range split across lines
21:53:10 <kbabbitt> ... or across elements
21:53:15 <TabAtkins> ::highlight(foo):hover {...} styles all ::highlight(foo) highlights when one is hovered, ::highlight(foo)::range:hover {...} styles only the one Range that is actually being hovered
21:53:17 <kbabbitt> .. or if you have shadow DOM or multiple DOM ranges
21:53:21 <kbabbitt> ... but one logical visual range
21:53:28 <kbabbitt> ... those two things should behave as a unit
21:53:32 <kbabbitt> ... don't see how you can do that just with CSS
21:53:45 <kbabbitt> ... I would think about implementing this use case with two kinds of custom highlightws
21:53:51 <kbabbitt> .... highlight variable and highlight variable hover
21:53:58 <kbabbitt> ... using script to tweak the ranges that are hovered
21:54:04 <kbabbitt> ... but you need some sort of what range is my pointer over
21:54:06 <lea> TabAtkins: I don't see how. `a:hover` doesn't highlight all links when one is hovered
21:54:10 <kbabbitt> ... or what ranges intersect with this point
21:54:17 <kbabbitt> ... I thnk  we resolved on that but don't recall detials
21:54:24 <kbabbitt> ... you could use mouse move
21:54:30 <kbabbitt> ... or implement this using script
21:54:34 <TabAtkins> lea, th eidea is that the ::highlight(foo) *is* the entire set at once (rather than N distinct pseudo-elements)
21:54:42 <kbabbitt> florian: if you hpver pver highlight pseudo that has ll variables
21:54:45 <kbabbitt> ... but only highlight x
21:54:54 <kbabbitt> ... instead of having premade x, y, z
21:55:09 <kbabbitt> emilio: main issue is I don't see how you can make ... other than hovering any range highlights ll rangees
21:55:13 <kbabbitt> ... whcih is not what people expect
21:55:20 <kbabbitt> ... I don't see how you get right behavior in some common cases
21:55:23 <lea> TabAtkins: is that a distinction that the current syntax exposes in any way? If not, perhaps we should revisit that. Maybe it should be N distinct pseudo-elements?
21:55:31 <kbabbitt> ... I would prefer to make sure we have right APIs to implement this kind of stuff
21:55:36 <schenney> q+
21:55:40 <kbabbitt> ... rather than allow hover and make that mean something likely not what author wants
21:55:47 <astearns> ack dbaron
21:56:05 <kbabbitt> dbaron: if we're supporting things like hover we need to define what the rectangles that matter are
21:56:05 <TabAtkins> lea, it's currently not exposed, somewhat intentionally. (this ties into what emilio was talking about, where even when you *do* have one "logical" highlight, it might still have to be multiple Range objects)
21:56:15 <kbabbitt> ... guessing same bounds as painted by background property
21:56:32 <kbabbitt> ... also fantasai said earlier that I agree with what the spec is, but cannot find it...
21:56:45 <kbabbitt> ...which is that user action pseudo classes are allowed after a bunch of kinds of pseudo elements
21:56:48 <fantasai> https://drafts.csswg.org/selectors-4/#pseudo-element-states
21:56:50 <fantasai> Still there ^
21:56:53 <lea> I suspect the mental model of authors is closer to the N pseudo-elements one. fwiw `::range` seems _incredibly_ confusing.
21:57:12 <astearns> ack schenney
21:57:38 <kbabbitt> schenney: having heard the discussion, to dbaron's point, rectangle that triggers hover would trigger pseudo styling
21:57:49 <kbabbitt> dbaron: don't think that's what you want
21:57:57 <kbabbitt> ... if you want hover style for selection
21:58:04 <kbabbitt> .. you have hello world and user hioghlight llo
21:58:07 <emilio> Right
21:58:18 <kbabbitt> ... mouse over hello, don't want to highlight world
21:58:20 <TabAtkins> in particular, the common case we want to address is a big plaintext chunk of code with highlights sprinkled over it
21:58:28 <kbabbitt> schenney: what I suggest is we try and implement and see what comes up
21:58:31 <TabAtkins> so it does need to be hover over the range's own "rectangle"
21:58:38 <emilio> q+
21:58:44 <emilio> q-
21:58:45 <dbaron> s/mouse over hello, don't want to highlight world/mouse over world, don't want llo to have the hover style/
21:58:53 <kbabbitt> fantasai: for figuring out if you're hovering, area we use is what gets painted by highlight background
21:58:54 <astearns> ack fantasai
21:58:54 <Zakim> fantasai, you wanted to react to schenney to clairify
21:59:07 <kbabbitt> ... there are restrictions in spedc that prevent author from depending on where that background is painted
21:59:19 <kbabbitt> ... but for triggering a hover it's fine
21:59:21 <TabAtkins> q+
21:59:30 <fantasai> s/where/exactly where/
21:59:31 <emilio> q+ to say that all behaviors here are implementable, but not sure if useful :)
21:59:32 <astearns> ack lea
21:59:45 <kbabbitt> lea: +1 to the feature, utility seem sobvious
21:59:57 <kbabbitt> ... strongly hopinh we can find a way to use current syntax
22:00:06 <kbabbitt> ... e.g. ::range on pseudo element looks confusing
22:00:12 <kbabbitt> ... authors will copy-paste without undertstanding
22:00:19 <kbabbitt> ... worries me how many of these we add to spec
22:00:37 <kbabbitt> ... it turns out the reason we need this inthe frst place is because highlight pseudo represents entire set at once
22:00:42 <kbabbitt> ... but this distinction is not exposed
22:00:45 <kbabbitt> ... so we could revisit
22:00:47 <TabAtkins> (my q+ is also about this topic fwiw)
22:00:53 <kbabbitt> ... and say it applies to range and not set of ranges
22:01:01 <kbabbitt> ... if that's more understandable maybe a good way forward
22:01:08 <astearns> ack TabAtkins
22:01:21 <kbabbitt> TabAtkins: the reason highlight pseudo applies to full set of ranges is because of what fantasai said
22:01:33 <kbabbitt> ... we purposely limit how much we expose exact composition of the highlight boxes
22:01:43 <kbabbitt> ... one logical highlight range might end up having to be implemented as multiple range objects
22:01:56 <kbabbitt> ... exposing that distinction to authors such taht you can't highlight entire range at once isn't great
22:02:09 <kbabbitt> ... also not great that you'll always highlight all ranges even if they're multiple distinct things
22:02:35 <kbabbitt> ... that's why I lean towards idea that we have the ability to distinguish between all highlights at once with a given name ..
22:02:53 <florian> q?
22:02:55 <florian> q+
22:02:57 <kbabbitt> ... and indivudal ranges with that highlight name plus ability to logically group ranges in JS API
22:03:20 <kbabbitt> astearns: may be that we can resolve our intent to allow hover and such
22:03:31 <kbabbitt> ... but working out how all of this works may be better taken back to issue
22:03:34 <astearns> ack emilio
22:03:34 <Zakim> emilio, you wanted to say that all behaviors here are implementable, but not sure if useful :)
22:03:50 <kbabbitt> emilio: the only logical sensible default I see is highlighting all the ranges
22:03:56 <kbabbitt> ...again there are use case where that's not wanted
22:04:11 <kbabbitt> ... personal preference is to first figure out how to do what authors want
22:04:24 <kbabbitt> ... highlighting only one range doesn't get you right behavior in some common cases
22:04:28 <astearns> ack dbaron
22:04:40 <kbabbitt> dbaron: my intuition is the opposite of emilio's
22:04:49 <kbabbitt> ... highlighting jut one range is what people want most of the time
22:04:58 <kbabbitt> ... I might have different sense of use cases
22:05:08 <kbabbitt> ... other possibility althugh it's not great
22:05:12 <jfkthame_> jfkthame_ has joined #css
22:05:18 <kbabbitt> ... there's an underlying model where there are separate highlights
22:05:25 <kbabbitt> ... that can consist of multiple ranges
22:05:35 <kbabbitt> ... but not expose that complexity through JS APIs
22:05:46 <kbabbitt> ... authors could use that if built in highlights like selection work that way
22:05:55 <kbabbitt> ... even if we don't want to expose complexity
22:06:08 <kbabbitt> ... sometimes selection might generate multiple ranges
22:06:28 <kbabbitt> emilio: my intuition of what authors want might be same as dbaron's
22:06:34 <kbabbitt> ... hovering one word to highlight that word
22:06:38 <kbabbitt> ... but in selection case it's more tricky
22:06:40 <kbabbitt> ... ::selection:hover
22:06:50 <kbabbitt> ... with disjoint selection I would expect hover to apply to all of selection
22:07:08 <kbabbitt> dbaron: I think it might make sense to model things like bidi visual selection using the thing I just described
22:07:24 <kbabbitt> emilio: my concern with making it behave single range by default is it breaks those sorts of use cases
22:07:33 <kbabbitt> ... anything selecting across shadow boundaries needs multiple ranges
22:07:42 <kbabbitt> ... there are situations where right behavior is selecting multiple ranges
22:08:01 <kbabbitt> ... that's why I mentioned that the only somewhat reasonable default is to highlight multiple ranges if you have hover
22:08:06 <kbabbitt> ... even if that's not what authors want in some cases
22:08:09 <astearns> ack fantasai
22:08:26 <kbabbitt> fantasai: one thing that's awkward is p::selection only pertains to part of paragraph taht's not inside any other element
22:08:31 <kbabbitt> ... but that's not going to be how authors perceive it
22:08:44 <kbabbitt> ... so we have to somehow propagate hover state up through highlight pseudos
22:08:53 <kbabbitt> ... to get highlight to work as expected
22:09:06 <astearns> ack florian
22:09:07 <dbaron> maybe it propagates the same way :hover state on elements does?
22:09:08 <kbabbitt> florian: I was going in same direction as dbaron
22:09:15 <kbabbitt> ... and a bhit further, expose in JS API
22:09:22 <kbabbitt> ... could intrudoce new type of range which is composite range
22:09:26 <kbabbitt> ... register that as a chunk
22:09:39 <kbabbitt> ...any range registered in a highlight gets highlighed one by one
22:09:55 <kbabbitt> ... but the thing fantasai just said, if I understood, threw me off
22:10:10 <kbabbitt> ... if they're scoping p::highight:hover what are they going after?
22:10:18 <kbabbitt> ... maybe it just works out but I haven't worked it out yet
22:10:36 <kbabbitt> astearns: can we resolve our intent to allow hover and other user interaction pseudos
22:10:43 <kbabbitt> ...but go back to issue to figure out details?
22:10:47 <kbabbitt> schenney: works for me
22:11:06 <kbabbitt> Proposed: We intend to allow user interaction pseudos after highlight pseudos
22:11:15 <kbabbitt> RESOLVED: We intend to allow user interaction pseudos after highlight pseudos
22:11:24 <dbaron> https://w3c.github.io/selection-api/#dom-selection
22:11:31 <dbaron> sort of looks like the multiple-Range API already!
22:11:50 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10527
22:11:50 <github-bot> Topic: [css-pseudo] allowing ::search-text:current its own overlay
22:11:50 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10527.
22:12:05 <kbabbitt> schenney: for context, there's a notion of highlight overlays that have a stacking order
22:12:10 <kbabbitt> ... overlay with defined order on overlays
22:12:13 <jensimmons> jensimmons has joined #css
22:12:26 <kbabbitt> ... pseudo for search text where you specify search text current which is currently active find in page instance
22:12:31 <kbabbitt> ... just search text is the inactive ones
22:12:42 <kbabbitt> ... this question is whether currently active one and active ones should have spearate highlight overlays
22:12:47 <kbabbitt> .. with current active on top of active in paint order
22:12:52 <kbabbitt> ... makes it easier to implement
22:13:02 <kbabbitt> ... change spec to say that search text current is one overlay, search text is another
22:13:08 <kbabbitt> ... define order as current over regular
22:13:31 <kbabbitt> florian: search-text includes current?
22:13:39 <kbabbitt> schenney: in principle they're mutually exclusive states
22:13:44 <kbabbitt> ... can't be both active and inactive
22:13:51 <kbabbitt> ... in practice ordering doesn't come up
22:14:02 <kbabbitt> florian: not one is superset of other, they're mutually exclusive?
22:14:04 <kbabbitt> schenney: yes
22:14:10 <kbabbitt> astearns: questions or concerns?
22:14:29 <kbabbitt> Proposed: Give search-text-current its own overlay
22:14:38 <kbabbitt> RESOLVED: Give ::search-text:current its own overlay
22:14:51 <kbabbitt> fantasai: if it's its own overlay, are we in same situation as :hover?
22:15:01 <kbabbitt> ... where we have multiple things and we're selecting one?
22:15:15 <kbabbitt> schenney: no
22:15:27 <kbabbitt> ... if you type multiple words into find in page, all words will match search-text-current
22:15:33 <kbabbitt> ... and get current highlighting
22:15:44 <kbabbitt> ....everything else will get search-text
22:16:07 <kbabbitt> florian: the interaction between this and hover
22:16:18 <kbabbitt> ... would we want it to be possible to do some effect when hovering search texty
22:16:24 <kbabbitt> ... vs hovering current search text
22:16:28 <kbabbitt> ... then it would need to be a subset
22:16:37 <kbabbitt> ... not sure it's a real use case but if it is we need to work it out
22:16:41 <kbabbitt> schenney: would work it out as part of hover
22:16:49 <kbabbitt> florian: we can only work it out as part of hover if ...
22:16:59 <kbabbitt> .... you just said they're mutually exclusive rather than a subset
22:17:00 <kbabbitt> ...
22:17:15 <kbabbitt> ... that seems to be incompatible with wanting to be able to highlight all search text when you hover current one
22:17:17 <kbabbitt> schenney: yes
22:17:27 <kbabbitt> florian: current one would also need to be part of everything else
22:17:37 <kbabbitt> ... so when you highlight one chunk, change the style of everything
22:17:51 <kbabbitt> ... not sure it's a real thing people want to do but defining them as mut ex makes it impossible to do
22:18:01 <kbabbitt> schenney: we've already defined them as mut ex so we'd ahve to revisit
22:18:05 <kbabbitt> ... but I see what you're saying
22:18:11 <kbabbitt> ... will open another issue for this
22:18:21 <kbabbitt> ... plan to open a bunch of issues related to hover
22:18:36 <kbabbitt> ... I'll make sure that gets addressed as part of hover stuff
22:18:50 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10298
22:18:50 <github-bot> Topic: [selectors-4][css-pseudo-4] meaning of ::search-text:current(…), :past, :future
22:18:50 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10298.
22:18:58 <TabAtkins> ...i feel like I might have missed the May 1 2024 meeting where we decided to reuse the timed text pseudos
22:19:16 <kbabbitt> schenney: in a previous resolution we decided to use current as the thing to mean prioritized search text element
22:19:20 <kbabbitt> ... don't want to revisit that naming
22:19:27 <kbabbitt> ... also a function name also notion of past and future
22:19:38 <TabAtkins> q+
22:19:40 <kbabbitt> ... should we just say everything other than function al form of current and past and future are all invalid
22:19:51 <florian> q+
22:19:57 <kbabbitt> ... should have been not allowed, should it be invalid selector or selector that doesn't match
22:20:09 <astearns> ack TabAtkins
22:20:18 <kbabbitt> TabAtkins: would need to check but given I didn't comment in previous minutes...
22:20:23 <kbabbitt> ...do want to revisit naming actually
22:20:30 <kbabbitt> .. weird to reuse webvtt pseudoes
22:20:35 <kbabbitt> ... given that they don't match in the same way
22:20:51 <kbabbitt> ... appears to have purely been we want a pseudo that represents current thing, current exits, let's use that
22:21:01 <kbabbitt> ...without consideration that it doesn't follow previous concepts
22:21:14 <kbabbitt> ... think we should revisit, or rename the time pseudo classes
22:21:18 <kbabbitt> ... since this has come up before
22:21:24 <kbabbitt> ... we tried to do it for current scroll marker as well
22:21:29 <kbabbitt> schenney: what did we choose?
22:21:34 <kbabbitt> TabAtkins: target-current I believe
22:21:45 <kbabbitt> fantasai: webvtt pseudo classes are heavily used
22:21:47 <astearns> ack fantasai
22:21:47 <kbabbitt> ... don't think we can change
22:21:53 <kbabbitt> ... in lots of content from what I understand\
22:22:02 <kbabbitt> ... re: not having concept of past and ufutre, that's not ture
22:22:17 <kbabbitt> ... there's an ordering in search results, you have next and previous and taht corresponds to past and future
22:22:24 <kbabbitt> ... we could define past and future to be applicable ot search text
22:22:31 <kbabbitt> ... past is result looked at already backward in chain
22:22:35 <kbabbitt> ... future is going forward
22:22:43 <kbabbitt> ... whether we want to impl that is separate question
22:22:50 <kbabbitt> TabAtkins: there's still thet ancestor mismatch
22:23:02 <kbabbitt> ... current past and future apply to element and ancestors
22:23:10 <kbabbitt> fantasai: but we're in a pseudo tree so that's okay
22:23:11 <kschmi> kschmi has joined #css
22:23:16 <astearns> ack florian
22:23:19 <kbabbitt> florian: assuming we don't rename to something else
22:23:29 <kbabbitt> ... and because it seems like we could define them to mean something
22:23:36 <kbabbitt> ... I think we should fail at parse time so you can @supports detect
22:23:43 <kbabbitt> ... if it doesn't do anything you can detecty
22:23:52 <kbabbitt> ...then one day when we want to make them do something they start existing
22:23:58 <kbabbitt> TabAtkins: that would be better, yes
22:24:00 <TabAtkins> agree if we don't rename, it shoudl fail to parse
22:24:10 <florian> s/define them/define past and future
22:24:14 <kbabbitt> fantasai: not 100% convinced we should use a pseudo class here
22:24:25 <kbabbitt> ... but if we are, past and future are perfectly sensible in this context
22:24:38 <fantasai> s/,/ current,/
22:24:41 <kbabbitt> astearns: for this issue, resolution would be to make past and future invalid for now?
22:25:09 <kbabbitt> RESOLVED: Make :past and :future invalid for now, to reserve them for future use
22:25:27 <kbabbitt> schenney: is the functional form of current also invalid? I propose that it is
22:25:49 <kbabbitt> TabAtkins: other than we should rename it instead, yes
22:26:11 <kbabbitt> Proposed: Make the functional form of :current also invalid for highlight pseudos
22:26:16 <kbabbitt> RESOLVED: Make the functional form of :current also invalid for highlight pseudos
22:26:34 <kbabbitt> schenney: the current language is like is but it isn't like is
22:26:46 <kbabbitt> TabAtkins: fixup to match intention in spec
22:26:57 <kbabbitt> ... I'll do it
22:27:29 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10297
22:27:29 <github-bot> Topic: [cssom-1][css-pseudo-4] getComputedStyle and pseudo-elements with pseudo-classes or sub-pseudo-elements
22:27:29 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10297.
22:27:46 <kbabbitt> schenney: observation is that with gCS you can gCS an element and an optional pseudo class string
22:27:55 <kbabbitt> ... currently speced as being a single pseudo class string
22:28:13 <kbabbitt> ... given other issues we just talked about, potential of having first-line hover etc.
22:28:23 <kbabbitt> ... no way to gCS on multiple chained pseudos
22:28:31 <emilio> q+
22:28:36 <kbabbitt> ... would be a change to behavior of gCS to enable
22:28:45 <jfkthame_> jfkthame_ has joined #css
22:28:59 <oriol> q+
22:29:07 <kbabbitt> ... proposal I agree with is to change 2nd argument from single pseudo selector string to become pseudo element compound selector
22:29:12 <lea> q?
22:29:26 <kbabbitt> ... propose we extend gCS to instead of single string with one pseudo, list of pseudos
22:29:31 <astearns> ack dbaron
22:29:39 <kbabbitt> dbaron: both pseudo element and pseudo class in there
22:29:44 <kbabbitt> ... need to be careful to distinguish
22:29:53 <kbabbitt> ... right now gCS argument is just pseudo element
22:30:01 <kbabbitt> ... gives style given what pseudo class is applied
22:30:07 <kbabbitt> ... providing a way to change that is a bigger discussion
22:30:17 <kbabbitt> ... second piece: I think we discussed this for some other use case
22:30:21 <bramus> https://github.com/w3c/csswg-drafts/issues/4456 was the issue
22:30:30 <kbabbitt> ... I think we have a resolution to allow multiple pseudo elements in that string
22:30:32 <TabAtkins> Yeah, `<pseudo-compound-selector>+` would be the grammar term to use
22:31:09 <kbabbitt> schenney: I did not follow up on that, I think we should table this
22:31:12 <lea> q+
22:31:17 <kbabbitt> s/that/issue 4456/
22:31:19 <oriol> q-
22:31:25 <kbabbitt> ... we should look at this more before we bring it back
22:31:37 <kbabbitt> ... oh wait, I said we should use the resolution for 4456
22:31:42 <astearns> ack emilio
22:31:47 <kbabbitt> emilio: what dbaron said
22:31:53 <kbabbitt> ... I don't think we should accept pseudo classes
22:32:01 <kbabbitt> ... for some specific cases it might be useful
22:32:06 <kbabbitt> .. doesn't match what happens for elements
22:32:10 <bramus> q+
22:32:18 <kbabbitt> ... element would give style with pseudoclasses applied at the time
22:32:24 <kbabbitt> ... could be use cases to request with a given pseudo class
22:32:31 <kbabbitt> ... but I don't think we want to expand that only for pseudo elements
22:32:45 <kbabbitt> astearns: if we use 4456 resolution it's only talking about pseudo classes
22:32:50 <astearns> ack lea
22:32:51 <emilio> s/classes/elements
22:32:54 <kbabbitt> emilio: think we should not mess with pseudo classes here
22:32:57 <TabAtkins> then we need to make the grammar a little more restrictive, that's fine
22:33:01 <dbaron> s/astearns/emilio/
22:33:12 <kbabbitt> lea: basically allowing chained pseudoe elements seems reasonable which not
22:33:15 <kbabbitt> s/which/why/
22:33:27 <kbabbitt> ... hoping we can limit number of times this is needed in the language in general
22:33:34 <kbabbitt> ... agree with dbaron about pseudo classes
22:33:41 <kbabbitt> ... time to turn that argument into  dicutionary perhaps
22:33:50 <kbabbitt> ... much larger scoped change than what's discussed here
22:33:59 <kbabbitt> ... seems like a useful addition that should be discussed separately
22:34:01 <astearns> ack bramus
22:34:01 <emilio> ack bramus
22:34:03 <fantasai> +!
22:34:10 <fantasai> +1
22:34:21 <kbabbitt> bramus: hijacking thread ... pseudo elements are not first class citizens in DOm
22:34:24 <kbabbitt> ... filed aqn issue for that
22:34:27 <kbabbitt> ...11559\
22:34:32 <kbabbitt> ...something to think about
22:34:46 <kbabbitt> astearns: for this issue, we can just apply resolution from 4456 and reuse mechanism from there?
22:34:56 <kbabbitt> schenney: I think it's close no change needed
22:34:58 <emilio> https://github.com/w3c/csswg-drafts/issues/11559 fwiw
22:35:05 <kbabbitt> astearns: might be good to have example in spec
22:35:12 <kbabbitt> schenney: will add example to spec so we can explain
22:35:24 <dbaron> I think the key distinction between pseudo-elements and pseudo-classes here is that pseudo-elements are about finding a different object, whereas providing a pseudo-class you're asking the entirely different question of "what would the style for *this* object be if we changed pseudo-class state in this way")
22:35:47 <kbabbitt> fantasai: propose adding bramus as co-editor to CSS Scroll Animations
22:35:59 <kbabbitt> ... he has contributed very heavily
22:36:12 <kbabbitt> ... very much on design side, coming at it from a different perspective by providing examples
22:36:24 <kbabbitt> ... he put in as much effort in design as editors have
22:36:33 <fantasai> s/examples/demos and use cases/
22:36:38 <kbabbitt> bramus: I would be happy to, thank you for acknowledging
22:36:46 <kbabbitt> RESOLVED: add bramus as co-editor to CSS Scroll Animations
22:36:59 <kbabbitt> Topic: break
22:37:21 <dbaron> (I'll be gone after the break; it will be dinnertime here.)
22:37:27 <fantasai> s/and use cases, and approaching the issues with insightful feedback on what needed changing/
22:49:32 <astearns> 6 more mins (ideally)
23:00:30 <alisonmaher> alisonmaher has joined #css
23:01:59 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11190
23:01:59 <github-bot> Topic: [css-functions-mixins] Handling superfluous arguments
23:01:59 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11190.
23:02:19 <miriam> go for it
23:02:47 <kbabbitt> TabAtkins: question raised, what to do if more arguments passed than defined
23:02:56 <kbabbitt> ... is this invalid, are arguments ignored, or something else
23:03:20 <kbabbitt> ... some discussion back and forth in issue, conclusion we're coming to is to make variable-arity part of validity of function call
23:03:27 <kbabbitt> ... so invalid call if wrong number of arguments passed
23:04:00 <kbabbitt> ... if we want to do variable-arity functions we can do that more explicitly
23:04:25 <kbabbitt> ... unless anyone has a good argument for doing something else with too many arguments, we'll stick with plan in the issue
23:04:32 <kbabbitt> ... which is to make it an invalid function call
23:04:38 <kbabbitt> astearns: comments/questions?
23:04:44 <kizu> kizu has joined #css
23:04:48 <kizu> +1
23:04:50 <kbabbitt> Proposed: If you have a function call with too many arguments, it's invalid
23:04:55 <miriam> +1
23:05:02 <kbabbitt> RESOLVED: If you have a function call with too many arguments, it's invalid
23:05:16 <kbabbitt> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10954
23:05:16 <github-bot> Topic: [css-mixins] Improve ergonomics of `using` by allowing wildcards
23:05:16 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10954.
23:05:35 <kbabbitt> TabAtkins: earlier I had implied that the interior of a fuinction can see custom props on element
23:05:45 <kbabbitt> ... questio is how should that be possible to what degree to make it automatic
23:05:51 <kbabbitt> ...current spec makes it not automatic at all
23:06:00 <kbabbitt> ... if you want to see custom props inside function you have to declare
23:06:08 <kbabbitt> ... then they become local varis inside function body
23:06:24 <kbabbitt> ... lea pointed out that doesn't work well in design systems with 100+ custom props
23:06:30 <kbabbitt> ... functions called by other functions also need to declare
23:06:39 <kbabbitt> ... lea's suggestion at first was to have some wildcarding syntax
23:06:48 <castastrophe> castastrophe has joined #css
23:06:53 <kbabbitt> ... but what I came around to instead was to remove that syntax entirely form fcuntion defintion
23:07:01 <kbabbitt> ... make all custom props visible inside custom function
23:07:04 <kizu> q+
23:07:05 <kbabbitt> ... arguments shadow if they have same name
23:07:06 <emilio> q+
23:07:11 <lea> strong +1 to TabAtkins' proposed behavior
23:07:15 <kbabbitt> ... my preference is to make all custom props behave similarly
23:07:24 <kbabbitt> ...nested variables visible in calling function in the same way
23:07:33 <kbabbitt> ... so you ca override when necessary but otherwise don't have to think about it
23:07:34 <lea> Way more flexible than the current syntax OR the wildcard syntax I proposed
23:07:38 <miriam> this matches my original proposal, and I like it :)
23:07:41 <ydaniv> ydaniv has joined #css
23:07:53 <kbabbitt> lea: the using feature is a wart in general, glad to be rid of it
23:08:01 <kbabbitt> ... makes  a lot more use cases possible
23:08:02 <astearns> ack kizu
23:08:07 <astearns> q+
23:08:11 <kbabbitt> kizu: no objection, huge +1
23:08:21 <kbabbitt> ... only thing I want to mention is we could still keep using syntax if we want to allow renaming
23:08:25 <kbabbitt> ... variables from outer scope
23:08:33 <lea> q?
23:08:36 <kbabbitt> ... if we want to use same names in inner scope or as argument names
23:08:44 <kbabbitt> .... could using foo to define outer foo as something else
23:08:54 <lea> q+ to say this sounds like a L2 feature, and something we need more data on
23:09:01 <kbabbitt> ... other than that, having all custom props from outside available at all times would be much more useful
23:09:07 <jensimmons> jensimmons has joined #css
23:09:13 <kbabbitt> TabAtkins: already possible today if you declare a local var and set its value to var to pull from
23:09:18 <kbabbitt> ... probably don't need additional syntax for that
23:09:23 <kbabbitt> ... theoretically there for the future
23:09:24 <astearns> ack emilio
23:09:31 <kbabbitt> emilio: was wondering use case for this originally?
23:09:37 <kbabbitt> TabAtkins: I wanted to be careful about encapsulation
23:09:48 <kbabbitt> ... so you don't accidentally grab unintended variables
23:09:51 <kbabbitt> emilio: seems fine to allow it
23:09:58 <kbabbitt> ... from impl perspective, easy to compute set of variables if needed
23:10:00 <ChrisL> q+
23:10:02 <kbabbitt> ... manual list seems fine
23:10:13 <kbabbitt> TabAtkins: other aspect was, assuming we'll do a JS backed custom fn as well
23:10:16 <kbabbitt> ... at some point
23:10:25 <kbabbitt> ... using syntax made it clear exactly what would be passed to JS context
23:10:35 <kbabbitt> .. instead we'll gether all custom props, probably not a big deal
23:10:39 <lea> q+ to reply to emilio: do we even need to compute them? We can just propagate these `var()`s to the result and have the function return an expression that contains them
23:10:46 <kbabbitt> ...certainly easier to avoid massive repetition in JS than CSS
23:11:02 <kbabbitt> astearns: if it was a good optimization, you could take a look at what props were used and subset things when passing it over js boundary
23:11:07 <kbabbitt> TabAtkins: aliasing is a hard problem
23:11:19 <kbabbitt> astearns: to clarify: what happens when a custom prop is not defined?
23:11:23 <kbabbitt> ... and function is using it?
23:11:29 <kbabbitt> TabAtkins: it's just a var reference
23:11:37 <kbabbitt> ... you use the var syntax, same as anything else
23:11:39 <astearns> ack astearns
23:11:42 <astearns> ack lea
23:11:42 <Zakim> lea, you wanted to say this sounds like a L2 feature, and something we need more data on and to reply to emilio: do we even need to compute them? We can just propagate these
23:11:45 <Zakim> ... `var()`s to the result and have the function return an expression that contains them
23:11:49 <kbabbitt> lea: re: kizu - yes I can see potentially things to adjust how scoping works
23:11:58 <kbabbitt> ... possibly opposite of using and excluding vars
23:12:02 <kbabbitt> ... sound like level 2 features
23:12:03 <weinig> q+
23:12:11 <kbabbitt> ... don't want to expand scope right now, keep it lean so we can ship soon
23:12:21 <kbabbitt> ... re: emilio - do we actually need to compute the union of props being used?
23:12:26 <kbabbitt> ... just propagate var references instead?
23:12:40 <kbabbitt> ... if using vars from outside, instead of fn returning single value, could return an expression that includes var references
23:12:44 <kbabbitt> ... then they get resolved when used
23:12:51 <kbabbitt> emilio: didn't mean to imply they needed to be computed
23:13:00 <kbabbitt> ... looking at names fns are using, can see the names while parsing
23:13:06 <kbabbitt> ... join them when substituting
23:13:15 <kbabbitt> ...if we need for some super fancy optimization we could get that list
23:13:18 <kbabbitt> lea: awesome
23:13:25 <astearns> acl ChrisL
23:13:28 <astearns> ack ChrisL
23:13:29 <kbabbitt> ChrisL: I understand desire from CS standpoint to want to do data hiding
23:13:43 <kbabbitt> ... but in this case passing things it doesn't actually care bout but 8 level deep does care
23:13:50 <kbabbitt> ... passing them through produces less footguns
23:13:56 <astearns> ack weinig
23:14:05 <kbabbitt> weinig: to clarify.... using the programming language jargon, is what's provided here dynamic scoping?
23:14:07 <kbabbitt> TabAtkins: yes
23:14:17 <kbabbitt> weinig: where you call the function, element or scope there defines additional ?
23:14:26 <kbabbitt> TabAtkins: variable definition doesn't have meaningful scope
23:14:35 <kbabbitt> ...carrying on existing dynamic scoping of inheritance that custom prtops rely on
23:14:40 <kbabbitt> Proposed: Kill using with fire
23:14:43 <TabAtkins> s/meaningful scope/meaningful lexical scope/
23:14:48 <kbabbitt> RESOLVED: Kill using with fire
23:15:21 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10992
23:15:21 <github-bot> Topic: [cssom-view] Allow elementFromPoint and elementsFromPoint to traverse shadow roots
23:15:21 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10992.
23:16:04 <TabAtkins> kbabbitt: request is to have elementFromPoint() be able to traverse shadows, so you can get the "real" element when it's in a shadow
23:16:28 <TabAtkins> astearns: simialr to caretPositionFromPoint(), i see
23:16:42 <emilio> q+
23:16:48 <TabAtkins> proposed: add shadowRoots param to ePFP() to match caretPFP()
23:16:50 <ydaniv> +1
23:16:53 <astearns> ack emilio
23:17:06 <TabAtkins> emilio: somewhat related, Gecko has a way of getting raw nodes from point
23:17:09 <TabAtkins> emilio: text nodes, etc
23:17:20 <TabAtkins> emilio: it always felt kinda funny that elementFromPoint() wouldn't giv eyou that.
23:17:24 <TabAtkins> emilio: wonder if that owuld be useful
23:17:42 <TabAtkins> emilio: nodesFromPoint(), returning the actual node when the point is text, rather than closest element
23:17:46 <TabAtkins> astearns: seems useful to me, open an issue?
23:18:17 <TabAtkins> emilio: we also have the ability to ask what elements/nodes intersect a rect, needed for finger tap testing
23:18:39 <TabAtkins> emilio: I'll file an issue
23:18:57 <TabAtkins> RESOLVED: add shadowRoots param to ePFP() to match caretPFP()
23:19:16 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/7922
23:19:16 <github-bot> Topic: [css-shadow-parts] Make `::slotted()` a combinator
23:19:16 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7922.
23:20:03 <TabAtkins> lea: Right now, the syntax aorund shadow dom includes a lot of pseudos - ::part(), ::slotted()
23:20:24 <TabAtkins> lea: ::slotted() is probably the easiest to "fix". Bunch of problems with it - can't use querySelector(), can't target descendants
23:20:36 <TabAtkins> lea: I udnerstand this seems desirable to avoid breaking encapsulation.
23:20:57 <TabAtkins> lea: But so many use-cases - wrappers, etc - that need the ability to select past.
23:21:07 <TabAtkins> lea: No way to target siblings of slotted elmeents, their pseudo-elements, etc
23:21:08 <TabAtkins> q+
23:21:27 <TabAtkins> lea: I had thought this was why their styling had low specificity, but that's actually a different issue
23:21:37 <TabAtkins> lea: There's no way to detect slots that have content....
23:21:46 <emilio> q+
23:21:51 <TabAtkins> lea: if "slotted" was a combinator you could use :has()
23:22:11 <TabAtkins> lea: In general, ::slotted() seems like a wart we introduced to get things done quickly, but it causes a lot of problems
23:22:19 <TabAtkins> lea: Ultimately, the relationships between elements is what combinators are for
23:22:25 <TabAtkins> lea: Using pseudo-elements introduces a lot of problems
23:22:42 <TabAtkins> lea: It seems like turning the syntax into a combiantor would solve a lot of problems, even if we have to apply restrictions for now
23:22:50 <TabAtkins> lea: Seems better than piling on more syntax over what pseudo-elements are.
23:23:02 <TabAtkins> lea: We can add more syntax, extend definitions, etc, but ultimately what people need is a combinator.
23:23:33 <emilio> TabAtkins: I think `::part()` has still good justification for its existance
23:23:48 <emilio> ... slotted was indeed kind of a workaround
23:24:08 <emilio> ... I agree if we could do this it'd be good
23:24:36 <TabAtkins> emilio: I think the main restriction that ::slotted() being a pseudo  gets you is that arbitrary elements in the light dom can't be targeted by shadow roots
23:24:39 <TabAtkins> emilio: that's a perf consideration
23:24:55 <TabAtkins> emilio: don't wnat to have to look thru arbitrary ancestor chains to know what nodes you need to pull styles from
23:25:09 <TabAtkins> emilio: ::slotted() being a pseudo-element guarantees you that you only need to look at the shadows you're slotted to
23:25:14 <lea> q?
23:25:16 <lea> q+
23:25:21 <astearns> ack TabAtkins
23:25:22 <TabAtkins> emilio: So I think that's a strong justification. I understand the limitations tho.
23:25:28 <emilio> ack emilio
23:25:28 <astearns> ack emilio
23:25:33 <astearns> ack lea
23:25:45 <TabAtkins> lea: I understand it might be tough to do impl-wise due to assumptions made so far.
23:25:59 <TabAtkins> lea: a path forward might be to make it a very restricted combinator at first, syntactigc sugar over the pseudo-element
23:26:10 <TabAtkins> lea: whatever argument you can put inside of ::slotted(), that's all that's allowed after it
23:26:19 <emilio> q+
23:26:31 <TabAtkins> lea: authors then could migrate over to using the new syntax. the longer we wait the more existing CSS we'll have to deal with.
23:27:00 <TabAtkins> lea: so paving the way with a restricted combinator is a way forward
23:27:07 <astearns> ack emilio
23:27:10 <TabAtkins> emilio: I'd lvoe to hear other impl takes
23:27:11 <bramus> q+
23:27:17 <TabAtkins> emilio: this doesn't look like the kind of restrictions you can lift
23:27:46 <TabAtkins> emilio: to figure out how to style a node that's a descendant or sibling of something slotted, you'd need to start arbitrarily walking the ancestor chain to find your closest ancestor that might be slotted
23:27:52 <TabAtkins> emilio: not even clsoest, all of them
23:28:05 <TabAtkins> emilio: I don't think this is the kidn of restriction we can really depend on
23:28:17 <bramus> q-
23:28:48 <astearns> https://github.com/w3c/csswg-drafts/issues/7922#issuecomment-2380098440
23:28:52 <zrhoffman> zrhoffman has joined #css
23:29:04 <TabAtkins> TabAtkins: ryosuke had some comments
23:29:16 <bramus> scribe+
23:29:32 <bramus> TabAtkins: the usefulness of it as lea listed is taht some of other syntactic parts of css work automatically
23:29:46 <bramus> … all the pseudoe classes and elements of a slotted one would be available
23:29:50 <bramus> emilio: but those already work>
23:29:54 <bramus> lea: queryselector will
23:30:11 <lea> s/ lea: queryselector will/ lea: queryselector too/
23:30:15 <bramus> tabAtkins: i dont think you can do ::slotted::before
23:30:19 <bramus> emilio: 99% sure
23:30:23 <bramus> iank_: (missed)
23:30:36 <nicole> nicole has joined #css
23:30:39 <bramus> TabAtkins: the qs() issue is rather frustrating too
23:30:44 <astearns> s/(missed)/I don’t think our style experts have seen this, but I can ping them/
23:30:52 <bramus> emilio: we would never be able to return textnodes
23:30:54 <bramus> TabAtkins: we dont
23:31:01 <bramus> emilio: (missed)
23:31:06 <lea> q?
23:31:24 <bramus> lea: i have been in csswg meetings where certain things that shipped today that the consensus was that it would never fly
23:31:37 <bramus> … there was a time where :has() was never possible
23:31:44 <bramus> … restrictions on what is impl. change over time
23:31:53 <bramus> … we should not design syntax around current limitations
23:31:58 <bramus> … we can expand it later
23:32:00 <bramus> … we did with nesting
23:32:08 <bramus> … at the time, nesting was designed without lookahead
23:32:10 <astearns> q+
23:32:19 <bramus> … and we designed a syntax that was compatible with unbounded lookahead
23:32:29 <bramus> … and eventually andruud and others had a good idea and it became possible
23:32:43 <bramus> … thats why i think to move to a syntax that would allow the expansions
23:32:43 <emilio> ::slotted() pseudos work afaict: https://www.software.hixie.ch/utilities/js/live-dom-viewer/saved/13451
23:32:46 <bramus> … (missed)
23:33:09 <bramus> s/(missed)/adding more warts of what pseudo elements were designed to do
23:33:27 <bramus> … we are using them more and more to represent elements in the DOM
23:33:39 <bramus> … its adding difficulty to learning CSS
23:33:40 <emilio> q+
23:34:01 <bramus> astearns: would push back on that. its not that we cant expand the pseudo syntax but that it would be likelye a one-off thing
23:34:05 <bramus> lea: thats what I am saying
23:34:05 <astearns> ack astearns
23:34:17 <bramus> … ideally its better solved in a way with existing things
23:34:37 <bramus> astearns: it would be still a little werid to have this combinator wher eyou might expect to be able to use it but then learn that there are limitations
23:34:40 <bramus> lea: its a tradeoff
23:34:43 <bramus> emilio: can i push back?
23:34:43 <astearns> ack emilio
23:34:50 <TabAtkins> emilio: push back on some of the things
23:35:06 <TabAtkins> emilio: it feels that turning it into a combiantor without a concrete plan to change the restrictions - it's not making CSS easier
23:35:27 <TabAtkins> emilio: If you have combiantor you can only use at very specific positions - you can't use Nesting, :has(), etc
23:35:40 <TabAtkins> emilio: so I dunno, I just don't feel like this is a meaningful improvement over the status quo
23:36:04 <TabAtkins> emilio: I get the querySelector() point. you'd need to special-case ::slotted() to return elements from another tree, currently qS() never does. But you could make it work.
23:36:10 <TabAtkins> q+
23:36:29 <TabAtkins> emilio: So I don't see this as  great answer unless there's a concrete path
23:36:51 <TabAtkins> lea: We didn't have a concrete path for nesting lookahead...
23:37:05 <TabAtkins> emilio: when we ahve a plan, we can go ahead. just don't see it useful until then.
23:37:21 <bramus> TabAtkins: looking over the list of things again, th ecurrent restrctions
23:37:25 <kschmi> kschmi has joined #css
23:37:31 <bramus> … some of them have been lfited, not what we can put pseudo after ::slotted is nice
23:37:35 <lea> s/We didn't have a concrete path for nesting lookahead.../We didn't have a concrete path for the north start nesting syntax either when we resolved to get partway there/
23:37:47 <bramus> … if we can fix qs to refer to slotted tha twould fix that part
23:38:01 <bramus> … the specificity one is prolly not compat when we try to fix
23:38:14 <bramus> … we still need has-slotted that you do want to know if there are text nodes in it
23:38:21 <lea> q+
23:38:27 <bramus> … if we just fix queryselector and think about specificity we might be sufficiently fine
23:38:33 <astearns> ack TabAtkins
23:38:40 <bramus> emilio: i dont see the tradeoff to making it a combinator be particularly good
23:38:52 <bramus> lea: either way we go,
23:39:11 <bramus> … if we continue pushing on the syntax we have
23:39:24 <bramus> … there is going to be at least 1 word here
23:39:32 <bramus> … not going to be elegant
23:39:33 <astearns> s/word/wart/
23:39:44 <bramus> ; if we continue pushing on the pseudo-element route, thre is multiple types of weirdness
23:39:55 <bramus> … every DOM api that takes  selector must also accept it
23:40:05 <bramus> … if authors want to provide a way for their users, they also have to special case that
23:40:09 <bramus> … and parse selectors on their won
23:40:12 <emilio> q+
23:40:17 <astearns> ack lea
23:40:21 <bramus> … yes, we can special case specificity fixing cascade order is not enough
23:40:31 <bramus> … and who knows what else to special case down the line?
23:40:39 <bramus> … adding more warts to the language
23:40:43 <bramus> … which we have to deal with forever
23:40:59 <bramus> … OTOH if we go combinator route there is only 1 word which we can get rid of later on
23:41:09 <bramus> … for me it seems that the combinator is in favor
23:41:16 <bramus> …when trying to see the big picture
23:41:22 <bramus> … but ymmv
23:41:24 <kbabbitt> s/word/wart/
23:41:40 <emilio> ack fantasai
23:42:21 <TabAtkins> fantasai: two comments. we shoudl keep in mind the experience of the author, so giving them a consistent syntax on a consistent model makes the platform more usable. that's worth doing if it's possible, it's not a no-op even if it seems that way from an engine perspective
23:42:54 <TabAtkins> fantasai: in the distant past we discussed putting elements/combiantors *after* a pseudo-element to indicate that they're processed relative to the pseudo; kinda the pseudo-element is a combinator
23:43:05 <TabAtkins> fantasai: ::region(foo) > a
23:43:07 <astearns> ack emilio
23:43:25 <lea> q+
23:43:36 <TabAtkins> emilio: I'm just not sure I agree that having a combinator ... it won't allow us to remove the pseudo, and a lot of the things you've mentioned work that way with ::slotted() already
23:43:51 <fantasai> s/::region(foo) > a/.foo::nth-fragment(2) a/
23:43:53 <TabAtkins> emilio: a bunch of special cases you need to special case *anyway* because it's a combinator and pointing to a different tree
23:44:17 <TabAtkins> emilio: I'm seeing it's two warts. You have a pseudo-element, and you have ac ombinator, and they both ahve restrictions
23:44:31 <TabAtkins> emilio: like `foo /slotted/ bar { div {...}}` needs to not work
23:44:46 <TabAtkins> lea: you need to invalidate that not at the syntax level, but at selector resolution
23:44:57 <TabAtkins> emilio: right, that's what pseudo-elements do today, it's the same restrictions
23:45:23 <lea> :host: /slotted/ .foo { &.bar { } }
23:45:40 <kizu> kizu has joined #css
23:45:47 <TabAtkins> lea: that's not possible with pseudo-elements
23:45:54 <TabAtkins> emilio: that's a third new wrinkle
23:46:05 <TabAtkins> lea: not a wrinkle, it's the same as what selectors do today
23:46:54 <TabAtkins> astearns: I dont' think people will be convinced today. Take it back to issue, emilio outline problems with combinator restrictions. We can see how extending querySelector() to allow ::slotted() might look so we can balance things against the proposal.
23:47:38 <TabAtkins> emilio: lea, you asked about pseudo-elements somehow forcing people to parse selectors in content
23:47:51 <TabAtkins> lea: say you have a web component that references other elements. a tooltip for something.
23:48:03 <TabAtkins> lea: either you do IDREF like HTML, or take a selector in an attribute
23:48:20 <TabAtkins> lea: Very useful for libraries to take selectors. There's a mutationObserver wrapper that uses selectors, for instance
23:48:30 <TabAtkins> lea: If we have to special-case certain pseudo-elements, authors also have to do so
23:48:47 <TabAtkins> lea: So I think it's better to have combinators return elements
23:48:57 <TabAtkins> lea: i think it's a good design principle to strive towards
23:49:30 <TabAtkins> emilio: I can buy that. But the pseudo-element isn't going to go away, so authors will need to special-case it anyway.
23:49:40 <TabAtkins> emilio: and they'll need to special-case the /slotted/ as well due to the restrictions
23:49:55 <TabAtkins> astearns: another thing we could ahv eint he issue discussion is whether there is a feasible path to removing the restrictions
23:50:15 <TabAtkins> emilio: yeah, i'm fine *if* we ahve a path to improve this so /slotted/ is a regular combinator, I just dont' see it
23:50:35 <TabAtkins> lea: we don't have to remove all, would probably be easier to let it look into descendants than looking everywhere
23:50:40 <TabAtkins> emilio: not really, sibling would be easier i think
23:51:05 <TabAtkins> emilio: what the browser needs is, giving node X, find all the places rules styling X will come from
23:51:26 <lea> q-
23:51:57 <TabAtkins> emilio: So alan's plan seems reasonable. Figure out what restrictions could be lifted, evaluate from there.
23:52:01 <smfr> smfr has joined #css
23:52:12 <TabAtkins> astearns: If we do the combinator we dont' have to lard up the pseudo-element
23:52:40 <TabAtkins> astearns: closing this for now, discuss more in issue
23:53:03 <TabAtkins> lea: we also need to listen to the author community, this is something the WC community has been very excited about
23:53:27 <TabAtkins> emilio: I think that's mostly a misunderstanding about the combinator restrictions fixing some things
23:53:56 <TabAtkins> emilio: I think a lot of the demand is based on the combiantor allowing this to work how they want, like it's interleaved with the outer document rules. but that's not how it's going to work.
23:54:11 <TabAtkins> emilio: rules from different trees just don't interleave, they're either fully before or after
23:54:33 <TabAtkins> emilio: I do think that's osmething we want to fix, but that's a separate issue
23:54:48 <TabAtkins> topic: end
23:55:04 <TabAtkins> fantasai: reservation for host dinner tomorrow, Oren's Hummus in cupertino
23:55:07 <TabAtkins> 6pm
23:55:46 <TabAtkins> (looks like 15 people in the room attending dinner)
23:56:25 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10524
23:56:25 <github-bot> Topic: [css-scrollbars] What is "the background"
23:56:25 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10524.
23:56:42 <TabAtkins> florian: a while back we talked aobut using transparent colors when setting scrollbar colors
23:56:56 <TabAtkins> florian: we resovled that if you set the transparent thumb, you see the track. if you set transparent track, you see the backgroudn of the element
23:57:17 <TabAtkins> florian: we didn't define waht actually is meant by "background"
23:57:31 <TabAtkins> florian: testing, we didn't mean "background", we seemed to mean "element".
23:57:33 <ChrisL> q+
23:57:38 <TabAtkins> florian: almost agreement in brwosers
23:57:55 <TabAtkins> florian: nuance, content of the element isn't seen, but that's just because it's clipped to the padding area so it's not there to *be* seen
23:58:17 <TabAtkins> florian: that's controlled by overflow-clip-margin, default is padding-box
23:58:21 <emilio> q+
23:58:33 <TabAtkins> florian: thus far I think Chrome and Firefox completely agree
23:58:38 <TabAtkins> florian: only one tiny difference, think it's a bug
23:58:49 <TabAtkins> florian: if you do background-attachment local, in Chrome the bg is clipped to the padding box.
23:58:56 <TabAtkins> florian: dont' think there's any spec justification for that
23:59:25 <TabAtkins> florian: wasn't meaningfully observable before, but in Chrome you can't see a local bg because it's clipped; in firefox you see the bg
23:59:51 <astearns> ack ChrisL
23:59:54 <TabAtkins> florian: just need to figure out how to define that stacking/painting