Script Loader: Do not normalize absolute-paths in `_wp_normalize_relative_css_links()`.

[scholdstrom]

Currently _wp_normalize_relative_css_links() normalizes all non-absolute URLs regardless if it's a relative-path or an absolute-path. The normalization should only happen for relative-paths (paths without a leading /) and not for absolute paths.

See ​RFC1808, Section 4, Step 4 and since it's against this RFC I'll classify this as a bug but it could just as likely be classified as a feature.

Currently using an absolute path would normalize the URL like this

-'p {background:url( "/image0.svg" );}'
+'p {background:url( "/wp-content/themes/test//image0.svg" );}'

Theme developers referencing urls in CSS would always use relative links so that hostname isn't fixed at build time. At the moment theme developers wanting to support wp_maybe_inline_styles() have to use relative paths and would not be able to set a base path for assets with ​Webpack publicPah option. I believe this is required for using webpack lazy loaded chunks.

I do believe this is more commonly used by agencies building websites.

• ​Sage
• ​10up-toolkit
• ​GitHub wide search

Currently _wp_normalize_relative_css_links() normalizes all non-absolute URLs regardless if it's a relative-path or an absolute-path. The normalization should only happen for relative-paths (paths without a leading /) and not for absolute paths.

Trac ticket: https://core.trac.wordpress.org/ticket/61909

[SergeyBiryukov]

In 58932:

Script Loader: Do not normalize absolute paths in inline block styles CSS.

_wp_normalize_relative_css_links() used to normalize all non-absolute URLs regardless of whether it's a relative path or an absolute path. The normalization should only happen for relative paths (paths without a leading /) and not for absolute paths.

Reference: ​RFC 1808, Section 4, Step 4.

Follow-up to [52036], [52695], [52754], [55658], [55669].

Props scholdstrom.
Fixes #61909.

Thanks for the PR! Merged in r58932.