David Woolley wrote:
> Patrick Garies wrote:
> >
>
> > h1 { background: transparent url("image.png"); } @missing
> > resource("image.png") { /* missing is a synonym for disabled,
> > blocked, unsupported, malformed, inaccessible, incomplete, etc.
> > resources */ h1 { background-color: black; } }
>
> You would have to tie the h1 and @missing lines together, so that the
> @missing group is only obeyed if the h1 group would have won in the
> cascade.
>
> Note that this example is degenerate in that the only selector in the
> @missing block is h1, but that would have to be enforced, if one was
> to avoid other selectors being introduced that were incompatible with
> a subsequent, or !important, h1 rule that changed the background
> image to one that did exist.
Forgive me if I’m being dense, but I don’t really understand anything
that you just said.
… perhaps I wasn’t clear; the basic methodology is as follows: if the
resource (e.g., image.png) is missing, then the whole @missing at‐rule
is parsed as if the CSS within were normally within the style sheet
(without the at‐rule) and normal specificity rules apply. If the
resource is present, then the entire at‐rule is ignored.
So, if image.png is missing, then the following:
h1 { background: transparent url("image.png"); }
@missing resource("image.png") {
h1 { background-color: black; }
}
… is the same as the following:
h1 { background: transparent url("image.png"); }
h1 { background-color: black; }
Otherwise, it’s the same as:
h1 { background: transparent url("image.png"); }
Feel free to clear things up; if you were saying that a subsequent h1
rule (or a previous !important h1 rule) could override a previous (or a
subsequent) @missing h1 rule, you’re, of course, right, but then that
would simply be an authoring issue, rather than an issue with the proposal.
— Patrick Garies