W3C home > Mailing lists > Public > public-webplatform@w3.org > November 2013

Re: Automatic stubs for JavaScript APIs

From: Max Polk <maxpolk@gmail.com>
Date: Sun, 17 Nov 2013 14:16:44 -0500
Message-ID: <CADPfvJu5weCz4CyoEkcvWB9JMqZ+RazP_ihTy6-2xyyPCAGVFg@mail.gmail.com>
To: Webplatform List <public-webplatform@w3.org>
We have an initiative to add pages about JavaScript the language, a kind of
language reference:
    http://docs.webplatform.org/wiki/javascript

A separate existing area is dedicated to APIs:
    http://docs.webplatform.org/wiki/apis

Then there are just popular JavaScript libraries.  The latter may also fall
into APIs, but doesn't necessarily need to.  It might be better to separate
what's built in and standardized versus the latest jQuery, maybe popular
libraries would be under wiki/libraries just to be distinct and be so clear
about what I get by default versus what I get by loading a third-party
library.



On Fri, Nov 15, 2013 at 4:44 AM, Dominique Hazael-Massieux <dom@w3.org>wrote:

> Hi,
>
> I chatted with Eliott this week on a potentially useful tool I've built
> that could be used to generate stubs for JavaScript API pages, based on
> how they're defined in specs (using WebIDL).
>
> As some of you may know, browser JavaScript APIs are described in a
> formal language called WebIDL that lets spec authors describe which
> properties and methods a given JavaScript interface exposes.
>
> As part of my (irregular) work on the W3C cheatsheet:
> http://www.w3.org/2009/cheatsheet/
> I built a ad-hoc workflow that takes an spec written in HTML, extracts
> the WebIDL fragments, and turn them into (somewhat) human-readable
> content that can then be displayed in the said cheatsheet.
>
> I won't get into the details of that workflow, but the most motivated
> readers can try to pull the pieces together from:
> https://github.com/dontcallmedom/w3c-cheatsheet/ esp.
>
> https://github.com/dontcallmedom/w3c-cheatsheet/commit/090e9b929e081fcfd444094a2174f8f5b5d3c861
>
> I could reasonably easily adapt that workflow to make it generate
> mediawiki markup, which could be used as stubs for a large number of
> APIs.
>
> I understand that for the most popular APIs, the preferred approach will
> be to import existing content, but hopefully such an automatic approach
> could help bootstrap the work on the APIs in which no or little content
> already exists.
>
> Is this of interest? If so, what is the best way to proceed with that
> idea?
>
> Dom
>
>
>
>
>
>
Received on Sunday, 17 November 2013 19:17:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:13:55 UTC