Is the behavior the spec defines for reflection of script's src attribute web-compatible? #1739

Closed
bzbarsky opened this Issue Sep 2, 2016 · 7 comments

Projects

None yet

2 participants

@bzbarsky
Collaborator
bzbarsky commented Sep 2, 2016

See https://bugzilla.mozilla.org/show_bug.cgi?id=1299373#c3 and testcase at http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4429

There is no UA that does what the spec says to do and no clear indication that any of them plan to change. The non-Edge UAs seem to be interoperable with each other and are applying the rules for normal URL attributes, not the ones that must be nonempty....

@zcorpan, @annevk said you might know something about this.

@zcorpan
Member
zcorpan commented Sep 5, 2016

The history is this:

w3c/web-platform-tests#2663

caused spec change

#859 (@sicking and @tkent-google supported the change)

I had missed to follow up with fixing tests and filing bugs, though. :-( I can do that.

I don't have data that this is Web-compatible, not sure how to find out. But if trying to ship we find that script src needs to be an exception, then we can spec it so?

@zcorpan
Member
zcorpan commented Sep 5, 2016
@zcorpan
Member
zcorpan commented Sep 5, 2016

w3c/web-platform-tests#3640 for reflection.js

@bzbarsky
Collaborator
bzbarsky commented Sep 6, 2016 edited

But if trying to ship we find that script src needs to be an exception, then we can spec it so?

I'm pretty tired of the HTML spec taking cases that are interoperably implemented and speccing them in some other way, then making UAs jump through hoops to prove that the changes are or are not web-compatible. It wastes a huge amount of UA engineer time that could be spent doing something actually useful, reduces trust in the HTML spec (e.g. at this point some engineers more or less assume that just because the HTML spec says something doesn't mean that has any bearing on reality or what they should implement, given their past experiences), and seems actively hostile to the project of getting everyone to interoperable behavior.

Sometimes there are strong reasons (e.g. security) for speccing something other than the paved cowpath. But I don't see any such strong reasons in this case, honestly....

Or put another way, I would want to see some proof that this change does not break any sites before Gecko actually implements it. Yes, I know this is asking to prove a negative.

@bzbarsky
Collaborator
bzbarsky commented Sep 6, 2016

Oh, and "I'm OK with this" comments without actual working code that has made it at least close to the release channel is not at all what I'd expect for "implementers are willing to go at it". Words are cheap. Actual willingness to make a change is a lot less so.

@zcorpan
Member
zcorpan commented Sep 6, 2016

Yes, you are right. Let's revert this. There wasn't a strong reason to change and indeed we should have stronger commitment before changing the spec.

@zcorpan zcorpan self-assigned this Sep 6, 2016
@zcorpan zcorpan added a commit that referenced this issue Sep 6, 2016
@zcorpan zcorpan Revert "Fix #859: Special-case empty string in reflect as URL"
This reverts commit f09dbee.

Fixes #1739.
095bacb
@zcorpan zcorpan added a commit to w3c/web-platform-tests that referenced this issue Sep 6, 2016
@zcorpan zcorpan Revert the empty string change a89e063
@zcorpan zcorpan added a commit to w3c/web-platform-tests that referenced this issue Sep 6, 2016
@zcorpan zcorpan Change empty string case to expect resolved URL 2f5f345
@zcorpan
Member
zcorpan commented Sep 6, 2016

PR to revert the spec #1745

WPT PRs updated also: w3c/web-platform-tests#3639 , w3c/web-platform-tests#3640

@annevk annevk closed this in #1745 Sep 6, 2016
@annevk annevk added a commit that referenced this issue Sep 6, 2016
@zcorpan @annevk zcorpan + annevk Revert "Fix #859: Special-case empty string in reflect as URL"
This reverts commit f09dbee.

Fixes #1739.
85227d2
@zcorpan zcorpan added a commit to w3c/web-platform-tests that referenced this issue Sep 15, 2016
@zcorpan zcorpan Update reflection tests around URLs (#3640)
If a URL fails to resolve, return the input string instead of the
empty string.

Change a.ping and area.ping to reflect as a normal string.

The empty string still resolves per the current spec, see:
whatwg/html#1745
whatwg/html#1739
71a68f3
@zcorpan zcorpan added a commit to w3c/web-platform-tests that referenced this issue Sep 15, 2016
@zcorpan zcorpan Refactor and fix HTMLTrackElement/src.html (#3639)
A single \u0000 character gets stripped by the URL parser;
"Remove any leading and trailing C0 controls and space from input."

Fixes #2125. Closes #2663.

The empty string case still expects resolved URL per the current spec, see:
whatwg/html#1745
whatwg/html#1739
1bf03c9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment