- From: dfabulich <notifications@github.com>
- Date: Tue, 13 Aug 2019 10:10:05 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/759/520922897@github.com>
> All-in-all I think this capability will be a huge boon to the userland solutions which will now have a standardized compile target. We already have a standardized compile target: HTML and CSS, with no client-side JS required. > • They are side-effectful. They all append a stylesheet to the main document. That's not a behavior we'd want in the JS module system where modules are by default side-effect free, unless code in them has a side-effect. I don't understand your point here. It seems like a tautology. Modules are side-effect free by default…unless they have a side effect. These modules certainly do have side effects, and that is part of their design, just like importing a module that declares a custom element. Your other points seem to emphasize that ICSS Modules won't stop working when this ships; I agree that they won't stop working. I never said they would. I said that the new thing would create incompatibility and confusion between two identical syntaxes with the same name ("CSS Modules"). I won't be able to mix-and-match CSS Modules with CSS Modules. If CSS Modules V1 solved all of the same problems of ICSS modules and more, then it might be worth paying that price, but it doesn't, so it isn't. We should only clobber ICSS modules if we have a solution that is so superior to ICSS modules that it would be worth switching to it. -- 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-520922897
Received on Tuesday, 13 August 2019 17:10:27 UTC