Set Ready For Review
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
This implementation is fairly complete, but I've opened https://github.com/whatwg/html/issues/11958 about one detail. I'd like the spec to change and will follow up with another CL and test if so.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
This implementation is fairly complete, but I've opened https://github.com/whatwg/html/issues/11958 about one detail. I'd like the spec to change and will follow up with another CL and test if so.
Oops, I forgot to upload my latest changes, doing that now.
PseudoStateChanged(CSSSelector::kPseudoStalled);There are several PseudoStateChanged() calls not exercised by tests (and code coverage check complaining). Could maybe have some more wpts for pseudo state changes?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Philip JägenstedtPerhaps mention which pseudo-classes?
Done
PseudoStateChanged(CSSSelector::kPseudoStalled);There are several PseudoStateChanged() calls not exercised by tests (and code coverage check complaining). Could maybe have some more wpts for pseudo state changes?
Yes, I'll try removing them one by one and seeing which don't fail any tests. Also the tests are failing on the bots but passed for me locally, so I need to investigate that.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
media code changes lgtm, but tests seem unhappy.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
return MatchesBufferingPseudo() && sent_stalled_event_;Thanks to https://github.com/whatwg/html/issues/12145 I realized that I should check `MatchesBufferingPseudo()` here and not just `sent_stalled_event_`. That makes the invalidation more complicated, however.
futhark@ do you have any general guidance for how precise invalidation needs to be? Is it worth carefully ensuring that `PseudoStateChanged()` is only called when it's really changed, or can one take the approach of calling it whenever it might have changed to reduce bookkeeping?
(Note that the tests are still wrong, so this CL isn't ready for review.)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
return MatchesBufferingPseudo() && sent_stalled_event_;Thanks to https://github.com/whatwg/html/issues/12145 I realized that I should check `MatchesBufferingPseudo()` here and not just `sent_stalled_event_`. That makes the invalidation more complicated, however.
futhark@ do you have any general guidance for how precise invalidation needs to be? Is it worth carefully ensuring that `PseudoStateChanged()` is only called when it's really changed, or can one take the approach of calling it whenever it might have changed to reduce bookkeeping?
(Note that the tests are still wrong, so this CL isn't ready for review.)
The style machinery assumes something changed when PseudoStateChanged() is called, so it depends on what the selectors involving the given pseudo class look like, the size of your DOM, and how often you invalidate.
Worst case, if your media element comes early in the pre-order traversal of your document, there are thousands of elements in your document, and it contains a selector such as: `video:playing ~ * * { ... }`, you are basically recomputing styles for thousands of elements for each style update after you call PseudoStateChanged().
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
return MatchesBufferingPseudo() && sent_stalled_event_;Rune LillesveenThanks to https://github.com/whatwg/html/issues/12145 I realized that I should check `MatchesBufferingPseudo()` here and not just `sent_stalled_event_`. That makes the invalidation more complicated, however.
futhark@ do you have any general guidance for how precise invalidation needs to be? Is it worth carefully ensuring that `PseudoStateChanged()` is only called when it's really changed, or can one take the approach of calling it whenever it might have changed to reduce bookkeeping?
(Note that the tests are still wrong, so this CL isn't ready for review.)
The style machinery assumes something changed when PseudoStateChanged() is called, so it depends on what the selectors involving the given pseudo class look like, the size of your DOM, and how often you invalidate.
Worst case, if your media element comes early in the pre-order traversal of your document, there are thousands of elements in your document, and it contains a selector such as: `video:playing ~ * * { ... }`, you are basically recomputing styles for thousands of elements for each style update after you call PseudoStateChanged().
Thanks, so it sounds like I should make some effort to only call `PseudoStateChanged()` when it did actually change, and not just invalidate whenever paused/readyState/networkState change.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |