W3C home > Mailing lists > Public > public-coremob@w3.org > April 2012

Re: Ringmark is now open source

From: James Graham <jgraham@opera.com>
Date: Mon, 16 Apr 2012 22:49:45 +0200 (CEST)
To: Tobie Langel <tobie@fb.com>
cc: James Graham <jgraham@opera.com>, Thaddee Tyl <thaddee.tyl@gmail.com>, "lbolstad@opera.com" <lbolstad@opera.com>, "public-coremob@w3.org" <public-coremob@w3.org>
Message-ID: <alpine.DEB.2.00.1204162226350.24600@sirius>
On Mon, 16 Apr 2012, Tobie Langel wrote:

> On 4/16/12 11:37 AM, "James Graham" <jgraham@opera.com> wrote:
>> On Sun 15 Apr 2012 02:25:11 AM CEST, Tobie Langel wrote:
>>> So I absolutely agree both specs should give a very clear signal that ES5
>>> is the target. I don't want to make all of ES5 a requirement in level 0
>>> however
>>> as a) devs don't rely on all the features and b) there aren't any fully
>>> compliant (mobile) implementations yet.
>> Neither are there any fully compliant mobile implementations of ES3.
>> But all browsers are now targeting ES5.1, including in cases where
>> there are different requirements for ES5.1 vs ES3. Since there isn't
>> strict backwards compatibility between the two languages, it's not
>> really possible to say "ES3 + x" and come up with something that any
>> implementation should target.
> I agree this is a problem and is what I've been struggling with. Saying
> "ES5.1 - y" does seems slightly better but it does have similar issues.
>> It feels like you don't want to add ES5.1 as a requirement because of
>> some existing browser.
> Well, given no mobile browser pass test262[1] and coremob level 0 is
> mean't to be a description of the reality, it is contradictory to make
> full compliance a requirement. Furthermore it reenforces the idea that
> failing to implement a small, underused part of a spec is the same as
> failing to implement a big, commonly used part of it.

But this is a problem for any spec we require. It's pretty likely that for 
any given spec we can find an edge case that will fail in each existing 
browser even when the implementations are essentially interoperable. 
Certainly ES3 is worse than ES5.1 in this regard; [1] shows the results of 
the Sputnik testsuite; one of the largest compliance testsuites for ES3 
(subsequently updated for ES5 and added to the official test262 
testsuite). You can see that Opera gets the best score failing 78 tests.
I was doing QA on the javascript engine at the time and so I know that 
~all of those fails were intentional deviations from the spec to be more 
web compatible. ES5.1 removed some of these compatibility problems so it 
is possible to do rather better on the official testsuite.

My essential point is this: if your criteria is no fails on the most 
comprehensive testsuite we can find then we are going to be restricted 
mainly to things where the testsuites aren't good enough. We won't be able 
to require that browsers load documents (document loading has horrible 
interoperability) or expose DOM APIs (most browser DOM bindings have 
distinctive bugs according to how they are created) or do any of the other 
things that we expect that a browser can do. There had to be a level of 
"good enough" that is less than perfect. On the other hand we also want 
people to be motivated to get from "good enough" to "perfect".

> For example, developers targeting mobile devices expect Array iterables to
> be available. Not implementing those is very much an issue. No
> implementing Object.freeze: not so much.

Is there any actual browser that has implemented one but not the other?

>> But the specification is clearly written as a
>> specification for UAs. I don't see the value in specifying that future
>> UAs must target less than they actually do target based on the fact
>> that some legacy UA didn't have a full implementation of some new
>> feature.
> Agreed that's not what we're trying to do either. What we're trying to do
> however is to make sure that their implementation is a superset of the
> ones (existing today) that developers have come to rely upon.
> Again, the idea here is to avoid the case where browser A implements ES5
> minus JSON and browser B implements ES5 minus Array iterables because is
> forces developers to polyfill both.

So in general I agree that having a coherent feature set backed up by 
tests and so on is a good thing. I don't agree that ES is something that 
needs to be subsetted in this way. And in general I think subsetting is a 
bad thing; other groups have tried subsetting various things at various 
times (making profiles of HTML and so on) and it never seems to go well.

>> If you also want to write a document that has requirements on authors
>> then it could make more sense to give some requirement to avoid
>> features that are known to have buggy or missing implementations in
>> extant UAs. But no one seems to be working on that document at the
>> moment.
> You're making an important point here. I've seen specs (DOM 3 I think)
> which have specific comments for implementors and for authors in the spec.
> Could this be something we'd want to explore for coremob? Could this help
> us solve problems like indicating the prefixed nature of the current
> implementation of a spec?

Certainly I can see the value in a document indicating which features are 
known to be relatively interoperable in various browsers. I am not sure 
that the W3C is a better place to do that than caniuse.com, although it 
may be a better place to write tests to back it up (as per the above, 
however, these will have to be interpreted in an informed way rather than 
just counting fails).

[1] http://blog.chromium.org/2010/03/does-your-browser-behave.html
Received on Monday, 16 April 2012 20:50:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:45 UTC