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

That's true, but this feature is clobbering an existing userland solution that solves the problem better than the proposal on the table.

Most features aren't clobbering any existing userland solution; under the extensible web, most new features add some totally new capabilities, and if V1 hasn't added enough capabilities, maybe we can add them in later, but having partial capabilities earlier is worth it. Not so in this case.

This feature violates the norm to "first, do no harm."

If we're going to introduce a naming conflict, with syntax that's confusingly similar to a widely loved existing userland transpiled solution, then it had better be _worth it_. It shouldn't just be an 80% solution compared to userland; it ought to be actually _better_ than userland if we're going to incur these costs on the web community's behalf. People using the old userland thing should say "It's a pain that I have to upgrade, but I'm glad they introduced this new thing; this is way better than our hacked up solution. Let's abandon the userland approach in favor of the new standard."

And if it's not worth it in the current form, but we still want to move ahead with it anyway, then it ought to at least be forward compatible with a solution that actually is better than userland. We ought to know what that solution could look like, making sure that we won't have to break backwards compat when we all finally adopt V2 or V3 which actually solves these problems.

I'm sure that a good solution for `@import` can be devised at some point, but I'm skeptical that even a polyfill with no client-side JS can be prototyped for this approach.

First, do no harm.

-- 
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-520653673