GitHub - gnat/css-scope-inline: 🌘 Scope your inline style tags in pure vanilla CSS! Only 16 lines. No build. No dependencies. (original) (raw)

🌘 CSS Scope Inline

(Art by shahabalizadeh)

Why does this exist?

You want an easy inline vanilla CSS experience without Tailwind CSS.
Hate creating unique class names over.. and over.. to use once.
You want to co-locate your styles for ⚡️ Locality of Behavior (LoB)
You wish this would work in <style> tags.
Want all CSS features: Nesting, animations. Get scoped @keyframes!
You wish @media queries were shorter for responsive design.
Only 16 lines. No build step. No dependencies.
Pairs well with htmx and Surreal
Want fewer layers, less complexity. Are aware of the cargo cult. ✈️

✨ Want to also scope your <script> tags? See our companion project Surreal

👁️ How does it look?

I'm blue

See the Live Example! Then view source.

🌘 How does it work?

This uses MutationObserver to monitor the DOM, and the moment a <style> tag is seen, it scopes the styles to whatever the parent element is. No flashing or popping.

This method also leaves your existing styles untouched, allowing you to mix and match at your leisure.

🎁 Install

✂️ copy + 📋 paste the snippet into <script> in your <head>

Or, 📥 download into your project, and add <script src="script.js"></script> in your <head>

Or, 🌐 CDN: <script src="https://cdn.jsdelivr.net/gh/gnat/css-scope-inline@main/script.js"></script>

🤔 Why consider this over Tailwind CSS?

Use whatever you'd like, but there's a few advantages with this approach over Tailwind, Twind, UnoCSS:

No repeated styles on child elements (..no @apply, no [&>thing] on each style).
No repeated prefixes for media queries, hover, focus, etc.
No visual noise on every <div>. Use a local <style> per group.
Share syntax between local and external styles. It's just CSS.
Regain your "inspect, play with styles, paste" workflow in your web browser!
No suffering from lost syntax highlighting on properties and units.
No high risk of eventually requiring a build step.
No chance of deprecations. 16 lines is infinitely maintainable.
No suffering from FOUC (a flash of unstyled content).
Zero friction movement of styles between inline and .css files. Just replace me
No special tooling or plugins to install.

⚡ Workflow Tips

Flat, 1 selector per line can be very short like Tailwind. See the examples.
Use just plain CSS variables in your design system.
Use the short @media queries for responsive design.
- Mobile First (flow: above breakpoint): 🟢 None (xs) sm md lg xl xx 🏁
- Desktop First (flow: below breakpoint): 🏁 xs- sm- md- lg- xl- 🟢 None (xx)
- 🟢 = No breakpoint. Default. See the Live Example!
- Based on Tailwind breakpoints. We use xx not 2xl to not break CSS highlighters.
- Unlike Tailwind, you can nest your @media styles!
Positional selectors may be easier using div[n1] for <div n1> instead of div:nth-child(1)
Try tools like- Auto complete styles: VSCode or Sublime

👁️ CSS Scope Inline vs Tailwind CSS Showdowns

Basics

Tailwind verbosity goes up with more child elements.

red

green

yellow

blue

green

red

green

yellow

blue

green

CSS variables and child elements

At first glance, Tailwind Example 2 looks very promising! Exciting ...but:

🔴 Every child style requires an explicit selector.
- Tailwinds' shorthand advantages sadly disappear.
- Any more child styles added in Tailwind will become longer than vanilla CSS.
- This limited example is the best case scenario for Tailwind.
🔴 Not visible on github: no highlighting for properties and units begins to be painful.

    <!-- Tailwind Example 1 -->
    <div class="mx-2 my-4">
        <div><a href="#" class="block py-2 px-3 my-2 bg-[--color-1] rounded-lg text-center hover:bg-[--color-1-active] hover:text-white">Home</a></div>
        <div><a href="#" class="block py-2 px-3 my-2 bg-[--color-1] rounded-lg text-center hover:bg-[--color-1-active] hover:text-white">Team</a></div>
        <div><a href="#" class="block py-2 px-3 my-2 bg-[--color-1] rounded-lg text-center hover:bg-[--color-1-active] hover:text-white">Profile</a></div>
        <div><a href="#" class="block py-2 px-3 my-2 bg-[--color-1] rounded-lg text-center hover:bg-[--color-1-active] hover:text-white">Settings</a></div>
        <div><a href="#" class="block py-2 px-3 my-2 bg-[--color-1] rounded-lg text-center hover:bg-[--color-1-active] hover:text-white">Log Out</a></div>
    </div>

    <!-- Tailwind Example 2 -->
    <div class="mx-2 my-4
        [&_div_a]:block [&_div_a]:py-2 [&_div_a]:px-3 [&_div_a]:my-2 [&_div_a]:bg-[--color-1] [&_div_a]:rounded-lg [&_div_a]:text-center
        [&_div_a:hover]:bg-[--color-1-active] [&_div_a:hover]:text-white">
        <div><a href="#">Home</a></div>
        <div><a href="#">Team</a></div>
        <div><a href="#">Profile</a></div>
        <div><a href="#">Settings</a></div>
        <div><a href="#">Log Out</a></div>
    </div>
</body>

🔎 Technical FAQ

Why do you use querySelectorAll() and not just process the MutationObserver results directly?
- This was indeed the original design; it will work well up until you begin recieving subtrees (ex: DOM swaps with htmx, ajax, jquery, etc.) which requires walking all subtree elements to ensure we do not miss a <style>. This unfortunately involves re-scanning thousands of repeated elements. This is why querySelectorAll() ends up the performance (and simplicity) winner.