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

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

Comments

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

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Sep 5, 2016

Member

The history is this:

web-platform-tests/wpt#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?

Member

zcorpan commented Sep 5, 2016

The history is this:

web-platform-tests/wpt#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

This comment has been minimized.

Show comment
Hide comment
@zcorpan
Member

zcorpan commented Sep 5, 2016

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan
Member

zcorpan commented Sep 5, 2016

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

@bzbarsky

This comment has been minimized.

Show comment
Hide comment
@bzbarsky

bzbarsky Sep 6, 2016

Collaborator

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.

Collaborator

bzbarsky commented Sep 6, 2016

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

This comment has been minimized.

Show comment
Hide comment
@bzbarsky

bzbarsky Sep 6, 2016

Collaborator

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.

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

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Sep 6, 2016

Member

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.

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 added a commit that referenced this issue Sep 6, 2016

zcorpan added a commit to web-platform-tests/wpt that referenced this issue Sep 6, 2016

zcorpan added a commit to web-platform-tests/wpt that referenced this issue Sep 6, 2016

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Sep 6, 2016

Member

PR to revert the spec #1745

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

Member

zcorpan commented Sep 6, 2016

PR to revert the spec #1745

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

@annevk annevk closed this in #1745 Sep 6, 2016

annevk added a commit that referenced this issue Sep 6, 2016

zcorpan added a commit to web-platform-tests/wpt that referenced this issue Sep 15, 2016

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

zcorpan added a commit to web-platform-tests/wpt that referenced this issue Sep 15, 2016

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment