Allow actual CSS strings?

[wmertens]

For DX, it would be nice to be able to directly copy CSS snippets, for example from the browser devtools, so it would be nice to have a helper function that converts actual CSS to ComplexCss:

style(css`
  color: red;
  background-color: white;
  &:hover {
    color: black;
  }
`)
// becomes
style({
  color: 'red',
  backgroundColor: 'white',
  '&:hover': {
    color: 'black',
  },
})

Is that desirable? What would the special properties like selectors and vars look like inside a template?

Looks like https://stylis.js.org could do it with a middleware

[wmertens]

extra benefit: you can transform classlists to selectors as part of the template transform instead of afterwards inside the object keys

[mattcompiles]

Personally, I'm not a fan of this being part of the core API. However I think it's nice to be able to convert from one to the other quickly. Someone has actually already built a CSS to VE converter btw: https://css-to-vanilla-extract.netlify.app/.

[astahmer]

this is great ! would it make sense to be mentioned somewhere in the docs, under an ecosystem section ?

[wmertens]

That convertor is nice but coming from styled-components it would still be nice to have the css syntax in the css.ts file.

@mattcompiles I've been playing with Stylis and I think I was able to make it. See this StackBlitz

I think this will work? I'm just not sure about converting classlists to selectors. When I encounter an interpolation in a selector, I check if it is a string of one or more words ending with 6 alphanumeric characters followed by digits separated by spaces. Is that always correct? I'd rather not have to dig into VE internals to grab the known identifiers.

Using my function, this css:

          // ignore me
          padding: 0.5em;
          border: thin solid var(${'--color-hint'});
          border-bottom: none;
          :focus {
            background: unsupported(123);
            background: gold;
          }
          @media screen and (min-width: 768px) {
            whatever: hello;
            :hover { color: green }
          }
          @media printer {
            // use up all the ink
            background-color: black
          }
          ${'header_header__1wihje60 oowjoq42'} + & {
            border-left: none;
          }
          @supports (display: grid) {
            display: grid;
          }

converts into

{
  "padding": "0.5em",
  "border": "thin solid var(--color-hint)",
  "border-bottom": "none",
  "selectors": {
    ":focus": {
      "background": [
        "unsupported(123)",
        "gold"
      ]
    },
    ".header_header__1wihje60+&": {
      "border-left": "none"
    }
  },
  "@media": {
    "screen and (min-width: 768px)": {
      "whatever": "hello",
      "selectors": {
        ":hover": {
          "color": "green"
        }
      }
    },
    "printer": {
      "background-color": "black"
    }
  },
  "@supports": {
    "(display: grid)": {
      "display": "grid"
    }
  }
}

Is that correct?
(actually I just realized I can leave the interpolations as is, right?)

[wmertens]

I released a library, probably there's some edge cases, but it works for me.
https://github.com/wmertens/qwik-styled-ve

It would be nice if #895 were merged 😀

[n8sabes]

@wmertens @mattcompiles This is high value, if not essential functionality from my perspective.

[wmertens]

It would be great if someone more knowledgeable about vanilla-extract could take a look at https://github.com/wmertens/qwik-styled-ve/blob/main/src/css.ts

Perhaps this could be included into VE? It's still 0 runtime...

[astahmer]

kinda related https://github.com/macaron-css/macaron

[wmertens]

So, is the css function from https://github.com/wmertens/styled-vanilla-extract/blob/main/README.md#css worthy for inclusion into vanilla-extract @mattcompiles?

[wmertens]

@mattcompiles It works nicely for me, and it's really not much code - would you be open to a PR that adds css template string support?

[karlhorky]

Hey @wmertens , cool that you built this! 🙌🚀

1st-class support would be the thing that would convert me to Vanilla Extract.

Using ordinary CSS in strings is so much better than the object syntax - so much more documentation and you can copy/paste. It's essential also for teaching beginners.

[dd-jonas]

Are there any updates on this? Looking for a new CSS solution, but the object syntax makes this cumbersome to write.

[mike-wheel]

@markdalgleish Do you have any thoughts on this?

[karlhorky]

Alternative Library

Looks like the new zero-runtime Panda CSS already implemented this feature!

• feat(extractor): support TaggedTemplateExpression chakra-ui/panda#786

Maybe a good reason to switch from Vanilla Extract over there 👍

[maranomynet]

Seems that they pose this as an either–or, an all–or–nothing choice for a project.

Being able to mix the two approaches seems like a more desirable feature.

