Repository navigation
[css-cascade-4] [css-values-4] [css-fonts-4] [css-font-loading] Further issues with URLs and fetching #12288
Description
Apologies, I should have tried actually implementing the PR'ed changes before approving them. I've found a few other issues, I think this is everything though:
fetch an @import now refers to parsedUrl which isn't set anywhere.
The fetch response does have a URL attached, is that safe to use here?
Previously fetch a style resource would return an error if parsing the URL failed, now it just returns:
- Let parsedUrl be the result of resolving urlValue given cssRuleOrDeclaration. If that failed, return.
Also in fetch a style resource, sheet is no longer defined, but it's used in steps 6 and 7. For now I've just duplicated steps 1-3 from style resource base URL.
@trflynn89 had noticed that what is now step 7 of fetch a style resource needs to also set an initiator type when the resource isn't associated with a stylesheet, so that it's observable through a PerformanceObserver. So Ladybird had some ad-hoc code for setting that to "script" when there is no sheet. Relevant Ladybird PR. (Pinging you Tim because this isn't an area I'm familiar with.)
Perhaps most awkwardly, fetch a font makes the assumption that there is a @font rule as the source, but it may be from a FontFace instead.
- Using the value of font face’s [[Urls]] slot, attempt to load a font as defined in [CSS-FONTS-3], as if it was the value of a @font-face rule’s src descriptor.
Activity
WIP: Update to latest spec for CSS URL/Fetch algorithms
cdoublev commentedon Oct 1, 2025
If I may also raise these two points, which seem confusing to me, in this issue...
"... from the href attribute of
rule" would be more explicit about the URL data type received in fetch a style resource. Since it is read-only, I assume implementers store it as a string.(edit) I am wrong, because it should be the internal representation of the parsed
rule's URL here, because browsers get rid of what is around<url>inurl(<url> <url-modifier>*)when serializingCSSImportRule.href, which is mildly defined as "the URL specified by the@importat-rule", whereas<url-modifier>s are needed in fetch a style resource."If the Constructor document of
parentStylesheetis in quirks mode" seems more correct, because the DOM spec says a document can be in quirks mode, while I cannot find any CSS spec that states that a style sheet can be in quirks mode.cdoublev commentedon Oct 18, 2025
The following two statements are incorrect (see the edit further below).
In fetch an
@import, the steps (2/5/6) that requires evaluating ifresponseis [not] CORS-same-origin are confusing sinceresponseis CORS-same-origin if its type is eitherbasic,cors, ordefault, and my understanding is thatresponsetype is alwaysopaquesince the request mode is alwaysno-cors.This is consistent with Chrome and Firefox not giving access to the
.cssRulesof a same-origin@import-ed style sheet. This access depends on the origin flag, which is set at step 6 ifresponseis CORS-same-origin.(edit)
Fetching a same-origin resource with
no-corsactually returns abasicresponse and so is CORS-same-origin.Now
responsenot being CORS-same-origin is expected to have two effects:@importstyle sheet is not loaded ifContent-Typeis nottext/cssand the document is not in quirks mode@importstyle sheet.cssRulesis not allowedHowever, browsers seem to load a cross-origin
@importstyle sheet regardless of the conditions in 1 (I may have tested this incorrectly), and Firefox does not conform to 2 when the URL was ultimately redirected to a same-origin URL, whereas this is tested on WPT based on discussions and consensus between browser implementers.My second statement regarding browsers not allowing access to the
.cssRulesof a same-origin@import-ed stylesheet was biased because it was imported from my local file system, which I assume is always considered as cross-origin.I am sorry for the confusions.
WIP: Update to latest spec for CSS URL/Fetch algorithms