Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Miscellaneous Custom Elements #231

Closed
josepharhar opened this issue Oct 20, 2022 · 12 comments
Closed

Miscellaneous Custom Elements #231

josepharhar opened this issue Oct 20, 2022 · 12 comments
Labels
accepted An accepted proposal focus-area-proposal Focus Area Proposal

Comments

@josepharhar
Copy link

josepharhar commented Oct 20, 2022 •
edited
Loading

This was split from #181

Description

This is a bunch of WPTs in the custom-elements directory that are failing. I don’t think they correspond to any particular big feature, they were just made from random one-off bugs.

Rationale

Basic custom elements behavior should be interoperable.

Callbacks

Tests:

Custom Element Registry

Tests:

Construction

Tests:

:defined Pseudo Selector

Tests:
https://wpt.fyi/results/custom-elements/pseudo-class-defined-print.html
Spec: https://html.spec.whatwg.org/multipage/semantics-other.html#selector-defined
@josepharhar josepharhar mentioned this issue Oct 20, 2022
Closed
@gsnedders gsnedders added the focus-area-proposal Focus Area Proposal label Oct 21, 2022
@gsnedders
Copy link
Member

:defined Pseudo Selector

Tests: https://wpt.fyi/results/custom-elements/pseudo-class-defined-print.html https://wpt.fyi/results/custom-elements/pseudo-class-defined.html Spec: https://html.spec.whatwg.org/multipage/semantics-other.html#selector-defined

For the print test, this is missing in Edge and Safari as print tests aren't run, so not related to this.

For the other, all the Safari failures are the lack of is= (#234), rather than anything about the semantics of :defined itself.

@gsnedders
Copy link
Member

Parsing and Serializing

Tests: https://wpt.fyi/results/custom-elements/parser Spec: https://html.spec.whatwg.org/C/#create-an-element-for-the-token https://dom.spec.whatwg.org/#concept-create-element

Similarly, the only failures here seem to be Safari due to lack of is= (#234).

@josepharhar
Copy link
Author

Thanks for looking at those, should I move them to #234 then?

@gsnedders
Copy link
Member

Probably?

@josepharhar
Copy link
Author

Ok, I moved pseudo-class-defined.html and custom-elements/parser/ to the other issue.
I kept pseudo-class-defined-print.html here because I don't see anything related to custom builtins, let me know if I missed anything.

@hsinyi
Copy link

hsinyi commented Nov 1, 2022

Based on the discussion with @jcsteh , we'd like to exclude https://wpt.fyi/results/custom-elements/reactions/AriaMixin-element-attributes.html i.e. exclude ARIA idref attributes.

We are interested in keeping https://wpt.fyi/results/custom-elements/reactions/AriaMixin-string-attributes.html
, i.e. ARIA non-idref part in the scope. However, there appear to be open spec issues for this part :
w3c/aria#1110
w3c/aria#1239

How likely is it that we can get consensus on the spec issues before the start of the Interop period?

@josepharhar
Copy link
Author

I am happy to drop AriaMixin-element-attributes.html if needed. I don't have context on those aria issues and I don't know how likely they are to be resolved before the start of the interop period.

@gsnedders
Copy link
Member

gsnedders commented Nov 9, 2022 •
edited
Loading

Looking at this again, a lot of the tests seem to be testing things only observable in combination with #234.

e.g.,

% rg '(createElement.*is\s*:|\sis\s*=|define.*extends\s*:)' custom-elements  --files-with-matches | sort -f
custom-elements/builtin-coverage.html
custom-elements/custom-element-registry/define.html
custom-elements/customized-built-in-constructor-exceptions.html
custom-elements/Document-createElement-svg.svg
custom-elements/Document-createElement.html
custom-elements/Document-createElementNS.html
custom-elements/htmlconstructor/newtarget.html
custom-elements/HTMLElement-attachInternals.html
custom-elements/HTMLElement-constructor.html
custom-elements/parser/parser-constructs-custom-elements-with-is.html
custom-elements/parser/parser-uses-create-an-element-for-a-token-svg.svg
custom-elements/parser/serializing-html-fragments.html
custom-elements/pseudo-class-defined.html
custom-elements/reactions/HTMLInputElement.html
custom-elements/reactions/HTMLMetaElement.html
custom-elements/reactions/HTMLSourceElement.html
custom-elements/reactions/resources/reactions.js
custom-elements/resources/custom-elements-helpers.js
custom-elements/scoped-registry/CustomElementRegistry-constructor.tentative.html
custom-elements/upgrading/Document-importNode.html
custom-elements/upgrading/Node-cloneNode.html

The closer I look, the more of these seem to just be customised built-ins (#234).

I think we need to closely review all the failing tests to see how many should just be part of #234, and whether that leaves much left here. Not sure what that means for the proposal v. test review periods, given accepting this and then removing (almost?) everything seems silly.

@foolip
Copy link
Member

foolip commented Nov 11, 2022

In the MDN short survey on APIs & JavaScript, "Web Components (custom elements, Shadow DOM, etc.)" was the most popular choice by a fairly wide margin, selected by ~39% of survey takers.

Web Components was split into many granular proposals, and the survey results don't tell us which aspects web developers want the most, but it's fair to say that something about Web Components is important. (I'm posting this comment on each of the split proposals.)

@josepharhar
Copy link
Author

josepharhar commented Nov 17, 2022 •
edited
Loading

I investigated each test and these are my findings for whether each test relies on custom builtins. Checkmark means no custom builtins, cross means it has custom builtins:

I'll move all the custom builtin ones to the custom builtins proposal.

Not sure what that means for the proposal v. test review periods, given accepting this and then removing (almost?) everything seems silly

If you don't think the remaining tests here are enough, then perhaps we could move them to the misc. shadowdom proposal: #230

@josepharhar josepharhar mentioned this issue Nov 17, 2022
Closed
@gsnedders
Copy link
Member

Not sure what that means for the proposal v. test review periods, given accepting this and then removing (almost?) everything seems silly

If you don't think the remaining tests here are enough, then perhaps we could move them to the misc. shadowdom proposal: #230

I don't think it's necessarily an issue—and we have other very small proposals—but it's something we may well want to deal with somehow through grouping.

And FWIW, I believe these are all of the included tests based on the above list.

@nairnandu nairnandu added the accepted An accepted proposal label Feb 1, 2023
@nairnandu
Copy link
Contributor

Thank you for proposing Miscellaneous Custom Elements for inclusion in Interop 2023.

We are pleased to let you know that this proposal was accepted as part of the Web Components focus area. You can follow the progress of this Focus Area on the Interop 2023 dashboard.

For an overview of our process, see the proposal selection summary. Thank you for contributing to Interop 2023!

Posted on behalf of the Interop team.

@nairnandu nairnandu mentioned this issue Sep 21, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
accepted An accepted proposal focus-area-proposal Focus Area Proposal
Projects
No open projects
Interop 2023
Status: Proposed
Milestone
No milestone
Development

No branches or pull requests
5 participants
@gsnedders @foolip @hsinyi @nairnandu @josepharhar