16:00:15 <RRSAgent> RRSAgent has joined #css
16:00:15 <RRSAgent> logging to https://www.w3.org/2021/08/25-css-irc
16:00:17 <Zakim> RRSAgent, make logs Public
16:00:18 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:00:41 <Rossen_> present+
16:00:46 <cbiesinger> present+
16:00:54 <miriam> present+
16:00:54 <vmpstr> present+
16:01:11 <TabAtkins> ScribeNick: TabAtkins
16:01:13 <alisonmaher> alisonmaher has joined #css
16:01:21 <alisonmaher> present+
16:01:30 <rachelandrew> present+
16:01:40 <emilio> present+
16:01:50 <dlibby> dlibby has joined #css
16:01:53 <drott> present+
16:02:05 <plinss> present+
16:02:07 <dlibby> present+
16:02:35 <Morgan> present+
16:02:37 <chrishtr> present+
16:02:38 <sanketj> sanketj has joined #css
16:02:50 <bradk> bradk has joined #css
16:03:36 <jfkthame> jfkthame has joined #css
16:03:53 <argyle> argyle has joined #css
16:04:03 <emeyer> emeyer has joined #css
16:04:14 <bradk> present+
16:04:18 <jfkthame> present+
16:04:19 <argyle> present+
16:04:25 <fantasai> present+
16:04:32 <TabAtkins> Rossen_: Any additional items?
16:04:53 <TabAtkins> astearns: Might need some extra wording in CRDs to trigger wide-review tooling checks. Chris, do you know which drafts are having this problem?
16:04:56 <sanketj> present+
16:05:20 <TabAtkins> astearns: Apparently there's some tooling the W3C has added for soliciting wide review, and there's some magic words that we need to add to CRDs we need wide review for
16:05:35 <TabAtkins> fantasai: I don't think we've published anything lately that need this. We have resolutions on some, but haven't published them yet
16:05:45 <TabAtkins> fantasai: And so far we've solicited wide review manually, so it shouldn't be a problem
16:05:51 <vmpstr_> vmpstr_ has joined #css
16:06:07 <fantasai> if you've been publishing the instructions on the wiki anyway https://wiki.csswg.org/spec/publish
16:06:09 <leaverou2> leaverou2 has joined #css
16:06:12 <TabAtkins> Rossen_: So maybe we just have to update the wiki if the tooling updates?
16:06:31 <TabAtkins> Rossen_: I'd encourage Chris to follow up on this and see if there are any edits needed
16:06:58 <TabAtkins> ??: Could we bump the highlight topic up? sanketj wanted to participate but has a 9:30 conflict
16:07:33 <TabAtkins> Topic: scrollIntoView() with content-visiblity:hidden
16:07:35 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6529
16:08:01 <leaverou2> Fine by me to bump, that gives me more time to join the call for the nesting issue too
16:08:11 <TabAtkins> vmpstr: We have content-visiblity:hidden that hides the content of the subtree, and spec says that the contents should not be available to UA features like focus, find-in-page, etc
16:08:21 <TabAtkins> vmpstr: I think one of the features it should be restrited from is fragment nav
16:08:27 <TabAtkins> vmpstr: I don't want to scroll into the hidden content
16:08:40 <bradk> Is content-visibility in a draft?
16:08:50 <TabAtkins> vmpstr: But the current fragment nav text points to scrollIntoView() for defining it. and sIV() says we scroll as long as there's a layout box
16:09:00 <chris> chris has joined #css
16:09:09 <chris> present+
16:09:17 <TabAtkins> vmpstr: My hope is we can prevent sIV() for c-v:hidden subtrees
16:09:24 <astearns> bradk: https://drafts.csswg.org/css-contain-2/#content-visibility
16:09:39 <TabAtkins> vmpstr: I think last comment from Chris is that we should change sIV() to say "if it doesn't ahve a layout box, or is not available to UA features, return"
16:10:08 <bradk> @astearns thanx
16:10:14 <TabAtkins> TabAtkins: I support this
16:10:24 <chris> rrsagent, here
16:10:24 <RRSAgent> See https://www.w3.org/2021/08/25-css-irc#T16-10-24
16:10:24 <leaverou2> Does that mean we also don’t scroll to disabled form controls since they can’t be focused?
16:10:35 <TabAtkins> vmpstr: To be specific we gen the layout box in the subtree when we *need* to, such as to getBoundingClientRect() on the subtree
16:10:37 <Arnaud> Arnaud has left #css
16:10:50 <TabAtkins> vmpstr: So the layout box *is* theoretically there, but it's generated on demand. We just don't want that to happen here.
16:11:18 <TabAtkins> Rossen_: Can we get a tighter definition for "available to UA features"? It's very broad
16:11:23 <jensimmons> present+
16:11:39 <TabAtkins> Rossen_: What would be the better scoped version of that? Is it just for focusing?
16:11:44 <chrishtr> q+
16:12:27 <TabAtkins> vmpstr: I think it should be "behaving similar to display:none", it's not just focus
16:12:37 <TabAtkins> vmpstr: display:none *also* doesn't have a layout box, but this does
16:12:50 <TabAtkins> chrishtr: We can scope it by "if you ahve a content-visiblity:hidden ancestor"
16:12:52 <bradk> bradk has joined #css
16:13:08 <TabAtkins> Rossen_: Okay so if it's hidden or has an ancestor
16:13:19 <TabAtkins> chrishtr: Only ancestor. If the element itself has it, it's still there on the page like normal
16:13:22 <leaverou2> But ancestor can’t be overridden by another ancestor lower down
16:13:34 <leaverou2> s/can’t/can/
16:14:25 <leaverou2> Perhaps if the computed value of the parent is c-v:hidden?
16:14:34 <TabAtkins> TabAtkins: I think best is to define the term somewaht generally, and say that c-v:hidden is the only way to trigger the term currently
16:14:46 <Rossen_> q?
16:14:54 <TabAtkins> Rossen_: Sounds reasonable
16:14:56 <Rossen_> ack chrishtr
16:15:00 <leaverou2> Agreed as well
16:15:00 <TabAtkins> Rossen_: Any more comments?
16:15:21 <TabAtkins> RESOLVED: c-v:hidden prevents scrollIntView() and similar functionality from working on the subtree
16:15:38 <TabAtkins> Topic: highlight API
16:15:49 <GameMaker> GameMaker has joined #css
16:15:50 <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/4597
16:15:51 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/4597
16:15:54 <GameMaker> present+
16:16:14 <TabAtkins> dandclark: This was originally what the criteria was to invalidate a static range during DOM mutations
16:16:23 <TabAtkins> dandclark: discussion evolved into use of StaticRange more generally
16:16:41 <TabAtkins> dandclark: So when an author adds a staticrange to a highlight, should we internally back it with a live range? Or just let it stay static
16:16:48 <TabAtkins> dandclark: I want to advocate we use statics internally
16:17:03 <TabAtkins> dandclark: One for perf; static range is better for perf in some cases when there's a lot of DOM mutations
16:17:18 <TabAtkins> dandclark: Team has done some benchmarks and shown the perf diffs aren't theoretical
16:17:42 <TabAtkins> dandclark: And issues with invalidation of static ragnes during paint time can be addressed with invalidation caches
16:17:53 <chrishtr> q+
16:18:04 <TabAtkins> dandclark: So if they're backed with live ranges internally, we pretty much lose all the benefits and there's no reason to support it
16:18:10 <TabAtkins> dandclark: Second is some issues sanketj pointed out
16:18:30 <TabAtkins> dandclark: If a static is backed internally with a live range, the author doesn't ahve a ref to it, so how do they manipulate this
16:18:52 <TabAtkins> dandclark: Like if a highlihgt is unregistered, should we maintain it? Highlight can be reregistered, unsure what the lifetime is
16:19:11 <TabAtkins> dandclark: So I'd like to get agreement that the internal range is indeed static
16:19:17 <florian> q?
16:19:29 <Rossen_> ack chrishtr
16:19:49 <TabAtkins> chrishtr: So your proposal is that the static range is not live internally, and as a result, when the highlight api uses a static range it's ignored if it's invalid
16:19:56 <TabAtkins> chrishtr: [missed]
16:20:13 <TabAtkins> dandclark: There are some cases like "start before end" that you might have to treewalk to determine; it's not constant-time to determine
16:20:31 <TabAtkins> dandclark: You can largely cache validity status and be fine; if there's no dom mutations you're guaranteed right
16:20:37 <florian> q+
16:20:44 <TabAtkins> chrishtr: But if the dom mutation was non-trivial, the UA might have to treewalk in the worst case?
16:20:46 <TabAtkins> dandclark: Yeah
16:20:54 <TabAtkins> chrishtr: And you couldn't avoid that situation?
16:21:18 <TabAtkins> dandclark: I think UAs could in theory do some optimizations, but the simplest way is to just cache the data; you won't have mutations between every paint in practice
16:21:34 <TabAtkins> chrishtr: So the script usually will make a static range and then immediately add it to the doc
16:21:37 <TabAtkins> dandclark: yeah
16:21:42 <GameMaker> q+
16:21:45 <Rossen_> ack florian
16:21:52 <TabAtkins> florian: agree. I think this is the right thing to do; it's why we proposed having static ranges in the first place
16:22:03 <TabAtkins> florian: Live ranges can be costly, and it might not even be a useful cost
16:22:12 <lea> lea has joined #css
16:22:20 <TabAtkins> florian: If the DOM changes and the UA updates the range, whether or not the updated range is what the author actually wanted isn't clear
16:22:36 <TabAtkins> florian: So paying the cost of updating the live range, only to immediately discard it and regen the range, is silly.
16:22:50 <sanketj> +1 to the proposed resolution
16:22:54 <chrishtr> +1
16:23:01 <GameMaker> +1
16:23:04 <TabAtkins> Rossen_: Any furhter comments?
16:23:22 <lea> present+
16:23:25 <myles> myles has joined #css
16:23:25 <Rossen_> q?
16:23:34 <Rossen_> ack GameMaker
16:23:44 <TabAtkins> GameMaker: Agreeement; webkit has the same perf issues that Chrome does, so +1
16:24:18 <TabAtkins> RESOLVED: When an author uses a static range for highlight API, it should actually be a static range internally, not backed by a hidden live range.
16:24:32 <myles> present+ myles
16:24:35 <TabAtkins> florian: Do we think we need a spec change to reflect this? Or is the spec already sufficiently implying this?
16:24:54 <TabAtkins> dandclark: I think the spec is clear as-is; we'd only need a change if we decided the other way
16:25:07 <TabAtkins> dandclark: There's another issues about invalidation we coudl discuss; it was the original issue.
16:25:25 <TabAtkins> sanketj: I think it would be good to have a note about using static ranges internally
16:25:35 <TabAtkins> sanketj: So for interop we should have an explanation
16:25:54 <TabAtkins> florian: We say already that when you use a static range they shouldn't be updated, but we can work over the note
16:26:11 <TabAtkins> dandclark: I can look over it
16:26:33 <ffiori> ffiori has joined #css
16:26:33 <Rossen_> ack fantasai
16:26:34 <Zakim> fantasai, you wanted to ask about publication
16:26:38 <TabAtkins> fantasai: last pub of this draft was Dec 2020; given changes, we should get an update onto TR
16:26:52 <TabAtkins> fantasai: ED claims there's only been minor changes since last WD, that probably isn't true
16:27:07 <TabAtkins> florian: agree. i'll start making sure the changes section is up to date
16:27:32 <dauwhe> dauwhe has joined #css
16:27:32 <TabAtkins> Rossen_: Should we get a resolution to republish the WD when it's ready?
16:28:13 <TabAtkins> RESOLVED: Publish a new Highlight API WD when changes are made
16:28:31 <castastrophe> castastrophe has joined #css
16:28:35 <castastrophe> present+
16:28:38 <TabAtkins> Topic: disallow interweaving of @import and @layer
16:28:40 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6522
16:29:31 <TabAtkins> miriam: xiaochang is working on a cascade layers impl, and was concerned about allowing `@layers ...;`rules allowed anywhere in the doc, including between @imports
16:29:41 <TabAtkins> miriam: He's suggesting instead we just allow them before or after all the imports, but not between
16:29:57 <TabAtkins> miriam: I think that's fine; there's no functionality loss, just a little bit of flexibility. I'm fine with this.
16:30:02 <fantasai> wfm
16:30:15 <chrishtr> +1
16:30:19 <TabAtkins> Rossen_: Seeing support, any other opinions? Objections?
16:30:27 <emilio> q+
16:30:51 <chris> ping
16:30:58 <Rossen_> ack emilio
16:31:01 <TabAtkins> emilio: I'd argue we shoudl only allow after
16:31:12 <TabAtkins> emilio: The less syntax we have to mess with preload scanners the better
16:31:23 <TabAtkins> miriam: That actually does reduce functionality, we need to be able to order layers before we import them
16:31:34 <TabAtkins> emilio: That means the scanners need to deal with this
16:31:42 <TabAtkins> emilio: Do we also allow the block syntax?
16:31:46 <smfr> smfr has joined #css
16:31:50 <TabAtkins> fantasai: No, we disallow that intentionally
16:32:01 <TabAtkins> emilio: Okay, as long as there's no arbitrary blocks before the imports it's okay
16:32:15 <Rossen_> q?
16:32:27 <TabAtkins> RESOLVED: @layer statements must occur before or after all @imports, not interleaved
16:32:43 <TabAtkins> Topic: nesting of @supports inside @font-face
16:32:44 <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6520
16:33:23 <TabAtkins> leaverou: A little background, in the TAG review request the current syntax is extending the format() syntax for 'src'
16:33:24 <lea> https://github.com/w3c/csswg-drafts/blob/main/css-fonts-4/src-explainer.md#use-case-3-detectability
16:33:40 <TabAtkins> leaverou: It hasn't been implemented yet; Chrome is keen to implement quickly
16:33:57 <TabAtkins> leaverou: In the TAG we recognized the use-case, but were concerned about a new microsyntax when @supports alreayd exists
16:34:08 <TabAtkins> leaverou: So was thinking about how we could utilize @supports, and posted this issue
16:34:14 <chris> Explainer for current src descriptor https://github.com/w3c/csswg-drafts/blob/main/css-fonts-4/src-explainer.md
16:34:22 <TabAtkins> leaverou: Two things. First, adding a new @supports query for detecting font tech.
16:34:43 <TabAtkins> leaverou: Lets authors differentiate their CSS in other places; existing proposal only lets them use it when selecting font source.
16:34:56 <TabAtkins> leaverou: Could imagine authors wanting different CSS for a monochrome vs color font
16:35:11 <drott> q+
16:35:13 <TabAtkins> leaverou: This also makes it much easier to programmatically detect, vs doing rule hacking and seeing if there is a syntax error
16:35:26 <TabAtkins> leaverou: Google said they could add the font-tech queries in @supports easily
16:35:42 <TabAtkins> leaverou: Second bit is to let @supports nest inside of @font-face, extending the Nesting proposal
16:35:50 <TabAtkins> leaverou: But that would be a more substantial request
16:36:15 <TabAtkins> leaverou: So proposal is just to add the @supports queries for now - it does the job, if a bit clunky. And in the future perhaps do the nesting thing.
16:36:33 <Rossen_> ack drott
16:36:35 <TabAtkins> drott: Good summary. I'd support font-tech queries in @supports
16:36:36 <chris> q+
16:37:04 <TabAtkins> drott: And am open to later improving it by integrating Nesting, but the immediate benefit is just feature detection, so the @supports queries works for me.
16:37:11 <emilio> q+
16:37:14 <TabAtkins> drott: I've made a syntax proposal for Conditional 4 to support this
16:37:18 <Rossen_> ack chris
16:37:26 <TabAtkins> chris: I wrote an explainer for it
16:37:37 <TabAtkins> chris: [missed due to chop]
16:38:21 <drott> 👍
16:39:10 <TabAtkins> chris: TAG asked for an explainer; having written it, it was clear the only benefit of the existing syntax is that old browsers would parse without falling over
16:39:21 <TabAtkins> chris: It has no other redeeming features. It's an ugly complex microsyntax and is hard to read
16:39:27 <Rossen_> q?
16:39:32 <TabAtkins> chris: I think using @supports makes sense even if we can't use it directly in @font-face
16:39:42 <TabAtkins> chris: We've got some examples in the thread and I think it reads easily
16:39:48 <TabAtkins> emilio: I like this
16:39:50 <myles> q+
16:39:56 <Rossen_> ack emilio
16:40:06 <TabAtkins> emilio: Only question is if there's another place we need to parse this font stuff?
16:40:14 <chris> q+
16:40:20 <TabAtkins> emilio: To avoid the "specialized parser" thing that we try to avoid with @supports
16:40:34 <fantasai> TabAtkins: while trying to avoid specialized parse is a general goal
16:40:43 <fantasai> TabAtkins: we recognized there will be cases where we do
16:41:09 <fantasai> TabAtkins: as long as we're carefully scoped wrt feature queries that are not just parsing-based, should be OK
16:41:26 <TabAtkins> myles: One question - if an author uses @supports, is there a way to say "else"?
16:41:47 <TabAtkins> myles: If there's not a way to do that... @font-faces join together to form a family, rather than overriding
16:41:48 <Rossen_> q?
16:41:50 <Rossen_> ack myles
16:42:02 <TabAtkins> emilio: Can use "not"?
16:42:13 <TabAtkins> myles: "not" is both "fails the query" and "doesn't understand"
16:42:36 <TabAtkins> chris: Usual fallback is to put something normal outside, then override in a @supports
16:42:55 <TabAtkins> myles: Right, that's problematic; if it's supported it'll define a combined family using both @font-face rules.
16:43:01 <TabAtkins> myles: Author probably wants it to override
16:43:25 <drott> q+
16:43:37 <TabAtkins> myles: If they're careful they might override, like all same weight/etc, but if they didn't they'll both be present
16:43:49 <lea> q+
16:43:49 <chris> q+
16:43:49 <TabAtkins> q+
16:44:24 <fantasai> myles: and they will join together to form a family
16:44:39 <fantasai> myles: if descriptors aren't identical, might end up using both fonts in the page instead of only the second one
16:44:50 <chris> q-
16:45:06 <TabAtkins> chris: we already have this thing where font faces can combine together into a family, that's be design
16:45:09 <fantasai> TabAtkins: he's saying that conflicts with the author's design here.
16:45:28 <TabAtkins> myles: Right, if you have the non-conditional outside and the conditional inside, that's brittle
16:45:47 <emilio> TabAtkins: this is a general problem with a lot of things
16:46:02 <emilio> ... we don't have an answer to negate a query, but there's a proposal for an "else" on conditional rules
16:46:06 <dbaron[m]> some of these problems seem specific to @font-face inside @supports rather than @supports inside @font-face
16:46:11 <lea> q?
16:46:14 <fantasai> +1 dbaron[m]
16:46:16 <emilio> ... if there's implementor interest I'd be happy to revive it
16:46:18 <TabAtkins> https://tabatkins.github.io/specs/css-when-else/
16:46:21 <Rossen_> ack TabAtkins
16:46:43 <emilio> myles: I think there isn't a lot of sense to build the stopgap solution on something that doesn't exist yet
16:46:51 <TabAtkins> myles: If the oracle delivered us some way of having an else attached to @supports tomorrow, that woudl solve the problem
16:46:58 <chris> q+ to say format strings were a stopgap that lasted 2 1/2 decades
16:47:14 <TabAtkins> drott: I think this is an improvement over the current proposed syntax
16:47:37 <TabAtkins> drott: You're basing this on the concern on the likelihood of a typo; I think most will be coming from 3rd party fonts so that's not really a concern
16:47:46 <Rossen_> ack drott
16:48:00 <TabAtkins> drott: Second, in browsers where author expects font-tech(color) to work, "not" would work
16:48:23 <TabAtkins> myles: I think it would help if after this call we could have an example of the fallback
16:48:25 <chris> the issue already has such an example
16:48:32 <dauwhe> dauwhe has joined #css
16:48:36 <TabAtkins> lea: There's a snippet in the issue that Chris posted
16:48:40 <Rossen_> q?
16:48:54 <Rossen_> ack lea
16:48:59 <TabAtkins> leaverou: I think drott mentioned most points
16:49:20 <TabAtkins> leaverou: Reminder that this isn't *ideal* but it can be done quickly, and when we go on to nesting it'll work without duplication
16:49:35 <TabAtkins> leaverou: Also think ahving "else" in a conditional block would be super useful; it shouldn't hold this up tho.
16:49:38 <drott> +1 for not blocking on an else block
16:49:39 <TabAtkins> Agreed, fwiw
16:49:49 <Rossen_> ack dbaron[m]
16:49:49 <Zakim> dbaron[m], you wanted to react to lea
16:49:51 <TabAtkins> But happy to lean on this to grab impl support ^_^
16:49:56 <Rossen_> ack dbaron[m]
16:50:27 <TabAtkins> dbaron[m]: My understanding of myles' concern is - I think a lot applies if we have @supports { @font-face{}}, but a lot of the proposal is doing @font-face { @supports{}}, and I don't think the interaction concerns apply in that case
16:50:33 <Rossen_> q
16:50:43 <TabAtkins> myles: Right. I have different feedback in that case, but the proposal is currently the first case.
16:50:48 <lea> q?
16:51:32 <TabAtkins> fantasai: First, given myles' example, I do have concern about allowing this without inline/nested supports, becuase of his mentioned concerns
16:51:57 <lea> q+ to say that this problem actually exists today when defining font families, it's not new
16:51:58 <TabAtkins> fantasai: Second, it seems the proposal is to add font-technology() function which include some features that could be part of a font format, but it's not clear to me how that relates tot he font format
16:52:04 <drott> q+
16:52:24 <TabAtkins> fantasai: What if the browser supports colorv1 in woff2, but not others. Would we need to tie the feature query to a font format?
16:52:27 <Rossen_> ack fantasai
16:52:31 <drott> q-
16:53:03 <TabAtkins> chris: woff1 and woff2 are encodings of the same font tech (truetype)
16:53:17 <chris> 1. stopgap 2. OM complexity inside @font-face 3. making other stylistic changes based on font support 4. unrelated to formats
16:53:23 <Rossen_> ack chris
16:53:23 <Zakim> chris, you wanted to say format strings were a stopgap that lasted 2 1/2 decades
16:53:34 <TabAtkins> chris: The entire format string was a stopgap because we didn't have font mime types
16:53:44 <TabAtkins> chris: So "stopgap" is a non-argument in my mind
16:54:01 <TabAtkins> chris: If we do put @supports inside @font-face it complicates the OM; current proposal avoid that
16:54:22 <TabAtkins> chris: Using @supports doesn't just allow switching font, it lets you vary other aspects of your style
16:54:50 <TabAtkins> chris: Finally, the only reason supports were smuggled into format string is for parsing. But spec actually mandates OpenType and TrueType treated the same.
16:54:59 <TabAtkins> chris: So the font technology is almost completely orthogonal to the format used
16:55:08 <myles> q+ to respond to chris
16:55:16 <drott> q+
16:55:18 <TabAtkins> chris: So decoupling as this proposal does is a much clearner and nicer way
16:55:24 <chris> q?
16:55:30 <Rossen_> ack lea
16:55:30 <Zakim> lea, you wanted to say that this problem actually exists today when defining font families, it's not new
16:55:41 <myles> q-
16:55:57 <TabAtkins> lea: The concern myles brought up about typos is already existant; when authors write a family they could already typo and have the wrong family happen
16:56:10 <Rossen_> ack drott
16:56:41 <TabAtkins> drott: as lea mentioned, the reason we brought to the TAG is it seemed helpful to get some time of feature detection for COLR v1, so I hope we can have CSS support for that at the same time
16:57:00 <TabAtkins> Rossen_: I think the TAG feedback was clear - colr1 was gonna be a great addition
16:57:10 <chris> s/was/is/
16:57:16 <TabAtkins> Rossen_: Introducing new microsyntaxes is generally discouraged when we have existing feature-detect capabilities
16:57:34 <dauwhe> dauwhe has joined #css
16:57:44 <TabAtkins> Rossen_: I appreciate you ahve some impl urgency on your end. Important to get what's gonna stick for the future right tho.
16:58:11 <Rossen_> q?
16:58:45 <TabAtkins> Rossen_: So not sure I'm hearing the solution that addresses the current user needs and the tech being proposed
16:58:47 <chris> s/colr1/COLRv1
16:59:03 <TabAtkins> Rossen_: With two minutes remaining, unsure if we'll have a resolution
16:59:15 <TabAtkins> Rossen_: Propose we continue in the issue and bring this back next week for resolution
17:00:20 <bradk> bradk has joined #css
17:00:58 <Rossen_> Topic: end
17:01:17 <Rossen_> Zakim, end meeting
17:01:17 <Zakim> As of this point the attendees have been Rossen_, cbiesinger, miriam, vmpstr, alisonmaher, rachelandrew, emilio, drott, plinss, dlibby, Morgan, chrishtr, bradk, jfkthame, argyle,
17:01:20 <Zakim> ... fantasai, sanketj, chris, jensimmons, GameMaker, lea, myles, castastrophe
17:01:20 <Zakim> RRSAgent, please draft minutes v2
17:01:20 <RRSAgent> I have made the request to generate https://www.w3.org/2021/08/25-css-minutes.html Zakim
17:01:22 <Zakim> I am happy to have been of service, Rossen_; please remember to excuse RRSAgent.  Goodbye
17:01:26 <Zakim> Zakim has left #css
17:01:31 <emeyer> emeyer has left #css
17:15:47 <freeworld> freeworld has joined #css
18:33:17 <hober> Ooooh, very simple CSS question that I apparently don't know the answer to: How can I, from CSS, get a URL to the current document? Not the current stylesheet, the current document. What to pass to url()?
18:36:21 <cbiesinger> I didn't think that was possible
18:39:04 <hober> oh, booo. filed https://github.com/w3c/csswg-drafts/issues/6546
18:40:35 <hober>             the current document? Not the current stylesheet, the
18:40:49 <hober> whoops, sorry
19:14:27 <jensimmons> jensimmons has joined #css
19:38:36 <projector> projector has joined #css
19:39:06 <leaverou> leaverou has joined #css
19:39:37 <Rossen> Rossen has joined #css
19:40:07 <shans> shans has joined #css
19:40:37 <sylvaing> sylvaing has joined #css
21:00:10 <dauwhe> dauwhe has joined #css
21:05:32 <dauwhe> dauwhe has joined #css
21:06:52 <dauwhe> dauwhe has joined #css
23:28:44 <futhark> futhark has joined #css