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

Re: Ringmark is now open source

From: Tobie Langel <tobie@fb.com>
Date: Mon, 16 Apr 2012 17:33:56 +0000
To: James Graham <jgraham@opera.com>
CC: Thaddee Tyl <thaddee.tyl@gmail.com>, "lbolstad@opera.com" <lbolstad@opera.com>, "public-coremob@w3.org" <public-coremob@w3.org>
Message-ID: <CBB1B5FA.79C1C%tobie@fb.com>

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.

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.

>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

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.

>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

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?


[1]: http://test262.ecmascript.org/
Received on Monday, 16 April 2012 17:34:57 UTC

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