- From: Chris Mills <cmills@opera.com>
- Date: Tue, 16 Oct 2012 13:50:07 +0100
- To: Dominique Hazael-Massieux <dom@w3.org>
- Cc: public-webplatform@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