"run the fullscreen rendering steps" and "run CSS animations and send events" do not actaully exist anywhere #707
Comments
This incorporates the monkey-patch from the intersection observer spec directly into HTML, per w3c/IntersectionObserver#94. As a drive-by while doing so, changed some nearby steps to link to the algorithms in [CSSOMVIEW], instead of pretending to be the defining instance of these terms. See also #707.
|
Does https://www.w3.org/Bugs/Public/show_bug.cgi?id=28001#c4 work for all rendering things? It seems @foolip implemented a single queue, but then rendering tasks cannot depend on other rendering tasks having happened. Happy to introduce "render tasks" if this approach works for folks. |
|
Note that the "animation frame task" code I worked on never landed, so that shouldn't shape the design. |
This incorporates the monkey-patch from the intersection observer spec directly into HTML, per w3c/IntersectionObserver#94. As a drive-by while doing so, changed some nearby steps to link to the algorithms in [CSSOMVIEW], instead of pretending to be the defining instance of these terms. See also #707.
|
I've now landed a concept of "animation frame task" in Blink that I intend to use for Fullscreen, to match the timing of "run the fullscreen rendering steps": What do you all think of introducing "queue an animation frame task"? I think going forward some events could also be done like that, as long as the order of "queue an animation frame task" calls themselves are in a predictable order the order of event dispatch should also stay reliable. |
Although HTML does not yet define animation frame tasks as used by Fullscreen, it does have "run the fullscreen rendering steps". That's the old hook, making the timing of these events relative to resize and animation frame callbacks unambiguous: https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model Spec issue: whatwg/html#707 document-exit-fullscreen-timing-manual.html consistently matches -expected.txt, with (accidentally) correct timing but no resize event. element-request-fullscreen-timing-manual.html usually matches -expected.txt, with incorrect timing, but can accidentally get the timing right and instead fail due to no resize event. Both are marked as flaky to be safe, and will be enabled in a coming CL. Note: This CL is also a test for the WPT export process. Firefox passes both fullscreechange event tests, but fails the fullscreenerror test. (Implementation preceded spec changes.) BUG=402376,672436 Review-Url: https://codereview.chromium.org/2564543002 Cr-Commit-Position: refs/heads/master@{#437283}
Although HTML does not yet define animation frame tasks as used by Fullscreen, it does have "run the fullscreen rendering steps". That's the old hook, making the timing of these events relative to resize and animation frame callbacks unambiguous: https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model Spec issue: whatwg/html#707 document-exit-fullscreen-timing-manual.html consistently matches -expected.txt, with (accidentally) correct timing but no resize event. element-request-fullscreen-timing-manual.html usually matches -expected.txt, with incorrect timing, but can accidentally get the timing right and instead fail due to no resize event. Both are marked as flaky to be safe, and will be enabled in a coming CL. Note: This CL is also a test for the WPT export process. Firefox passes both fullscreechange event tests, but fails the fullscreenerror test. (Implementation preceded spec changes.) BUG=402376,672436 Review-Url: https://codereview.chromium.org/2564543002 Cr-Commit-Position: refs/heads/master@{#437283}
Although HTML does not yet define animation frame tasks as used by Fullscreen, it does have "run the fullscreen rendering steps". That's the old hook, making the timing of these events relative to resize and animation frame callbacks unambiguous: https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model Spec issue: whatwg/html#707 document-exit-fullscreen-timing-manual.html consistently matches -expected.txt, with (accidentally) correct timing but no resize event. element-request-fullscreen-timing-manual.html usually matches -expected.txt, with incorrect timing, but can accidentally get the timing right and instead fail due to no resize event. Both are marked as flaky to be safe, and will be enabled in a coming CL. Note: This CL is also a test for the WPT export process. Firefox passes both fullscreechange event tests, but fails the fullscreenerror test. (Implementation preceded spec changes.) BUG=402376,672436 Review-Url: https://codereview.chromium.org/2564543002 Cr-Commit-Position: refs/heads/master@{#437283}
Although HTML does not yet define animation frame tasks as used by Fullscreen, it does have "run the fullscreen rendering steps". That's the old hook, making the timing of these events relative to resize and animation frame callbacks unambiguous: https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model Spec issue: whatwg/html#707 document-exit-fullscreen-timing-manual.html consistently matches -expected.txt, with (accidentally) correct timing but no resize event. element-request-fullscreen-timing-manual.html usually matches -expected.txt, with incorrect timing, but can accidentally get the timing right and instead fail due to no resize event. Both are marked as flaky to be safe, and will be enabled in a coming CL. Note: This CL is also a test for the WPT export process. Firefox passes both fullscreechange event tests, but fails the fullscreenerror test. (Implementation preceded spec changes.) BUG=402376,672436 Review-Url: https://codereview.chromium.org/2564543002 Cr-Commit-Position: refs/heads/master@{#437283}
Although HTML does not yet define animation frame tasks as used by Fullscreen, it does have "run the fullscreen rendering steps". That's the old hook, making the timing of these events relative to resize and animation frame callbacks unambiguous: https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model Spec issue: whatwg/html#707 document-exit-fullscreen-timing-manual.html consistently matches -expected.txt, with (accidentally) correct timing but no resize event. element-request-fullscreen-timing-manual.html usually matches -expected.txt, with incorrect timing, but can accidentally get the timing right and instead fail due to no resize event. Both are marked as flaky to be safe, and will be enabled in a coming CL. Note: This CL is also a test for the WPT export process. Firefox passes both fullscreechange event tests, but fails the fullscreenerror test. (Implementation preceded spec changes.) BUG=402376,672436 Review-Url: https://codereview.chromium.org/2564543002 Cr-Commit-Position: refs/heads/master@{#437283}
Although HTML does not yet define animation frame tasks as used by Fullscreen, it does have "run the fullscreen rendering steps". That's the old hook, making the timing of these events relative to resize and animation frame callbacks unambiguous: https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model Spec issue: whatwg/html#707 document-exit-fullscreen-timing-manual.html consistently matches -expected.txt, with (accidentally) correct timing but no resize event. element-request-fullscreen-timing-manual.html usually matches -expected.txt, with incorrect timing, but can accidentally get the timing right and instead fail due to no resize event. Both are marked as flaky to be safe, and will be enabled in a coming CL. Note: This CL is also a test for the WPT export process. Firefox passes both fullscreechange event tests, but fails the fullscreenerror test. (Implementation preceded spec changes.) BUG=402376,672436 Review-Url: https://codereview.chromium.org/2564543002 Cr-Commit-Position: refs/heads/master@{#437283}
Although HTML does not yet define animation frame tasks as used by Fullscreen, it does have "run the fullscreen rendering steps". That's the old hook, making the timing of these events relative to resize and animation frame callbacks unambiguous: https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model Spec issue: whatwg/html#707 document-exit-fullscreen-timing-manual.html consistently matches -expected.txt, with (accidentally) correct timing but no resize event. element-request-fullscreen-timing-manual.html usually matches -expected.txt, with incorrect timing, but can accidentally get the timing right and instead fail due to no resize event. Both are marked as flaky to be safe, and will be enabled in a coming CL. Note: This CL is also a test for the WPT export process. Firefox passes both fullscreechange event tests, but fails the fullscreenerror test. (Implementation preceded spec changes.) BUG=402376,672436 Review-Url: https://codereview.chromium.org/2564543002 Cr-Commit-Position: refs/heads/master@{#437283}
Although HTML does not yet define animation frame tasks as used by Fullscreen, it does have "run the fullscreen rendering steps". That's the old hook, making the timing of these events relative to resize and animation frame callbacks unambiguous: https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model Spec issue: whatwg/html#707 document-exit-fullscreen-timing-manual.html consistently matches -expected.txt, with (accidentally) correct timing but no resize event. element-request-fullscreen-timing-manual.html usually matches -expected.txt, with incorrect timing, but can accidentally get the timing right and instead fail due to no resize event. Both are marked as flaky to be safe, and will be enabled in a coming CL. Note: This CL is also a test for the WPT export process. Firefox passes both fullscreechange event tests, but fails the fullscreenerror test. (Implementation preceded spec changes.) BUG=402376,672436 Review-Url: https://codereview.chromium.org/2564543002 Cr-Commit-Position: refs/heads/master@{#437283}
Although HTML does not yet define animation frame tasks as used by Fullscreen, it does have "run the fullscreen rendering steps". That's the old hook, making the timing of these events relative to resize and animation frame callbacks unambiguous: https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model Spec issue: whatwg/html#707 document-exit-fullscreen-timing-manual.html consistently matches -expected.txt, with (accidentally) correct timing but no resize event. element-request-fullscreen-timing-manual.html usually matches -expected.txt, with incorrect timing, but can accidentally get the timing right and instead fail due to no resize event. Both are marked as flaky to be safe, and will be enabled in a coming CL. Note: This CL is also a test for the WPT export process. Firefox passes both fullscreechange event tests, but fails the fullscreenerror test. (Implementation preceded spec changes.) BUG=402376,672436 Review-Url: https://codereview.chromium.org/2564543002 Cr-Commit-Position: refs/heads/master@{#437283}
Although HTML does not yet define animation frame tasks as used by Fullscreen, it does have "run the fullscreen rendering steps". That's the old hook, making the timing of these events relative to resize and animation frame callbacks unambiguous: https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model Spec issue: whatwg/html#707 document-exit-fullscreen-timing-manual.html consistently matches -expected.txt, with (accidentally) correct timing but no resize event. element-request-fullscreen-timing-manual.html usually matches -expected.txt, with incorrect timing, but can accidentally get the timing right and instead fail due to no resize event. Both are marked as flaky to be safe, and will be enabled in a coming CL. Note: This CL is also a test for the WPT export process. Firefox passes both fullscreechange event tests, but fails the fullscreenerror test. (Implementation preceded spec changes.) BUG=402376,672436 Review-Url: https://codereview.chromium.org/2564543002 Cr-Commit-Position: refs/heads/master@{#437283}
Although HTML does not yet define animation frame tasks as used by Fullscreen, it does have "run the fullscreen rendering steps". That's the old hook, making the timing of these events relative to resize and animation frame callbacks unambiguous: https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model Spec issue: whatwg/html#707 document-exit-fullscreen-timing-manual.html consistently matches -expected.txt, with (accidentally) correct timing but no resize event. element-request-fullscreen-timing-manual.html usually matches -expected.txt, with incorrect timing, but can accidentally get the timing right and instead fail due to no resize event. Both are marked as flaky to be safe, and will be enabled in a coming CL. Note: This CL is also a test for the WPT export process. Firefox passes both fullscreechange event tests, but fails the fullscreenerror test. (Implementation preceded spec changes.) BUG=402376,672436 Review-Url: https://codereview.chromium.org/2564543002 Cr-Commit-Position: refs/heads/master@{#437283}
|
That sounds very reasonable to me! |
|
@foolip didn't we want some tasks to be done before others? E.g., resize before fullscreen or the other way around? Seems hard with a single queue. |
|
Yes, some order is important, so we can't just replace everything with "queue an animation frame task" and hope that it's preserved. For resize and fullscreenchange in particular, it could be that the spec (HTML?) that says "enqueue an animation frame task to update this and that and fire a resize event" then calls something in Fullscreen causing the request/exit algorithms to continue after the "resize viewport" steps. For events that are triggered by unrelated things (say network activity and battery level) I think it's reasonable that the order of those events within an animation frame task is unpredictable, same as any "queue a task to fire an event" for such cases. Practically speaking, do we having things beyond resize and fullscreenchange already known to have a "correct" order? |
|
Scrolling maybe? Why would network/battery not use the normal event loop? No need to synchronize those with 60Hz display. |
|
You're right, I just picked two things with no correlation. I guess all things that make sense to synchronize with animation frames are more likely to be correlated. For scroll events, I suppose their order relative to the input events that triggered them matters? Since other specs have to adopt "enqueue an animation frame task" I think we'll have to look at ordering in each case individually, but of course just by having the hook there's a risk that people use it wrong. But then people can already say vague things about animation frames that don't integrate with HTML's event loop at all. |
Other specifications (Fullscreen) should use this by saying "queue an animation frame task for /doc/ to ...". Fixes the fullscreen part of #707.
Introduced in whatwg/fullscreen#92. Fixes the fullscreen part of #707. Drive-by: re-wrap lines to 100 columns.
Matches whatwg/fullscreen#94. Fixes the fullscreen part of #707. Drive-by: re-wrap lines to 100 columns.
Matches whatwg/fullscreen#94. Fixes the fullscreen part of #707. Drive-by: re-wrap lines to 100 columns.
|
OK, so we fixed the fullscreen thing. What remains is that the spec references a nonexistant "run CSS animations and send events":
I tried to find some kind of processing model that fires these events in https://drafts.csswg.org/css-animations-1/, but I could not. Paging the editors of that spec for advice; it appears there's no normative requirement, either in HTML or in the Web Animations spec, which actually states that things must animate and that events must be fired? |
|
The second half of the "Timing model concepts" section describes the integration of Web Animations with this processing model but its somewhat placeholder text at this stage. Perhaps we could reword "run CSS animations and send events" to "update declarative animations and send animation events". Then we can refer back to that definition from Web Animations / CSS animations / CSS transitions. Long-term when CSS animations and transitions are speced in terms of Web Animations we can drop the "passing in now as the timestamp" part. |
|
That sounds great. Let me know if you're able to work on creating such a hook for us to link to, and I'll happily update HTML. |
|
I'll put together some spec text for this in the next few days. (It's a bit awkward because ultimately the spec text belongs in Web Animations even though Web Animations is not yet a normative reference for CSS Animations/Transitions.) |
|
@domenic I've added update animations and send events to Web Animations now so I suggest that might be a suitable place to link to. |
|
Note that today I moved the Web Animations ED into the csswg-drafts repository so the updated link is: https://drafts.csswg.org/web-animations-1/#update-animations-and-send-events (I've updated my previous comment too). |
|
And an unversioned link, i.e. just |
Matches whatwg/fullscreen#94. Fixes the fullscreen part of whatwg#707. Drive-by: re-wrap lines to 100 columns.
https://html.spec.whatwg.org/#run-the-fullscreen-rendering-steps
Fullscreen and Web Animations do not actually define these terms. This seems bad?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28001 may already cover this, for Fullscreen at least.
(Separately, I am changing the CSSOMVIEW steps to be links instead of
<dfn>s.)The text was updated successfully, but these errors were encountered: