I suppose the same could be said for the pipes in #contentSub on Special:Contributions and Special:DeletedContributions.

On the other hand, content is supported from IE8, but we still support IE6+, so I assume this is blocked on raising grade C support to IE8+?

Pipes like on Special:Contributions and Special:DeletedContributions are used in a large number of places (see usages of the 'Language::pipeList' function). That's a bigger thing and I'm not sure if there's really a reason to change that.

This particular pipe on the edit form is probably unnecessary. It's a leftover indeed, but less so from IE 6 times than from old editor times. It was useful when "Cancel" and "Editing help" were plain links, but we could probably just remove it now.

Probably no one paid any attention to it because the pipe and "Editing help" are hidden when WikiEditor is enabled (because its toolbar has editing help integrated).

Let's stay with the case in the task description for now. @Aklapper I'd mentor this.

@Nirmos The pipe character is just an additional visual element to the already given whitespace between the Cancel and the Help link. The basic functionality doesn't break on IE6 & 7 by not showing the pipe there.

Thanks. Published as https://codein.withgoogle.com/tasks/5520145537564672/

Change 403066 had a related patch set uploaded (by Albert221; owner: Albert221):
[mediawiki/core@master] Remove redundant HTML element in favor of CSS

https://gerrit.wikimedia.org/r/403066

@Volker_E pipe-separator is a translatable i18n message. You lose translations with plain CSS approach.

@Nikerabbit do you think there is any need to have separator internationalizable?

We are using multiple kinds of separators. Some of them are stylistic, some are not, and I blocked adding a new kind of separator as an translatable message some time ago.

Arguably pipe-separator is one of the separators that is more stylistic. But my real argument is that it is used in multiple places, and because of that, to stop using it in one place only introduces inconsistencies. I would like to see a plan to bring more consistency over time.

Also, with some effort it is possible to do language specific customisations with CSS, if that is required.

@Nikerabbit theoretically, would replacing all internationalized separators with CSS ones work?

In theory yes, but one should be prepared to handle the community interactions if it causes changes.

Hmm, good point @Nikerabbit.

We definitely could use the message in CSS. We can put the localisation message in a Less variable – you'd need to create a new PHP class similar to ResourceLoaderEditToolbarModule (used for the 'mediawiki.toolbar' module) and use that for this module.

In my opinion though, the best thing here would be to just remove this separator. The buttons are already clearly visually separated, simply by being buttons.

@Nikerabbit Thanks for pointing that out. Yeah, agree with @matmarex, removing it altogether then sounds to be the right thing to do from my perspective as well in this specific case.

@Volker_E so the target of the task changes to removing this separator completely, right? :)

BTW could you join on IRC please

Here's how the patch looks:

Do we need a follow-up task to remove overrides from extensions/skins? https://codesearch.wmflabs.org/search/?q=mw-editButtons-pipe-separator&i=nope&files=&repos=

Change 403066 merged by jenkins-bot:
[mediawiki/core@master] EditPage: Remove separator between cancel and help

https://gerrit.wikimedia.org/r/403066

In T183672#3888930, @Legoktm wrote:

Do we need a follow-up task to remove overrides from extensions/skins? https://codesearch.wmflabs.org/search/?q=mw-editButtons-pipe-separator&i=nope&files=&repos=

• WikiEditor: https://gerrit.wikimedia.org/r/403547
• CodeEditor: https://gerrit.wikimedia.org/r/403548
• Minerva: https://gerrit.wikimedia.org/r/403549