User talk:Clindberg

From Wikipedia, the free encyclopedia

1 "Edit Top" script
2 Navigation bars
- 2.1 Your code
3 Lyttleton
4 Spider Martin

[edit] "Edit Top" script

I had the same issues with the edit link showing up on diff and history pages. The elements that your script was looking for appeared to be there, so I don't know why your script didn't work, but that's the way it is :-) When I made other changes to the script, those changes appeared, so it's not a browser refresh issue. I actually prefer the mechanism used in recent change to Monobook.js to determine whether to show it or not -- it looks for other appearances of the [edit] link on the page, and only adds if one is found. That should respect the user's edit link preference as well. Also, you need to do a global replace of space to underscore -- your current replace() just does the first one. However, your method of actually adding the link appears to work much better than that one. You can see what I'm experimenting with at User:Clindberg/monobook.js if you like (I have broken things up into separate variables for experimentation purposes; not really necessary though). Carl Lindberg 16:37, 3 September 2006 (UTC)

To be clear, I'm not the original author of "Edit Top," nor am I knowledgeable enough to perform a major rewrite. I simply made various tweaks to the existing code.

I agree that the other script's detection mechanism is much better, and I was ready to abandon "Edit Top" until the Safari problems surfaced. Indeed, combining the better detection mechanism (which appears to be Safari-compatible) with the better insertion method (which also appears to be Safari-compatible) is theoretically ideal. I've tested your code, and it seems to work perfectly. —David Levy 20:59, 3 September 2006 (UTC)

Thanks for trying it out (and thanks for providing the script in the first place, even if you weren't the original author). I've made a couple of other tweaks, mainly to the hover label of the link,and also so that the /* Intro */ label gets inserted into the edit box when the link is clicked similar to what happens with the other sections (my changes broke that I think). I'll try it out for a bit more, then post this version over on the Village Pump discussion in case anyone wants to reinstate it. Obviously, it would be better to get this feature into the core software, but if and until that happens, this is a pretty good alternative. Feel free to insert any changes into your Edit Top script... I doubt I'll make a script page over there. Carl Lindberg 23:01, 3 September 2006 (UTC)

Very nice work! The "Intro" link is clever in the respect that it works correctly by technically not working. (No such section heading is found, so the page is loaded without jumping down—thereby displaying the correct section.) Only if there happens to be a heading named "Intro" somewhere on the page (fairly unlikely) would this fail.

I've changed the 47px top margin to 38px. This causes the edit link to be vertically aligned with the text "From Wikipedia, the free encyclopedia" (in my browsers, anyway). The 47px margin was an attempt to leave the same distance between the edit link and the title heading line as there is between a regular edit link and the heading line from its section, but I now realize that the latter sometimes varies.

I'm extremely optimistic regarding the possibility of implementing this code site-wide. —David Levy 23:48, 3 September 2006 (UTC)

I definitely prefer the new margin; looks cleaner to me. The "Intro" bit was pretty clever... that existed before I got there though :-) It was just at the bottom of the script, so it was never executed when it needed to be.

However, my current version does not seem to work on IE6. Not sure why... investigating. Carl Lindberg 00:37, 4 September 2006 (UTC)

Okay, figured it out. IE6's innerHTML text had class=editsection instead of class="editsection" (i.e. without the double quotes) so I had to search either way. Once I made that fix, it seems to work fine on IE now. I tested on Safari (older 1.x version), Firefox/Mac, Opera/Mac, and IE6/Win, and it seems to work on all of them. The edit link is horizontally aligned with the "From Wikipedia" text on all browsers that I tested with, so that part worked well. Carl Lindberg 03:28, 4 September 2006 (UTC)

[edit] Navigation bars

Carl, you seem to be helpful testing other people's javascript. When you are finished with David's project, would you be willing to help a bit on mine? Gimmetrow 03:36, 4 September 2006 (UTC)

I could take a peek, at least. What problems are you having? Carl Lindberg 03:46, 4 September 2006 (UTC)

