mozilla

Revision 104891 of User talk:Sevenspade

  • Revision slug: User_talk:Sevenspade
  • Revision title: User talk:Sevenspade
  • Revision id: 104891
  • Created:
  • Creator: Sevenspade
  • Is current revision? No
  • Comment + /* Reply to (formatting) */ moving from [[User:Sevenspade]]

Revision Content

Re: Deletion request

Hi there, just wanted to let you know I answered you at User_talk:Nickolay#Templates_for_non-standard_stuff. --Nickolay 13:32, 2 September 2006 (PDT)

JS history

Re the TODO list on your user page - I doubt the information on pre-JS1.5 versions is of any practical interest. After all, JS 1.5 was out for over 6 years now. IIRC someone (brendan?) advocated for removal of pre-1.5 info from the reference.

The ECMA row is helpful as an indicator whether a feature is defined in the standard or a proprietary extension. When we start documenting the JS2 stuff, it may be useful to differentiate ECMA-262 ed. 3 vs ed. 4.

My personal opinion is that NES info is not useful, while information about JS bugs in modern browsers is. --Nickolay 05:10, 5 February 2007 (PST)

Shortly after I created the TODO, I read over Main's message on the mailing list about the removal of the backwards compatibility sections.
When I first began editing, my initial thought was to completely remove the Backwards Compatibility/JavaScript 1.2 sections, but decided against it after assuming its existence was because including the information was a general desire common among other editors (you all). Instead I opted for keeping a very clear distinction between JavaScript 1.2 information (plus other, older versions) and the documentation (of the modern use) of the language. My thoughts on that were that okay, fine, we can keep the older information about backwards compatibility, but if we're going to do that, it should be comprehensive and not just a few, seemingly out-of-place words on JavaScript 1.2.
That's where my plans on expanding "implemented in . . ." boxes came from. Basically, this is my vote in agreement to remove references to deprecated JS versions. I'm aware that you, dria, and Brendan support this, and apparently Maian was fine with it. I will take this to be a "consensus" on the subject and begin making changes when I can.
Similarly, I am in agreement to remove NES information. Also, I guess my comment about the usefulness of the ECMA line was confusing. I am definitely in favor of keeping information regarding ECMA standardization. However, as of now, pages merely mention "ECMA 262," and do not note which revision of the specification first introduced each aspect. This should be fixed.

--Sevenspade 12:49, 7 February 2007 (PST)

The difference between ECMA-262 ed.1 and ed.3 is no more interesting than information on JS 1.2 vs 1.5 --Nickolay 06:58, 9 February 2007 (PST)

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

<h3 name="Re:_Deletion_request"> Re: Deletion request </h3>
<p>Hi there, just wanted to let you know I answered you at <a href="User_talk:Nickolay#Templates_for_non-standard_stuff">User_talk:Nickolay#Templates_for_non-standard_stuff</a>. --<a href="User:Nickolay">Nickolay</a> 13:32, 2 September 2006 (PDT)
</p>
<h3 name="JS_history"> JS history </h3>
<p>Re the TODO list on your user page - I doubt the information on pre-JS1.5 versions is of any practical interest. After all, JS 1.5 was out for over 6 years now. IIRC someone (brendan?) advocated for removal of pre-1.5 info from the reference.
</p><p>The ECMA row is helpful as an indicator whether a feature is defined in the standard or a proprietary extension. When we start documenting the JS2 stuff, it may be useful to differentiate ECMA-262 ed. 3 vs ed. 4.
</p><p>My personal opinion is that NES info is not useful, while information about JS bugs in modern browsers is. --<a href="User:Nickolay">Nickolay</a> 05:10, 5 February 2007 (PST)
</p>
<dl><dd>Shortly after I created the TODO, I read over <a class="external" href="https://mail.mozilla.org/pipermail/devmo-general/2005-November/000538.html">Main's message</a> on the mailing list about the removal of the backwards compatibility sections.
</dd></dl>
<dl><dd>When I first began editing, my initial thought was to completely remove the Backwards Compatibility/JavaScript 1.2 sections, but decided against it after assuming its existence was because including the information was a general desire common among other editors (you all). Instead I opted for <a class="external" href="http://developer.mozilla.org/en/docs/index.php?title=Talk:Core_JavaScript_1.5_Reference&amp;oldid=35790"> keeping a very clear distinction between JavaScript 1.2 information (plus other, older versions) and the documentation (of the modern use) of the language. </a><a class="external" href="http://developer.mozilla.org/en/docs/index.php?title=Talk:Core_JavaScript_1.5_Reference&amp;diff=prev&amp;oldid=36043">My thoughts on that</a> were that okay, fine, we can keep the older information about backwards compatibility, but if we're going to do that, it should be comprehensive and not just a few, seemingly out-of-place words on JavaScript 1.2.
</dd></dl>
<dl><dd>That's where my plans on expanding "implemented in . . ." boxes came from. Basically, this is my vote in agreement to remove references to deprecated JS versions. I'm aware that you, dria, and Brendan support this, and apparently Maian was fine with it. I will take this to be a "consensus" on the subject and begin making changes when I can.
</dd></dl>
<dl><dd>Similarly, I am in agreement to remove NES information. Also, I guess my comment about the usefulness of the ECMA line was confusing. I am definitely in favor of keeping information regarding ECMA standardization. However, as of now, pages merely mention "ECMA 262," and do not note which revision of the specification first introduced each aspect. This should be fixed.
</dd></dl>
<p>--<a href="User:Sevenspade">Sevenspade</a> 12:49, 7 February 2007 (PST)
</p>
<dl><dd><dl><dd> The difference between ECMA-262 ed.1 and ed.3 is no more interesting than information on JS 1.2 vs 1.5 --<a href="User:Nickolay">Nickolay</a> 06:58, 9 February 2007 (PST)
</dd></dl>
</dd></dl>
<h2 name="Reply_to_.28formatting.29"> Reply to <a href="User_talk:Waldo#.28formatting.29">(formatting)</a> </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