- From: Domenic Denicola <domenic@domenicdenicola.com>
- Date: Mon, 6 Oct 2014 13:54:49 +0000
- To: Anne van Kesteren <annevk@annevk.nl>, "Hallvord R. M. Steen" <hsteen@mozilla.com>
- CC: public-webapps <public-webapps@w3.org>, Jungkee Song <jungkees@gmail.com>, Julian Aubourg <j@ubourg.net>
Very cool work Hallvord! This is exactly the kind of stuff that we need more of for today's specs, IMO. From: annevankesteren@gmail.com [mailto:annevankesteren@gmail.com] On Behalf Of Anne van Kesteren > On Mon, Oct 6, 2014 at 3:04 PM, Hallvord R. M. Steen <hsteen@mozilla.com> wrote: >> If you do try this on xhr.spec.whatwg.org, you'll see that quite a lot of the meta data is still valid - it does add plenty of spec links, while warning in the console about the entries that need updating to match this version of the spec. You just need to turn off mixed content blocking if you wish to test this before I have those scripts on a HTTPS URL that allows CORS requests for the JSON file.. > I see. We could make xhr.spec.whatwg.org offer a checkbox that would add these links. We could also host the JSON file in the same repository to make sure the links don't go stale and to enable TLS. I would be happy to help enabling that. +1. We are doing a similar thing for Streams. Tests and spec really need to co-evolve together, and even if some kind soul takes on the burden of writing many of the initial tests, the editor of the spec should ideally be updating the tests as they update the spec. (Or, if that kind soul is awesome enough to stick around, they can help update too.) A solution like the one Anne proposes seems really excellent and I hope you are a fan of it, Hallvord :). In general I am excited about exploring this kind of living-test-suite approach as I think it provides a much-needed indicator of how far "ahead" of browsers living standards are, thus mitigating one of their main drawbacks.
Received on Monday, 6 October 2014 13:55:20 UTC