I'm trying to enhance the dynamic navigation bars. I have general questions about the best approach (ie, whether it's good to use these JS calls, and whether it should create a new class or replace the old one), and specific ones about performance. Ultimately, I need enough support to convince an admin to roll it in. See also here. Gimmetrow 04:01, 4 September 2006 (UTC)

Hm. You've obviously been thinking about this for a couple months, so I may be missing some context. From what you're saying, you are trying to genericize the NavBox javascript so you can use it in other circumstances, such as packing a lot of information in an infobox by having expand/collapse sections, so not too much screen real estate is taken up initially?

I'm not too familiar with any utility functions the MediaWiki monobook.js has already, so I have no idea if something would already exist. I see that you probably need to work with spans instead of divs, and you probably want inline instead of block styles (sadly, inline-block is not very well supported among browsers). However, those are significant enough changes that I would probably not want to alter the NavBox code; that seems designed for that one specific purpose. It is also possible that NavBox requires a block display; IE in particular has some behaviors that depend on that. Unless it would make it less likely for an admin to accept, I'd probably go with separate functions / CSS classes.

The code doesn't look particularly efficient -- it is calling document.getElementsByTagName() every time through its loop -- but the current NavBox stuff seems to work fast enough. Which performance questions did you have? I'm not a big expert on that, but maybe I can answer.

Is there any way you could avoid abusing the title attribute? I'm pretty sure the HTML spec allows unknown attributes to exist, which are ignored, but should be available in the DOM tree. For example, if you add "expandtitle" and "collapsetitle" attributes on your outer div, can you access those values with hasAttribute() and getAttribute() in javascript? That would let you put "parameters" of a sort in custom attributes on the outer div tag, which you could use in the code. Maybe even a "block" versus "inline" parameter :-) Carl Lindberg 06:00, 4 September 2006 (UTC)

The motivation for this was the Popes template. It lists some 260 names, but most readers probably only care to navigate to the few before or after. I basically wanted a structure that would allow a list of names with most of them "collapsed" and only a few (likely to be relevant) ones available immediately.

I copied the NavBox code from the standard monobook.js. Some of the code seems to be designed so as not to store values. My first version used more variables and it was rather slow. The NavBox is very specific - dynamic content is blocked, and it's hidden by default (in browsers that support the code). People complain about javascript bloat, so if it's possible to build functionality into the current routine and maintain compatibility, that would be great. Unfortunately, one particular behaviour is apparently used by some templates and I broke that behaviour trying to improve efficiency, so it would involve less testing to just have a new class. But repeating the NavBox code seems like bloat.

As for unknown attributes, on one platform (probably MacOS), the code simply would not work with non-standard attributes. (It's been a while since I worked on that issue.) Only the ones listed as officially part of each tag were recognized. For the div tag, I decided that "title" would be the easiest one for passing variable values. The other option would be to create my own custom tag(s) just to pass variable values, but that seemed to require more parsing, and more efficiency issues. Gimmetrow 07:07, 4 September 2006 (UTC)

If the unknown attributes strategy doesn't work, I'm not sure there's a way to modify the existing NavBox stuff without changing its current behavior... and I would definitely not want to change that. Maybe there is a way to insert empty spans with attributes that have parameter values. If so they could be put in by parameters to the hidden templates, and picked up by the javascript to alter behavior. Seems like a lot of effort though. May be a bit slower performance, but only for the setup javascript, not the toggle (where were the previous performance issues btw? setup or when the user clicked?) I'd really like to know which of the browsers did not include unknown attributes in the DOM tree though :-)

One option for the Pope template would simply to make the whole thing a collapsible navbox, similar to how the Presidents of the USA is done now. Since there are already "Preceded by" and "Followed by" boxes for the previous/next pope, I'm not sure you need to try to duplicate that in the popes template. Simply making the entire thing collapsible may be the best approach it seems to me; the user would not see the entire list unless they were looking for a pope other than the immediately preceding or following one. Carl Lindberg 03:33, 5 September 2006 (UTC)

