Talk:Change to section edit links

edittop.js

This will require fixing at least the en:MediaWiki:Gadget-edittop.js gadget when this is deployed, but there are lots of variants of that script in the wild. We should have a fixed version ready. TheDJ (talk) 08:43, 27 April 2013 (UTC)

On a quick glance, we just need to replace parent.insertBefore (span0, parent.firstChild); with parent.appendChild (span0); and all occurences of editsection with mw-editsection. Just like I described in the Technical information section :) But anyway, once this is out the door, I'm planning to implement an editsection link for the zeroth section in MediaWiki itself, too. Matma Rex (talk) 14:34, 27 April 2013 (UTC)

• It would be really helpful if an effort was made to make these kinds of changes easier, for example having the class be "mw-editsection editsection" for a while, so that we don't have to do everything to deal with the change during five minutes of panic and breakage. --Yair rand (talk) 19:56, 29 April 2013 (UTC)
  • This isn't possible precisely due to all the scripts already binding to the .editsection class. The way I've done it the worst thing that can happen if a script doesn't get updated in time is merely that some addition will stop working, instead of it throwing errors when it doesn't encounter elements in their old places (and thus possibly breaking other scripts) or messing up the interface entirely. This was thought out. :) Matma Rex (talk) 20:20, 29 April 2013 (UTC)
    Also, this is being publicized reasonably widely and reasonably in advance, I believe – an email went out to the ambassadors list today, and I think there's a EdwardsBot global message about to happen as well. Matma Rex (talk) 20:22, 29 April 2013 (UTC)
  • I had the Commons version of the script fixed and submitted an "editprotected" request on en.wp with the fixed version. (The aforementioned global message has been sent out, by the way.) Matma Rex (talk) 16:21, 4 May 2013 (UTC)

Font size

Resolved.

Who decided to give the font-size of all edit section links 'x-small'? This drops the font size for all edit link to 10px; which is way below the legible minimum font size of 11px. Using CSS keywords is unpredictable (and evil). It should be reverted to use the old way of declaring font-size per header level. — Edokter (talk) — 08:08, 30 April 2013 (UTC)

I did, and it's been OK'd by Foundations' designers. The font size for these links has been declared in this way on the Polish Wikipedia since at least 2011, and likely much longer, but I don't feel like tracing the origins of these lines back to when they were still in common.css. I'd like some references for the unpredictability and evilness claims; the ones I found claim exactly the opposite [1] [2]. And the old way I can only describe as twisted – I am not going to calculate six different percentages for six different heading levels only to hope to get them to actually look the same. Matma Rex (talk) 08:34, 30 April 2013 (UTC)

Actually, I traced it. This was added back in January 2007[3], and set to x-small shortly thereafter[4]. I have never heard anybody complain. Matma Rex (talk) 08:43, 30 April 2013 (UTC)

How long it has been in use is not relevant. As a (my) rule of thumb, no font should ever fall below 11px. The edit link does now (10px). As a result, me and other users now really have to aim to click the link. Here's a screenshot as it looks in all browsers at default font and pdi settings: .

With all the usability initiatives in the past years, I find it very hard to believe the foundation OK'ed this. Can you point me to a relevant discussion? Using such a small link goes completely against its intended effect. It is as if the edit link is trying it hardest not to be clicked. If we're not going to use the old CSS, then at least the size should be set to 'small'. — Edokter (talk) — 08:52, 30 April 2013 (UTC)

Well, the gerrit change I6a6c12a9 was merged after nearly two months of me waiting for someone to look at it and a few days of discussion, so I assume that someone did look at it before doing that. I won't insist on the current size myself if there's an agreement that it's wrong (although it still looks okay to me). Matma Rex (talk) 09:40, 30 April 2013 (UTC)

Well, I missed it, otherwise I would have raised a flag. In my opinion, we should simply use the old CSS present commonElements.css (adding .mw-editsection) and remove the font-size declaration in shared.css; it has worked well in the past, it will continue to work well in the future; no matter how twisted you think they are (we use the same trick for the headers themselves.) In short: It wasn't broken, so why 'fix' it? — Edokter (talk) — 11:35, 30 April 2013 (UTC)

No, we're not using the same trick for headers; we're just setting each one to have different size – and for .editsections, we're setting each one to have the same size by setting them to different sizes, which is in my opinion slightly mad. I'm "fixing" it since such design, with only some very minor inconsistencies, has already been implemented by the users of five out of the top ten Wikipedias for years, because a similar design has been tested and shown to improve click and edit rates, and last but not least because I personally believe this look to be much more useful and so I'm trying to improve a piece of software I'm passionate about.

