Re: JS content plan

I seem to have caught up with everything now.

I think Rick Byers is right - and I mentioned this before, too - that the
suffixes ("x Function", "x Method" and so on) should be dropped.

Like I wrote above (or is it below? ;)), about the suggestion of Rick
Waldron, I think "prototype" is too ECMAScript specific and while
ECMAScript is currently the language of the web, we need to think forward a
bit and not get too caught up on ECMAScript terms, since developers that
are just starting out would be more familiar with "instance" rather than
the rather specific term, "prototype".
Inconsistency with the rest of the namespaces is bad. Either every non
static thing has a prototype in the path, or none.

And I also agree that it should be "API" (or "api") or something similar,
instead of "Objects".


☆*PhistucK*


On Wed, Nov 13, 2013 at 9:04 PM, Julee Burdekin <jburdeki@adobe.com> wrote:

> Hi, PhistucK:
>
> Thanks for that. And we will definitely wait until at least next week, as
> Doug will be back and we can get on with the import & template work then.
>
> Regards!
> J
> ----------------------------
> julee@adobe.com
> @adobejulee
>
>  From: PhistucK <phistuck@gmail.com>
> Date: Wednesday, November 13, 2013 at 5:20 AM
> To: julee <jburdeki@adobe.com>
> Cc: Eliot Graff <Eliot.Graff@microsoft.com>, WebPlatform Public List <
> public-webplatform@w3.org>
>
> Subject: Re: JS content plan
>
> I am sorry, I did not have time to read through the feedback Doug
> forwarded a few days ago and I did not follow this thread.
>  I would appreciate if you could wait until after the weekend before
> making any practical steps so I could chime in.
>
> One thing I read in the feedback that seems weird to me is the addition of
> "prototype" to the path that was suggested. If this is how it is going to
> be, it should be consistent among all of the APIs, because there are
> (fairly few) objects in the APIs namespace that have static properties as
> well and thus are not part of the prototype.
> So either everything includes "prototype" in the path, or none. I do not
> think inconsistency would be good here (even though I know these are two
> different areas and that APIs are not strictly related to ECMAScript).
>
> Regarding my personal opinion - even though I generally favor correctness,
> in this case, I think including "prototype" in the path is a bit over
> verbose. I think it is enough to indicate "static" at the top of the page
> somewhere and "prototype" within the actual syntax example.
>
>
>
> ☆*PhistucK*
>
>
> On Wed, Nov 13, 2013 at 10:49 AM, Julee Burdekin <jburdeki@adobe.com>wrote:
>
>> Yes! But, we do not have someone to work on the templates right now. I
>> was hoping whoever was going to do that could act in the same manner as
>> Scott did before.
>>
>> J
>>
>>
>> Sent from my "smart" phone... go figure...
>>
>>
>> -------- Original message --------
>> From: Eliot Graff
>> Date:11/12/2013 11:54 PM (GMT-08:00)
>> To: Julee Burdekin ,WebPlatform Public List
>> Subject: RE: JS content plan
>>
>> Yes, like that! Do we need people to flesh out page structures like that?
>>
>>
>>
>> Thanks,
>>
>>
>>
>> E
>>
>>
>>
>> *From:* Julee Burdekin [mailto:jburdeki@adobe.com]
>> *Sent:* Wednesday, November 13, 2013 2:40 PM
>> *To:* Eliot Graff; WebPlatform Public List
>> *Subject:* RE: JS content plan
>>
>>
>>
>> Hi, Eliot!
>>
>> I hope I'm answering your questions, here.
>>
>> Max has broken down the reference into the 9 top-level categories.[1] In
>> that list, is an implied granularity. So, that's what'll be imported in. We
>> may want to break down some of these more (separate pages for each error
>> type, for instance), but this is the starting point for the page-level
>> granularity. So we should review the pages and determine if a special
>> template is needed: for example, the reserved word page doesn't need it's
>> own template, right?
>>
>> But we do need new templates for some JS language elements, right? For
>> example, the Object template would need the following semantic fields:
>>
>> * Summary (currently non-existent, appears in non-titled first section of
>> content)
>>
>> * Syntax (currently non-existent, appears in non-titled first section of
>> content; derived content)
>>
>> * Parameters
>>
>> * Usage (currently part of "Remarks" section)
>>
>> * Examples (currently part of "Remarks" section)
>>
>> * Properties (derived content)
>>
>> * Functions (derived content)
>>
>> * Methods (derived content)
>>
>> * Specification link (currently in "Requirements")
>>
>> * Compatibility (currently in "Requirements")
>>
>> * Attribution (currently non-existent)
>>
>> * See also (currently non-existent)
>>
>> Is that the kind of thing you're looking for? What do you think?
>>
>> Julee
>>
>> [1]
>> http://docs.webplatform.org/wiki/WPD:Projects/javascript#Top-level_pages
>>
>>
>>
>> Sent from my "smart" phone... go figure...
>>
>>
>>
>> -------- Original message --------
>> From: Eliot Graff
>> Date:11/12/2013 8:04 PM (GMT-08:00)
>> To: Julee Burdekin ,WebPlatform Public List
>> Subject: RE: JS content plan
>>
>> Hi Julee.
>>
>>
>>
>> Thank you so much for doing this.
>>
>>
>>
>> How granular do you think we need to go on the templates for the
>> reference page? Do we need a separate template for functions, operators,
>> objects, etc.? At the last Seattle doc sprint, people were looking for
>> guidance like that for HTML elements, attributes, at the more granular
>> level. I know for CSS we really just had the one Font property page as the
>> exemplar. But that may be a different animal.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Eliot
>>
>>
>>
>> *From:* Julee Burdekin [mailto:jburdeki@adobe.com <jburdeki@adobe.com>]
>> *Sent:* Wednesday, November 13, 2013 10:06 AM
>> *To:* WebPlatform Public List
>> *Subject:* JS content plan
>>
>>
>>
>> Hi, folks:
>>
>>
>>
>> I’ve started a content plan for the JavaScript import.[1] Please feel
>> free to add to it, or send feedback my way.
>>
>>
>>
>> Regards!
>>
>>
>>
>> Julee
>>
>> [1] http://docs.webplatform.org/wiki/WPD:Projects/javascript/content
>>
>>
>>
>> ----------------------------
>>
>> julee@adobe.com
>>
>> @adobejulee
>>
>
>