You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
constmyElement=document.createElement('div');\
myElement.ariaAtomic="foo"// not allowed, currently allowedmyElement.ariaAtomic="true"// okmyElement.ariaAtomic="false"// okmyElement.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.
The text was updated successfully, but these errors were encountered:
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 :)
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.
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
🙁 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.
The text was updated successfully, but these errors were encountered: