ES3.1 Proposal Working Draft
mjs at apple.com
Wed Feb 20 11:59:43 PST 2008
(Moving from another mailing list.)
On Feb 20, 2008, at 10:54 AM, Kris Zyp wrote:
>> "No new syntax" actually does create a meaningful benefit, which is
>> ability to do graceful degradation in browsers that don't support
>> the new language. New builtin types, properties and methods can be
>> tested for from script before using it, but new syntax can't since
>> the presence of it alone will cause a syntax error at parse time.
>> So it is less arbitrary than some other possible rules.
> True in the immediate future, but there will be a reverse effect
> down the road. At some (hopefully) ES3.1 and higher will be
> pervasive enough that devs just use it without detection, and only
> some browsers will support ES4. At this point having syntax already
> in ES3.1 means the syntax can be used, and the methods/properties
> that we deferred to ES4 can be detected and used optionally. At this
> point in the future, syntax that we don't include won't be useful
> for the reason you mention, but properties/methods we don't include,
> can be detected and optionally used.
I'm not sure if the concrete benefit of "no new syntax" outweighs the
benefits of possible pieces of new syntax. I just wanted to explain
why I don't think it is totally arbitrary. If not this rule, then I am
not sure what rule we would set. If we start adding selected new
syntax to ES3.1, then it just turns into "the parts of ES4 that
Microsoft is willing to implement". While I can see how this would be
of practical interest to scripters, I do not think it is a principled
way to design a specification.
ECMAScript in general has an issue with addition of syntax that the
other major web standards don't. CSS and HTML both have a simple
surface syntax and a well-defined way to handle unknown terms. I think
we should consider adding features to ES4 and ES3.1 to allow future
extension of the syntax in a way that degrades gracefully.
More information about the Es4-discuss