Set Ready For Review
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
core/animation and core/css lgtm
Will this be useful in practice because applying @starting-style also to the end point of the interpolation will often effectively stop the interpolation from happening?
This is the backend CL to allow authors to force an element into its
starting style. It uses a probe that tracks which elements are forcedI think "force elements to always have @starting-style rules applied" is more accurate?
An element's "starting style" is the style that is calculated for the starting point of the interpolation. This change will apply @starting-style to all other styles too, right?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
# Ensures that the given node is in its starting-style state```suggestion
# Ensures that the given node is in its starting-style state.
```
# Boolean indidcating if this is on or off```suggestion
# Boolean indidcating if this is on or off.
```
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
core/animation and core/css lgtm
Will this be useful in practice because applying @starting-style also to the end point of the interpolation will often effectively stop the interpolation from happening?
Yes, this is to allow authors to debug the `@starting-style` styles in DevTools.
I am currently working on a Design Doc on how this would look, but the idea is authors can toggle this on and off. When on, they can manipulate the `@starting-style` styles to see what they are doing. They toggling it back off, the interpolation will run.
This is the backend CL to allow authors to force an element into its
starting style. It uses a probe that tracks which elements are forcedI think "force elements to always have @starting-style rules applied" is more accurate?
An element's "starting style" is the style that is calculated for the starting point of the interpolation. This change will apply @starting-style to all other styles too, right?
Good callout to more correctly word this. I have updated the description.
# Ensures that the given node is in its starting-style state```suggestion
# Ensures that the given node is in its starting-style state.
```
Done
```suggestion
# Boolean indidcating if this is on or off.
```
| 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. |
| Code-Review | +1 |
| 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. |
The build failed and mentioned I had to rebase. If y’all could +1 this again, that’d be great.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
The build failed and mentioned I had to rebase. If y’all could +1 this again, that’d be great.
| 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. |
mode_ != SelectorChecker::kResolvingStyle) &&Why are you re-introducing this check? The CL description doesn't state that you're reverting the behavior of always showing @starting-style rules as matched?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
mode_ != SelectorChecker::kResolvingStyle) &&Why are you re-introducing this check? The CL description doesn't state that you're reverting the behavior of always showing @starting-style rules as matched?
The idea is that these styles only need to be gathered when the author is actively inspecting + debugging the `@starting-style` rules from DevTools. They can (~ will be able to) to that by triggering a `forceStartingStyle` on the inspected element.
This indeed rolls back part of the previous CL that unconditionally gathered the `@starting-style` rules. By only conditionally collecting them, DevTools will only show those rules when the element has `forceStartingStyle` set to `true`.
Would you recommend to continue gathering the `@starting-style` rules by default, and have DevTools conditionally show them instead? A possible concern with that approach is that the traffic over CPD would include `@starting-style` rules for every inspected element, even when the author is not even inspecting that state.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
mode_ != SelectorChecker::kResolvingStyle) &&Bramus Van DammeWhy are you re-introducing this check? The CL description doesn't state that you're reverting the behavior of always showing @starting-style rules as matched?
The idea is that these styles only need to be gathered when the author is actively inspecting + debugging the `@starting-style` rules from DevTools. They can (~ will be able to) to that by triggering a `forceStartingStyle` on the inspected element.
This indeed rolls back part of the previous CL that unconditionally gathered the `@starting-style` rules. By only conditionally collecting them, DevTools will only show those rules when the element has `forceStartingStyle` set to `true`.
Would you recommend to continue gathering the `@starting-style` rules by default, and have DevTools conditionally show them instead? A possible concern with that approach is that the traffic over CPD would include `@starting-style` rules for every inspected element, even when the author is not even inspecting that state.
The idea is that these styles only need to be gathered when the author is actively inspecting + debugging the `@starting-style` rules from DevTools. They can (~ will be able to) to that by triggering a `forceStartingStyle` on the inspected element.
This indeed rolls back part of the previous CL that unconditionally gathered the `@starting-style` rules. By only conditionally collecting them, DevTools will only show those rules when the element has `forceStartingStyle` set to `true`.
Thn that should be called out in the commit message.
Would you recommend to continue gathering the `@starting-style` rules by default, and have DevTools conditionally show them instead? A possible concern with that approach is that the traffic over CPD would include `@starting-style` rules for every inspected element, even when the author is not even inspecting that state.
I just wanted to make sure that's the intent and that's also clear to the devtools reviewers here.
| 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. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
11 is the latest approved patch-set.
No files were changed between the latest approved patch-set and the submitted one.
Add forceStartingStyle command to DevTools
This is the backend CL to allow authors to force an element having its
`@starting-style` rules applied on top of all other styles.
It uses a probe that tracks which elements are forced into that state,
which is taken into account when collecting and applying styles.
This is a follow-up CL to [^1] which unconditionally collected
`@starting-style` rules. Gathering `@starting-style` rules now happens
conditionally again (effectively reverting part of that previous CL).
By conditionally collecting those rules, DevTools will only show them
when the element has `forceStartingStyle` set to `true`.
[^1]: https://chromium-review.googlesource.com/c/chromium/src/+/5916506
R=alexr...@chromium.org, fut...@chromium.org, pfa...@chromium.org
| 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. |