As I said, I don't care that much about the precise font size; please feel free to submit a patch and pester someone who actually has the rights to merge it (since I don't). :) Matma Rex (talk) 14:38, 30 April 2013 (UTC)

Also, here's some hard data: the font sizes set on each of the top ten Wikipedias that uses this customization, and the actual rendered sizes (for me on Opera 12 on Windows). Matma Rex (talk) 14:45, 30 April 2013 (UTC)

Wikipedia	font-size	actual
pl:	x-small	10px
it:	x-small	10px
fr:	x-small	10px
ja:	small	13px
de:	MediaWiki default CSS	between 12px and 13px, varies slightly

Edokter: I think what Matma has patched is okay for now, but if you feel strongly about the font size I'd encourage you to submit your own style patch, which could be discussed. I think there are legitimate reasons to consider not having x-small, even if I don't think the current state is a blocker. As Matma said, this went through pretty intensive review before being merged. Steven Walling (WMF) • talk 17:58, 30 April 2013 (UTC)

Yeah, that is much too small. While if a computer has decent font rendering it's not apt to cause significant legibility issues any more than use of <small> would, it's still small enough to be potentially annoying even for those with good eyesight and at very least we do not want to be deemphasising the section edit links, and the smallness does exactly that. That they are so small does make them stand out in another way, but it's not a good one. What we should be after here is something that is unobtrusive that people still notice - and that should mean normal text. Just add some more padding between the edit link and the header text itself so it stands out more as something distinct, or something. -— Isarra ༆ 20:16, 30 April 2013 (UTC)

I think maybe the margin left could be reduced or removed as well. It's a new addition for some wikis, like English and German, and looks a teensy bit odd on the Vector h2 style in particular. Compare: with margin-left: 1em and without. Steven Walling (WMF) • talk 20:55, 1 May 2013 (UTC)

It needs more margin left (padding between the header text and the link), not less. That space is what distinguishes link from header when quickly scaning - or should be, at least. -— Isarra ༆ 07:06, 2 May 2013 (UTC)

I submitted gerrit:61896 to change it to small. I confirmed that both Chromium and Firefox show a computed size of 13px for me locally. Superm401 | Talk 21:17, 1 May 2013 (UTC)

Merged, and we'll backport it to the current MediaWiki release today. Steven Walling (WMF) • talk 20:14, 2 May 2013 (UTC)

Thank you for this quick resolve. (Now I find myself staring at the right side of the screen searching for the edit link.) — Edokter (talk) — 18:05, 3 May 2013 (UTC)

One more edit link please

You may have noticed by editing Wikipedia that nobody, really nobody (the only exceptions are only there to show that they are really exceptions, rare ones) uses the ADD TOPIC link on the top of the page. Come on, admit it. YOU do not use this. You (and I) are only using the edit section link and you just add a == text == as a new topic, because it makes no sense to go to the top of a lengthy page to find the Add topic link. It is so simple! Just add next to the [edit] link a [new topic] link. Simple. --FocalPoint (talk) 22:01, 30 April 2013 (UTC)

I use Add Topic frequently. Steven Walling (WMF) • talk 22:44, 30 April 2013 (UTC)

I always use Add Topic to add a new topic. Based on discussion page edit histories, I'm pretty sure most people do. --Yair rand (talk) 01:29, 1 May 2013 (UTC)

I use Add Topic often. --Sphilbrick (talk) 19:10, 1 May 2013 (UTC)

I use alt-shift-+ but I almost never see people using section=new to create a new section on my talk pages (I wish they did, though, and I dislike your proposal). --Nemo 05:52, 3 May 2013 (UTC)

Mostly, I use the "Add topic" at the top of the page because there is no [new topic] link next to the [edit] link in de-Wikibooks. I'ld prefer if the [new topic] link would be available in each wiki. -- Juetho (talk) 07:14, 13 May 2013 (UTC)

Meh

I see this has gone live on en.wikt. I think it's bad for usability. Finding an edit link now requires horizontal scanning, since its position is relative to the header's text length. It used to be easy: absolute far right. 86.164.187.169 18:28, 1 May 2013 (UTC)

Translatable

Pageviews are dropping so now it makes little sense, but next time please prepare for translation (everyone can) and send less English walls of texts to village pumps. --Nemo 05:54, 3 May 2013 (UTC)

Little weirdness with unfinished bolding in section title

