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
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.
On Thu, Jun 9, 2016 at 11:49 AM, Jim Blandy 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
>> On Thu, Jun 9, 2016 at 11:42 AM, Jim Blandy 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.