Bugs with selectors and multiple elements

[wesbos]

Great lib! A few issues and suggestions, all revolving around some valid CSS selectors.

First, I'd like to be able to specify something like this and have it available to all elements:

[data-card-variant="primary"] {
  background-color: green;
  color: white;
}

On it's own it generates nothing.

When there is a selector above it, it merges it:

button {
  border-radius: 1rem;
  &[data-variant="primary"] {
    color: white;
  }
}

[data-card-variant="primary"] {
  background-color: green;
  color: white;
}

Sticks them all on button:

interface Mist_button extends ReactHTMLProps<'button'> {
  'data-variant'?: 'primary'
  'data-card-variant'?: 'primary'
}

I tried a few different ways to select multiple elements.

Nothing is generated for for this:

[data-card-variant="primary"]:is(div, article, section) {
  color: white;
}

This one generates the interfaces for all elements, but only applies it to the last one:

*:is(div, article, section)[data-card-variant="primary"] {
  color: white;
}

interface Mist_div extends ReactHTMLProps<'div'> {
}

interface Mist_article extends ReactHTMLProps<'article'> {
}

interface Mist_section extends ReactHTMLProps<'section'> {
  'data-card-variant'?: 'primary'
}

As does this:

article,
div,
section {
  &[data-card-variant="primary"] {
    color: white;
  }
}

I did get this to work, but it's not very scalable:

div[data-card-variant="primary"],
article[data-card-variant="primary"],
section[data-card-variant="primary"] {
  color: white;
}

[juice49]

I ran into the same issue, and considered trying to add the following:

1. Better support for targeting multiple elements (e.g. using :is).
2. Support for bare selectors (e.g. [data-card-variant="primary"]) by augmenting the type of all elements. Something like this:

Input CSS

[data-card-variant="primary"] {
  background-color: green;
  color: white;
}

Output TypeScript

declare namespace React {
  interface HTMLAttributes {
    "data-card-variant"?: "primary";
  }
}

Not quite sure how viable these ideas are, or whether they conflict with the core principles of Mist. But they are certainly how I intuitively want to use the tool. I haven't had much time to work on a PR yet.

[typicode]

Hey,

First of all, thanks a lot for the review and this feedback. I must admit I've not considered doing it this way.

Basically, I considered how visual components are written and translated it to CSS (simplified example):

function Button(props) { return <button className={props...}>... }
function AnotherButton(props) { return <button className={props...}>...

button { &[data-props] { /* ... */ } }
button[data-component="anotherButton"] { &[data-props] { /* ... */ } }

The first tag[data-...] needs to be the component "name" then other [data-...] should be "props".

In this regard, you need to structure your CSS just like you would your React components which is familiar to devs but could be made more DRY in CSS.

This is a convention that has pros and cons. I'd like to keep it for the moment as it may be useful to have one to make it easier to build other features on top of it (goto definition for example #73).

I'm not sure to understand this use case:

[data-card-variant="primary"] {
  background-color: green;
  color: white;
}

If it's applied to all tags then, for example, <hr /> would get data-card-variant="primary" autocomplete in the code editor, which I'm unsure would be useful?

That said I'm always curious about better understanding how MistCSS is used and if there are things that could be improved.

[wesbos]

I think <hr /> is an example of where it wouldn't make sense, but if you consider something like a callout element might be a div, section, blockquote or aside.

Or a common use case I have is heading elements:

[data-heading="gradient-text"]:is(h1,h2,h3,h4,h5,h6) { ... } 

not a huge deal, but these kinds of papercuts are what cause people to use non-semantic elements and we end up with click handlers on divs