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

What does screw-ie8 break? #1204

Closed
JoeUX opened this issue Jul 14, 2016 · 3 comments
Closed

What does screw-ie8 break? #1204

JoeUX opened this issue Jul 14, 2016 · 3 comments

Comments

@JoeUX
Copy link

JoeUX commented Jul 14, 2016

I saw the change to make --screw-ie8 on by default, and the new support-ie8 flag. The description refers to "IE 6-8 quirks".

I've never known what this was about. Now that it's on by default, can someone document what quirks this is about, and which versions of IE they apply to? IE 6-8 is a pretty broad swath, and I probably only care about IE 8.

If this is about mangling, maybe it should be unified under one flag for both old IE and modern Safari, since Safari seems to have special mangling issues.

I didn't see anything in the mangling docs about these browsers, but the --screw-ie8 change says "catch identifier is mangled correctly for ES5 standards-compliant JS engines by default."

There's a standard for mangling? Can someone unpack this?

@kzc
Copy link
Contributor

kzc commented Jul 14, 2016

"catch identifier is mangled correctly for ES5 standards-compliant JS engines by default."

Catch block scoping behavior in ie6/7/8 is broken/non-standard. It can present problems when the identifier in the catch block mirrors a var of the same name in function scope. In trying to accommodate ie6/7/8 it led to incorrect try/catch code being generated for modern browsers in certain cases. See #409 for a few examples.

can someone document what quirks this is about, and which versions of IE they apply to?

That someone can be you. Pull requests welcome.

Search for screw_ie8 in the code and tests and you can piece together what it encompasses without too much trouble:

https://github.com/mishoo/UglifyJS2/search?utf8=✓&q=screw_ie8&type=Code

@JoeUX
Copy link
Author

JoeUX commented Jul 23, 2016

can someone document what quirks this is about, and which versions of IE they apply to?

That someone can be you. Pull requests welcome.

You know, that might be good training for me, so maybe I should go ahead and do it.

If I do it, can I convince you, or whomever needs convincing, to rename the flag to something less abrasive? "screw-ie" seems a bit unprofessional. I'm pro-IE and pro- all other browsers.

It's actually not clear why that flag is needed anymore given that it's enabled by default and that there's the new support-ie8 flag. Couldn't everything be folded into support-ie8? And it's a nice straightforward label, without the heat.

NOTE: In #1201, people are talking about how IE 6-8 browser share is in single digits and falling, as a reason for not caring about it. I for one definitely care about a 5% or 3% situation. That's a lot of people, and notably the Chrome project uses a much, much smaller usage threshold to decide whether to drop a feature (something less than 1% use in the wild). I think people have trouble understanding the context of old IE users. One context is public machines that aren't actively maintained. For example, the free machines in the lobby of a dorm building, or the machines in a stats lab classroom in graduate school (which I experienced first-hand), or all sorts of public kiosks. Plus, there are still large organizational and government contexts where people are forced to use IE 8 for legacy app reasons – these are fading (e.g. the Dept. of Defense is swiftly and comprehensively moving to Windows 10 for security reasons), but they're still out there. A lot of these users are prized users from business/marketing perspectives since they're salaried professionals or whatever.

Then of course are the elderly. We don't think enough about them. There's no reason to expect site visitors to be like web developers in their choices or context.

@kzc
Copy link
Contributor

kzc commented Jul 23, 2016

Supporting IE 6/7/8 is not without consequence. As previously mentioned, screw_ie8: false in certain circumstances can produce incorrect code in try/catch blocks for the majority of browsers in use today. It makes sense that uglify 2.7.x's default behavior works correctly with 95% of browsers. People are free to set uglify options that best suit their user base.

Couldn't everything be folded into support-ie8?

It appears you can use --support-ie8 from the CLI in all versions and it will not complain. It's essentially a no op with uglify-js versions <= 2.6.x since that was the default.

For require('uglify-js').minify() you must set the screw_ie8 option in compress, mangle and output sections. See: #1213 (comment) . That API is portable across all uglify versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants