Re: JavaScript APIs organization

Hi, Dom-

I've had similar concerns, but larger organizational and logistical 
issues to resolve first.

If you propose a concrete structure, maybe informed by MDN's choices, 
I'm very open to rearranging this part of the docs.


On 10/15/12 6:29 AM, Dominique Hazael-Massieux 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
>>> 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 Wednesday, 17 October 2012 18:18:44 UTC