Custom scoped CSS namespace

[theprojectsomething]

Currently an .astro-XXXX is attached to elements for scoping purposes. The astro- namespace is a hardcoded value.

Minor (and exceptionally pedantic) nitpick, but it would be great to be able to customise the namespace. At a stretch, it would mean less information leaked about the underlying site (so security - unlike most other frameworks Astro can potentially hold server logic), but mainly it's just because it's nice to have full control over your output. No disrespect to the project!

@FredKSchott mentioned that he'd discussed migrating scoping concerns from a class to an attribute, post v1.0 (his example):

- <div class="astro-123456 my-class">
+ <div class="my-class" data-component-id="123456">

The above would go someway to solving the problem, though not all the way (unless data-component-id is a standard ns). But not an easy solution there - it will always be obfuscation. Regards the attribute, it could be worth considering Vue's approach, which is to store the hash in the attribute itself (not the attribute value). A full solution along these lines - with ns customisation - could look like:

<!-- with a custom namespace supplied (customisation / prevent clashes) -->
<div data-custom-ns-123456>
<!-- and without -->
<div data-123456>

Cheers!

[FredKSchott]

Thanks for kicking this off! I'm +1 on moving scoped CSS out of the class and into an attribute.

I think I'm less on board with making this customizable (mainly because of the complexity to support it) but if we named it something abstract like data-component-id="xxx" or data-cid-xxx then I think the need to customize would be way less.

[theprojectsomething]

Cheers! Agreed on the complexity vs need. Question - is the hash used outside of CSS-land? If not, customisation could be something outsourced to (Vite / Rollup) plugin land.

[matthewp]

I think I'm +1 on allowing customization of the name. This seems equivalent to being able to customize build filenames via rollup config (entryFileNames, chunkFileNames, manualChunks, etc). And this wouldn't be hard to implement, it's just a function that takes a hash and returns a class name.

I'd be open to moving to from class names to attributes but would want to understand more the problems it solves. One i suppose is that it lets you as the user completely own your classes and probably makes things slightly easier in Astro proper.

[theprojectsomething]

Thanks for the consideration @matthewp. Regards attributes over class names, there don't seem to be any practical concerns (e.g. specificity), so it seems like it comes down to semantics and preference.

Semantically, the current setup seems correct. The hash isn't unique to a component instance (it's repeated all over the shop). It's also not storing anything.

From a user-land perspective, preference might deem that classes are a bit too personal; whereas data attributes remain inconspicuous, less likely to get noticed / flagged.

And to be fair things are compounded by the fact that the class names are repeated on every element within a component. This looks like a mistake. If I saw this (outside of present context) I'd assume the author didn't understand what they where doing 🙂 Is this a convention?¹

Footnotes

1. Vue does the same but seems like for most cases a :where ancestor (at component level only) would suffice to scope/target child elements. Edge cases abound? ↩

[ken0x0a]

About implementation.
How about just use an environment variable (e.g.: ASTRO_CSS_PREFIX=your_prefered_prefix npx astro dev)?
It's really simple & super easy to implement.

[stormitornado]

I would suggest to generate class names from files paths, like path__to__file__localClassName, at least as an option.
It make sense in case, for example, when you generate static for subsequent backend integration with php, python (yes, it's my case :) ).

[thomas-callahan-collibra]

Changing the class name would be nice to have -- "astro-" isn't that long, but if I know my code doesn't have to worry about conflicts with anything else, changing it to just "a-" still provides full scoping and saves 4 characters per rules. In the relatively simple project I'm working on now, "astro" appears 179 times in the output CSS, so 179 * 4 = 716 bytes. Not huge, but something.

[Princesseuh]

It would not save you 716 bytes, after gzip it would save you like 6 bytes.

[eterv]

In my opinion, using a hardcoded value of astro- kills customizability. When I open the browser developer tools, I see astro- in the class of each tag.

Is this the intention of the astro team to let everyone know that it's made with Astro? (a kind of watermark?)
I believe the broad-minded Astro team wouldn't have done that.
I don't know which way is best, but this needs to be fixed. I think the config needs to be modified to allow for user-defined values rather than hardcoded values.

By the way, I could use customized values in Svelte.

// vite.config.ts
...
svelte({
  compilerOptions: {
    cssHash: ({ css, hash }) => `custom1-${hash(css)}`,
  },
}),
...

Obviously Astro is structured differently, but I'm sure there is a way :)
I'm hoping it will be resolved quickly.

[matthewp]

Hey, just chiming in to say that it's not as a watermark, purely as a namespacing mechanism. Definitely open to customizing via config API or something, as you show here with Svelte.

[Ownedunkn]

Right? Nothing beats neat HTML.

[maddsua]

Currently an .astro-XXXX is attached to elements for scoping purposes. The astro- namespace is a hardcoded value.

Minor (and exceptionally pedantic) nitpick, but it would be great to be able to customise the namespace. At a stretch, it would mean less information leaked about the underlying site (so security - unlike most other frameworks Astro can potentially hold server logic), but mainly it's just because it's nice to have full control over your output. No disrespect to the project!

@FredKSchott mentioned that he'd discussed migrating scoping concerns from a class to an attribute, post v1.0 (his example):

- <div class="astro-123456 my-class">
+ <div class="my-class" data-component-id="123456">

The above would go someway to solving the problem, though not all the way (unless data-component-id is a standard ns). But not an easy solution there - it will always be obfuscation. Regards the attribute, it could be worth considering Vue's approach, which is to store the hash in the attribute itself (not the attribute value). A full solution along these lines - with ns customisation - could look like:

<!-- with a custom namespace supplied (customisation / prevent clashes) -->
<div data-custom-ns-123456>
<!-- and without -->
<div data-123456>

Cheers!

I don't see how changing scope names would benefit "security through obscurity", considering that you're still gonna have <astro-island> all over the page.