User talk:Waldo

bug template

FYI, the bug template has been created, and there's MDC:To Do List now. --Nickolay 04:39, 2 Jun 2005 (PDT)

The block-title template

Please see Help_talk:Custom_Templates. Many links to anchors don't work. --Nickolay 01:14, 18 Aug 2005 (PDT)

What was the point of this change?

The "accidental" links, like [[document.loadOverlay]] are much easier to read and edit than [[DOM:document.loadOverlay|document.loadOverlay]], which is what now on that page (and the third variant, link with "DOM:" in its display text, is clearly not desired).

I'd like to work out a common guideline that everyone would follow. Right now, many of the links I create are to redirect pages, and you seem to prefer to link directly to the target page, even if that makes the wikisource less readable. --Nickolay 08:27, 11 December 2005 (PST)

Yes, mea culpa on the DOM: prefix being displayed -- I distinctly remember previewing the change, so I don't know how I missed it. A response to the rest of the comments is on your talk page.--Waldo 14:04, 11 December 2005 (PST)
Er, where did you get that impression that mediawiki redirects are slow? They are not HTTP redirects - just page aliases. #mediawiki people said they are not noticeably slower. After all, wikipedia makes active use of redirects.
As for this site being for users and not for editors, - true, but then we could all code in XHTML, if editors' convenience didn't matter at all. --Nickolay 15:36, 11 December 2005 (PST)
He never said it didnt matter at all. Hence wiki rather than html + cvs commits ;-). But it is an extra db query or two, and I'd rather avoid the "redirected from" text as well in documentation. Prevents user confusion, et-all. More discussion should probably go to devmo-general. --Callek 16:58, 11 December 2005 (PST)
They're going to be slower than not redirecting no matter how quickly MediaWiki can execute them, so I'd rather not see them used. Callek's point that the redirect message is displayed is also a good one, and it's actually the one that matters most to me as well as the one I should have mentioned first. The redirect message was the subconscious trigger to make me change the page, and it was so subconscious I didn't even remember it. As for using devmo-general, go ahead, but I unfortunately will be unlikely to be able to give much feedback. I'm about 125 messages behind on devmo-general and it's finals time for me, so I only have time for quick-in, quick-out edits (roughly what I've been doing for the past couple weeks, if not months). I'll try to get through the messages, but I doubt I'll catch up until after my last final. :-( --Waldo 21:08, 11 December 2005 (PST)
Ok, I agree the 'redirected from' text sucks. IMO, it just should be fixed in the skin.
I don't agree with the performance point though: a single extra db hit [which is the cost of a redirect page] is not that bad, especially given that we have some caching on top of mediawiki, according to polvi.
I guess my point is that the benefit of avoiding redirects is smaller than the inconvenience it causes to editors. The other point is that we should either use redirects or not, that is have some kind of guideline about it. I'll post to devmo-general later. --Nickolay 05:03, 12 December 2005 (PST)
The redirected from text should not be removed if so it will cause undue confusion when someone type "document.forms" for example, gets shown the "DOM:document.forms" page, and goes to edit it, "wait this is not the right page...what happend" which happend to me before, which is why I pushed to get that status part of the skin back in. --Callek 06:07, 12 December 2005 (PST)
The "redirected from" text has to stay, as it's the only way to effectively get back to a redirect page, which is the only easy way to check the "what links here" list so those links can be fixed. Links to pages that are internal redirects are usually broken and should be fixed by replacing them with proper links. There is, of course, a chance that I have missed part of this thread...if that's the case please let me know. We need to get a better discussion system going -- talk pages kinda suck for this sort of thing. -- dria 06:20, 12 December 2005 (PST)
Remember, this site is for users, and not editors ;) I'm not asking for the text to be removed at all, just put it in a bit less visible place. --Nickolay 07:11, 12 December 2005 (PST)
One purpose of the site, however, is to turn users into editors (readers into writers), and hiding things like that (which could cause confusion and bad linking habits) seems to be of questionable wisdom. Also, pretty low-priority in the overall scheme of things :) -- dria 07:55, 12 December 2005 (PST)

(formatting)

I've noticed that in some of your formatting edits for the JSRef, amongst your other changes, you've been changing the Syntax sections' markup from using <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. Sevenspade 00:27, 1 December 2007 (PST)

Reply to (formatting) by Waldo 11:37, 1 December 2007 (PST)
First, I'd like to say I feel the same about talk pages. It's one of several problems I have with the way edit-mode is handled in MediaWiki.
As for my comment regarding your changes, I was only talking about the changes to the syntax sections, and not example code sections. I think my clarifying that should make it easy to explain my view of the pros and cons. I feel that when deciding between use of a leading-space preformatted block and code tags, that the preformatted blocks should be used for blocks. The syntax sections are rarely more than a single line, and when they are, it is to document multiple uses of the method/property, which doesn't exactly qualify it as a block.
. . . it's displayed in a box with a background to distinguish it from the article text.
Again, I don't know if you thought I was referring to the example code sections, but the syntax sections are very short, usually one line, and those that do contain multiple lines contain no article text in the sense that we are discussing.
. . . the original way the reference did it . . . was completely unacceptable.
I agree with this, which is why I have been leaving your changes to this intact, and changing other pages to follow your example (well, since this morning).
Second, var. The reason I've been adding var is that this code will be copy-pasted a lot.
Again, the issue of copy-and-pasteability is something affecting the code samples and not so much the syntax descriptions. Also, anyone pasting stuff like
var truncatedRepresentation = number.toFixed( [digits] )
rather than typing it out by hand is just lazy and, ultimately, actually wasting effort by the time he or she replaces the affected object, the function parameters, and the variable name with their own identifiers and values. Not to mention, it's quite possible that they aren't even putting the return value into a variable, but instead the many other possibilities. So, in practice, this is of limited convenience. Additionally, when getting to this section when editing an article, I really don't look forward to coming to a standstill in progress before doing
var variableNameThatConciselyConveysTheContentsYetIsGenericEnoughToBeUsedAsAnExampleIdentifierForTheArticle = whatever;
Sevenspade 17:20, 1 December 2007 (PST)

print revisited

I had been in favor of removing the legacy code and DOM stuff from the JavaScript Reference, and so was also in favor of replacing the document.write with print. Potappo pointed out, however, that there is a conflict with window.print. Although the JavaScript shell uses print, I think we'd benefit by using println instead. As you've pointed out before, there's a high likelihood of copy-and-pasting of our examples here, and so those who do so might find it discouraging (and confusing) to find the print dialog popping up (in comparison to a helpful error in the console). So what do you think? -- Sevenspade 15:07, 4 January 2008 (PST)

Document Tags and Contributors

Contributors to this page: Dria, Nickolay, Callek, Waldo, Sevenspade
Last updated by: Sevenspade,