Is there a problem with using the title attribute? It seems to work for me, and it allows compatibility with the existing NavBox. The efficiency issue involved determining the hide/show text. In order to make that faster, I coded it as part of the botton html during page setup, so it wouldn't require further javascript calls in the toggle to collect the title text. This meant that the button calls become complex, and it was no longer simple to support the old behaviour that made all boxes hidden if there were more than N of them. It could still be done, I just haven't worked out the logic to do it. There are some templates which apparently assume N=1, so I can emulate that behaviour. Then I supported a default show option with an empty div/span.

The pope template was just the original idea. A box with 260 names is a little hard to navigate than a box with 43 names, and I thought having the 10-20 previous and 10-20 subsequent would make it more manageable. Even if this functionality is not useful there, it seems useful in other contexts. Gimmetrow 01:45, 6 September 2006 (UTC)

The title attribute is supposed to have a description of the element it is attached to. Accessibility software often uses it to aid blind viewers; having arbitrary technical content in there could prove to be confusing. Also, browsers can use that as popup text when you hover the mouse over the area (for example, Safari on your "sand" page over some of the text items). Additionally, it's not very extensible to other potential parameters... it would be better to figure out another way if at all possible... it's really a shame that arbitrary unknown attributes didn't work; that would have been best.

An alternative to passing parameters to the toggle function would be to declare global array variables with the title for each navbox at its index, allowing the toggle function to just reference the variables by index. I.e. have a NavBarShowTitles[] and NavBarHideTitles[] global arrays, with the strings at each index, so the toggle function can pull them out by index. This should let you support hiding the rest of the boxes again. Carl Lindberg 04:14, 6 September 2006 (UTC)

[edit] Your code

On your code, two things:

if the page has no sections, it still has a section0. Do you want to have an [edit] link ? It's the same as edit page, so it's not really necessary, but if you get used to the [edit] link it's nice to have.
the diff and history pages do show an [edit] link for sections when the page corresponds to the current page (ie, last diff or last history link); if those are shown, I think a section0 [edit] should be shown as well. (It may become possible at some point in the future to edit sections of older pages from history.) Gimmetrow 04:01, 4 September 2006 (UTC)

If a page has no sections, I was figuring the edit page tab would be enough. It's not all that far away, and determining whether to include it or not gets much more difficult if it is displayed when no other edit links are present. Maybe that could be revisited if the feature ever gets added to the base software directly.

I forgot about the diff and history pages when looking at the current edit; yes the section 0 link will show up there too. It's arguable that it shows up in the wrong place when looking at the current diff, but that is a lot of special-case code and I'm not sure it's worth it. If historical versions start having edit links, this script would probably need to be revisited to deal with that (if it's even possible). Carl Lindberg 06:00, 4 September 2006 (UTC)

The first is not a big deal, but currently I do not see section0 [edit] links in the diff and history pages, when links are displayed for other sections. Gimmetrow 07:07, 4 September 2006 (UTC)

Odd, it works for me, both with Safari and Firefox on the Mac. Which browser/platform are you using? I assume you mean when looking at a history page, clicking on the most recent "diff" or revision timestamp essentially shows you the current page, and all the edit links exist there. In my case, the section 0 link also shows up, albeit right under the h1 line (on the diff page, that is above the diff). Carl Lindberg 03:33, 5 September 2006 (UTC)

OK, that issue seems to be working now; there is an section0 edit link on the last diff or revision. At some point that was not the case with Safari. There is still a problem encoding &, however, see Robert_Randolph_&_the_Family_Band. Gimmetrow 01:45, 6 September 2006 (UTC)

Ah, thanks, good catch. I put a fix in. Hopefully that is only a problem with '&' characters... I tried a few articles with other odd characters and they seemed to work, but maybe there is one I missed. I'm leery of using the javascript escape() function due to purported Unicode issues on some browsers. Carl Lindberg 04:14, 6 September 2006 (UTC)