Thanks for this documentation, it was helpful for me in quickly adjusting the wiki -> WordPress HTML conversion script we use for the Wikimedia blog.

Here, I observed a little weirdness which may or may not be due to this change. The following wikitext:

====Wikipedia assignment has positive impact on students' "research persistence"'''====

results in this HTML:

<h4><span class="mw-headline" id="Wikipedia_assignment_has_positive_impact_on_students.27_.22research_persistence.22">Wikipedia assignment has positive impact on students' "research persistence"</span> <b><span class="mw-editsection">[<a href="/w/index.php?title=Research:Newsletter/2013/April&action=edit&section=10" title="Edit section: Wikipedia assignment has positive impact on students' "research persistence"">edit</a>]</span></b></h4>

In other words, the extraneous three apostrophes at the end of the section heading wikitext result in a <b> tag around the edit link. I guess this is overridden by the CSS anyway, so it's not a big deal in this case, but in general one would not expect being able to change the style of the edit link from within the section title. I also tested opening and not closing a span at the end of the section title, but in that case the style was properly ignored in the resulting HTML.

Happy to file a bug if this is Bugzilla-worthy.

Regards, Tbayer (WMF) (talk) 19:20, 3 May 2013 (UTC)

Hmm, thanks for the report. It seems like it is actually possible to apply other changes, but only if the tag you're using is something else than a span: [5]. This isn't really caused by this change, but it certainly exposed this behavior; it wasn't possible to get such a thing to happen previously as the editsection markup was inserted before anything else in the heading, not after it. It's probably worth a report, but it might be a little hard to get it fixed; I'll investigate when I have time. (In short, this is caused by the editsection links being magically inserted into the document after it's parsed and processed by Tidy.) Matma Rex (talk) 19:41, 3 May 2013 (UTC)

de.wikisource paralysed

Since at least 06:44, 30. Apr. 2013 (CEST) editing with parallel scans (in German Korrekturlesen-Button) has disappeared on german wikisource, and also other function do not work, possibly because of changed JavaScript handling on the server side. Work there is seriously paralysed and no one seems to know who and why made changes in the system infrastructure. See for a description de.ws:Change_to_wiki_account_system_and_account_renaming and alreadyWo_ist_der_Korrekturlesen-Button. Could somebody please direct me to a place where this problem is properly addressed? S8w4 (talk) 02:13, 4 May 2013 (UTC)

If this was really broken on April 30, it can't be this – the change to edit section links was deployed on May 1, apparently at 18:14 UTC, together with MW 1.22wmf3 – see [6]. Matma Rex (talk) 11:29, 4 May 2013 (UTC)

Unintended consequences

See Steward_requests/Miscellaneous#.22Change_to_section_edit_links.22_on_sv.wikisource. PiRSquared17 (talk) 15:48, 5 May 2013 (UTC)

Fixing this is a trivial task, and the necessity to make such changes has been widely announced. I responded at the linked request. Matma Rex (talk) 16:31, 5 May 2013 (UTC)

More unintended consequences

Note to FocalPoint — I used the add topic button, and I would have even if I'd not seen what you said :-)

See the "Edit links on Commons files" section of this revision of the en:wp Technical Village Pump: this change has (accidentally?) added section-edit links to local versions of Commons display images, and because the links work properly, it's quite appreciated. Nyttend (talk) 20:10, 5 May 2013 (UTC)

Change back

Here's one who doesn't like the edit button wandering about vaguely to the left. I've saved that code thing in Notepad so I can find it to change all my other language Wikipedia settings when I go to them. Damn nuisance. Why can't there be a way of keeping one set of settings and have it apply on all the other places? (Obviously with room for changing things if you really want your Russian pages to come up in Modern not Monobook.) Peridon (talk) 19:13, 6 May 2013 (UTC)

See Tech#Global_css.2Fjs for information about global CSS and JS, which seems to be what you want. I'd recommend using User:Pathoschild/Scripts/Synchbot if you have accounts on many wikis (you can create an account on all WMF wikis using User:Krinkle/Tools/Global SUL). If you only edit one or two wikis, it might not be worth it. As for global settings, the Synchbot page has another workaround for that, which is basically having you give a steward a temporary password. Too bad it's not built-in to CentralAuth. PiRSquared17 (talk) 19:20, 6 May 2013 (UTC)

Pointless change. Worthless change. I understand that hacky code must be replaced. But keep the edit tab to the right. One should not have to look for it in various places, depending how long the section heading is. "Right" does not equal "hacky code", and left (sort of) does not equal "good code". When 99% of existing editors have added the .css code, will you still claim the change was good? HandsomeFella (talk) 17:56, 8 May 2013 (UTC)

