W3C home > Mailing lists > Public > public-webplatform@w3.org > October 2012

Re: JavaScript APIs organization

From: Chris Mills <cmills@opera.com>
Date: Tue, 16 Oct 2012 13:50:07 +0100
Cc: public-webplatform@w3.org
Message-Id: <5193CE38-06E8-4DAB-8EF5-82B985BC6734@opera.com>
To: Dominique Hazael-Massieux <dom@w3.org>
What you propose all sounds reasonable to me. Do you fancy having a go at updating http://docs.webplatform.org/wiki/WPD:Content/Topic_Hierarchy to reflect this? I would rather not do it myself, as I am not a JS expert.

Anyone else got any issues with this? 

Chris Mills
Open standards evangelist and dev.opera.com editor, Opera Software
Co-chair, web education community group, W3C
Author of "Practical CSS3: Develop and Design" (http://my.opera.com/chrismills/blog/2012/07/12/practical-css3-my-book-is-finally-published)

* Try Opera: http://www.opera.com
* Learn about the latest open standards technologies and techniques: http://dev.opera.com
* Contribute to web education: http://www.w3.org/community/webed/

On 15 Oct 2012, at 11:29, Dominique Hazael-Massieux <dom@w3.org> wrote:

> Le lundi 15 octobre 2012 à 11:54 +0200, Dominique Hazael-Massieux a
> écrit :
>> Le lundi 15 octobre 2012 à 10:31 +0100, Chris Mills a écrit :
>>> First of all, we need to make sure
>>> http://docs.webplatform.org/wiki/WPD:Content/Topic_Hierarchy works.
>>> Does this work for JS, and we just need to move the pages so they are
>>> consistently placed? Or could this use some updating? This is the
>>> definitive document that defines the IA for the site.
>> 
>> Thanks for that link, I hadn't stumbled upon it yet :)
>> 
>> I don't think the described hierarchy works for JavaScript stuff; I've
>> already mentioned DOM vs APIs, and the problems with name clashes if we
>> stuff all methods (resp. properties) in dom/methods (resp.
>> dom/properties) [I'll note that the table mentions using
>> dom/apis/methods, rather than "methods/" as a direct child of dom/].
>> 
>> Having "methods" and "properties" for Events in a separate hierarchy
>> might also be troublesome, since at the end of the day, events also have
>> DOM interfaces similar to other DOM interfaces.
>> 
>> The third hierarchy for "js" would probably make sense, but there again,
>> there is a risk of duplication/confusion if the rules of what go in JS
>> aren't crystal-clear. What is outlined in the proposed hierarchy seems
>> to make a strong link between the "js" subtree and the ECMAscript
>> language, which sounds good to me.
> 
> Another sub-tree that would be worth considering in this reorg would be
> the cssom (in css/cssom) one.
> 
> Dom
> 
> 
Received on Tuesday, 16 October 2012 12:50:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:57:34 UTC