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

Allow to use LegacyNullToEmptyString on USVString. #915

Merged
merged 1 commit into from
Sep 3, 2020

Conversation

emilio
Copy link
Contributor

@emilio emilio commented Sep 3, 2020

This is needed for the CSSOM spec, as that allows to use USVString as
the underlying string type.

Given the USVString conversion to JS values is already calling into the
DOMString conversion, there's no need to modify that section even, which
is great.

cc w3c/csswg-drafts#5010

This is needed for the CSSOM spec, as that allows to use USVString as
the underlying string type.

Given the USVString conversion to JS values is already calling into the
DOMString conversion, there's no need to modify that section even, which
is great.
Copy link
Member

@domenic domenic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As sad as I am about the interop issue that is CSSOMString, this does seem like approximately the right fix. (E.g., the idea of only applying it to the DOMString typedef would be weird, as then the behavior would differ in browsers which use DOMString vs. USVString.)

There's a separate issue where it's not clear that extended attributes properly flow across typedefs; see #649. But the intent is clear enough, and that can be fixed orthogonally.

@domenic domenic merged commit 6bccbca into whatwg:master Sep 3, 2020
@emilio emilio deleted the LegacyNullToEmptyString branch September 4, 2020 10:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants