This is something that can only be done in a NEW SKIN. Obviously it can't be done for the actual skins. This will change the user defined script file to Special:Mypage/newskinname.js and MediaWiki:Newskinname.js, so the user defined functions won't be avaliable --the same as when the wikis upgraded to the new Quartzslate/smoke skins. It hasn't been a pain, at least for you, isn't it?
People that wants this "mode" and knows what are doing could do some changes to its personal javascript to adapt it. It wouldn't be necessary to rewrite all the code. And, as I said, this would be a new skin, so users could still use the "old" skins without being affected. This would be probably the most clean change that could be done in a new skin change We are talking about something will never be done, at least for Wikia side. But it could be done and, probably, with only per-user javascript. The way it would work is at follows: The page is loaded as the actual pages do. When loaded, a function checks if the browser has javascript enabled and support some necessary features (DOM, etc). If it does, then all <a> elements are processed to prevent the default behavior (of load the linked page) and associates the onclick event to a function. When a link is followed, the function will process the link to point something like /index.php?title=(the title)?action=render or a special param for this purpose --maybe using the api.php--, and load its content in the content area, but not the entire page. Along with the content, we could get some variables indicating if the page is watchlisted, the current namespace, if it has talk page, etc. Or it would require a second request (probably to api.php) to get these variables. The content that we'll from the servers would be HTML content, not Wiki content, so the client-side processing would be minimal. And the content would be the same for ALL users (logged in or not) and for ALL skins, so the cache servers would do their work very well :) Once the content is loaded, then a function similar to runOnloadHook() will be called, along with the user-javascript functions that adapts the content --but not the skin-content. This has done in the onload. Some skin-links are modified, like the add to watchlist and talkpage. The links to permalink, whatlinkshere and others could be built using the article-dependent variables. All DOM-Events oriented. The different articles doesn't actually make changes on the skin, except some few links, so it isn't a pain to change them with javascript. The MediaWiki code doesn't need to be rewritten. ONLY needs a new skin (like Quartz). And nothing else than some javascript that will do that stuff, probably less that all the JUNK of DUPLICATED code that is included now for google ads, google analytics and the YUI (whick % of the YUI code is used on the site, excluding user-defined functions? the YUI components must be loaded only if needed) And it would be totally accessible for people that don't have javascript enabled or for the search spiders --The page loads are as statically as they are now, all the dynamic stuff is done after it checks the browser supports all the stuff. The links are only modified when this check is done. Accessibility, usability... if all web designers would have these concepts in mind Internet would be a better place :) PD: <http://lists.wikia.com/pipermail/wikia-l/> is not updating. 2007/9/15, DanTMan Wrote > > Jesús Martínez wrote: > Nested comments: > > 2007/9/14, DanTMan wrote > > > It also isn't a very good idea not to reload the sidebar and tabs. > The Toolbox in the sidebar is always dependent on what page you are on. > It will list user contributions if in the user area of an existent area. > Permanent links to a page, etc... > > It all could be done with javascript. Not only the content would be > returned with Ajax. Also some javascript code like the code is > injected in all headers. Some of the variables: wgCanonicalNamespace, > wgCanonicalSpecialPageName, wgNamespaceNumber. > > > > Then there's the tabs. Each page has it's own set of tabs. The Special > tab for Special pages always has the same link you are currently on, > each article has the article, talk, and various edit, watch, delete, and > protect tabs. And these all change depending on what access the user > has, what level of protection the page has, and if the user has the page > in their watchlist or not. > > wgUserGroups = ["bureaucrat", "sysop", "*", "user", "autoconfirmed", > "emailconfirmed"]; and so on :) > > > And you're saying we rewrite half the MediaWiki code in JS to set tabs and > toolbox items, using groups without rights info which Wikia could change at > any time. That just doesn't work. > > > > > Another issue with removing the page load from happening is with User > scripts. I add a User tabmenu when I'm in a userspace to give me a few > useful tools. As well as a number of other things, some of these are > dependent on what is on the page and therefore will not load right if > the page load is eliminated. > > > > If people is using addOnloadHook() function to load personal stuff, > the load of new content could do a call to addOnloadHook(), or call > other global function so users could adapt its scripts to the > different "concept" of page load. > > Ya... then I get a brand new WikiSwitch tab each time addOnloadHook is > called and you fill up users screens because user's scripts are not designed > to have addOnloadHook called multiple times on a page. > And what If I'm not using addOnloadHook? Some people could be using YUI's > load functions, or they may have code which is actually run when the code is > actually being run through. Also remember that user's methods of loading > extra JS or CSS, which is also page dependent can only be one during the > real loading of the page. > Whatever you do, with this idea you'll always require half the users around > to rewrite their scripts, and not all of them know enough JS to actually do > that. Unless you plan on rewriting the way JavaScript works itself and > forcing every browser to change it's code and then force everyone in the > world to update ;) > > > > > And the last issue is with site JS... If you remove the page load... You > remove the ability to use Collapsible tables, the Show/Hide NavFrame, > Table Sorting, and the new TabView extension one of the techs nicely put > together from YUI. ^_^ And now... you have 85% of Wikia staring at you > with murderous faces because you broke 90% of their fancy features and > ability to customize their own experience... > > > > > Same as last commnet. And it's not the first time Wikia breaks our > fancy features... > <http://www.wikia.com/wiki/Forum:Images_in_%22sortable%22_tables> > <http://www.wikia.com/wiki/Forum:Miniupload_and_image_licensing> > <http://www.wikia.com/wiki/Forum:Myskin_problem> > and more! :) > > > Ok, it would be a major change, but the idea is great. just an > "extension" of TabView extension > <http://toys.wikia.com/wiki/TabViewTest> > _______________________________________________ > Wikia-l mailing list > [email protected] > http://lists.wikia.com/mailman/listinfo/wikia-l > > > Ya... Wikia has done some things which some users have issues with. But > they've never added features which have broken user's ability to properly > use userscripts. > ~Daniel Friesen(Dantman) of The Gaiapedia, Wikia Graphical Entertainment > Project, and Wiki-Tools.com > > _______________________________________________ > Wikia-l mailing list > [email protected] > http://lists.wikia.com/mailman/listinfo/wikia-l > > _______________________________________________ Wikia-l mailing list [email protected] http://lists.wikia.com/mailman/listinfo/wikia-l