Please don't pull statistics out of your ass. I am not going to waste my time measuring this just to prove someone wrong on the Internet. Matma Rex (talk) 18:01, 8 May 2013 (UTC)

Visible changes, especially changes that feel pointless, always upset people, until they've had time to get used to them. If it had "always" been on the other side, and they moved it out to the edge of the page, we'd be getting complaints about the pointlessness and stupidity of moving it to the far edge of the page and how hard it is to find the right button on sections with multiple images shoving the edit buttons around, or when multiple short sections are encountered on wide screens.

Complaints that appear immediately after a cosmetic change really say more about the person making the complaint than about the change. I encourage you to try it out for a month or two, and then see whether it's really as upsetting as it seems now. WhatamIdoing (talk) 16:22, 9 May 2013 (UTC)

Relevant blog entry

Just wanted to make sure this got linked somewhere here. Sharihareswara (WMF) (talk) 19:55, 7 May 2013 (UTC)

Add new section

What happened to newsectionlink? __NEWSECTIONLINK__ does not work. --Gusama Romero (talk) 21:29, 8 May 2013 (UTC)

It's absolutely impossible to be caused by this change. Where does it not work? Matma Rex (talk) 21:39, 8 May 2013 (UTC)

Adding the magic word, Add topic button appears, but not the link next to [edit] in the last section. This also happens in all Talk pages, including this one. --Gusama Romero (talk) 21:53, 8 May 2013 (UTC)

That's because MediaWiki has no such feature :) If you saw it somewhere, it must have been a local gadget, which can be likely easily fixed according to the instructions at Change_to_section_edit_links#Technical_information. Matma Rex (talk) 22:17, 8 May 2013 (UTC)

see next section: what this person complains about is really a script or gadget (that he was probably not even aware of) that stopped working because together with this change, the CSS class name was changed from "editsection" to "mw-editsection" and nobody bothered to inform us. peace - קיפודנחש (talk) 20:50, 9 May 2013 (UTC)

sneaky parasitic change - broke many scripts.

i have nothing against the change to attach the "edit section" links to the section title. some wikis, notably dewiki use this for years now.

However: while doing it, the developers also changed the class name from "editsection" to "mw-editsection". this was done in a sneaky way: the messages that appeared on the different wikis announcing the up-and-coming change did not mention the "oh, by the way, we are going to change the class name", and the only indication to the change we got was that after deployment, scripts began breaking left and right, not because "float:oneway" was change to "float:theotherway", but because the class name was changed.

well, first, i can't see good enough reason for the class name change: sometime you get stuck with less-than-ideal-names in order to maintain backward compatibility. you need significantly better reason to change class name and break backward compatibility than "i like this name better".

second, *if* you consider it seriously and make a conscious decision to change class names and break compatibility, please, please, announce it as clearly as you announced the attach-left/attach-right change.

you can run a simple search on enwiki right now, and you'll notice more than a 100 different scripts that depend on the "editsection" class name. this change carelessly and without notice broke them all.

please try to be more discriminating in the future when changing things that break so many things (typically css class names and html entities IDs), and please try to announce them in a way the will help users and admins to mend what you broke.

peace - קיפודנחש (talk) 20:47, 9 May 2013 (UTC)

I am the person (and volunteer) who implemented this change. While you're right that the announcements might have been done better, the change was mentioned at Change_to_section_edit_links#Technical_information, and the fix in most cases is trivial search&replace.

The reasoning for the class name change was to avoid worse breakage of core MediaWiki itself, not just gadgets. As you can see on the aforementioned page, the HTML changed as well, and due to the caching scheme WMF uses the new CSS has to be compatible with old HTML or things break horribly all over (bugzilla:42452 is a good example of what happens when we're not careful, and was in fact my own fault). This meant that we either have to change the class name, add some hacks like a new temporary <body> class, or use a script to mangle the HTML before the gadgets get to it. I first planned to use the third solution, but then after extended discussion decided on the first one – see the comments on https://gerrit.wikimedia.org/r/#/c/49364/ . This was also done to avoid breaking other scripts, like the ones that moved those links to the left previously – they shall continue to work on cached pages and then stop doing anything after the elements disappear. Believe it or not, this was thoroughly thought out.

I remain convinced that this was the least disruptive way to do this (but the deployment might have been handled better), and I hope my explanation makes sense to you :) Matma Rex (talk) 21:19, 9 May 2013 (UTC)

