Pale Moon forum

Moonchild wrote:So... bugreport it to DA?

Error: SyntaxError: property name element appears more than once in object literal
Source File: http://st.deviantart.net/roses/jsmin/core.js?1447796205855
Line: 4, Column: 60
Source Code:
iew:"peek",element:"deviant_menuitem",action:"view",element:c})}}},{key:"moreCommentsClick",value:function(){this.getAct

js> (function(){"use strict";({1:1,1:1})}())

It is a syntax error if strict mode code contains an ObjectLiteral with more than one definition of any data property (11.1.5).

Moonchild wrote:Well, I'm afraid we can't force compatibility in something that is solely under their control.
Also, looks like it's a simple error redefining something that's already defined, which isn't allowed in strict mode:

Code: Select all

Error: SyntaxError: property name element appears more than once in object literal
Source File: http://st.deviantart.net/roses/jsmin/core.js?1447796205855
Line: 4, Column: 60
Source Code:
iew:"peek",element:"deviant_menuitem",action:"view",element:c})}}},{key:"moreCommentsClick",value:function(){this.getAct

It's the "element:c" part there.

Code: Select all

js> (function(){"use strict";({1:1,1:1})}())

I'd say it's perfectly logical that this throws in strict mode. They should clean up their code to prevent double property names/assignments in object literals, or not use strict mode without understanding all implications of doing so.

Also, if they are making it a point to not support us, then their bookmark will also be removed from the start portal. Tit for tat.

ECMAScript 5 standard, annex C:

It is a syntax error if strict mode code contains an ObjectLiteral with more than one definition of any data property (11.1.5).

So, we're perfectly in-line with ES5. If ES6 changed this then the spec is in direct conflict with itself (how on earth do they justify this for a standard that takes years to adopt?), and implementing this change would break our compatibility with the standard one way or another. DA, being a generic, large art site, should not assume or even enforce all visitors limit themselves to what they prescribe, and they should be as browser-agnostic as possible. That includes not using strict mode in case of a conflict in it, or avoiding the use of conflicting methods in standards in use altogether.

Moonchild wrote:Update: it's indeed a change in ES6 that breaks with this restriction in ES5 in strict mode.
So, ES6 allows sloppy coding in strict mode. Great way to ensure code quality, people.

ThunderclawShocktrix wrote:at some point as this sort of slop gets more common that pale moon is going to need to be able to handle this

Moonchild wrote: Considering this slop has now been standardized in ES6 as acceptable slop, we have no choice but to break ES5 standards compliance to adopt the more lenient of the two specs. Otherwise, yes, it will "break teh webz" as more and more web-"coders" don't care how they code.

It's totally retarded though. ES3 allowed this kind of coding. Then, ES5 actually cleaned this up and made it a more proper standard by making strict mode actually strict; it's called that way for a reason!... and now ES6 is undoing that again.