arguments_ok = stream.AtEnd();
Steinar H GundersonWe don't need `arguments_ok`?
```suggestion
if (!steam.AtEnd()) {
ConsumeErroneousAtRule(stream, CSSAtRuleID::kCSSAtRuleApplyMixin);
return nullptr;
}
```
No, that won't consume the rest of the at rule, since we're still in the block guard?
// We need to resolve the argument in the context of this function,
// so that we can do type coercion on the resolved value before the call.
// In particular, we want any var() within the argument to be resolved
// in our context; e.g., --foo(var(--a)) should be our a, not foo's a
// (if that even exists).
//
// Note that if this expression comes from directly a function call,
// as in the example above (and if the return and argument types are the
// same), we will effectively do type parsing of exactly the same data
// twice. This is wasteful, and it's possible that we should do something
// about it if it proves to be a common case.
Steinar H GundersonThis comment does not make sense here.
Done
Steinar H GundersonWe should also test:
- That env(--custom) inside if() works.
- That env(--custom) inside a custom function does *not* resolve against the bindings of the applied mixin that made the function call. (I.e. your comment at line 1807 in style_cascade.cc.)
- That env(--custom) works in attr().
Added the two former, I thought I already had a test for the latter?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Code-Review | +1 |
arguments_ok = stream.AtEnd();
Steinar H GundersonWe don't need `arguments_ok`?
```suggestion
if (!steam.AtEnd()) {
ConsumeErroneousAtRule(stream, CSSAtRuleID::kCSSAtRuleApplyMixin);
return nullptr;
}
```
No, that won't consume the rest of the at rule, since we're still in the block guard?
My bad.
Steinar H GundersonWe should also test:
- That env(--custom) inside if() works.
- That env(--custom) inside a custom function does *not* resolve against the bindings of the applied mixin that made the function call. (I.e. your comment at line 1807 in style_cascade.cc.)
- That env(--custom) works in attr().
Added the two former, I thought I already had a test for the latter?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Implement mixin parameters.
Applying a mixin now instantiates a “custom @env binding”, and all
style rules that we create point back to that binding. (Bindings
can point back to parent bindings, if we are applying mixins within
mixins.) Like tree scopes, we send this pointer through the cascade
so that we know what values env() should look up into when we apply
the winning value. In other words, we substitute custom env() at
computed-value time, like all other similar functions.
This costs us a bit of extra RAM (~50 kB in a typical page),
but we haven't seen any regressions on the style perftest.
We generally follow the spec whenever it is clear, but there are some
unknowns involved; in particular, the spec isn't clear on what happens
if there are too few parameters and no defaults. We don't attempt
to support mixins (and thus also custom env resolving) together with
@keyframe, @function, @page and a number of other at-rules that would
cause edge cases.
This should also build a reasonable foundation for implementing @env
later, although the spec there is also a bit in flux.
We also don't have any devtools support.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
The WPT PR for this CL has been merged upstream! https://github.com/web-platform-tests/wpt/pull/54923
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |