-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Reflecting as URL and failing to resolve #561
Comments
For http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3843 IE logs "http://[/" twice. It looks like interop for invalid URLs in |
The IDL attributes that reflect as a URL are:
(This would be easier to find and be confident about being correct if reflecting was using IDL syntax instead...) |
|
Value is "x" http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3995 |
When an attribute that reflects as a URL fails to parse, the IDL attribute should return the content attribute's value. This matches the HTMLHyperlinkElement#href getter behavior.
When an attribute that reflects as a URL fails to parse, the IDL attribute should return the content attribute's value. Also do this for HTMLBaseElement#href getter. This matches the HTMLHyperlinkElement#href getter behavior.
https://html.spec.whatwg.org/#reflecting-content-attributes-in-idl-attributes
I'm not sure empty string is right. For
a.href
it returns the attribute's value instead:https://html.spec.whatwg.org/multipage/semantics.html#dom-hyperlink-href
Also related is
base href
https://html.spec.whatwg.org/multipage/semantics.html#dom-base-hrefhttp://software.hixie.ch/utilities/js/live-dom-viewer/saved/3843 - Gecko returns the attribute's value for both
img src
andbase href
.I suggest we switch to that so it's consistent with
a href
.cc @Ms2ger
The text was updated successfully, but these errors were encountered: