MediaWiki talk:Common.js/Archive 4: Difference between revisions

Revision as of 21:22, 3 April 2007

Latest revision as of 22:59, 22 June 2024

(11 intermediate revisions by 6 users not shown)

Line 1:

<span id="63298023827" ></span>

<span id="63298023827" />

==vandal problem==

Line 13 ⟶ 12:

:Any changes we could make here would be fairly easy for the vandal to work around. It would probably be more effective to get the anti-vandalism bots to automatically revert such edits and report the users making them. It's not as if detecting them should be hard, given that we have the source for the script that makes them. —[[User:Ilmari Karonen|Ilmari Karonen]] <small>([[User talk:Ilmari Karonen|talk]])</small> 00:23, 1 March 2007 (UTC)

<span id="63298253943" ></span>

== Access key for project page: why change it? ==

Why is the access key for a Wikipedia: namespace article now A instead of C as it is in all other namespaces? This is inconsistent and irritating. Can this please be changed back? [[User:Grouse|Grouse]] 00:46, 2 March 2007 (UTC)

: Done. Since several weeks MediaWiki ships with default accesskeys so they no longer need to be defined here (except for links not part of the default interface.) Those defaults seem to be not fully consistent with the old accesskeys. —''[[User:Ruud Koot|Ruud]]'' 00:13, 3 March 2007 (UTC)

::Thanks Ruud! For the explanation and the fix. [[User:Grouse|Grouse]] 16:19, 3 March 2007 (UTC)

<span id="63298430893" ></span>

== escape() and replace() in importScript function ==

I read this [[MediaWiki_talk:Common.js/Archive_2#Import_Module|December discussion about import module]] but I still don't see why <code>escape()</code> is there in the first place. Can you please give me an example when it's really needed? As far as I can see, it doesn't work for 2-byte Unicode characters anyway, so in [[:ru:MediaWiki:Common.js]] we had to remove it so far.

Same question for <code>replace()</code>: everything seems to work fine without it, even with spaces in the script path.

— [[User:Alex Smotrov|Alex Smotrov]] 20:48, 3 March 2007 (UTC)

:The only reason for <code>escape()</code> to be there is to avoid problems with ampersands and percent signs. You're right that <code>escape()</code> produces weird results with non-ASCII Unicode (e.g. "Б" becomes "%u0411", which makes Apache choke). It looks like the appropriate function may actually be <code>encodeURIComponent()</code>. Using that function instead of <code>escape()</code>, "Б" is encoded as "%D0%91" instead of "%u0411", which Apache and MediaWiki interpret correctly as the UTF-8 encoding of "Б". (Tested on Galeon/Mozilla 1.7, Firefox 2.0, and IE 6.0) [[User talk:Mike Dillon|Mike Dillon]] 21:02, 3 March 2007 (UTC)

:: Thank you for the answer. I've yet to see any real users with & or % (and they can always specify the correct way to call their modules in their documentation). But since our version of <code>importScript()</code> can import from other Wikipedias, I guess it's better to be consistent and I'll recommend our admins to use <code>encodeURIComponent</code> [http://en.wikipedia.org/w/index.php?title=MediaWiki:Common.js&curid=763577&diff=112423294&oldid=112202941 as well]. Still <code>page.replace</code> was not and is not necessary unless there is slight perfomance difference for Mediawiki servers or we're simply willing to save 2 bytes in URL ( _ vs %20 ). — [[User:Alex Smotrov|Alex Smotrov]] 00:11, 4 March 2007 (UTC)

::: I ''may'' avoid a HTTP redirect from "Page%20name" (from the escaped/URI-component encoded "Page name") to "Page_name". I'm not entirely sure yet which mechanism is used to rewrite those URLs, but the performance gain/loss of the replace is very likely insignificant. —''[[User:Ruud Koot|Ruud]]'' 00:50, 4 March 2007 (UTC)

::::You're correct that it avoids an HTTP redirect. I just tested it. [[User talk:Mike Dillon|Mike Dillon]] 17:28, 5 March 2007 (UTC)

<span id="63298753350" ></span>

== Collapsible tables ==

Some times I have an error from that function:

Error: Header has no properties

Source File: http://en.wikipedia.org/w/index.php?title=-&action=raw&smaxage=0&gen=js

Line: 240

Perhpas add a test if Header exist. _{→[[User:AzaToth|<span style="color:#773">Aza</span>]][[User_talk:AzaToth|<span style="color:#359">Toth</span>]]} 17:11, 6 February 2007 (UTC)

: On which page does this happen? —''[[User:R._Koot|Ruud]]'' 17:37, 6 February 2007 (UTC)

: Tables without a header shouldn't have the class "collapsible" as this is where the show/hide button is placed. —''[[User:R._Koot|Ruud]]'' 19:38, 6 February 2007 (UTC)

::I have added a test for whether any header row exists: HTH HAND —[[User:Phil Boswell|Phil]] | [[User talk:Phil Boswell|Talk]] 11:02, 9 March 2007 (UTC)

<span id="63298677990" ></span>

== Optimizing [[Mediawiki:Edittools]] ==

Please revert [http://en.wikipedia.org/w/index.php?title=MediaWiki:Common.js&curid=763577&diff=113147951&oldid=112423294 «optimization»] and let's discuss it first. And most importantly, let's ''test'' new solutions in ''different'' browsers. — [[User:Alex Smotrov|Alex Smotrov]] 21:21, 6 March 2007 (UTC)

:Second. It's pretty uncool to simply add this with no discussion. [[User talk:Mike Dillon|Mike Dillon]] 21:23, 6 March 2007 (UTC)

I reverted it because of the discussion above and discussion at the [[Wikipedia:Village_pump_%28technical%29#Please_enable_JavaScript|village pump]]. It seems to cause issues in Firefox. I have also left a message with [[User:Misza13]] explaining my actions. If they weren't appropriate, another admin should feel free to revert me. --[[User:PS2pcGAMER|PS2pcGAMER]] ([[User talk:PS2pcGAMER|talk]]) 21:32, 6 March 2007 (UTC)

:Also you have to revert: [[MediaWiki:Edittools]]. And btw that's where the discussion happened in the 1st place, guess I should have watched that page as well. — [[User:Alex Smotrov|Alex Smotrov]] 21:36, 6 March 2007 (UTC)

::Got it. I'll let Misza13 sort out where s/he wants to go from here. At least the edit box is there now for everyone. --[[User:PS2pcGAMER|PS2pcGAMER]] ([[User talk:PS2pcGAMER|talk]]) 21:53, 6 March 2007 (UTC)

:From a usability standpoint, I think this is a step backwards. Now in order to use the edit box, two clicks are required -- Open editing toolbox; click on desired symbol. Plus, there's a wait/lag in the middle. To me, this is a bad (mis-)use of AJAX. Plus, doesn't it bypass the "Show edit toolbar (JavaScript)" option in Preferences/Editing? &ndash;[[User:Dvandersluis|Dvandersluis]] 21:48, 6 March 2007 (UTC)

::It was working, so I didn't want to revert this page back again. Although [[User:Ruud Koot]] has since reverted everything back to its original state. --[[User:PS2pcGAMER|PS2pcGAMER]] ([[User talk:PS2pcGAMER|talk]]) 22:01, 6 March 2007 (UTC)

::For start, many people (like myself) don't use the tools at all. Now if you scan the traffic between the server and your browser, you'll notice that the edit tools actually form the '''majority''' of traffic of edit pages, which is unacceptable, because the code doesn't get cached (with my solution, it would). Second, this generates a lot of objects with attached JS events, which causes '''major''' problems in Firefox, known for leaks in this department. Third, the option in Prefs is about the editing toolbar (above the edit box), not the editing tools below - the devs were for some reason reluctant to add a new option to the preferences (which would be a near-ideal solution). [[User:Misza13|Миша]][[User talk:Misza13|<span style="color:green">'''13'''</span>]] 22:05, 6 March 2007 (UTC)

::: Okay, I misunderstood the distinction (or even the fact that there was one) between the two elements. I guess it's not (easily) possible to just get a new checkbox in there, rather than go through this process? Is finding a solution through javascript the only option there is (save for an update by the devs)?

::: Do you understand my usability concern, though? If there is a low percentage of usage of this to begin with, adding in an extraneous action will further reduce the number.

::: &ndash;[[User:Dvandersluis|Dvandersluis]] 22:13, 6 March 2007 (UTC)

::::Yes, I do understand, but here's a clash of a usability problem of my own (as outlined in my reply below) where my Firefox doesn't handle so much JS leaks and needs a restart every like 10 pages edited (or less if preview is used), because memory usage becomes sky-high. [[User:Misza13|Миша]][[User talk:Misza13|<span style="color:green">'''13'''</span>]] 22:36, 6 March 2007 (UTC)

=== Reverted ===

I reverted the changes for several good reasons:

# A similar solution has been rejected in the past.

# The code was undiscussed, badly written, undocumented and untested. ''If'' we want to have this stuff a small multi-purpose and well-tested and documented AJAX framework should be written first.

# I do not believe the usability problems caused by this particular solution to the problem described at [[User:Cyde/Saving bandwidth]] are an acceptable trade off. In fact, I believe the edit pages are sent in compressed form, so there might not be a problem at all.

—''[[User:Ruud Koot|Ruud]]'' 22:12, 6 March 2007 (UTC)

:For the record, I reverted because of usability issues. People reported (and I also experienced) error messages that said something to the effect of "Javascript is not enabled" which confused a lot of people, especially since they knew that they had JS enabled. I didn't see an urgency in leaving the code in place so I reverted until things could be clarified. --[[User:PS2pcGAMER|PS2pcGAMER]] ([[User talk:PS2pcGAMER|talk]]) 22:24, 6 March 2007 (UTC)

:For the record, the code '''was''' tested, works fine on Firefox and I also saw it working on IE (it failed on my PC tho). Also, whether or not the code is compressed (not all browsers support compression), it generates lots of objects with attached JS and causes severe memory leaks on Firefox. That's verified: as long as one only browses articles, it's fine, but whenever a few pages get edited (God forbid to use "preview"!), the whole thing gets bogged down, memory exhausted and further browsing impossible. In that aspect, I have a '''serious''' usability problem with the '''current''' implementation and am desperate to find a solution. [[User:Misza13|Миша]][[User talk:Misza13|<span style="color:green">'''13'''</span>]] 22:33, 6 March 2007 (UTC)

:: I believe there are other, better, solutions are possible which need to be carefully considered first. I have not experience any problem with Firefox and editing pages myself? Are there any other users who are experiencing this? —''[[User:Ruud Koot|Ruud]]'' 22:42, 6 March 2007 (UTC)

:: Also on the bandwidth side: I suspect common.js is load 100 times or more often than edit pages are, meaing that adding 1kb of code here would much worse than the 20kb saved on the edit paged. —''[[User:Ruud Koot|Ruud]]'' 22:42, 6 March 2007 (UTC)

:::I think Edittools is more like 38 kbytes. Common.js could call a ''separate'' javascript file only for edit pages. — [[User:Alex Smotrov|Alex Smotrov]] 22:56, 6 March 2007 (UTC)

:: I use firefox (and wikipedia) extensively, and have never experienced any sort of slowdown related to the edit box. If there actually is a problem, what if the event was set on a parent element, and [http://www.quirksmode.org/js/events_order.html event capturing] was used? &mdash;[[User:Dvandersluis|Daniel Vandersluis]]^{([[User talk:Dvandersluis|talk]])} 00:53, 7 March 2007 (UTC)

=== An older proposal ===

I guess it's a good time to point to an older proposal of mine, [[MediaWiki talk:Edittools/Archive 3#Replacing charinsert with dynamic JavaScript]]. It does not use [[AJAX]]; instead, the list of characters is inlined on the Javascript file itself, which should be much more compatible (and after being loaded behaves exactly like the old implementation; the only disadvantage is a small amount of flicker). It was not accepted because there was no [[MediaWiki:Common.js]] at the time, which would be needed to make it work on all skins. --[[User:CesarB|cesarb]] 22:27, 6 March 2007 (UTC)

:I second dynamic Javascript proposal. I've been having this idea myself for some time.

:For the reference: today's AJAX code could use functionality in [{{SERVER}}/skins-1.5/common/ajax.js ajax.js] and use <code>&action=<s>raw</s>render</code> ''(corrected later)'' instead of downloading the whole Edittools page.

:Btw, any other comments on page compression?

: — [[User:Alex Smotrov|Alex Smotrov]] 22:37, 6 March 2007 (UTC)

:: See http://lists.wikimedia.org/pipermail/wikitech-l/2007-February/thread.html#29440. —''[[User:Ruud Koot|Ruud]]'' 22:55, 6 March 2007 (UTC)

===Fallback? ===

What are your proposals for fallback for those with JS disabled, or even for browsers without JS at all?

Any solution without such plans is unacceptable.

HTH HAND —[[User:Phil Boswell|Phil]] | [[User talk:Phil Boswell|Talk]] 07:05, 8 March 2007 (UTC)

: Charinsert doesn't work without JS anyway. —''[[User:Ruud Koot|Ruud]]'' 10:57, 8 March 2007 (UTC)

:As Ruud just said, there is no need for a fallback, since the edit tools already do not work (and cannot work) without Javascript. --[[User:CesarB|cesarb]] 14:06, 8 March 2007 (UTC)

<span id="63299025922" ></span>

== Placing the cursor after the section name ==

A long time ago, [[User_talk:Quarl/Archive_2006-02#User:Quarl.2Fauto_summary.js|Quarl and I discussed]]{{Broken anchor|date=2024-04-21|bot=User:Cewbot/log/20201008/configuration|target_link=User_talk:Quarl/Archive_2006-02#User:Quarl.2Fauto summary.js|reason= }} some user scripts and made a little snippet of code that, when you press ''tab'' to go to the Summary field, puts your cursor after the section name, so you can just start typing. It's a tremendously helpful little tweak, and now that I've removed Quarl's code from my monobook.js, I miss it. :-) It would be a good thing to implement site-wide, though. This was my version, though I think he improved on it in his Power Tools scripts:

<pre>

/* When the summary box is clicked, select only the part *after* the section title/place the cursor after the auto summary */

addOnloadHook(function () {

if (document.getElementById('wpSummary')) {

summary = document.getElementById('wpSummary');

function selectSummary() {

section = summary.value.match(/(?:\/\*(?:.*)\*\/)?\s*(?:«(?:.*)»)? ?/);

if (section) {

sectlen = section[0].length;

end = summary.textLength;

summary.setSelectionRange(sectlen,end);

}

}

summary.onclick = selectSummary;

}

});

</pre>

I don't know enough about JavaScript to follow his code, but I think this is equivalent:

<pre>

// auto focus

$autosummary._focusSummaryEvent = function(event) {

var sumField = document.editform.wpSummary;

if (sumField.value.match(/^(?:\/\*.*?\*\/)?\s*(?:«(?:.*)»)? ?/)) {

var n = RegExp.lastMatch.length;

var m = sumField.value.length;

// apparently you can't setSelectionRange in an onFocus handler, but

// you can set a timer to do it 0 seconds from now.

setTimeout(function() { sumField.setSelectionRange(n, m) }, 0);

}

}

</pre>

Found on http://www.cubewano.org/wpt/scripts/COMBINED.js

— [[User:Omegatron|Omegatron]] 00:13, 2 March 2007 (UTC)

:Please check that code on multiple browsers; I think I remember something about selection code being different on IE and FireFox. --[[User:ais523|ais523]] 11:21, 9 March 2007 ([[User:ais523|U]][[User talk:ais523|T]][[Special:Contributions/Ais523|C]])

:: I don't know enough to check it for compatibility with all browsers and situations. I'm just proposing that someone with the knowledge include it site-wide. — [[User:Omegatron|Omegatron]] 03:59, 10 March 2007 (UTC)

:::Your version is a syntax error in IE6. Code shouldn't be added to the site-wide JS unless it works on ''all'' browsers! --[[User:ais523|ais523]] 14:45, 12 March 2007 ([[User:ais523|U]][[User talk:ais523|T]][[Special:Contributions/Ais523|C]])

<span id="63299562298" ></span>

:Further work at [[bugzilla:9937]]. --[[User:Brion VIBBER|brion]] 15:59, 17 May 2007 (UTC)

== Proposal: Edittools with Javascript ==

Replace all those <code><a … onlcick=InsertTags </code> lines now generated from [[MediaWiki:Edittools]] with javascript code inside <code>MediaWiki:Editpage.js</code>. Sample version of this code: [[User:Alex Smotrov/createEditTools]], see discussion page for instructions on how to test it. Advantages:

* ease of removing (not just hiding) unnecessary characters and adding your own

* Js code is about 10 times smaller

* Js code should be cached by browser because it's a separate file

— [[User:Alex Smotrov|Alex Smotrov]] 20:47, 8 March 2007 (UTC)

:Great idea! I like the js, but I have one idea. Once we're doing this, why don't we have a drop-down menu like at [[:commons:]]? —<span style="color: red;">[[User:Mets501|M<small>ETS</small>501]] ([[User talk:Mets501|talk]])</span> 21:03, 8 March 2007 (UTC)

::Question: What happens for users with javascript disabled? [[User:Prodego|<span style="color:darkgreen;">''Prodego''</span>]] [[User talk:Prodego|<sup style="color:darkgreen;">talk</sup>]] 19:23, 18 March 2007 (UTC)

:::The edit tools don't appear. Since clicking on them relies on JavaScript anyways, this is not a problem. It's actually better than the current situation since right now the tools show up if you don't have JS enabled, but they don't actually work. [[User talk:Mike Dillon|Mike Dillon]] 19:44, 18 March 2007 (UTC)

<span id="63298081396" ></span>

== Collapsible sections ==

I was wondering whether it would be possible to adjust the collapsible table code a little to allow a table to be collapsed section-by-section?

What I was thinking was that you could have a table like this:

{|

|+ <span style="float:right; color: blue;">&#x5B;hide&#x5D;</span>Caption

|-

! colspan="2" | <span style="float:right; color: blue;">&#x5B;hide&#x5D;</span>Section 1

|-

| some stuff || …and more stuff

|-

! colspan="2" | <span style="float:right; color: blue;">&#x5B;hide&#x5D;</span>Section 2

|-

| some stuff || …and more stuff

|}

where clicking the <span style="color: blue;">&#x5B;hide&#x5D;</span> link in the caption hid the entire table whereas the corresponding link in each header-row hid the rows from there up to the next header-row.

Would it be difficult to arrange that the intermediate rows, those to be hidden, could have "header cells" in the first column?

This would be helpful in quite a few places, like in some infoboxes, where it would be helpful to have much of the information hidden until required.

HTH HAND —[[User:Phil Boswell|Phil]] | [[User talk:Phil Boswell|Talk]] 16:23, 1 March 2007 (UTC)

<span id="63298702036" ></span>

== Proposal: Editpage.js ==

Create another «common» javascript file <code>MediaWiki:Editpage.js</code> and «call» it from [[MediaWiki:Common.js]] (already implemented e.g. in [[:pl:MediaWiki:Monobook.js]] and [[:ru:MediaWiki:Common.js]]: search for "<code>Onlyifediting.js</code>")

if (document.___URL.indexOf('action=edit') > 0 || document.___URL.indexOf('action=submit') > 0)

importScript('MediaWiki:Editpage.js');

Then move from [[MediaWiki:Common.js]] → <code>MediaWiki:Editpage.js</code>

* code «Extra toolbar options» (mwCustomEditButtons)

* code «fix edit summary prompt for undo»

— [[User:Alex Smotrov|Alex Smotrov]] 20:47, 8 March 2007 (UTC)

<span id="63299899636" ></span>

== notcollapsed class in collapsible tables and navframes ==

Tables and navframes have collapsed and autocollapse classes, but what about a notcollapsed class that would specify to keep that specific table or frame open by default on a page, but still allow it to be closed. This would come in handy for the Climate Statistics box on [[Denver, Colorado]] (we could leave one of the boxes open by default, but have the other three collapse) and the behavior is not unprecedented (Table of Contents allows show/hide and defaults to open). --[[User:MattWright|MattWright]] ([[User talk:MattWright|talk]]) 18:36, 21 March 2007 (UTC)

: Just give it the collapse class, without specifying collaped or autocollapse. —''[[User:Ruud Koot|Ruud]]'' 10:31, 22 March 2007 (UTC)

::Thanks for the reply Ruud. --[[User:MattWright|MattWright]] ([[User talk:MattWright|talk]]) 17:27, 22 March 2007 (UTC)