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.

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

ARIAMixin typings do not accurately represent all properties #46456

Closed
chrisdholt opened this issue Oct 21, 2021 · 3 comments
Closed

ARIAMixin typings do not accurately represent all properties #46456

chrisdholt opened this issue Oct 21, 2021 · 3 comments
Labels
Question An issue which isn't directly actionable in code

Comments

@chrisdholt
Copy link
Member

chrisdholt commented Oct 21, 2021

Bug Report

In v4.4.0 the ARIAMixin was introduced, which enumerates all properties of the ARIAMixin as string. The FAST team (and subsequently anyone leveraging our Foundation components) is currently blocked from upgrading beyond [email protected] due to these types. The feedback from #45047 calls out the issue that these should be nullable, but we're hitting a somewhat different issue as well. Prior to the introduction of these types, we enumerated these ourselves due to specific requirements around our custom elements which delegate focus. With the introduction of ARIAMixin and the broad definition of strings in 4.4.0 we're hitting type definitions.

While each of these properties are a DOMString, many are specific strings. I don't have a direct link to each in the spec on hand, but I'll link to MDN's enumeration of these (ariaAtomic, ariaAutocomplete, ariaLive, ariaHidden, ariaHasPopup as a few examples). While many of the properties on the Mixin are strings not all are - from a standards and accuracy perspective, I think the typings should be updated to represent specific strings where applicable.

I would be more than happy to contribute a fix for this if you like.

🔎 Search Terms

ARIAMixin - As noted above, #45047 addresses the nullable nature of these, but there are no relevant issues regarding the specific typed DOMString's.

🕗 Version & Regression Information

This changed and is present in all versions greater than 4.3.5 (beginning 4.4.0).

💻 Code

const myElement = document.createElement('div');\

myElement.ariaAtomic = "foo" // not allowed, currently allowed

myElement.ariaAtomic = "true" // ok

myElement.ariaAtomic = "false" // ok

myElement.ariaAtomic = undefined; // ok

🙁 Actual behavior

Any string is valid. Anyone enumerating typed DOMStrings for these will get type errors due to one being essentially a type which !== generic string.

🙂 Expected behavior

The types map to the specification, where properties with specific DOMString values allowed are enumerated and nullable.

@chrisdholt
Copy link
Member Author

I realized after opening that this is related to generated files so I've opened an issue in that repo as well. If this issue needs to close, please feel free to do so :)

@orta
Copy link
Contributor

orta commented Oct 21, 2021

Yeah, there's nothing that can happen in this repo to address your original point, I'll mark it as a question and let it close after some time

@orta orta added the Question An issue which isn't directly actionable in code label Oct 21, 2021
@chrisdholt
Copy link
Member Author

I believe that getting 45047 resolved to allow these to be nullable will resolve this for us as well. I'll close this as I see that issue is still open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Question An issue which isn't directly actionable in code
Projects
None yet
Development

No branches or pull requests

2 participants