User talk:Nickolay

Please add comments in a separate section, new comments at the bottom. To make it easier to track the discussion, I will reply here and I ask you to do the same. --Nickolay 13:18, 2 September 2006 (PDT)

No header

I thought that it was better than nothing, and someone can overwrite it anytime they've got something better. --Briprowe 18:07, 29 Jul 2005 (EST)

Deletion Requests

Re: your not on User_talk:Callek

I agree that simply no links is not enough, my opinion has been shaped somewhat since then. Feel free to drop any of the requested deletions off that page if you have a feeling they should stay.

I'll Create a (temporary) page Somewhere later on, (where I'm not too sure); to list all Redirects that are intended to stay, and why (if not blatantly obvious). In the future, this can be replaced by using Category links on each redirect page to categorize "why it is staying", but that needs to wait until Redirects are categorizeable.

--Callek 21:59, 3 Aug 2005 (PDT)

XSLT reference

I guess I don't know how to do a simple redirect. I deleted the content of my pages and added a link to the new pages. There are no longer any links to my pages anyway.

Thanks for the heads up about the new XSLT reference. I didn't know it was there. It appears that XSLT:Elements and XPath:Axes are filled in with up-to-date content on every page.

XPath:Functions appears to be full of blank pages. I guess that's where I'll start filling things in. If there's anything else I can focus on in the XSLT/XPath section, I'd be glad. Jonnyq

Re: Redirect Categories (from User_talk:Callek) I agree it may not be maintained well enough, but what I do hope to acheive is a de-facto standard here about "what do we do about redirects". I intend to propose a MW change to polvi/shaver/dria et-all which will put an "Should This Redirect Stay" category on all page moves, (not self-created redirects however). This will help to "keep up with" it all, I will also poke Polvi to run a SQL query to find all pages which are redirects for me, so I can categorize them as either "needs to be deleted" or "needs to stay" or "I am not sure". This is to help keep devmo clutter down, especially as we develop rules for these things. The document one, was simply a quick and dirty test of what I am thinking of doing. Not-so-much a "final thing". I would still need to create a Category: information, and other things. And this would bake on the mailing list before I went "all out" on categorizing it. Worst case I would do is a manually updated page in my User (or Devmo) area saying which ones are meant to stay. --Callek 10:38, 26 Aug 2005 (PDT)

Re: User_talk:Callek#External_redirects

I do not feel strongly about it in this case, though I do feel strongly about ones which have any semblance of being migrated instead. (Such as the "Priority Items for Migration" external redirects on the existing content page. --Callek 11:27, 21 September 2005 (PDT)

Based on re-reading your comments (and dria's posted today) at Help_talk:External_Redirects I'll concede this point, and possibly consider writing up a Special: page to enumerate all "real" external Links used, (and allow searching of them) this would need to be discussed with dria and company first, and of course be after my creation of Special:Redirects. --Callek
My biggest desire for this was to NOT have recursive redirects abound, (link TO Then have a page redirect to a page HERE, and then possibly have THAT page redirect to its "resting" location HERE) just seems like alot of extra work to me --Callek 23:15, 21 September 2005 (PDT)


Thanks for the telling me about the Help:Contents section for Help:Wiki_Markup_Reference info. I guess I'm blind. I went ahead and removed it from the Preferences System discussion since it's not really related. --S280Z28

Re: document.loadOverlay

I also prefer DOM prefix for this, when we have the common setup it "just makes sense" to me to use it, we can keep redirects to allow "accidental linking" but imho, all links to redirects should be periodically changed to links to the actual article. I await Waldo's reply --Callek 08:36, 11 December 2005 (PST)

The point of the change was to eliminate a redirect that will have to happen every time that link's clicked, which will increase the time it takes for that link to load. In order for MDC to be most useful it has to be snappy, and a redirect is not going to be snappy. As for prefixed vs. unprefixed editability, is one really that much easier than the other in the long run? Creating the link is a one-time process, but links will be used hundreds of times. It may take (generously) an extra half-minute to use the long form, but that half-minute will easily be eaten up as more and more users click the link. This site is for the user, not for the editor, and when it comes to link forms I think user needs outweigh editor needs. But anyway, having a guideline for this makes some sense. I wouldn't prioritize it too much, tho, because it's nothing MDC users will actually see, and lack of content is a much more important problem than slightly varying link styles.--Waldo 14:02, 11 December 2005 (PST)

Creating toolbar buttons

Re: this; To me, the <div class="note"> makes sense here, while to me your change is not "wrong" it is not as clear/apparant to someone finding that article and wants to do it without knowing the needed material. I'll leave the final call on what version to use up to you though. --Callek 21:38, 30 January 2006 (PST)

Nickolay's version (without the "note" div) is more appropriate I think. As the second paragraph of the introduction it makes perfect sense as part of the regular text of the article. -- dria 06:13, 31 January 2006 (PST)
Yes, that was exactly my thinking. For me, class="note" is for drawing reader's attention to something important that could be missed without the special formatting (for example for a note between long text paragraphs). In this case, it's the second paragraph, which is separated from the rest of article with a TOC div. Pretty easy to notice. Also the note div and the TOC div didn't look good together (at least for me).
BTW, you can comment on the ordinary talk pages, there's a pretty high chance I'll notice it. --Nickolay 16:45, 31 January 2006 (PST)


... for the fixes you've been making to A_re-introduction_to_JavaScript --Simonw 23:02, 13 March 2006 (PST)

To delate

Please delate this redirect links, that might links to polish devmo but I didn't change 'en' to 'pl', and I saved this redirect link in english devmo - sorry

Ptak82 23:47, 1 May 2006 (PDT)

Done --Nickolay 01:03, 2 May 2006 (PDT)
Thanks Ptak82 01:42, 2 May 2006 (PDT)

Templates for non-standard stuff

Yesterday I created Template:non-standard inline and Template:non-standard header to go along with Template:deprecated inline, Template:obsolete inline, Template:deprecated header, and Template:obsolete header with the intent of tagging all the pages within the JavaScript Reference that document non-standard behavior. Today I noticed we already have Template:not standard and Template:not standard inline. Oops.

I was going to suggest deleting the two templates I created yesterday, until I began to wonder whether we should use "not standard" rather than "non-standard" and I noticed that Template:not standard doesn't follow the same naming scheme (it isn't named not standard header).

In the event that you choose to keep the "non-standard" templates, I'll replace the other templates, and I think I'll adopt orange for the colors. If you decide to keep the "not standard" templates, I'll mute the colors and tag away. Until then, I won't use either one before a decision is made. [unsigned, by User:Sevenspade]

I think it makes sense to use the common naming scheme. However, I'm not sure which one of "Non-standard_inline" and "Not_standard_inline" is better, but whatever is chosen, I think it should match the text we put in the template. FWIW, I like your variant slightly better.
When you start using the templates, please add them to MDC:Custom_Templates.
You may want to discuss this with others or be bold and just use the templates you created. Once we decide which templates to use, you can put the rest in Category:Junk and somebody will delete them. Thanks! --Nickolay 13:29, 2 September 2006 (PDT)
Thanks. I think I will change the uses of the old templates to the newer ones. I don't have enough time to start tagging the JavaScript Reference today, though. Sevenspade 14:26, 2 September 2006 (PDT)

getElementsByTagNameNS pages

The getElementyByTagNameNS pages you just fixed were basically copies of the namespace-unaware getElementsByTagName pages. So you might want to fix those as well. ;) --Andreas Wuest 13:39, 4 October 2006 (PDT)

Build doc edits

Look this page's source. The <nowiki></nowiki> tags are when there is something in <pre> or anything else that you don't want wikified. For example:

{{ :en/Build_Documentation/TOC() }}

Wikified (but on a newer version of MediaWiki).

{{:Build Documentation:TOC}}

Not wikified.


About the page moves...better organisation. Ivise301 Talk - Contribs 11:08, 24 December 2006 (PST)

