I agree with the motivation of the proposal: provide reliable cross-browser date parsing capability. The choices are:
- change the behaviour of an existing, fragile API - add a new API with well-specified behaviour To take advantage of the former case, a program must know that it's running in an engine that has updated to the spec, by version checks or (less likely on the web, IMO) probing with known patterns. To be damaged by the former case, it need only trip over an edge case that was deemed insignificant. To take advantage of the latter case, a program must also know that it's running in an engine that has update to the spec, but it can do that through feature testing. A program can't be damaged by the latter case. I am in favour of the latter case. Mike On Thu, Jun 9, 2016 at 11:49 AM, Jim Blandy <jbla...@mozilla.com> wrote: > I'm not sure where you're going with this, other than, yes, any observable > change to an API can have a negative impact. Making behavior consistent > across browsers often has a positive impact as well. > > Do the observations you made suggest ways to improve the proposal? > > On Thu, Jun 9, 2016 at 11:43 AM, Mike Shaver <mike.sha...@gmail.com> > wrote: > >> On Thu, Jun 9, 2016 at 11:42 AM, Jim Blandy <jbla...@mozilla.com> wrote: >> >>> The current behavior varies from one browser to another anyway. Assuming >>> the new grammar only codifies existing practice, won't any such programs >>> already be behaving inconsistently across browsers? >>> >> >> Many programs adapt to the browser they're running in. >> >> Mike >> >> > _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
