You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So i like the proposed ability. However, i'm unclear how the proposal impacts development vs production.
In development you most likely have a folder with:
my-custom-element.js
my-custom-element.css
And you would have import styles from './my-custom-element.css' with { type: 'css' }; in my-custom-element.js. So this is a relative path.
How do you get from this relative path to an absolute path as shown in the specifier attribute in the proposal? Do we need new tooling where the custom element is "compiled" to HTML that uses <template shadowrootmode="open"> and convert the relative paths to absolute paths?
The text was updated successfully, but these errors were encountered:
I think the idea would be that whatever tooling you'd be using to emit my-custom-element.js shadowRoot declaratively would also process and emit the styling in the proposed format.
So i like the proposed ability. However, i'm unclear how the proposal impacts development vs production.
In development you most likely have a folder with:
And you would have
import styles from './my-custom-element.css' with { type: 'css' };
inmy-custom-element.js
. So this is a relative path.How do you get from this relative path to an absolute path as shown in the
specifier
attribute in the proposal? Do we need new tooling where the custom element is "compiled" to HTML that uses<template shadowrootmode="open">
and convert the relative paths to absolute paths?The text was updated successfully, but these errors were encountered: