-
Notifications
You must be signed in to change notification settings - Fork 707
[scroll-animations] ScrollTimeline
constructor has contradictory IDL and prose
#11340
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Cc @flackr, @kevers-google and @andruud. |
Note that the Web IDL spec says:
|
To match the WPT test, I believe that:
That way implementations could distinguish between the three cases outlined above. |
Upon closer inspection, the IDL constructor definition seems fine because So I think the only required change is to update the spec text as I wrote just above. I'll make a PR to that effect. |
…` should default to the document's scrolling element https://bugs.webkit.org/show_bug.cgi?id=284360 rdar://141206809 Reviewed by NOBODY (OOPS!). The specification for the `ScrollTimeline` constructor specifies [0] that "the scrollingElement of the Document associated with the Window that is the current global object" should be used if a source is not explicitly set via the `options` parameter. Note that the wording of the spec at the time of writing is not clear on this topic but the IDL definition as well as the relevant WPT test (scroll-animations/scroll-timelines/constructor.html, fixed by this patch) clearly identify the expected behavior. An issue [1] was filed to address this. [0] https://drafts.csswg.org/scroll-animations-1/#dom-scrolltimeline-scrolltimeline [1] w3c/csswg-drafts#11340 * LayoutTests/imported/w3c/web-platform-tests/scroll-animations/scroll-timelines/constructor-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/scroll-animations/scroll-timelines/source-quirks-mode-expected.txt: * Source/WebCore/animation/ScrollTimeline.cpp: (WebCore::ScrollTimeline::create): (WebCore::ScrollTimeline::ScrollTimeline): * Source/WebCore/animation/ScrollTimeline.h: (WebCore::ScrollTimeline::create): (WebCore::ScrollTimeline::ScrollTimeline): Deleted. * Source/WebCore/animation/ScrollTimeline.idl: * Source/WebCore/animation/ScrollTimelineOptions.h:
…` should default to the document's scrolling element https://bugs.webkit.org/show_bug.cgi?id=284360 rdar://141206809 Reviewed by NOBODY (OOPS!). The specification for the `ScrollTimeline` constructor specifies [0] that "the scrollingElement of the Document associated with the Window that is the current global object" should be used if a source is not explicitly set via the `options` parameter. Note that the wording of the spec at the time of writing is not clear on this topic but the IDL definition as well as the relevant WPT test (scroll-animations/scroll-timelines/constructor.html, fixed by this patch) clearly identify the expected behavior. An issue [1] was filed to address this. In order to be able to distinguish a `null` value explicitly set on the `source` property of the `options` parameter, we change `ScrollTimelineOptions.h` to use an `std::optional<>` to wrap the `RefPtr<Element>`. We also need to pass the document to the `ScrollTimeline` constructor to be able to get at the scrolling element. [0] https://drafts.csswg.org/scroll-animations-1/#dom-scrolltimeline-scrolltimeline [1] w3c/csswg-drafts#11340 * LayoutTests/imported/w3c/web-platform-tests/scroll-animations/scroll-timelines/constructor-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/scroll-animations/scroll-timelines/source-quirks-mode-expected.txt: * Source/WebCore/animation/ScrollTimeline.cpp: (WebCore::ScrollTimeline::create): (WebCore::ScrollTimeline::ScrollTimeline): * Source/WebCore/animation/ScrollTimeline.h: (WebCore::ScrollTimeline::create): (WebCore::ScrollTimeline::ScrollTimeline): Deleted. * Source/WebCore/animation/ScrollTimeline.idl: * Source/WebCore/animation/ScrollTimelineOptions.h:
…` should default to the document's scrolling element https://bugs.webkit.org/show_bug.cgi?id=284360 rdar://141206809 Reviewed by NOBODY (OOPS!). The specification for the `ScrollTimeline` constructor specifies [0] that "the scrollingElement of the Document associated with the Window that is the current global object" should be used if a source is not explicitly set via the `options` parameter. Note that the wording of the spec at the time of writing is not clear on this topic but the IDL definition as well as the relevant WPT test (scroll-animations/scroll-timelines/constructor.html, fixed by this patch) clearly identify the expected behavior. An issue [1] was filed to address this. In order to be able to distinguish a `null` value explicitly set on the `source` property of the `options` parameter, we change `ScrollTimelineOptions.h` to use an `std::optional<>` to wrap the `RefPtr<Element>`. We also need to pass the document to the `ScrollTimeline` constructor to be able to get at the scrolling element, so we add the `CallWith=CurrentDocument` processing directive and fix an uncounted issue with the generated that would result in `JSScrollTimeline.cpp`. [0] https://drafts.csswg.org/scroll-animations-1/#dom-scrolltimeline-scrolltimeline [1] w3c/csswg-drafts#11340 * LayoutTests/imported/w3c/web-platform-tests/scroll-animations/scroll-timelines/constructor-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/scroll-animations/scroll-timelines/source-quirks-mode-expected.txt: * Source/WebCore/animation/ScrollTimeline.cpp: (WebCore::ScrollTimeline::create): (WebCore::ScrollTimeline::ScrollTimeline): * Source/WebCore/animation/ScrollTimeline.h: (WebCore::ScrollTimeline::create): (WebCore::ScrollTimeline::ScrollTimeline): Deleted. * Source/WebCore/animation/ScrollTimeline.idl: * Source/WebCore/animation/ScrollTimelineOptions.h: * Source/WebCore/bindings/scripts/CodeGeneratorJS.pm: (GenerateCallWith):
…` should default to the document's scrolling element https://bugs.webkit.org/show_bug.cgi?id=284360 rdar://141206809 Reviewed by NOBODY (OOPS!). The specification for the `ScrollTimeline` constructor specifies [0] that "the scrollingElement of the Document associated with the Window that is the current global object" should be used if a source is not explicitly set via the `options` parameter. Note that the wording of the spec at the time of writing is not clear on this topic but the IDL definition as well as the relevant WPT test (scroll-animations/scroll-timelines/constructor.html, fixed by this patch) clearly identify the expected behavior. An issue [1] was filed to address this. In order to be able to distinguish a `null` value explicitly set on the `source` property of the `options` parameter, we change `ScrollTimelineOptions.h` to use an `std::optional<>` to wrap the `RefPtr<Element>`. We also need to pass the document to the `ScrollTimeline` constructor to be able to get at the scrolling element, so we add the `CallWith=CurrentDocument` processing directive and fix an uncounted issue with the generated that would result in `JSScrollTimeline.cpp`. [0] https://drafts.csswg.org/scroll-animations-1/#dom-scrolltimeline-scrolltimeline [1] w3c/csswg-drafts#11340 * LayoutTests/imported/w3c/web-platform-tests/scroll-animations/scroll-timelines/constructor-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/scroll-animations/scroll-timelines/source-quirks-mode-expected.txt: * Source/WebCore/animation/ScrollTimeline.cpp: (WebCore::ScrollTimeline::create): (WebCore::ScrollTimeline::ScrollTimeline): * Source/WebCore/animation/ScrollTimeline.h: (WebCore::ScrollTimeline::create): (WebCore::ScrollTimeline::ScrollTimeline): Deleted. * Source/WebCore/animation/ScrollTimeline.idl: * Source/WebCore/animation/ScrollTimelineOptions.h: * Source/WebCore/bindings/scripts/CodeGeneratorJS.pm: (GenerateCallWith): * Source/WebCore/bindings/scripts/test/JS/JSTestLegacyFactoryFunction.cpp: (WebCore::JSTestLegacyFactoryFunctionLegacyFactoryFunction::construct): * Source/WebCore/bindings/scripts/test/JS/JSTestObj.cpp: (WebCore::JSTestObjDOMConstructor::construct): (WebCore::jsTestObjConstructor_testStaticReadonlyObjGetter): (WebCore::jsTestObjPrototypeFunction_withCurrentDocumentArgumentBody): (WebCore::jsTestObjPrototypeFunction_withRelevantDocumentArgumentBody):
…` should default to the document's scrolling element https://bugs.webkit.org/show_bug.cgi?id=284360 rdar://141206809 Reviewed by NOBODY (OOPS!). The specification for the `ScrollTimeline` constructor specifies [0] that "the scrollingElement of the Document associated with the Window that is the current global object" should be used if a source is not explicitly set via the `options` parameter. Note that the wording of the spec at the time of writing is not clear on this topic but the IDL definition as well as the relevant WPT test (scroll-animations/scroll-timelines/constructor.html, fixed by this patch) clearly identify the expected behavior. An issue [1] was filed to address this. In order to be able to distinguish a `null` value explicitly set on the `source` property of the `options` parameter, we change `ScrollTimelineOptions.h` to use an `std::optional<>` to wrap the `RefPtr<Element>`. We also need to pass the document to the `ScrollTimeline` constructor to be able to get at the scrolling element, so we add the `CallWith=CurrentDocument` processing directive and fix an uncounted issue with the generated that would result in `JSScrollTimeline.cpp`. [0] https://drafts.csswg.org/scroll-animations-1/#dom-scrolltimeline-scrolltimeline [1] w3c/csswg-drafts#11340 * LayoutTests/imported/w3c/web-platform-tests/scroll-animations/scroll-timelines/constructor-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/scroll-animations/scroll-timelines/source-quirks-mode-expected.txt: * Source/WebCore/SaferCPPExpectations/UncountedLambdaCapturesCheckerExpectations: * Source/WebCore/SaferCPPExpectations/UncountedLocalVarsCheckerExpectations: * Source/WebCore/animation/ScrollTimeline.cpp: (WebCore::ScrollTimeline::create): (WebCore::ScrollTimeline::ScrollTimeline): * Source/WebCore/animation/ScrollTimeline.h: (WebCore::ScrollTimeline::create): (WebCore::ScrollTimeline::ScrollTimeline): Deleted. * Source/WebCore/animation/ScrollTimeline.idl: * Source/WebCore/animation/ScrollTimelineOptions.h: * Source/WebCore/bindings/scripts/CodeGeneratorJS.pm: (GenerateCallWith): * Source/WebCore/bindings/scripts/test/JS/JSTestLegacyFactoryFunction.cpp: (WebCore::JSTestLegacyFactoryFunctionLegacyFactoryFunction::construct): * Source/WebCore/bindings/scripts/test/JS/JSTestObj.cpp: (WebCore::JSTestObjDOMConstructor::construct): (WebCore::jsTestObjConstructor_testStaticReadonlyObjGetter): (WebCore::jsTestObjPrototypeFunction_withCurrentDocumentArgumentBody): (WebCore::jsTestObjPrototypeFunction_withRelevantDocumentArgumentBody):
…` should default to the document's scrolling element https://bugs.webkit.org/show_bug.cgi?id=284360 rdar://141206809 Reviewed by Anne van Kesteren. The specification for the `ScrollTimeline` constructor specifies [0] that "the scrollingElement of the Document associated with the Window that is the current global object" should be used if a source is not explicitly set via the `options` parameter. Note that the wording of the spec at the time of writing is not clear on this topic but the IDL definition as well as the relevant WPT test (scroll-animations/scroll-timelines/constructor.html, fixed by this patch) clearly identify the expected behavior. An issue [1] was filed to address this. In order to be able to distinguish a `null` value explicitly set on the `source` property of the `options` parameter, we change `ScrollTimelineOptions.h` to use an `std::optional<>` to wrap the `RefPtr<Element>`. We also need to pass the document to the `ScrollTimeline` constructor to be able to get at the scrolling element, so we add the `CallWith=CurrentDocument` processing directive and fix an uncounted issue with the generated that would result in `JSScrollTimeline.cpp`. [0] https://drafts.csswg.org/scroll-animations-1/#dom-scrolltimeline-scrolltimeline [1] w3c/csswg-drafts#11340 * LayoutTests/imported/w3c/web-platform-tests/scroll-animations/scroll-timelines/constructor-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/scroll-animations/scroll-timelines/source-quirks-mode-expected.txt: * Source/WebCore/SaferCPPExpectations/UncountedLambdaCapturesCheckerExpectations: * Source/WebCore/SaferCPPExpectations/UncountedLocalVarsCheckerExpectations: * Source/WebCore/animation/ScrollTimeline.cpp: (WebCore::ScrollTimeline::create): (WebCore::ScrollTimeline::ScrollTimeline): * Source/WebCore/animation/ScrollTimeline.h: (WebCore::ScrollTimeline::create): (WebCore::ScrollTimeline::ScrollTimeline): Deleted. * Source/WebCore/animation/ScrollTimeline.idl: * Source/WebCore/animation/ScrollTimelineOptions.h: * Source/WebCore/bindings/scripts/CodeGeneratorJS.pm: (GenerateCallWith): * Source/WebCore/bindings/scripts/test/JS/JSTestLegacyFactoryFunction.cpp: (WebCore::JSTestLegacyFactoryFunctionLegacyFactoryFunction::construct): * Source/WebCore/bindings/scripts/test/JS/JSTestObj.cpp: (WebCore::JSTestObjDOMConstructor::construct): (WebCore::jsTestObjConstructor_testStaticReadonlyObjGetter): (WebCore::jsTestObjPrototypeFunction_withCurrentDocumentArgumentBody): (WebCore::jsTestObjPrototypeFunction_withRelevantDocumentArgumentBody): Canonical link: https://commits.webkit.org/287657@main
…constructing a `ScrollTimeline` It should be possible to explicitly set a `null` source when constructing a `ScrollTimeline`. This addresses #11340.
Fixed by #11357. Closing. |
The
ScrollTimeline
IDL reads as follows:And its specification text is:
To me, the IDL and the spec text are contradictory. Since the constructor is specified as taking
optional ScrollTimelineOptions options = {}
then I don't think we can distinguish betweenScrollTimeline
being constructed without anoptions
parameter or with{ source: null }
. But I believe the spec text is actually trying to distinguish between three cases:{}
where the source would be set todocument.scrollingElement
,{ source: null }
where the source would not be set,{ source: document.body }
where the source would be set todocument.body
.At least this is what is being tested by the WPT test scroll-animations/scroll-timelines/constructor.html.
The text was updated successfully, but these errors were encountered: