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
{{ message }}
Repository navigation
[css-cascade] When an import rule fails to load or has an unsatisfied condition, does the layer still count? #6776
@importurl(url-not-found.css) layer(A);
@importurl(sheet.css) layer(B) not all;
@importurl(sheet.css) layer(C) supports(display: invalid-value);
While these are valid but ineffective imports, do the layer declarations still count (and hence affect the global layer ordering)? The current spec seems unclear about it.
I suppose for conditional imports whose conditions evaluate to false, the layer declarations should not count, because nested @layer rules inside false media/supports rules do not count.
I'm unsure about imports that fail to load, though. We may count the layer for a stable global layer ordering, or do not counter the layer to be consistent with media/supports conditions. Either as a resolution will be fine for me.
changed the title [-][css-cascade] When an import rule fails to load or isn't enabled, does the layer still count?[/-][+][css-cascade] When an import rule fails to load or has an unsatisfied condition, does the layer still count?[/+]on Oct 28, 2021
The precise interleaving of layers and conditions in the import rule isn't specified, so we should be clearer about this, but I agree with @mirisuzanne on the details of how each case should work. The mental model should be that a layer is wrapped around the contents of the import (even if they're empty due to a load failure), and a condition is wrapped around the whole thing:
The CSS Working Group just discussed [css-cascade] When an import rule fails to load or has an unsatisfied condition, does the layer still count?, and agreed to the following:
RESOLVED: Accept proposal
RESOLVED: Republish css-cascade-5
The full IRC log of that discussion
<fantasai> Topic: [css-cascade] When an import rule fails to load or has an unsatisfied condition, does the layer still count?
<fantasai> github: https://github.com//issues/6776
<fantasai> miriam: A few questions in here
<fantasai> miriam: All related to establishing layers inside of an @import statement.
<fantasai> miriam: One question is what to do if the import fails
<fantasai> miriam: other question is what to do if the conditions of the import don't match
<fantasai> miriam: consensus in the thread was that we should conceptualize this to "layer is wrapped around contents of the import, even if empty due to failure, and condition is wrapped around the whole thing"
<fantasai> miriam: We added language to spec to express it that way
<fantasai> miriam: layer is still added to layer order if import fails
<fantasai> miriam: but not added if the conditions don't match
<fantasai> miriam: that matches the behavior of if you had import inside of layer inside of condition
<fantasai> miriam: wanted to check with WG if this is acceptable
<fantasai> jensimmons: Makes a lot of sense from authoring point of view
<fantasai> +1 from me
<fantasai> RESOLVED: Accept proposal
<fantasai> miriam: This allows us to republish
<fantasai> RESOLVED: Republish css-cascade-5
Activity
[-][css-cascade] When an import rule fails to load or isn't enabled, does the layer still count?[/-][+][css-cascade] When an import rule fails to load or has an unsatisfied condition, does the layer still count?[/+]mirisuzanne commentedon Oct 28, 2021
The way I understand the spec, we should already have implied answers to all of these, which we can clarify if we need to:
Ais established, but empty (stable layer order)BandCare not established since the global queries are falsetabatkins commentedon Oct 29, 2021
The precise interleaving of layers and conditions in the import rule isn't specified, so we should be clearer about this, but I agree with @mirisuzanne on the details of how each case should work. The mental model should be that a layer is wrapped around the contents of the import (even if they're empty due to a load failure), and a condition is wrapped around the whole thing:
[@layer] Ensure layer establishment behavior on failed/unmatched imports
[@layer] Ensure layer establishment behavior on failed/unmatched imports
[@layer] Ensure layer establishment behavior on failed/unmatched imports
[@layer] Ensure layer establishment behavior on failed/unmatched imports
Bug 1740613 [wpt PR 31586] - [@layer] Ensure layer establishment beha…
[css-cascade-5] Clarify the behavior of layer syntax in @import #6776
mirisuzanne commentedon Nov 16, 2021
Agenda+ to get this spec change approved by the group.
Bug 1740613 [wpt PR 31586] - [@layer] Ensure layer establishment beha…
css-meeting-bot commentedon Nov 17, 2021
The CSS Working Group just discussed
[css-cascade] When an import rule fails to load or has an unsatisfied condition, does the layer still count?, and agreed to the following:RESOLVED: Accept proposalRESOLVED: Republish css-cascade-5The full IRC log of that discussion
<fantasai> Topic: [css-cascade] When an import rule fails to load or has an unsatisfied condition, does the layer still count?<fantasai> github: https://github.com//issues/6776
<fantasai> miriam: A few questions in here
<fantasai> miriam: All related to establishing layers inside of an @import statement.
<fantasai> miriam: One question is what to do if the import fails
<fantasai> miriam: other question is what to do if the conditions of the import don't match
<fantasai> miriam: consensus in the thread was that we should conceptualize this to "layer is wrapped around contents of the import, even if empty due to failure, and condition is wrapped around the whole thing"
<fantasai> miriam: We added language to spec to express it that way
<fantasai> miriam: layer is still added to layer order if import fails
<fantasai> miriam: but not added if the conditions don't match
<fantasai> miriam: that matches the behavior of if you had import inside of layer inside of condition
<fantasai> miriam: wanted to check with WG if this is acceptable
<fantasai> jensimmons: Makes a lot of sense from authoring point of view
<fantasai> +1 from me
<fantasai> RESOLVED: Accept proposal
<fantasai> miriam: This allows us to republish
<fantasai> RESOLVED: Republish css-cascade-5
[@layer] Ensure layer establishment behavior on failed/unmatched imports
Bug 1740613 [wpt PR 31586] - [@layer] Ensure layer establishment beha…