Skip to content

[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

Closed
graouts opened this issue Dec 9, 2024 · 5 comments
Closed
Labels

Comments

@graouts
Copy link
Contributor

graouts commented Dec 9, 2024

The ScrollTimeline IDL reads as follows:

dictionary ScrollTimelineOptions {
  Element? source;
  ScrollAxis axis = "block";
};

[Exposed=Window]
interface ScrollTimeline : AnimationTimeline {
  constructor(optional ScrollTimelineOptions options = {});
};

And its specification text is:

  1. Let timeline be the new ScrollTimeline object.
  2. Set the source of timeline to:

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 between ScrollTimeline being constructed without an options parameter or with { source: null }. But I believe the spec text is actually trying to distinguish between three cases:

  1. {} where the source would be set to document.scrollingElement,
  2. { source: null } where the source would not be set,
  3. { source: document.body } where the source would be set to document.body.

At least this is what is being tested by the WPT test scroll-animations/scroll-timelines/constructor.html.

@graouts graouts added the scroll-animations-1 Current Work label Dec 9, 2024
@graouts
Copy link
Contributor Author

graouts commented Dec 9, 2024

Cc @flackr, @kevers-google and @andruud.

@cdumez
Copy link
Collaborator

cdumez commented Dec 9, 2024

Note that the Web IDL spec says:

If the type of an argument is a dictionary type or a union type that has a dictionary type as one of its flattened member types, and that dictionary type and its ancestors have no required members, and the argument is either the final argument or is followed only by optional arguments, then the argument must be specified as optional and have a default value provided.

@graouts
Copy link
Contributor Author

graouts commented Dec 9, 2024

To match the WPT test, I believe that:

  1. the IDL should be set to constructor(optional ScrollTimelineOptions options),
  2. the spec text should be updated to say "If the source member of options is present" and not "If the source member of options is present and not null".

That way implementations could distinguish between the three cases outlined above.

@graouts
Copy link
Contributor Author

graouts commented Dec 10, 2024

Upon closer inspection, the IDL constructor definition seems fine because ScrollTimelineOptions does not define source to default to null, so it is possible to distinguish between source being explicitly set to null and source not being explicitly set.

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.

graouts added a commit to graouts/WebKit that referenced this issue Dec 10, 2024
…` 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:
graouts added a commit to graouts/WebKit that referenced this issue Dec 10, 2024
…` 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:
graouts added a commit to graouts/WebKit that referenced this issue Dec 10, 2024
…` 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):
graouts added a commit to graouts/WebKit that referenced this issue Dec 10, 2024
…` 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):
graouts added a commit to graouts/WebKit that referenced this issue Dec 10, 2024
…` 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):
webkit-commit-queue pushed a commit to graouts/WebKit that referenced this issue Dec 11, 2024
…` 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
graouts added a commit that referenced this issue Dec 12, 2024
…constructing a `ScrollTimeline`

It should be possible to explicitly set a `null` source when constructing a `ScrollTimeline`. This addresses #11340.
graouts added a commit that referenced this issue Dec 13, 2024
…constructing a `ScrollTimeline` (#11357)

It should be possible to explicitly set a `null` source when constructing a `ScrollTimeline`. This addresses #11340.
@bramus
Copy link
Contributor

bramus commented Dec 30, 2024

Fixed by #11357. Closing.

@bramus bramus closed this as completed Dec 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants