[css-contain-3] container-name string vs ident

https://drafts.csswg.org/css-contain-3/#container-name accepts either a string or a custom ident, with identical semantics. We should probably stick to one of the two. Given that this is a name that originates in css and is used in css, I don't think we have a particular need to accomodate for names that don't fit a custom ident, so I'd suggest dropping strings.

For other named at-rules:

@color-profile: <dashed-ident> | device-cmyk
@counter-style: <custom-ident>
@custom-media: <dashed-ident>
@custom-selector: <dashed-ident>
@font-palette-values: <custom-ident>
@keyframes: <custom-ident> | <string>
@layer: <ident> [ '.' <ident> ]*
@property: <dashed-ident>
@scroll-timeline: <custom-ident> or <string>

By accepting a string, we allow attribute patterns like:

[container-name] {
  container-name: attr(container-name);
}

I don't see that as a deal-breaker, but it does seem nice-to-have, and based on prior art?

It's still not implemented anywhere, but using css-values-4 syntax, you could achieve that without needing strings:

[container-name] {
  container-name: attr(container-name ident);
}

I would love to see browsers support the full attr() syntax. Failing that, I like the flexibility our current syntax provides. Either way, this probably needs to be settled, as browsers seem eager to start shipping.

Yeah, I'm fine with keeping it as it is right now (accepting both, with them living in the same namespace). It's not a pattern we'll want to continue for the indefinite future, but nothing is harmed, and some use-cases are helped, by allowing it right now.

living in the same namespace

That means any string that would match <custom-ident> when "ident-ified" by the computed-value process would need to be disallowed?

I'm not sure what you mean by that. I mean that foo and "foo" should represent the same container name.

Yeah. No wonder, that didn't make much sense. :-)

that would match <custom-ident>

Should have been "that would NOT match ...".

I'm just saying that as currently specified, container-name: "initial" would compute to container-name: initial. At first I thought that was what you meant with "living in the same namespace". Need to use "Computed value: as specified", or deal with it some other way.

We don't necessarily need to make "initial" invalid, but I think it would be a good idea, yeah. You can't construct a custom-ident with that value (unlike things like "1em" or "foo bar", which can be done with escapes).

I agree supporting both string and ident is not ideal in the long run. It's typically the type of thing that becomes a quirk on the web platform and small maintenance burden for the engine (which accumulate).

For the attr() use case, since vendors currently only implement attr() for ::before/::after atm, I would expect the generalization of attr() to also cover attr(container-name ident).

The CSS Working Group just discussed container name - string vs ident, and agreed to the following:

RESOLVED: Restrict container-name to just idents

The full IRC log of that discussion

<TabAtkins> Topic: container name - string vs ident
<TabAtkins> github: https://github.com//issues/6405
<TabAtkins> miriam: In the current spec we allow container names to be either a string or an ident.
<TabAtkins> miriam: Advantage of string is you can use attr() to take from the element and use it for a container name.
<TabAtkins> miriam: That could also be possible if browsers implement the extensions to attr() that let you specify the type, attr(foo ident)
<TabAtkins> miriam: Florian suggested just accepting ident would be easier
<astearns> ack fantasai
<TabAtkins> miriam: Don't have a strong opinion here. Like the flexibility, but would like browsers to implement attr() stuff
<TabAtkins> fantasai: Currently attr() is not only restricted to strings, but also just to the content property, so it'll require extensions regardless.
<bkardell_> kinda +1 to that
<TabAtkins> fantasai: So I think we can keep it ident-only, and when we extend attr() we can make sure it allows for idents as well.
<bkardell_> q+
<astearns> ack bkardell_
<TabAtkins> astearns: Not sure it follows we'd get attr() in this property and with 'ident' behavior at same time, but I suppose we'd have to either change attr() or change this property to allow strings.
<TabAtkins> bkardell_: +1 to fantasai about starting with ident.
<TabAtkins> bkardell_: I think attr() is a need in lots of use-cases way beyond this, feels bad to make an exception to solve one case.
<TabAtkins> q+
<astearns> ack TabAtkins
<Rossen_> q
<fantasai> TabAtkins: I think I'm the main defender of keeping string, but fantasai makes a good point that attr() isn't allowed anywhere at this point, so we'll fix it when we fix it, and I'm fine with ident for now
<TabAtkins> astearns: So hearing strong arguments for restricting to ident. Anyone wanna argue for strings?
<TabAtkins> astearns: Proposed resolution is to restrict to idents. We'll see if we need to add strings later, or if attr() is sufficient.
<bkardell_> s/ feels bad to make an exception to solve one case/ feels bad to make an exception to solve one case as a first option. It might be a thing we need to do, but it feels bad to start assuming that
<TabAtkins> RESOLVED: Restrict container-name to just idents

@container