Platonides wrote: This question is so cliché... It has become one of the default excuses when someone doesn't want to bother thinking about a problem. Then, I argue: 1. How many users, normal users, have javascript disabled? Note that we are power users. The average user doesn't even know the difference between a "computer" and "Windows", and use whatever is installed. Javascript is something beyond their naked-eye visible universe. They don't know it exists, and how to disable it. These users are the majority. 2. How many of these users, who have Javascript disabled, are actually editors of content in Wikipedia and other MediaWiki-based wikis? 3. How many of these editors who have Javascript disabled will actually feel more inconvenient to go up and click the "edit this page" link on the top of the article instead of turning Javascript back on? 4. Note that the many Ad providers rely on Javascript to place their Ads into pages, because they know that Javascript brings flexibility that overwhelms the few percent (perhaps even less than one percent) of users with Javascript disabled. 5. Disabling Javascript completely render so many (badly designed) sites unusable that doing so almost rips you of a leg. Who are really concerned about having Javascript enabled ends up using Opera or the NoScript extension to disable scripts selectively. In this case, the user just needs to enable Javascript for MediaWiki sites. Simple. 6. Adding section edit links via Javascript is not going to render MediaWiki unusable, not even near that. People will still be able to read anything, and *edit* anything, since we are not going to get rid the "edit this page" functionality. 7. MediaWiki already depends on Javascript for many other non-essential stuff. Of course, proper care was taken to not make it unusable, although it sucks using MediaWiki without Javascript. Table sorting, quick watch/unwatch, instant upload filename collision check, search suggestions based on page titles, etc... They are all convenient features added to MediaWiki via Javascript. I don't see any problem in making edit links the same. 8. There is always the option of using <noscript>...</noscript> as a fallback: Use javascript to place edit links for people who have Javascript enabled, and leave <noscript/> fallbacks in place for people who don't. I just tested in Firebug, selecting and copying a text across an invisible <noscript/> tag doesn't copy its contents, so it would fix the problem of the surprise "[Edit]"s that pop up when you copy/paste text from the wiki. Yeah, right. I just checked it. There are setEditSection() and getEditSection() in ParserOptions that affect the parser in Parser::formatHeadings(). I assumed that that came from the user preferences, but now I see that the user preferences only affects CSS styling. -- Juliano F. Ravasi ·· http://juliano.info/ 5105 46CC B2B7 F0CD 5F47 E740 72CA 54F4 DF37 9E96 "A candle loses nothing by lighting another candle." -- Erin Majors * NOTE: Don't try to reach me through this address, use "contact@" instead.

Hi again, I might mention that I love contentious tech debate, and this is blue-ribbon, but I have to work on my tech writing (first tech $ since 2002!) Just to insert my ideas about the Javascript, or perhaps AJAX: I believe in starting from basics, and adding "automation" only as necessary and purely optionally. I developed this idea in a previous life a decade before the Web was invented: I was customizing classic automobiles with modern performace add-ons, so of which I was making myself. I believed that sophistications such as automation should always assist but not replacements. In the case of Javascript, it is useful but should not replace the web basics. In other words Wikimedia should work in the most basic incarnation of the Web (well, not the MOST basic, but you get the idea), and Javascript should be implemented with optionally removeable modularity. I can simply make that statement without further thought because of duality in technology; what works for one technology will work for all technologies simply because technology is, in effect, humanity. Humanity is built on the Information Society -- which is what we here think of as technology. Not only the Information Society, but also its woes, goes back to the early empires such as the Egyptian, if you read Lewis Mumford. But now that I think about it, benefits comes forth: Mediawiki NEEDS to support dial-up access, as most of the Information Society -- humanity that is -- lacks high bandwidth; the average world bandwidth may be only in the 20s. Using Google's Gmail as an example, it's AJAX works on dial-up, better than its pure HTML version, but only if you have the Javascript that makes it special pre-loaded. I personally start my browser when I have Wifi, keep it loaded using hibernation; but this is a "hack" and not a solution. I think the solution is to build from basics from the ground-up, and then add "sophistication" optionally as it provides benefits, and allow an easy "back out" for each added "sophistication" as those add-ons become more of a burden than a benefit. Mediawiki does support low bandwidth, and I believe it benefits in this way from being an early more simplistic implementation of the web, rather than being a newish AJAX monster such as Gmail. As I mentioned, I am using the Mediawiki for collaborative tech writing, and so happens some of my co-writers are in the Himalayas, where I imagine bandwidth can be narrow indeed. But getting back to the [Edit] tag issue, I will be happy with a temporary hack, so I can get this tech writing done, get paid, and use my writing as an example for other, hopefully more fulfilling jobs, such continuing my decades old project of providing all humanity with un-repressed access and computational abilities: http://Thinman.com -- Empathy http://thinman.com/empathy Photography http://thinman.com/photography Technology http://thinman.com