On Wednesday, June 8, 2016 at 2:29:03 PM UTC-7, Morgan Reece wrote:
> After spending some time looking at the date parsers in SpiderMonkey, V8,
> and Chakra I think the most sensible way to fix this situation once and for
> all is to create a date parsing grammar and lobby to have it put into the
>
I'm trying to create a union of the quirks, though it may indeed turn out
to be an intersection instead. If that is the case my hope is that other
implementations will compromise by submitting amendments to the proposal.
2016-06-09 0:33 GMT-07:00 :
> On Wednesday, June 8, 2016 at 2:29:03 PM UTC-7
If engines pass parsing through to system libraries, it may be difficult
for them to fully specify their quirks.
Having things that currently fail become valid could also change the
behaviour of existing programs that do speculative parsing; something to
keep in mind.
Mike
On Thu, Jun 9, 2016 a
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
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
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 A
On Thu, Jun 9, 2016 at 5:02 AM, Mike Shaver wrote:
> If engines pass parsing through to system libraries, it may be difficult
> for them to fully specify their quirks.
>
True; I wouldn't be surprised to see experiments assessing the impact of
specific proposals turning out to be influential.
Ha
Thank you for the additional issues to consider. The existing API is indeed
fragile but for the moment I'm optimistic that we can create a drop in
replacement with minimal issue. I prefer this approach because leaving `new
Date(...)` the way it is will not address the inconsistencies which are our
I certainly get the argument in favor of new APIs over changes to old APIs.
But when an API behaves inconsistently from one browser to the next, it
seems to me the argument for preserving its specification gets a lot
weaker. ECMAScript has pinned down under-specified behaviors plenty of
times.
On
The more I think about this, the more I'm coming around to Shaver's
position. The volume of code on the web is such that it's not a bad first
approximation to just think of it as a complete cover of every observable
behavior the APIs exhibit. And so much of it is poorly maintained, or not
actively
And spec'ing the union of every browser's quirks is not practical.
Chrome's implementation, in particular, is very lenient, even accepting
"JanZ ..Zu.aZ.r.Zzy.Z . 1 2016" as 2016-01-01.
On 6/9/16 2:09 PM, Jim Blandy wrote:
The more I think about this, the more I'm coming around to Shaver'
11 matches
Mail list logo
