Re: [w3c/webcomponents] CSS Modules (#759)

**Regarding the `import as` proposal:**

It doesn't belong to this particular discussion, but I think the question arises naturally when you're discussing about a way to import other things into JS. We (the webpack team) already had [a long discussion](https://github.com/webpack/webpack/issues/378) when we tried to streamline this with browserify. It's kind of limiting if the platform defines how these assets are imported. In the long run, I'd really appreciate if there was a way to import assets into JS while allowing the importer to define the *how*. Kudos to @AshleyScirra 👏 

**Regarding this proposal:**

However, it still makes sense to define a sensible default behavior for common things like importing CSS. It also helps us to get a better understanding of the domain and maybe also helps to speed up the development of these generic import proposals.

I really like @justinfagnani 's proposal because it doesn't introduce new concepts. It looks very consistent with other parts of the web components API, like the `shadowRoot`.

Speaking as an application developer, it would be *very* useful to have a way to reference CSS class names from JavaScript. This makes it easier for bundlers and other tools to statically analyze the usage of class names. It allows them to remove unused class names. I think this makes current CSS-in-JS solutions like [styled-components](https://www.styled-components.com/) and the [CSS modules project](https://github.com/css-modules/css-modules) so appealing: it just plays well with existing tools because it makes it statically analyzable.

**There is also a different approach:**

Instead of standardizing CSS module imports, we could also make the CSSOM better approachable from the JS-side. The [Constructable Stylesheet Objects](https://wicg.github.io/construct-stylesheets/index.html) proposal is a step in the right direction.

Consider we'd allow the developer to write code like this:

```js
import uuid from "uuid";
import {regularPadding} from "../styles/paddings.js";
import {regularMargin} from "../styles/margins.js";
import {modularScale} from "../styles/typography.js";

const hamsterImage = new URL("../hamsters.jpg", import.meta.url);

export const modal = `modal-${uuid}`;
export const header = `header-${uuid}`;

export default CSSStyleSheet.parse`
.${modal} {
    background-image: url(${hamsterImage});
    padding: ${regularPadding};
}

.${header} {
    font-size: ${modularScale(2)};
}

.${modal} > ${header}:not(:last-child) {
    margin-bottom: ${regularMargin};
}
`;
```

Inside the component, you'd do:

```js
import (LitElement, html} from "lit-element";
import styles, {modal, header} from "./styles.js";

class MyElement extends LitElement {
    constructor() {
        this.attachShadow({mode: open});
        this.shadowRoot.moreStyleSheets.push(styles); // push() doesn't actually exist yet
    }

    render() {
        return html`<section class=${modal}>
        <h1 class="${header}">
            This is a modal
        </h1>
    </section>`;
    }
}
```

You could also put everything into one file, leaving that decision up to the developer.

With that approach, we wouldn't need to standardize this and still had all the flexibility the ecosystem needs. Tools like bundlers are already able to analyze that code. They could even remove styles that are not used anymore (also this is a more complex operation with my example).

The developer could also decide to wrap the class names with a library:

```js
import className from "some-library";

export const modal = className("modal");
```

This allows the library to track all used class names during render. This is how other CSS-in-JS libraries enable developers to include the critical styles on server render. Of course, this approach has several caveats, but the point is that this is all solvable in userland without specification.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/759#issuecomment-416515836