Built-in CSS-relative url()
assets
#1327
Replies: 4 comments 6 replies
-
Would it be possible to write one version of the CSS to the If so, we could keep the relative URLs in the |
Beta Was this translation helpful? Give feedback.
-
I’ll have to check on the reason why we’re using absolute URLs in CSS, but we switched JS imports to all-relative not too long ago for the same reasons. I agree relative URLs should probably be preferred for all assets. |
Beta Was this translation helpful? Give feedback.
-
Sorry if this is not completely related, but I am having trouble trying to use monaco-editor in my app because of a relative css url. Basically I import monaco-editor in my code
I mount my source in the dev server with:
Note that the reason I am mounting node_modules/manaco-editor/esm/vs is because there are js files in there that need to be served as webworkers, but in fact the ttf file in question does live under that tree. Now when I run my app it tries to fetch |
Beta Was this translation helpful? Give feedback.
-
I wonder if it would be possible to create an empty CSS stylesheet, then use https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleSheet/insertRule Would the inserted rule then use relative-URL assets relative to the CSS stylesheet? |
Beta Was this translation helpful? Give feedback.
-
Creating this discussion to gather thoughts & resources. Previously @FredKSchott suggested possibly making CSS-relative assets built in to snowpack.
As noted in that link, there's a snowpack plugin called snowpack-plugin-relative-css-urls that lets you keep your image assets and CSS together within the same component directories.
Some background
CSS normally allows relative images. It does so through a "baseURI" property--a read-only property that is set on link or style tags when CSS files are loaded by the browser. This allows a CSS file's internal
url()
references to refer to assets relative to the CSS file, NOT the path of the current page (i.e. the HTML file).When snowpack adds
*.css.proxy.js
files in place of*.css
files, it injects a style tag with the CSS corresponding to the.css
file into the page. Everything in these proxy CSS files works EXCEPT relativeurl()
paths, because there is no way to set the dynamically created style tag's baseURI.Without this additional information (the baseURI to resolve the url() references from) there is no "relative path" on the browser side that will consistently work--it would depend on whatever page the user is visiting whether the CSS works (BAD). So for snowpack, the URLs inside
url()
references must be absolute.The solution
The snowpack-plugin-relative-css-urls plugin's solution is to re-write relative-path URLs in CSS files to their absolute-path counterparts. So for example, this CSS in
src/ui/Button/Button.svelte
:becomes
when written to the snowpack build directory or served up by the snowpack dev server.
Remaining problems
When absolute-path URLs are written in CSS files like this, subsequent bundling has trouble. For example, rollup does not recognize these paths:
See KonnorRogers/snowpack-plugin-rollup-bundle#21 for more discussion on the rollup-specific aspect.
Are there any other clever ways to address this problem? Does there need to be a "pre-bundler" step in snowpack that massages these URLs back into relative URLs for rollup/webpack? It doesn't seem ideal to have to solve this problem in each downstream bundler.
See also
Beta Was this translation helpful? Give feedback.
All reactions