[karlhorky]

Seems that they pose this as an either–or, an all–or–nothing choice for a project

Interesting, maybe you can show the quote + link that you found that suggests that? (haven't tried Panda CSS yet myself, and actually in the process of moving projects over to Tailwind CSS, which has since convinced me on adopting a minimal alternative to hand-written, real CSS)

[maranomynet]

I might be wrong, but that's how I understand this paragraph:

In styled-components, you can use both tagged template literals and object syntax to style components.

In Panda, you need to decide which syntax you want to use. Panda recommends using the object syntax, but provides a way to opt-in to tagged template literals.

https://panda-css.com/docs/migration/styled-components#installation-and-syntax

[maranomynet]

KISS workaround:

import { GlobalStyleRule, globalStyle, style } from '@vanilla-extract/css';

/** Adds free-form CSS as a globalStyle */
export const vanillaGlobal = (css: string) =>
  globalStyle('x', { x: `} ${css} x{x:` } as GlobalStyleRule);

/** Spread the return value into a style object, to inject free-form CSS properties */
export const vanillaProps = (css: string) =>
  ({ x: `; ${css}` } as GlobalStyleRule);

/** Returns a scoped cssClassName styled with free-form CSS */
export function vanillaClass(css: string): string;
export function vanillaClass(debugId: string, css: string): string;
export function vanillaClass(cssOrDebugId: string, css?: string): string {
  const debugId = css != null ? cssOrDebugId : undefined;
  css = css != null ? css : cssOrDebugId;
  return style(vanillaProps(css), debugId);
}

Usage:

import { style } from '@vanilla-extract/css';

export const page = style({
  borderTop: '1px solid blue',

  ...vanillaProps(`
    /* Plain CSS that's inject into the "page" style block */
    border-bottom: 1px solid red;
    color: ${theme.color.primary}; /* I can still use typesafe values */
    random-css-prop-normally-rejected-by-vanilla-extract: 'YOLO!';
  `)
});

export const myClass = vanillaClass('myClass', `
  background-color: #ccc;
  padding: .5em 1em;
`);

vanillaGlobal(`
  /* I'm free to write my own CSS!! */
  body {
    --fruit: 'banana!'
  }
`)

By adding the styled-components VSCode extension and writing a tiny tagged-template literal called css you can even get full CSS syntax-highlighting and Intellisense for your raw CSS strings.

</ducks-for-cover>

FAQ:

• Q: Is this hacky ?
  A: Yes. Yes it is.
• Q: Does it leave some gunk in the generated CSS ?
  A: The vanillaGlobal function leaves x{x:} (meaningless, safely-ignored style block) both before AND after the inserted CSS block — a total of 10 characters for each invocation. Meanwhile vanillaProps leaves x:; (meaningless rule) before the inserted CSS.
  This gunk should get removed during minification.
• Q: Isn't this "dangerous" ?
  A: Yes, obviously. You should probably rename these functions dangerous_vanillaGlobal, dangerous_vanillaProps, etc.
• Q: But, but, this doesn't convert the CSS into objects...?
  A: True, and that's exactly the point. Vanilla-extract supports an idealized, abstracted subset of all possible CSS, and sometimes your project needs to leverage advanced CSS features (new language features, nasty workarounds, etc.) that Vanilla-extract's sense of correctness won't accept. These functions allow solving those real-world problems, while still enjoying the benefits of using typesafe, featureful styling for everything else.

[maranomynet]

But seriously, I like vanilla-extract for being zero-runtime, mature with lots of nice integrations and tooling, type-safe by default, etc. etc.

What I don't like, is how there's no escape-hatch into plain/real CSS. It's either object-syntax or the highway.

With these functions I finally have no good reason not to like vanilla-extract. It's close to being "best of all worlds" for me now.

So, please, pretty please, don't "update" the library to prevent this hack. Let me (and possibly others too) enjoy this.

[brandonpittman]

If the goal is to write plain CSS, wouldn't a .css file be sufficient? I don't see the benefit of writing type-unsafe CSS strings in a Vanilla Extract file. Is this just to keep stuff in the same file? Or to do interpolation?

[maranomynet]

The style() function creates scoped classNames which can't be passed to separate .css files unless you set up a whole other CSS processor. Also to be able to use typesafe values in the template string.

As I see it this is about having an "escape hatch" into regular CSS, when you're willing to trade local type-safety for access to the full features and expressiveness of real CSS.