[selectors] decide on :blank

Is :whitespace-only really that bad? It's a more niche case so longer names seem acceptable then? Or just decide on :blank and remove the issue marker, allowing implementations to remove the prefixed variant (if still feasible).

Is there a particular reason why :ws-only would be unacceptable? It contains what would be a new abbreviation (“ws”) in CSS, but the result is much pithier while remaining semantically unambiguous, from what I can tell.

In addition, though perhaps less importantly, :whitespace-only is inconsistent with the already-introduced white-space CSS property, which considers “white space” to be a two-word phrase.

(My apologies if this particular option has already been discussed; I could find no mention of “ws-only” in this GitHub repository, the www-style archives, or the web in general. I can only imagine the tedious bikeshedding that has been occurring for the past four-to-five years.)

Edit: I typed “ambiguous” instead of “unambiguous”.

Fwiw, there was also a discussion around maybe redefining :empty to allow white space, since that's what most people would expect it to be. The main question there would be Web-compat, I guess.

The Working Group just discussed decide on :blank.

The full IRC log of that discussion

<dael> Topic: decide on :blank
<dael> github: https://github.com//issues/1967
<dael> fantasai: We had an issue in the spec for name of :blank. It was a request to pick a name. There was a discussion in the past to redefine empty to allow whitepsace inside it.
<dael> fantasai: That's a Q for the WG. Question is do we want to drop :blank and have :empty allow for whitespace or do we want two descriptors? In the second case we need a name for the selector.
<dael> Rossen: Use case?
<dael> fantasai: Most of the time you're trying to pick something empty there's often white space in there. Currently if you try and select empty table cells but you didn't carefully close all tags an make sure there were no spaces then :empty doesn't work.
<dael> glazou: Another reason they're not completely empty is because if there's no content you don't have a frame to rendor and then cannot edit.
<dael> fantasai: There should be a frame
<dael> glazou: Not always.
<dael> glazou: It means we have tons of doc in the wild with whitespaces.
<bradk> :empty-ish
<dael> fantasai: Question is about the selector. We have :empty. We can say it also matches elemnents that contain whitespace. Or we can say it does not match when it has a whitespace in which cae we need another selector that matches to things with nothing or white space.
<Rossen> someone is typing loud
<dael> glazou: I favor the later.
<dael> dbaron: I think :empty has been around long enough that we would break if we changed the behavior.
<AmeliaBR> I liked :blank. But if we need to be more clear, :whitespace-only is as explicit as we can get.
<dael> florian: On the one hand I have a hard time thinking of use case to distinguish, but there is a compat concern and that's what should decide the issue.
<fantasai> AmeliaBR, it might not contain any though :)
<AmeliaBR> (Definitely don't change the current behavior of :empty. That could mess up use cases like using it to show a placeholder for a <div contenteditable>
<dael> astearns: Might be somewhat difficult to figure out web compat problems b/c it's likely code that is dealing with interaction.
<dael> glazou: Has MS commented?
<AmeliaBR> :empty-or-whitespace
<dael> Rossen: I'm interested to find out what hte webcompat is. I don't remember if we even impl :empty. I'd be surprised if there's too much interop
<dael> glazou: I was asking about the stats MS has online on props. Does it incl selectors? Do we have metrics?
<dael> glazou: On :empty usage
<dael> Rossen: I'll take a look at what the crawlers have seen. I'd be surprised if it's wildly used.
<dael> glazou: Me too.
<dael> astearns: Whether or not it's possible to redefile :empty is there a reason to have both?
<dael> Rossen: I'd be in favor of the simple way to only have :empty that fantasai desc
<bradk> :mostly-empty
<dael> astearns: Shall we need the issue as needs data?
<dael> fantasai: Yes
<dael> Rossen: Looking at CSS usage I don't see hits for :empty. fwiw there's nothing we find.
<dael> glazou: So nothing prevents us from redefining it?
<dael> Rossen: THat's my read. If anyone has data for the contrary I'm willing to take a look. On our end I don't see anything.
<dael> fantasai: To be clear the case that would break is if someone uses :empty and expects it not to select an element that includes whitespace.
<fantasai> s/whitespace/only whitespace/
<dael> Rossen: That sounds to me like a fringe case. This could be a toolability work around where an editor is carefully adding and removing and this is selecting only things not edited by a user yet. But this is an edge case. I'd say we should make the change.
<dael> glazou: Case where element is content:Editable and you wan tto make difference between entirely empty and whitespace is there.
<glazou> s/content:Editable/contenteditable
<dael> dbaron: [missed] someone tried to use :empty, it didn't work, they didn't remove it and then it suddenly matches.
<dael> Rossen: If we find those use cases let's discuss, but I don't see any usage.
<dael> astearns: Prop is redefine :empty to allow whitespace and to remove :blank
<dael> astearns: Obj?
<dael> glazou: I don't like it. I'd prefer preserve :empty and have a selector for both.
<dael> florian: You think there's a case for one or the other?
<dael> glazou: THen you can write a more coplex selector.
<dael> astearns: I thought you argued before where when you want a blank thing...
<dael> glazou: I was misunderstood. I want the two features to be able to handle sep.
<bradk> :empty(ws)
<dael> fantasai: The case where you only care about non-whitespace is the more common.
<AmeliaBR> Example of the contenteditable usecase, would be weird if it treated a space as empty: https://codepen.io/AmeliaBR/pen/QvMGmR?q=%3Aempty&limit=mine
<dael> dbaron: This doesn't feel like the kind of thing where we want to spend a lot of resources on testing for compat. Breaking changes are a lot of work
<dael> astearns: From the principle of less work, proposal is keep current definition of :empty and keep current definition of :blank and have people impl :blank if the empty with whitespace use case is useful.
<dael> dauwhe: Is there concern we have a blank pseudo class in pages?
<dael> astearns: Same syntax?
<dael> dauwhe: In a page context, but it's :blank. I think in an @rule
<dael> astearns: Does that @rule select paes with only whitespace?
<dael> dauwhe: Pages created by rendering engine that don't have content.
<fantasai> https://www.w3.org/TR/css-page/#blank-pseudo
<dael> florian: So it maches :empty not :blank
<dael> dauwhe: Yeah, although you can make master pages with content that match :blank
<dael> dauwhe: prob not confusing for most, but woth mentioning
<fantasai> :empty-ish
<dael> astearns: So an argument to change :blank name to :whitespace-only or something
<dael> astearns: First, would anyone obj to keeping :empty with current definition and havin a selector that means empty or whitespace.
<dael> florian: Not an obj, but I'm not sure keep things the way it is is really less work. People need to impl a new thing.
<dael> dbaron: But if we change empty people impl the new thing too.
<dael> astearns: Work we're avoiding is the web compat check.
<dael> Rossen: My position is if we're keeping :empty let's keep as-is. If we're changing lets do so completely and have something that's the superset. If we don't care about webcompat let's not. But if we keep :empty as is 'd oppose to change empty and have a selector that means something kinda like :empty
<dael> astearns: Yeah, I don't think that's on the table.
<dael> Rossen: THe last proposal I heard was change :empty
<dael> florian: No, fix empty to mean what blank means or get both.
<dael> fantasai: We have an empty cells prop for tables that behaves like :blank. It triggers when there's white space. So there's a comflict in meaning.
<dael> fantasai: I wouldn't obj to keeping things the way they are, but I would be annoyed because I've found the way :empty was defined to be annoying.
<dael> astearns: Two avenues and there are people that would obj or be unhappy with both.
<fantasai> https://www.w3.org/TR/CSS2/tables.html#empty-cells
<dael> Rossen: Do we go back to GH and see if we can argue more there?
<dael> fantasai: I'd like to talk with glazou more offline on his concerns.
<dael> astearns: Was there previous discussion on redefine empty?
<dael> fantasai: Yes, but nothing formal. When it was first defined I believe it was discussed and people were saying if there's a text node in the dom it's not empty, but that's not how people go about styling their pages.
<dael> astearns: I think we've had enough on the call. fantasai and glazou can discuss and summerize on GH.
<dael> dbaron: One other point is elements like :pre where whitespace is significant.
<astearns> https://lists.w3.org/Archives/Public/www-style/2017Nov/0018.html

Yeah, the white space only version would be far less niche than :empty is.

My preference is to make :empty into a functional notation, and if you leave off the parentheses it is the same as :empty(legacy) or whatever. Then you could have :empty() be the more useful version that ignores white space, and have other possible arguments to say whether non-breaking spaces, thin spaces, etc. are significant.

I suggest
:empty(strict) -- match elements with nothing inside
:empty() -- match elements that contain only '\s', '\t', '\n' or nothing
:empty(blank) -- match elements that contain nothing or '\s', '\t', '\n' or descendant elements that produce only whitespace, eg. <p></p>, <br/>, <pre> </pre>, etc...

OR

:blank(empty) -- match elements with nothing inside
:blank() -- match elements that contain only '\s', '\t', '\n' or nothing
:blank(children) -- match elements that contain nothing or '\s', '\t', '\n' or descendant elements that produce only whitespace, eg. <p></p>, <br/>, <pre> </pre>, etc...

To be clear, I'm adding Agenda+ back since while it was discussed, no conclusion was reached and it's nearly a year later now without a path forward for implementations.

@annevk

Thanks @annevk, totally lost track of this one.

Related issue: #1283

The CSS Working Group just discussed decide on :blank, and agreed to the following:

RESOLVED: :empty does cover whitespace

The full IRC log of that discussion

<dael> Topic: decide on :blank
<dael> github: https://github.com//issues/1967
<nigel> I don't follow why we don't use the same definitions for blank and empty as are in selectors §13.2 and 13.3
<dael> fantasai: The discussion was about...one of the problems with empty selector is it does not select elements iwth only whitespace. Those are fairly common. <li>enter<li> will auto close and have a line feed and therefore is not empty.
<dael> fantasai: Issue was can we have a selector that means actually empty.
<dael> fantasai: Last conversation was either add a second selector that means empty and ignore whitespace or redefine :empty where if it contains whitespace it's still empty
<dael> fantasai: Discussion on webcompat, weren't many instances of empty. Daniel wanted a distinction somehow. Point that empty-cells ignores whitepsace the same way we proposed to redefine :empty.
<dael> fantasai: After that discussion brad proposed making empty a functional psuedo class to have different kinds of empty. That's where we're at
<dael> Rossen_: What's the favored proposal in your PoV?
<bkardell_> q+
<dael> fantasai: Ideally :empty would look from the author propsective and ignore whitepsace. If need more options make it a functional pseudo class
<dael> bkardell_: Definion of :empty is so strict that I feel part of the ask is to lessen that strictness. I don't know that getting that wrong will be more helpful.
<TabAtkins> I agree that :empty's current definition is just plain too strict to be worthwhile. I bet we can loosen it by default, and don't need to make it controllable.
<dael> bkardell_: Example if it has a link tag or style tag would an author consider that empty? What about a hidden attribute? Comments are a different node type so they don't count. THis raises a lot of questions we should carefully consider or it'll be similarly disaoppinting.
<gregwhitworth> I agree with TabAtkins here. Probably a good default is not to include white space
<dael> bkardell_: How close can you come to what people want.
<dael> florian: Good idea to consider these things you've listed. Driving use case is indenting and self-closing tags. Just loosening to consider whitespace would pretty much over the use case
<dael> bkardell_: Lots of comments and articles about editors. Closing is one, but Daniel brought up last time an editor when you create something with nothing in it how to style that is tricky. Other blog posts looking for that. Other blog posts wanting more.
<TabAtkins> We cant' ignore <style>, unfortunately - you can display those! (and make them contenteditable, for live-editting of a stylesheet).
<dael> bkardell_: Not sure why we say the use case is that unless we're sure.
<TabAtkins> But yeah, ignoring whitespace-only text nodes seems A-OK
<dael> florian: Not sure I see the use case for a selector that only selects link elements.
<dael> florian: Why would you want to select these things specifically?
<dael> bkardell_: Not only thign swith link. Select something that from author standpoint thinks is empty. Functionally if you add something from an editor it may have content, but from the viewer/author prospective it's empty.
<dael> florian: I hear you but don't agree
<TabAtkins> You can display a <link> too...
<TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/
<TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6230
<dael> fantasai: A lot of these selectors won't work if you don't understand your markup. That's true for nth-child and only-child. THe structural selectors don't work with stray elemetns in the markup. That as a driving use case doesn't make a lot of sense. If you're in that world you need to put classes on. You can't use these without control on markup.
<dael> florian: As TabAtkins put in IRC you can display most of what you wrote.
<dael> fantasai: Def we can't change ":empty to solve that. We can't make things depend on styling. So where there's tags but no text if you style that it's very visible. From author view it does not look empty. It comes down to are you understanding your markup. If you're not the tree selctors can't help you. Can't write selectors that work based on styling of element.
<dael> fantasai: If a wysiwyg author thinks the thing is empty depends on what you see. We can only help authors in markup
<dael> bkardell_: Yes, I think what a lot of people want is not possible. Thinking through and making the least surprising thing seems good.
<dael> florian: I wonder about comments. Are they gone before we do selector parsing?
<dael> TabAtkins: They don't show in the dom tree that selectors see
<dael> florian: Only whitepsace means whitespace and comments
<dael> TabAtkins: And other nodes
<dael> florian: As long as it falls out
<dael> bkardell_: Empty clearly specifies that
<dael> fantasai: If our goal is not surprising [missed]
<dael> TabAtkins: Selector modal only sees syntax nodes. Other elements aren't seen by selectors.
<dael> florian: I think we circled around. Can we resolve on :empty also allowing whiespace?
<TabAtkins> s/syntax nodes/element and text nodes/
<dael> fantasai: sgtm
<TabAtkins> +1
<dael> Rossen_: Proposal is :empty does cover whitespace?
<dael> florian: Yep.
<dael> Rossen_: Other opinions?
<dael> Rossen_: Objections to :empty does cover whitespace?
<bkardell_> so to clarify
<dael> RESOLVED: :empty does cover whitespace
<bkardell_> lol
<bkardell_> nm
<dael> bkardell_: Wanted to clarify we're changing the existing definition of :empty?
<dael> florian: Yes.
<dael> bkardell_: Last WG there were concerns about that where someone left an :empty that was false as a test. No concerns on that?
<dael> fantasai: Last discussion I recall Rossen_ said he checked and didn't see enough use of :empty. Author mistakes or author intention it's possible someone put a stray :empty or the author put :empty and it didn't apply to every element due to whitespace. Not sure if this ould break more uses or fix more uses
<bkardell_> yes, me too, what fantasai said
<dael> florian: But it's rarely used anyway
<bkardell_> ok, no real objection then
<dael> Rossen_: And I just looked at the data since then and I don't see an uptick of usage. If there are different numbers we can revisit.
<dael> Rossen_: Anything else to resolve?

I really don't like the idea of a breaking change!

An example of a use-case this change would break: using :empty on a <div contenteditable></div> to set a style indicating that it hasn't been edited or show a placeholder message indicating that editing is possible (old demo of mine). It would be rather confusing if the author did edit the content but the placeholder didn't disappear.

The CSS Working Group just discussed [selectors] decide on :blank.

The full IRC log of that discussion

<dael> Topic: [selectors] decide on :blank
<Guest60> present-
<dael> github: https://github.com//issues/1967
<dael> fantasai: Previous discussion wanted to see if :empty can ignore whitespace. Currently if you have any whitespace it's not considered empty. Believed that was super confusing because usually whitespace goes away. Collected compat and lots of websites use empty
<dael> fantasai: Not seeing if anyone was using empty in a way that specifically expects whitespace to not match empty
<dael> fantasai: My take is more investigation on web compat would be good. Don't know if anyone else has opinions
<fantasai> s/Not seeing/But no one did a random sample to see/
<dael> astearns: chrishtr you commented?
<dael> chrishtr: Data we have so far is whitespace appears on 2% of page loads. Without a bunch more work we wouldn't be able to confidently change
<dael> fantasai: I didn't have the data. Is any way to create a random sample of some pages with the data and I can do a human look?
<dael> chrishtr: It's http archive which you can query. Have you used that?
<dael> fantasai: No
<dael> chrishtr: I'll point you to it offline
<dael> chrishtr: I don't have other context on this so I don't know how critical it is and if it's fine towait.
<dael> fantasai: I don't think it's urgent
<dael> astearns: Next step is analyze data?
<dael> fantasai: Yep

Implementing :empty per spec is a proposal for Interop 2023, see web-platform-tests/interop#180. However, the use counter already referenced in this thread is now at 2.5%. Careful analysis of a large-ish random sample of sites hitting the use counter would be needed to show that the risk is low enough.

@foolip

I think a simpler route would be to have four different selectors (two of which already exist), each clearly fulfilling a different purpose, which would also help to avoid any breaking changes for that 2.5% that @foolip (via @lilles) pointed out and also to attempt to be more future proof:

:empty – no children (no whitespace allowed)
:blank – empty value (for form fields and related elements)
being discussed here: Define :blank pseudo-class behavior whatwg/html#8451
:whitespace-only – no child element nodes or non-whitespace text nodes (whitespace allowed)
:text-only – no child element nodes (text and whitespace allowed)

Related notes:

:whitespace-only could be nearly identical in implementation to :empty with the slight difference of assessing trimmed contents rather than untrimmed contents.
:text-only is technically possible today (AFAICT) as a decorator using :not(:has(> *)) though there's likely a simpler way to actually implement this than as a decorator.

Pseudo selector	Decorator / implementation note
:empty	implementation stays as is, matches elements without any contents (whitespace will not match), spec is adjusted to exclude whitespace as allowed contents to match `:empty`
:blank	matches empty values as spec'd here and discussed here: https://github.com/whatwg/html/issues/8451
:whitespace-only	similar to `:empty` but assesses the element's trimmed contents rather than untrimmed to ignore whitespace when evaluating for emptiness
:text-only	decorator for `:not(:has(> *))` to match any elements without any child elements

This might be personal, but I find :whitespace-only and :text-only confusing.
It is not clear to me that these are related to :empty.

Something like:empty(allow-whitespace) or :empty(allow-text) makes it clear that we are matching some definition of "empty" while allowing/ignoring certain bits.

I do agree that all four features are relevant.

@romainmenke

@romainmenke I dig that! 🙌🏼

I think :empty() could be a pseudo selector with a single argument for any exceptions, that being allow-whitespace and allow-text, which would also leave the door open in case any more options were ever to be conceived.

The one odd-ball out would be :blank which I think can stay separate, as that's rather unrelated to the empty state and has more to do with the state of a form field's value. It's a little deeper than that, but we go into that in the link I mentioned before re :blank.

The argument that :empty without including whitespace (the old spec) is confusing should be rephrased as "More than 50% of developers that have not read the documentation for :empty assumes that it includes whitespace"

...if that statement is false, then changing :empty to include whitespace would increase confusion among developers instead of decrease it. Does anyone actually have statistics for this, or is it only "many" devs found it confusing - which doesn't prove that including whitespace would decrease confusion - it just proves that :empty was poorly named?

In a made-up sample of new web developers, let say that 25% assume :empty include whitespace, 25% are unsure / no strong expectation, and 50% assume it does not include whitespace. If so then changing :empty to include whitespace would in fact double the confusion instead of improve things. Did I miss the part where solid statistics were presented?

The :blank pseudo-class would significantly streamline dynamic form calculations, for example in educational contexts. It helps developers easily identify empty or non-empty input fields in CSS and JavaScript. For instance, in this Stack Overflow post, a teacher needs to calculate student averages based on test scores, but only for fields that have been filled (since students may skip optional tests).

Currently, developers must rely on JavaScript event listeners to manually track input changes and count non-empty fields. This approach is cumbersome. With :blank, a one-liner like:

document.querySelectorAll("input:not(:blank)").length

could dynamically determine the divisor for averages, eliminating the need for hardcoded values and reducing complexity.

This use case highlights the practical importance of :blank for forms requiring conditional logic based on user input. Its implementation would not only benefit educators but also improve form handling in surveys, assessments, and other interactive applications.

Proposed Action: Prioritize the implementation and standardization of :blank to address real-world scenarios like this. Broader browser support would empower developers to build more robust and maintainable solutions with simple, elegant approaches.

@annevk

To agree with @annevk's original sentiment here, I think we need to decide on a direction for :whitespace-only vs. :blank and move forward. This is a rather crucial feature for developers. Current workarounds largely rely on build tools to strip all whitespace to permit using the current implementation of :empty.

I agree with @Fast-Nick's point that changing the current implementation would be more confusing, not to mention that it would introduce a breaking change (Don’t Break The Web).

However, I think most developers don't have a use case for :empty outside of what :whitespace-only provides, so this would solve those cases.

Developers set up their apps working a specific way, so having them suddenly switch when already live and functional could be annoying, but if this is a risk the CSSWG is willing to run, I believe that it would be net good long-term. We'll likely be writing :empty for decades to come, and having one API for that feature might be best, though I've argued against that in the past.

I've set up a few apps with this :empty vs. with-whitespace distinction, which I would have to refactor now, but those are edge cases at best. If this is obstructing development, I think browsers should move forward in implementing this the way the CSSWG resolved to above.

Apologies for maybe commenting in a place where I don't belong? (I was looking to see if a :blank selector existed in draft and wound up here.)

Is the intent for this to match any general elements that have no content (eg, <span></span>) or interactive controls that have no content (eg, <input value=""> and <textarea></textarea> but not <span></span>)? The draft spec says it's for interactive controls but some comments in this thread seem to be implying the idea is ":empty except whitespace nodes don't count"

Anyhow, I don't have a strong feeling about whether we need the :empty only-whitespace variant but I would absolutely use the :blank for form controls thing to improve the usability of a data collection system where I can't change markup but can inject CSS.

(As an aside: Thank you to everyone who has made CSS so much better over the years. :has. I cannot sing its praises enough.)

Is the intent for this to match any general elements that have no content (eg, <span></span>) or interactive controls that have no content (eg, <input value=""> and <textarea></textarea> but not <span></span>)? The draft spec says it's for interactive controls but some comments in this thread seem to be implying the idea is ":empty except whitespace nodes don't count"

This is my understanding, going off of Selectors Level 4:

If you're talking about :blank, it is intended to specifically target elements that accept user input, but do not currently have any user-entered data (so input.defaultValue and input.value are both empty strings). Currently, I believe this is only achievable if the developer includes a placeholder and uses :placeholder-shown, which is simply not possible with some elements that accept input (e.g. date inputs, file inputs, select, etc.), as they don't support the placeholder attribute.

If you're talking about :empty, it's intended to select any element with zero child nodes. Current implementations include whitespace text nodes when considering :empty, though that is out of spec. So:
<span></span> Will always get selected by :empty, but
<span> </span> Will not be selected by :empty with current implementations (but should be).

Blocks with only a newline will also be ignored, which is where the problem with :empty really arises in my opinion.
<span> </span>
Using :not(:has(*)) would select the empty element above, but I can't imagine that's incredibly efficient.

Updating :empty to ignore whitespace would definitely make it more useful. I use PHP frequently in my work, and not being able to include whitespace within an element can be a nightmare for readability. The spec addresses this issue, but implementations have failed to do so thus far. I can understand this to an extent if there is a significant number of websites using it, but I don't see it often (if ever).

I do believe there is a place for :blank, and I do feel it is distinct enough from :empty that the two can coexist. I agree that :blank should be for form control elements. :empty seems to be more intended for container elements (paper is blank, a bucket is empty).

At least one issue I can foresee is any element with the contenteditable attribute, since it accepts user input. Would it be considered :blank, :empty, or possibly even both or neither?

Is this issue still in a needs-more-data holding pattern?

@EricBMoreno

@EricBMoreno
:not(:has(*)) would also select all elements which contain only text nodes (even non‑whitespace ones, or any other non‑Element nodes), in addition to matching all of :empty.

Navigation Menu

Repository navigation

[selectors] decide on :blank #1967

47 remaining items

Related notes:

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[selectors] decide on :blank #1967

Description

Activity

js-choi commented on Nov 30, 2017

fantasai commented on Dec 4, 2017

css-meeting-bot commented on Dec 20, 2017

bradkemper commented on Dec 20, 2017

whileloopa commented on Sep 21, 2018

annevk commented on Sep 22, 2018

fantasai commented on Sep 26, 2018

fantasai commented on Sep 26, 2018

css-meeting-bot commented on Sep 26, 2018

AmeliaBR commented on Sep 26, 2018

47 remaining items

css-meeting-bot commented on Oct 7, 2020

foolip commented on Nov 1, 2022

brandonmcconnell commented on Nov 1, 2022

Related notes:

romainmenke commented on Nov 1, 2022

brandonmcconnell commented on Nov 1, 2022

Fast-Nick commented on Feb 7, 2024

MortezaMirmojarabian commented on Feb 13, 2025

brandonmcconnell commented on Feb 13, 2025

sandstrom commented on May 19, 2025

njvack commented on Oct 22, 2025

EricBMoreno commented on Oct 23, 2025

svgeesus commented on Jun 27, 2026

ExE-Boss commented on Jun 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions