Sevenspade (:crussell)

  • Revision slug: User:Sevenspade
  • Revision title: Sevenspade (:crussell)
  • Revision id: 129740
  • Created:
  • Creator: Waldo
  • Is current revision? No
  • Comment respond to comment

Revision Content

I will be mostly (probably exclusively) working on the JavaScript Reference pages.

TODO

Implementation history

Currently, most pages in the JavaScript Reference have a table documenting that particular object/method/property's existence throughout each version of JavaScript. These usually look something like this:

Method of Object
Implemented in: JavaScript 1.x, NES x.0 , JScript ''x''.''x''
ECMA Version: ECMA-262

I plan to work on fully documenting the implementation history and backwards compatibility of each aspect of JavaScript. Changes in behavior for different versions should be noted (particularly JavaScript 1.2). The ECMA specification line is pretty unhelpful because it does not include the revision number for the specification, leaving articles to contain only "ECMA-262," the only ECMAScript specification document (as of now). This should be remedied by adding information about changes to the spec in each revision.

Additionally, should we keep information about Netscape Enterprise Server? Should we include information about implementation in JScript? If so, do we then include information about implementation in Opera? KJS/JavaScriptCore? Currently, there is little-to-no mention of specific browser versions in the Reference, instead referring to everything in the abstract "JavaScript 1.x" way. I think this reference should strive to remain fairly browser neutral, and that the best way to do that would be to continue referring to everything strictly as JavaScript, even if it is a bit Mozilla-biased.

Reply to (formatting)

...you've been changing the Syntax sections' markup from using code tags to using leading-space preformatted blocks and adding variable declarations, although this isn't the way things are handled in the rest of the reference.

I'm not sure how closely you'd follow my talk page, so I'm responding here. Oh, how I hate the talk-page mechanism...

The leading-space preformatted blocks are cleaner and more readable than the code-formatted ones. The code in effect looks like it's been blockquoted, you don't get misalignment for the first line due to a leading opening code tag (or a gratuitous newline), and on-page it's displayed in a box with a background to distinguish it from article text. The other alternative that I occasionally use is a pre tag, only because HTML (and wiki formatting) in it is interpreted as raw text. As for why it doesn't use the indent-formatting already, that's partly because the initial importer didn't know about it at the time. We were all new to wiki syntax at the time, and we pick it up as we go.

Finally, the code-changing issues. First, let me say the original way the reference did it (e.g. just propertyIsEnumerable(p)) was completely unacceptable. Even though most methods are almost invariably called on objects, the reference just didn't show them being used that way, making them basically useless. I've been fixing that as I edit pages in the reference. (I'd be surprised if I haven't converted more than half, to be honest.) Second, var. The reason I've been adding var is that this code will be copy-pasted a lot. Without var, any one of these will create a global variable, breaking modularity and eventually setting up whoever's done this for a fall when they depended on the assignment being local. We should not promulgate code with a hidden gotcha like this when it's so trivial to avoid the problem.

I think we should change back the edits you made to undo these changes, but I'd at least like to try to convince you that there are good reasons for the changes before reverting. Let me know your feedback (here or on my page, either works as I read the recent changes feed), and we'll work from whatever your understanding is to some sort of agreement. --Waldo 11:37, 1 December 2007 (PST)

Revision Source

<p>I will be mostly (probably exclusively) working on the <a href="en/Core_JavaScript_1.5_Reference">JavaScript Reference</a> pages.
</p>
<h3 name="TODO"> TODO </h3>
<h4 name="Implementation_history"> Implementation history </h4>
<p>Currently, most pages in the JavaScript Reference have a table documenting that particular object/method/property's existence throughout each version of JavaScript. These usually look something like this:
</p>
<blockquote>

<table class="fullwidth-table">
<tbody><tr>
<td class="header" colspan="2">Method of <a href="en/Core_JavaScript_1.5_Reference/Objects/Object">Object</a></td>
</tr>
<tr>
<td>Implemented in:</td>
<td>JavaScript 1.<i>x</i>, NES <i>x</i>.0 <span class="comment">, JScript ''x''.''x''</span></td>
</tr>
<tr>
<td>ECMA Version:</td>
<td>ECMA-262</td>
</tr>
</tbody></table>
</blockquote>
<p><strike>I plan to work on fully documenting the implementation history and backwards compatibility of each aspect of JavaScript. Changes in behavior for different versions should be noted (particularly JavaScript 1.2). The ECMA specification line is pretty unhelpful because it does not include the revision number for the specification, leaving articles to contain only "ECMA-262," the only ECMAScript specification document (as of now). This should be remedied by adding information about changes to the spec in each revision.</strike>
</p><p>Additionally, should we keep information about Netscape Enterprise Server? Should we include information about implementation in JScript? If so, do we then include information about implementation in Opera? KJS/JavaScriptCore? Currently, there is little-to-no mention of specific browser versions in the Reference, instead referring to everything in the abstract "JavaScript 1.<i>x</i>" way. I think this reference should strive to remain fairly browser neutral, and that the best way to do that would be to continue referring to everything strictly as JavaScript, even if it is a bit Mozilla-biased.
</p>
<h2 name="Reply_to_.28formatting.29"> Reply to (formatting) </h2>
<dl><dd> ...you've been changing the Syntax sections' markup from using <code>code</code> tags to using leading-space preformatted blocks and adding variable declarations, although this isn't the way things are handled in the rest of the reference.
</dd></dl>
<p>I'm not sure how closely you'd follow <i>my</i> talk page, so I'm responding here.  Oh, how I hate the talk-page mechanism...
</p><p>The leading-space preformatted blocks are cleaner and more readable than the code-formatted ones.  The code in effect looks like it's been blockquoted, you don't get misalignment for the first line due to a leading opening code tag (or a gratuitous newline), and on-page it's displayed in a box with a background to distinguish it from article text.  The other alternative that I occasionally use is a pre tag, only because HTML (and wiki formatting) in it is interpreted as raw text.  As for why it doesn't use the indent-formatting already, that's partly because the initial importer didn't know about it at the time.  We were all new to wiki syntax at the time, and we pick it up as we go.
</p><p>Finally, the code-changing issues.  First, let me say the original way the reference did it (e.g. just <code>propertyIsEnumerable(p)</code>) was completely unacceptable.  Even though most methods are almost invariably called on objects, the reference just didn't show them being used that way, making them basically useless.  I've been fixing that as I edit pages in the reference.  (I'd be surprised if I haven't converted more than half, to be honest.)  Second, <code>var</code>.  The reason I've been adding <code>var</code> is that this code will be copy-pasted a lot.  Without <code>var</code>, any one of these will create a global variable, breaking modularity and eventually setting up whoever's done this for a fall when they depended on the assignment being local.  We should not promulgate code with a hidden gotcha like this when it's so trivial to avoid the problem.
</p><p>I think we should change back the edits you made to undo these changes, but I'd at least like to try to convince you that there are good reasons for the changes before reverting.  Let me know your feedback (here or on my page, either works as I read the recent changes feed), and we'll work from whatever your understanding is to some sort of agreement. --<a href="User:Waldo">Waldo</a> 11:37, 1 December 2007 (PST)
</p>
Revert to this revision