Rename canvas container class
grischaerbe opened this issue · 13 comments
Thanks for your effort!
I'm playing around with svelte-cubed for an artistic project. My setup includes TailwindCSS. The actual canvas is wrapped in a div with a class container that is a default TailwindCSS class to contain content to breakpoint sizes.
Since TailwindCSS styles are applied globally and TailwindCSS being a rather dominant library that is hard to neglect renaming the container div class to something more specific would be great.
What do you suggest?
I'd argue container is so widely used for the 'main' element, you'll run into similar problems in the future.
Can't you just reproduce the Tailwind CSS class on your own?
This is exactly the reason why I would opt for a more specific container class name like svelte-cubed-container.
It really doesn't matter as long as it's specific enough that it's most likely not interfering with user space classes and libraries. container, wrapper and other generics are so widely used that I would avoid using them in the context of a library.
What drew me to svelte was its billing as cybernetically enhanced. I don't know what it means but it reminded me of Norbert Weiner, Shannon, Baudillard, etc -- which I dug.
As the canvas is so essential to a webXR app, naming it something unique could be an opp to further distinguish svelte cubed from other 3js frameworks.
How about something funky like "simulacrum"? A) the canvas is the medium of fantasy projection, and B) it is the fulcrum of the scene.
@grischaerbe Just for my understanding, why would tailwind get preference over svelte-cubed here? Isn't svelte-cubed also just a library? Why doesn't tailwind change its naming to tw-container or something?
I think the main problem here is tailwind itself, with its its liberal use of classes.
I have no experience with tailwind, but doesn't this solve it?
https://tailwindcss.com/docs/configuration#prefix
@sebbasim Of course TailwindCSS gets preference. If you pull it in, you want to use the provided styles, that is what TailwindCSS is about. Prefixing all classes (like @JackDra mentioned) should be the last resort.
But in essence you already answered that question: It's not about the preference of TailwindCSS in particular, but rather that this problem occurs within every codebase using a class called container.
It still puzzles me a bit, because the way tailwind names its classes so generically, I would think you'd get all kind of conflicts at some point, with any kind of codebase. So your proposed solution is that every other codebase should specifically name its css classes just so other users can pull in tailwind if they want to?
What about other consequences like best practice naming conventions for the 'other' codebases?
Why is prefixing a last resort?
Honestly, don't want to drag the discussion here, but I'm genuinely wondering :)
@sebbasim
Disclaimer: This is now about my experience and workflow.
In most of my projects using TailwindCSS I try to use as little "real" CSS (as in CSS in components, with classes, IDs and you-name-it) as possible and for me that is generally a successful approach. For me it feels a lot like you also don't want to mix inline styles with external styles. This also means that optimistically speaking there is no other CSS at play. Of course libraries sometimes bring their own CSS (as this library proofs) but they very rarely interfere with TailwindCSS classes. In fact, I never came across it until now. You could also argue that TailwindCSSs container class is a rather oddly named class as others are called px-4 or space-y-12 and I would agree.
Regarding your questions:
I'm not proposing to avoid TailwindCSS classes in general (although I guess it's a good approach to be as specific as possible and necessary and therefore avoiding naming a class container).
Prefixing is a last resort as my main pain point with TailwindCSS is the long lines of css classes. Prettier recently changed their handling of line breaks concerning class names with TailwindCSS in mind and I think it just got worse. Prefixing would mean even longer lines.
But again: the class name we're talking about here is so widely used that it's not about TailwindCSS and I don't understand why it's necessary to burn it in a library. What if I want to use it in a non-TailwindCSS context?
I don't see a problem in a standard Svelte context, since css would be component-scoped then.
Well if you go for a <Container> component with scoped CSS, you are right. Another totally valid approach is global CSS with commonly used classes like .container. 😉
Well if you go for a
<Container>component with scoped CSS, you are right. Another totally valid approach is global CSS with commonly used classes like.container. 😉
the global approach is my current setup too. super easy, consistent across all my pages with minimum fuss.
I hear you though @sebbasim, either side has validity. For this discussion though, I would add that svelte-cubed isn't aiming at the css, it's aiming at the graphics so by extension should prefix it's css. If not for tailwind then bootstrap and then the next biggest thing which comes along after that, all of which will raise the same issue here.
Why does the canvas need to be wrapped in the first place?
Seems like we should be able to choose how to wrap the canvas tag ourselves.
I believe you can 😅 I would encourage it