People who write scripts and gadgets need to watch for breaking change notifications like anybody else. This change was a long time coming, and if people who write widely-used code are not following lists like wikitech-l, wikitech ambassadors, the deployments announcements, or their local technical Village Pump, there is little we can do other than search for every script that might break and notify these people directly, which is not practically going to happen. Steven Walling (WMF) • talk 22:06, 9 May 2013 (UTC)

thanks for the response. i'm glad to learn that this was not done without thought, but i remain unconvinced about the necessity to change the class name. the 2nd answer above (from Steve) demonstrate the skew or bias i am talking about: mediawiki software is used by tens (if not hundreds) of thousands of wikis, some private and some public. the wikimedia wikis are a small fraction of those (admittedly, with the largest user audience). the answer basically boils down to "we are not committed to backward compatibility, and it's the responsibility of our users to follow up on the announcements (which, by the way, appear in a pretty obscure place), and to fix their scripts in accordance with the compatibility breaking changes we make".

true, in the spirit of open source software, every project is responsible to its own policies, and is perfectly "allowed" to have a policy that ignores backward compatibility. at the same token, i, as a user (and i might add - a loyal user, who also try to contribute back to the project, either by code snippets or by bug reports) am also within my rights when i come back to the project and whine and complain about this policy, which i think is bad.

peace - קיפודנחש (talk) 22:58, 9 May 2013 (UTC)

I agree that Steven's response could've been better (expecting people to follow a single mailing list, much less a labyrinth of mailing lists and wikis, is completely unreasonable), however I think you're a being a bit unfair here. You're discussing MediaWiki generally, but it's absolutely unequivocally and unambiguously recommended to run the stable version of MediaWiki. That requires updating MediaWiki occasionally and as we can see from <https://gerrit.wikimedia.org/r/#/c/49364/37/RELEASE-NOTES-1.22>, there are very clear notes about this breaking change (it's in all capital letters, even). While I agree that this is a breaking change, there was a clear rationale for it (maintaining CSS + HTML compatibility) and it has been advertised (in capital letters) to MediaWiki end-users. You can argue that it's rude to Wikimedia users (particularly the announcement that neglected to mention the breaking change), but to argue that it's rude to MediaWiki users really doesn't seem reasonable to me. --MZMcBride (talk) 02:26, 10 May 2013 (UTC)

thanks. i will take one more shot at it, at the risk of making myself a public nuisance: the assumption is that all changes in head version will eventually make their way to stable. true, by this time it will be possible to document it better, using things like "release notes", but the basic issue remains: maintaining backward compatibility is important, and i am not sure we respect it as much as we should. another example i just stumbled upon is the change in the way "watched" items appear in the "recent changes" list. in both cases there was a logical and good change to the html structure, combined with CSS class name change. in both cases the change is "good", but they also broke numerous users' scripts. please take this long tirade as a plea to avoid, as much as possible, such changes, or to put a little differently: see it as a plea to assign to backward compatibility significantly heavier weight when considering an improvement to html structure, CSS class names, and API. peace - קיפודנחש (talk) 18:00, 10 May 2013 (UTC)

It appears that there are an enormous number of changes planned for the next year, and on a scale that will rival the switch to Mediawiki software from UseModWiki back in 2002. I think that you can safely assume that all scripts are going to break at some point, even with significant attention to backwards compatibility. WhatamIdoing (talk) 20:45, 10 May 2013 (UTC)

I'm fairly disappointed. The time was taken to say, "Hey, we're moving the edit section link closer to the header from the edge of the screen." and you couldn't toss in "edge of the screen and updating the class to mw-editsection." I actually like the new classname as it is consistent with other changes such as mw-collapsible and so forth... I'm not happy you couldn't expand your note six words to give everyone a better heads up. Lack of communication or even just poor communication is the leading cause of failure in any application. Let's work together on that, please? Technical 13 (talk) 16:17, 11 May 2013 (UTC)

Sure. You could subscribe to the wikitech-ambassadors mailing list for a start: Tech/Ambassadors#Staying_informed (the information about this went there first). You can't complain about not being informed if you are avoiding all communication channels. 77.254.206.127 16:20, 11 May 2013 (UTC)

Gadget-edittop.js @ ml.wiki

Hi, Gadget edittop stopped working @ ml.wiki. We are unable to find the problem. Code is exactly simillar to that of en.wp or Wikimedia Commons. If possible please help--Praveen:talk 03:25, 15 January 2014 (UTC)