New page names...done. Check out Build Documentation. Ivise301 Talk - Contribs 11:13, 24 December 2006 (PST)
I know what nowiki is for. What I don't get is why you insert it everywhere, even when there's no visible effect of using it. Doing so just makes the markup more verbose.
As for page moves, you should update all links (using the What Links Here feature), otherwise the next time someone moves those pages, the redirects will become double-redirects and will stop working. --Nickolay 22:21, 24 December 2006 (PST)
BTW, the nowiki tags fscked up the shell examples in Mozilla Source Code (CVS) heavily, the second line now always gets indented.--Andreas Wuest 03:29, 25 December 2006 (PST)

Style manual?


Thanks for your comments at User talk:Ruakh. Does the MDC have a style manual somewhere with all that sort of information? (I've read MDC:Writer's guide, but it doesn't mention anything like what you mentioned.)

Thanks again,

Ruakh 10:27, 16 February 2007 (PST)

Not really, I'm afraid. I think there would be few non-obvious things there anyway, so just keep editing :) --Nickolay 10:50, 16 February 2007 (PST)

Can you elaborate further on what kind of contributions are welcome on the wiki?

Hi, thanks for your comments at User talk:Hamstersoup. I've added some questions, could you elaborate further on what you are looking for / not looking for. Thanks, --Hamstersoup 14:52, 5 March 2007 (PST)

Scriptable Objects missing from wiki

Hi Nickolay, I notice that many of the Scriptable Objects mentioned at XUL Planet are missing from the wiki. Are there any plans to add them all? For example, I wanted to add a comment about converting HTMLCollection to an Array. --Hamstersoup 09:16, 9 March 2007 (PST)

I would hope so. You could bring this up on dev-mdc. --Nickolay 09:51, 9 March 2007 (PST)

Inherited properties/methods in JavaScript Reference

One of the things that reorganization is supposed to fix is the ambiguity between static and non-static methods and properties, since stuff like Object:toString will be moved to JS:Object.prototype.toString. As an extension of this, to differentiate between the two, I've been thinking about moving the non-static property and method lists from the their respective constructors' pages and to constructor:prototype pages. I've gone ahead and made some initial changes like this to the Error and NativeError pages, since these pages were non-existent until I created them earlier this month and I figured I could


<ins>experiment</ins> with my ideas on these pages and see how I liked the result. I've also created the JSInherits template and used it on these pages.

But now I'm torn on this approach. Currently the Error page says

Error instances will inherit from Error.prototype. For a list of properties and methods inherited by Error instances, see Error.prototype.

The distinction I'm going for here is that the Error page (and eventually all other constructors' pages) should document the object/function itself, while the behavior of instances of that object should be described at the constructor.prototype page. I think the former of these described effects makes perfect sense while the latter is a bit of a stretch to rationalize. The alternative, of course is to let constructor.prototype pages document only the prototype object itself and not instances of that object and to use the JSInherits template on the constructor page for all properties and methods inherited by instances of that constructor; essentially, we would be documenting both the constructor and instances on the same page (which was


<ins>kind of</ins> how things were done before, <ins>although they were much less straightforward</ins>).

Here are some pages to illustrate what I mean:

Variant 1/Error
Variant 1/Error.prototype
Variant 2/Error
Variant 2/Error.prototype

Variant 1 is what I envisioned and things are halfway there now. Variant 2 is moving things back the way they were: moving the description of instances out of Error.prototype and letting that page strictly describe properties and methods of the prototype object, but there are adverse effects of variant 2 to Error. I think it seems slightly confusing, shifting between describing the Error object itself and the instances created by it.

So which do you think is better? Or is there another form that you would prefer beside these two? -- Sevenspade 17:41, 13 December 2007 (PST)

I think variant 1 is okay. I'm not really intimate enough with the nuances of JavaScript at issue here to feel 100% comfortable making this call, so I think my position is: "I don't have a problem with it, so if it makes sense to folks that know more about JavaScript than I do, go for it.". --Sheppy 08:14, 17 December 2007 (PST)

Bogus permissions

Sorry, I only just noticed your question. Normally when creating files on Unix, you should respect the user's umask, unless you have specific reason to restrict it. So, for creating a public directory or executable, you should always use 0777; other public files should use 0666; private files should use 0600. --Neil 07 February 2010