15:56:35 <RRSAgent> RRSAgent has joined #css
15:56:40 <RRSAgent> logging to https://www.w3.org/2026/07/01-css-irc
15:56:41 <Zakim> RRSAgent, make logs Public
15:56:42 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:57:36 <PaulG> PaulG has joined #css
15:59:12 <ydaniv> ydaniv has joined #css
15:59:41 <vitorroriz> vitorroriz has joined #css
15:59:48 <ChrisL> present+
16:00:03 <JoshT> present+
16:00:10 <kbabbitt> kbabbitt has joined #css
16:00:26 <ydaniv> present+
16:00:31 <JohnJansen> present+
16:00:50 <rachelandrew> present+
16:01:03 <hoch> hoch has joined #css
16:01:23 <CameronPsychpsyo> present+
16:01:29 <hoch> present+
16:01:32 <vitorroriz> present+
16:01:33 <kbabbitt> present+
16:01:36 <bramus> present+
16:01:41 <kizu> kizu has joined #css
16:01:46 <davidjmarland> davidjmarland has joined #css
16:01:53 <kizu> present+
16:01:55 <masonf> masonf has joined #css
16:01:57 <noamr> noamr has joined #css
16:02:03 <masonf> present+
16:02:12 <alisonmaher> alisonmaher has joined #css
16:02:12 <noamr> present+
16:02:15 <schenney> schenney has joined #css
16:02:17 <alisonmaher> present+
16:02:18 <davidjmarland> present+
16:02:53 <JoshT> github-bot, topic https://github.com/w3c/csswg-drafts/issues/13816
16:02:53 <github-bot> Topic: [css-overflow] Scroll direction of unicode-bidi: plaintext.
16:02:53 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13816
16:02:56 <oriol> present+
16:03:04 <romain> present+
16:03:21 <fantasai> present+
16:03:25 <lea> lea has joined #css
16:03:54 <Estelle> Estelle has joined #css
16:04:09 <JoshT> github-bot: none
16:04:09 <github-bot> JoshT, Sorry, I don't understand that command.  Try 'help'.
16:04:09 <JoshT> github: none
16:04:14 <CameronPsychpsyo> I think Emilio said he might only make it to the IRC channel and left comments on Github
16:04:21 <JoshT> github-bot, topic https://github.com/w3c/csswg-drafts/issues/13652
16:04:21 <github-bot> Topic: [css-sizing] "behaves as auto" needs clarifications
16:04:21 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13652
16:04:42 <lea> present+
16:04:49 <JoshT> fantasai: when we drafted the auto stuff, we were handy wavy about it
16:04:58 <JoshT> ... it behaves as auto in most but not all cases
16:05:14 <smfr> smfr has joined #css
16:05:14 <JoshT> ... interesting case brought up is margin collapsing
16:05:27 <TabAtkins> q+
16:05:32 <JoshT> ... box with margin height, its last child can collapse with its own margin and the following sibling
16:05:48 <JoshT> ... but if it's not auto, like length or %, then margin collapsing does not happen
16:06:06 <PaulG> present+
16:06:10 <JoshT> ... so the auto behaviour gets set if % is resolvavle because the container has a definite height
16:06:33 <JoshT> ... spec says that when the % can't resolve like in block layout, the height is calc in a way that behaves as auto
16:06:43 <JoshT> ... but spec checks computed value which is %, not auto
16:06:56 <JoshT> ... so the spec says you are not supposed to collapse the margins
16:07:05 <cepan> cepan has joined #css
16:07:13 <JoshT> ... but since written, there are new keywords so what is the right thing to do in various cases
16:07:32 <JoshT> ... brings up question that some impl include margin collapsing and some check the computed value specifically
16:07:56 <JoshT> ... so on one side, people says it should behave as auto in all aspects. on the other side, should it also unpack margin collapsing
16:08:01 <oriol> q+
16:08:04 <astearns> ack TabAtkins
16:08:10 <fantasai> fantasai has joined #css
16:08:17 <JoshT> TabAtkins: comment in issue asks for concrete proposal
16:08:27 <JoshT> ... right now it doesn't actually propose what is changing
16:08:32 <JoshT> ... and asks for some examples
16:08:47 <JoshT> ... i do not support a change now before more concrete pros, suggestions and what this means for pages
16:09:00 <JoshT> fantasai: I filed this originally to flesh this out a bit more
16:09:02 <dbaron> Present+
16:09:09 <JoshT> ... oriol and ??? got into this case of margin collapsing
16:09:21 <JoshT> TabAtkins: in that case, I don't know what you want to edit
16:09:26 <JoshT> ... if that's only one aspect
16:09:36 <JoshT> fantasai: they're all probably independently editable
16:09:37 <kbabbitt> s/???/anne/
16:09:57 <JoshT> ... i can't remember what other side effects there are for auto
16:09:58 <dholbert> dholbert has joined #css
16:10:04 <dholbert> present+]
16:10:07 <astearns> ack oriol
16:10:07 <dholbert> present+
16:10:19 <JoshT> oriol: I think that if we say something behaves as auto, then behaviour should be ??
16:10:35 <JoshT> ... we could add dependencies on computed values, but I do not see agreement on that here
16:11:05 <astearns> s/??/as close to auto as we can/
16:11:08 <JoshT> ... we should only add the auto behaviour when there's a good reason
16:11:19 <CameronPsychpsyo> fwiw, I got confused by the spec wording on this while working on Ladybird once.
16:11:22 <JoshT> ... this allows margins to collapse as auto. it's only webkit that checks the computed value
16:11:37 <oriol> https://github.com/w3c/csswg-drafts/issues/12218
16:11:41 <JoshT> ... several impl seem to collapse margins like webkit but there are some cases quite non-sensical
16:11:47 <JoshT> ... explained in linked issue
16:11:53 <JoshT> ... I think Blink's model is better
16:12:11 <astearns> ack fantasai
16:12:11 <Zakim> fantasai, you wanted to distinguish what's obvious from spec terminology != what's obvious for authoring
16:12:12 <JoshT> ... even then it's only webkit behaving in this way. I think it should allow collapsing margins as auto
16:12:20 <astearns> q+
16:12:28 <JoshT> fantasai: so I want to make a distinction for what makes sense based on what's in the spec
16:12:43 <JoshT> ... the original reason for this behavuiur is that % are not resolvable
16:12:56 <JoshT> ... we just needed some term to hook onto this idea
16:13:06 <JoshT> ... would like to ask what will the author most likely expect to happen
16:13:23 <JoshT> ... if most obvious is to collapse margins with % heights, then we should align on that
16:13:25 <oriol> q+
16:13:29 <JoshT> ... if it's not, then we should do the other thing
16:13:29 <TabAtkins> I think my point is still just that this issue doesn't actually contain any proposals (but there's an *implied* proposal about margin collapsing, which has a proposed WPT change to match)
16:13:43 <JoshT> astearns: web compat is likely a good reason not to follow auto if impl are not following spec
16:13:56 <JoshT> ... but also, does anyone know what is the test case that anna added is checking
16:14:08 <ydaniv> s/anna/anne
16:14:18 <JoshT> oriol: i think originally came from a test cases I added
16:14:24 <JoshT> fantasai: test case about stretch keyword
16:14:38 <JoshT> ... in most cases, it's treated as implicit size and margins will not collapser
16:14:52 <JoshT> ... if it has a child, the margin will not collapse as it's not expected to match
16:15:08 <TabAtkins> Currently all browsers pass the test in its current form https://wpt.fyi/results/css/css-sizing/margin-collapse-with-indefinite-block-size-005.html?label=master&label=experimental&aligned
16:15:12 <JoshT> ... if the container that the stretched item is in has a height, we run into this issue of whether to collapse
16:15:20 <JoshT> ... for stretch, the size of the container could be resolved
16:15:38 <kurt> kurt has joined #css
16:15:43 <JoshT> ... but when you have explicit height, the margins collpse, and when you don't, the margins don't collapse
16:15:49 <JoshT> ... that's confusing
16:15:50 <astearns> ack oriol
16:15:54 <astearns> ack astearns
16:16:11 <JoshT> oriol: for author expectations, when the spec is checking this, it's making sure margins only collapse when they align
16:16:13 <TabAtkins> *Is* this issue specifically about the margin-collapse issue? Elika stated it was about several things.
16:16:26 <JoshT> ... so you can make the bottom margin of last item and parent collapse
16:16:36 <JoshT> ... if parent has explicit size, you can't guarantee that you can do that
16:16:41 <fantasai> It was an issue about "we have some wording that needs tightening up here". And the margin collapsing issue is the main one that we have identified.
16:16:57 <JoshT> ... if this case, a % behaves as auto for sizing purposes, then margin collapsing purposes is the same
16:17:10 <JoshT> ... I think it makes sense to allow margin collapsing in all cases
16:17:22 <JoshT> fantasai: if you pick 40px as the size of your box, we still don't collapse the content
16:17:34 <JoshT> oriol: true. earlier linked to issue about it.
16:17:47 <JoshT> ... but point is whether you guarantee it adapts to content
16:18:00 <JoshT> ... % behaves as auto always, so size will always ???? contents
16:18:08 <JoshT> fantasai: depends on where you use the box
16:18:38 <JoshT> ... if someone sizes margins and padding with some assumption about whether margins collapse and then put it in container with auto height, it may or may not collapse, it's confusing
16:18:45 <JoshT> ... could cause unexpected breakage
16:18:57 <JoshT> ... if you set it to stretch or 100%, you're expecting something different to happen
16:19:25 <JoshT> ... for behaviour to change depending on what you put it into, it's confusing. if you want the other bhaviour,. you can just ask for it
16:19:45 <JoshT> ... if you are expecting margins to collapse sometimes and not other times, that's not a winning thing
16:20:06 <JoshT> ... depending on the spacing you want, you'd have to compensate for the collapsing or not collapsing
16:20:28 <JoshT> astearns: as Ian and TabAtkins suggested, we can take this back to the issue with one concrete example
16:20:44 <JoshT> ... we can have an idea of what we want to resolve on before this comes back onto the agenda
16:20:56 <JoshT> github-bot, topic https://github.com/w3c/csswg-drafts/issues/11801
16:20:57 <github-bot> Topic: [css-navigation-1] Add pseudo-class selector to target the element that initiated the outgoing navigation
16:20:57 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11801
16:21:09 <JoshT> noamr: issue that was open for a while
16:21:19 <JoshT> ... we wanted to address with css-nav-1 spec
16:21:34 <JoshT> ... quite ready on it's own. to select a link that triggers a navigation
16:21:35 <dholbert> dholbert has joined #css
16:21:49 <JoshT> ... unlike active pseudo, it stays on
16:21:50 <fantasai> Like :active in IE5!
16:22:13 <JoshT> ... so we defined in css-nav-1 as trigger-link. we define exact processing model of when it starts and stops being active
16:22:26 <JoshT> ... we found about css-nav that it's a reflection of the Web Navigation API
16:22:34 <JoshT> ... has concept of source-element.
16:22:41 <JoshT> ... not sure if that was the best name
16:22:48 <JoshT> ... can be a link, a form or submit button
16:22:54 <TabAtkins> q+
16:22:58 <JoshT> ... things that trigger a navigation
16:22:58 <astearns> q+
16:23:14 <JoshT> ... trigger-link is both the source element and the link
16:23:18 <kbabbitt> q+
16:23:21 <JoshT> ... could be confusing otherwise with forms
16:23:32 <JoshT> ... could say we have a navigation trigger element that also includes forms
16:23:42 <JoshT> ... current case is a pseudo class called trigger-link
16:23:48 <JoshT> ... activated on link you click
16:23:54 <JoshT> ... stops when navigation is done
16:24:04 <kbabbitt> q-
16:24:07 <JoshT> ... when you swap to the new document
16:24:27 <JoshT> TabAtkins: echoing discussion, odd specialised just to links when there are forms doing nav
16:24:28 <astearns> ack TabAtkins
16:24:38 <JoshT> ... assuming more general pseudo class, this is just adding 'a'
16:24:41 <fantasai> +1
16:24:57 <JoshT> ... could we just let people use the tag name in the selector to say which they want to match on?
16:25:04 <CameronPsychpsyo> Don't image maps also have links in them?
16:25:19 <PaulG> web components and aria-* components will probably like to support this as well
16:25:21 <JoshT> noamr: not great in my opinion, but could be wrong. we can change that
16:25:43 <JoshT> TabAtkins: concern is just in general it's not great to encourage authors to use links when they should use a form
16:25:51 <fantasai> +1
16:25:54 <JoshT> ... if these touch both cases, they should work on both cases
16:25:55 <dbaron> CameronPsychpsyo, image maps have <area> elements these days -- HTML4 had a feature that allowed them to use <a> as well but it got removed in HTML5 due to only one browser implementing it.
16:26:17 <JoshT> astearns: have maybe terrible idea. if we need something different than active for the lifecycle, then maybe this could be a parameter on :active
16:26:23 <CameronPsychpsyo> Yes, but <area> can have an href to link to elsewhere when clicked.
16:26:25 <astearns> ack astearns
16:26:26 <ntim> ntim has joined #css
16:26:34 <JoshT> fantasai: had the same concerns as TabAtkins
16:26:44 <JoshT> ... think a more general definition is better
16:26:46 <ntim> present+
16:27:04 <JoshT> ... for more general name, could be navigation-source, connecting to the source term
16:27:08 <JoshT> noamr: sounds good to me
16:27:22 <JoshT> ... i was nervous about trigger because we also have nav trigger
16:27:36 <PaulG> navigation referrer?
16:27:42 <JoshT> bramus: but you can have source and destination so having source here could confusing
16:27:48 <JoshT> noamr: still related
16:28:00 <JoshT> fantasai: what happens if you have a link that navs to a different part of the page?
16:28:12 <JoshT> noamr: it will still activate and pseudo will still be active
16:28:23 <JoshT> ... as long as Navigation API is going, it will apply
16:28:29 <dbaron> I think (somewhat agreeing with Bramus) that some people might see the "source" as the page you're navigating from rather than the element that caused that page to navigate.
16:28:39 <JoshT> ... because it's very quick, effect might not be different from activ
16:28:54 <JoshT> fantasai: old versions of IE have more persistent versions of :active
16:28:56 <bramus> q?
16:29:04 <JoshT> noamr: will be active until animation is done
16:29:10 <JoshT> ... same with smooth scroll
16:29:17 <bramus> q+
16:29:20 <JoshT> ... as long as the spinner goes, this will also be active
16:29:25 <JoshT> fantasai: in general, a good idea
16:29:30 <astearns> ack fantasai
16:29:32 <astearns> ack bramus
16:29:45 <JoshT> bramus: hearing +1 on the ask for a broader selector
16:30:00 <JoshT> ... if we could have that, I'd be very happy as that was the original request
16:30:09 <JoshT> ... then you just prepend an element selector
16:30:30 <JoshT> ... for name, dbaron said he also agrees people might confuse source with source vs destination
16:30:53 <JoshT> ... suggested in issue :navigation-trigger to make it clear it's the element and not the 'from' page
16:31:10 <JoshT> fantasai: the source element API is already using that term so reflecting that makes sense
16:31:25 <JoshT> ... and you can't just select the page with a selector so there's no room for confusion here
16:31:43 <JoshT> noamr: we could just not use 'source' in other places and say 'from' in those nav to and from use cases
16:32:02 <JoshT> astearns: and the Navigation APi uses 'source' for this concept?
16:32:04 <JoshT> noamr: yes
16:32:16 <JoshT> astearns: any concerns about adding this regardless of the name?
16:32:43 <JoshT> ... given everyone seems OK with it, shall we give a provisional name of :navigation-source?
16:32:53 <JoshT> ... or :nav-source?
16:33:07 <JoshT> noamr: i like the shorter one because it makes it feel like an element
16:33:13 <PaulG> I still like referrer but it's harder to spell?
16:33:22 <JoshT> ... if we do something that is a navigation source, we can distinguish from a nav source
16:33:29 <JoshT> bramus: I'm leaning to full version
16:33:29 <romain> prefers to avoid abbreviations
16:33:44 <JoshT> fantasai: can we have nav-up, nav-down?
16:34:07 <JoshT> ... would be consistent with that and nav is shorter to write and we have precident
16:34:14 <rachelandrew> I prefer not abbreviating in this case
16:34:18 <JoshT> astearns: precedent in specs or implementations?
16:34:23 <TabAtkins> i do prefer abbreviating
16:34:39 <JoshT> florian: I recall that nav-up and nav-down are not interoperable
16:35:01 <JoshT> astearns: at least on IRC, people are on both sides
16:35:09 <JoshT> TabAtkins: and HTML spec has nav element
16:35:19 <ChrisL> happy with nav
16:35:24 <JoshT> astearns: resolve on adding :nav-source in short form?
16:35:36 <noamr> :navigation-source-trigger-element
16:35:40 <JoshT> fantasai: I'm ok with either or doing a Twitter poll
16:35:57 <ydaniv> +1  on short form
16:35:59 <TabAtkins> :navigation-starting-element
16:36:06 <CameronPsychpsyo> "source" or "src"?
16:36:08 <JoshT> PROPOSED: add :nav-source pseudo for this use case
16:36:16 <noamr> source. src feels like a URL of sorts
16:36:23 <TabAtkins> lol we spell out "source" everywhere else in css
16:36:32 <JoshT> RESOLVED: add :nav-source pseudo for this use case
16:36:37 <ntim> i'd rather abbreviate source than nav
16:36:43 <JoshT> people discuss src or source
16:36:44 <fantasai> PROPOSED: Add :nav-source to select element that initiates navigation (whether link or not)
16:36:45 <davidjmarland> sauce
16:36:55 <ntim> :navigation-src
16:37:08 <fantasai> RESOLVED: Applies not just to links
16:37:26 <JoshT> github-bot, topic https://github.com/w3c/csswg-drafts/issues/14062
16:37:27 <github-bot> Topic: [css-anchor-position-1] Add flip-self-inline/flip-self-block keywords
16:37:27 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/14062
16:37:46 <JoshT> astearns: Might be the shortest issue ever!
16:37:53 <TabAtkins> +1 to the keywords
16:38:03 <JoshT> fantasai: we have flip-inline and flip-block which use writing mode of the container
16:38:14 <JoshT> ... we have use cases to have the writing mode of the element itself
16:38:22 <JoshT> astearns: both self and the parent?
16:38:25 <JoshT> fantasai: yes
16:38:39 <JoshT> ... we should be consistent
16:38:51 <JoshT> ... and make them the keyword that you use for the custom select dropdown
16:39:02 <JoshT> astearns: any concerns?
16:39:17 <JoshT> PROPOSED: add flip-self-inline and flip-self-block
16:39:35 <JoshT> RESOLVED: add flip-self-inline and flip-self-block to position-try
16:39:40 <ntim> position-try-fallbacks
16:39:47 <fantasai> RESOLVED: Use these values for ::picker(select)
16:40:10 <JoshT> github-bot, topic https://github.com/w3c/csswg-drafts/issues/13853#issuecomment-4820636728
16:40:10 <github-bot> Topic: [web-animations] How/when do the "rangeStart/rangeEnd" attributes the Animation interface get evaluated
16:40:10 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13853
16:40:52 <JoshT> weinig: issue is that in the animations API in the JS API, there are places where you can set values
16:40:59 <JoshT> ...the setters have been defined to take strings
16:41:12 <JoshT> ... but the spec says 'parse this as...' and then a CSS property
16:41:37 <JoshT> ... in this case, the issue with range-start is that it takes what it should parse, and animation-range-end allows a length-percentage with any number
16:41:43 <JoshT> ... you can have length relative units
16:41:50 <JoshT> ... there's no spec on how to resolve those units
16:41:59 <JoshT> ... it's not happening during the style resolution
16:42:13 <JoshT> ... in other places, there's an API that takes a string and parses it as a CSS construct
16:42:29 <JoshT> ... normally we limit it to absolute units because we don't have a way to resolve relative units
16:42:57 <JoshT> ... in this bug it's about range-end, but we can take the same idea to other cases and limit to absolute length units and %. % are ok because they resolve later
16:43:01 <TabAtkins> I'm fine with this
16:43:05 <fantasai> sgtm
16:43:14 <dholbert> dholbert has joined #css
16:43:22 <JoshT> astearns: is it possible to define some way to resolve %?
16:43:34 <JoshT> weinig: % are not an issue. it's just relative units
16:43:46 <JoshT> astearns: so can we just pick something to resolve against like the root?
16:43:54 <JoshT> weinig: there are other options we could takw
16:44:00 <TabAtkins> q+
16:44:02 <JoshT> ... one is to treat it like media queries
16:44:18 <JoshT> ... say that relative units resolve against the initial style. could be different to the root
16:44:38 <JoshT> ... could say the units resolve against the target element of anim if it exists
16:44:48 <JoshT> ... then need to define what happens if target is null
16:44:57 <JoshT> ... and we need to pay the sync style resolution cost
16:45:11 <JoshT> ... or alt, we could define alternative time that these values get resolved against an element
16:45:16 <JoshT> ... i think they're all complicated
16:45:25 <JoshT> ... someone would need to figure out the tradeoffs
16:45:31 <JoshT> ... right now not implementable
16:45:43 <JoshT> ... want something implementable in a uniform way
16:46:07 <ydaniv> SGTM, until we define this properly
16:46:12 <JoshT> ... or maybe in future we'll have a generic way in JS to say 'given this element and unit, give me the computed px values'
16:46:19 <JoshT> ... someone in bug says this makes it useless
16:46:31 <JoshT> ... don't know if they were thinking if % weren't allowed
16:47:02 <JoshT> ydaniv: [that was me]. it is limiting, but it's OK to patch this now and spec it later
16:47:34 <JoshT> astearns: I agree and I'm fine, but if there is something that would be better for authors where we can arbitrarily pick an element without author choice, it might be better to do that than only have absolute units
16:47:52 <JoshT> ... if we do only absolute units now, we'll need an opt in to get the better behaviour
16:48:10 <JoshT> weinig: we can just do a parse error for relative units for now, and then not have a parse error in the future
16:48:10 <astearns> ack TabAtkins
16:48:19 <JoshT> TabAtkins: I agree with sam. don't want to resolve on root element
16:48:28 <JoshT> ... would rather make it parse-time invalid now
16:48:31 <fantasai> +1 to TabAtkins and weinig
16:48:44 <JoshT> weinig: my proposal is for both the string form and type CSS form
16:48:50 <TabAtkins> yeah there shoudln't be any difference between those two
16:48:59 <JoshT> ... you can do a typed value that is an em value, so we have to treat them the same here
16:49:53 <JoshT> PROPOSED: make it a parse error to set string values or typed CSSOM values that don't use absolute length units or percentages
16:50:53 <JoshT> weinig: one other clarificatio.n also precludes things like var, sibling-index() and anything that requires an element to resolve
16:51:04 <fantasai> sgtm
16:51:14 <fantasai> We can always relax restrictions once we figure out what's the best thing to do
16:51:14 <JoshT> ... but the implication is we're excluding anything that requires an element context
16:51:31 <JoshT> PROPOSED: make it a parse error to set string values or typed CSSOM values that require an element to resolve
16:51:40 <JoshT> RESOLVED: make it a parse error to set string values or typed CSSOM values that require an element to resolve
16:51:56 <JoshT> weinig: I've filed a bunch of issues like this. should I turn them all into a single issue that we can resolve on later?
16:52:04 <JoshT> ... or should we go through them one by one?
16:52:14 <JoshT> astearns: I'm fine with that if they're all basically the same decision
16:52:22 <JoshT> ... we can even make it an async proposal
16:52:52 <JoshT> github-bot, topic https://github.com/w3c/csswg-drafts/issues/13904
16:52:53 <github-bot> Topic: [css-view-transitions] [cssom] Inheritance of non-existing pseudo-elements.
16:52:53 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13904
16:53:19 <JoshT> TabAtkins: emilio pointed out that we have a WPT that expects a non-existant vt element to inherit from its non-existent parent
16:53:32 <JoshT> ... because vt pseudos aren't creating but you're asking for the computed style
16:53:52 <JoshT> ... emilio suggests that we inherit from the existing element rather than assuming a non-existent tree
16:54:10 <JoshT> ... the dev who did this had a crash and so he fixed it in a way and doesn't have opinions on which way it should go
16:54:15 <JoshT> ... I also agree
16:54:31 <JoshT> ... we probably should not be making assumptions about the state of a tree that doesn't exist
16:54:40 <JoshT> ... I suggest we take emilio 's suggestion
16:54:58 <JoshT> ... just say it's inheriting from the originating element
16:55:15 <bramus> sgtm
16:55:35 <JoshT> fantasai: so this is only while they don't exist? and then when we have a tree, do usual behaviour?
16:55:39 <JoshT> TabAtkins: yes?
16:55:44 <JoshT> s/yes?/yes/
16:56:00 <TabAtkins> el.gCS("::foo")
16:56:00 <JoshT> TabAtkins: and there is always in the query an originating element to look at
16:56:14 <JoshT> fantasai: there was a term for ultimate originating element
16:56:18 <JoshT> TabAtkins: yes
16:56:56 <JoshT> PROPOSED: non existing pseudo-elements are considered to inherit from their ultimate originating element if you query the computed style
16:57:19 <JoshT> astearns: any suggestions or objections?
16:57:28 <JoshT> RESOLVED: non existing pseudo-elements are considered to inherit from their ultimate originating element if you query the computed style
16:57:36 <JoshT> astearns: do we have any other situations like this?
16:57:55 <JoshT> TabAtkins: you can't ask for an element that might not exist. it's only pseudos where this can happen
16:58:00 <noamr> "A non-existent pseudo element falls in the forest. what style does it have?"
16:58:27 <JoshT> topic: end
17:00:24 <astearns> zakim, end meeting
17:00:24 <Zakim> As of this point the attendees have been ChrisL, JoshT, ydaniv, JohnJansen, rachelandrew, CameronPsychpsyo, hoch, vitorroriz, kbabbitt, bramus, kizu, masonf, noamr, alisonmaher,
17:00:27 <Zakim> ... davidjmarland, oriol, romain, fantasai, lea, PaulG, dbaron, ], dholbert, ntim
17:00:27 <Zakim> RRSAgent, please draft minutes v2
17:00:29 <RRSAgent> I have made the request to generate https://www.w3.org/2026/07/01-css-minutes.html Zakim
17:00:36 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
17:00:36 <Zakim> Zakim has left #css
17:29:26 <sbender> sbender has joined #css
19:16:23 <sbender_> sbender_ has joined #css
20:33:52 <sbender> sbender has joined #css
21:00:07 <github-bot> github-bot has joined #css