Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: native constructible stylesheets #30

Open
wants to merge 12 commits into
base: main
Choose a base branch
from
Open

Conversation

bennypowers
Copy link
Owner

Closes #29

@changeset-bot
Copy link

changeset-bot bot commented Nov 2, 2022

🦋 Changeset detected

Latest commit: d85ee52

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 4 packages
Name Type
esbuild-plugin-lit-css Minor
@pwrs/lit-css Minor
lit-css-loader Minor
rollup-plugin-lit-css Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@bennypowers
Copy link
Owner Author

cc @jrencz wdyt of this?

I'm not 100% convinced how good this works with import assertions. does this even make sense?

does this make any sense at all?

import style from './style.css' assert { type: 'css' };

./style.css:

export const sheet = new CSSStyleSheet();
sheet.replaceSync(`html {
  display: block;
}
`);
export default sheet;

@heyMP
Copy link

heyMP commented Nov 2, 2022

Instead of having js in a .css file would this not be preferable?

styles.css

html {
  display: block;
}

index.js

import style from './style.css' assert { type: 'css' };

export const sheet = new CSSStyleSheet();
sheet.replaceSync(style);
export default sheet;

@bennypowers
Copy link
Owner Author

that adds an extra import though

@heyMP
Copy link

heyMP commented Nov 2, 2022

I was thinking that this block would be injected below the import statement:

export const sheet = new CSSStyleSheet();
sheet.replaceSync(style);
export default sheet;

But I suppose that's probably not what you want. 🤔

@bennypowers
Copy link
Owner Author

you're right I'm not super jazzed by it 😉
This library was never meant to aim for perfect, it was always a "done is better than perfect" kind of joint. The idea from the start was to imitate the as-yet-unavailable native workflows, even if not in a byte-perfect way.

So I guess the question this PR is asking is "do we want to export native css style sheets in the manner of css modules, but import them without import assertions in the manner of css-in-js"?

@castastrophe
Copy link

I like Potter's suggestion here for syntax. JS in a CSS file will be a blocker for a lot of folks adopting something like this. Part of the original goal in allowing traditional CSS files and importing them into the web components was to allow front-end developers not experienced with JS to contribute & engage in the projects.

@bennypowers
Copy link
Owner Author

ok so maybe this PR is a bit too broad in scope

I think it should just be about exporting native constructible stylesheets, and questions about import assertions can be removed from the docs. then, as now, users could still choose to write .css.js, but docs will still recommend .css

would that make sense @heyMP @castastrophe

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CSS Modules / Import Assertions
3 participants