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)
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)
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)
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.
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)
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 mozilla.org Then have a mozilla.org 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
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)
- Yes, that was exactly my thinking. For me,
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
http://developer.mozilla.org/en/docs/XULRef_%28link%29 http://developer.mozilla.org/en/docs/index.php?title=XULRef_%28link%29&rcid=31774 http://developer.mozilla.org/en/docs/index.php?title=Walidator_XML_%28link%29&rcid=31760
Ptak82 23:47, 1 May 2006 (PDT)
Templates for non-standard stuff
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)
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:
Wikified (but on a newer version of MediaWiki).
- 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)
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.)
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)
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 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
Errorinstances will inherit from
Error.prototype. For a list of properties and methods inherited by
Errorinstances, 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 how things were done before).
Here are some pages to illustrate what I mean:
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)