This happens in WTE 2017. I haven't looked to see if the same happens in VE.

This is intended behavior. There is an intermediate size between "icons" and "2 column view".

In T160830#4295086, @Liuxinyu970226 wrote:

Why <references /> instead of just <references>? Isn't it now broken following RemexHtml?

In T197087#4293639, @Tgr wrote:

@Izno do less-experienced users involve admins, stewards etc?

Related to T194125: [RFC] Future of charset and collation for mediawiki on mysql and T193222: Error: 1071 Specified key was too long; max key length is 767 bytes probably.

@TheDJ has done quite a bit of work maintaining user scripts (I guess he would prefer not to do it, but I do know he currently provides his time in this fashion) that less-experienced users would probably not be willing (read: "sure-enough") or able to do. Removing the permissions is not sensible from this dimension.

In T6964#3897917, @Iniquity wrote:

I think we need to discuss this anew.

In T190015#4273946, @TerraCodes wrote:

I think this might have been mentioned above, but JS/CSS review would also be a good idea to add. Might also be a good time to go through all of the css and js pages and see if anything can be removed or added to the core.

In T69700#4262456, @stjn wrote:

If this can’t be resolved in 4 years already

This is resolved in Timeless now, which isn't an old skin. Kind of changed the goalpost on us there @TheDJ :)

In T195625#4250286, @Legoktm wrote:

Why is this showing up on my desktop computer (seemingly related to high zoom levels / small screens)

Funnily enough, I like the animation strictly because it tells me whether something is collapsible with en.WP's current homegrown collapsible code or with mw.collapsible.

In T157418#4205078, @ssastry wrote:

Our round trip testing infrastructure compares roundtripped wikitext with original wikitext. In order to figure out which diffs are syntactic and which are semantic, it does diffing with a bunch of normalizations and other tricks. But, those tricks are proving insufficient with the kind of normalization that is happening with this whitespace trimming. So, we need to update our round-trip diffing strategy. In order to not block other Parsoid deployments (since all deployments have to go through round trip testing and not have any unexplainable semantic diffs), I am reverting this patch till then.

In T193454#4170463, @Schniggendiller wrote:

Maybe you’ll find lintHint interesting :-)

There were never parser-migration edit links in this context, only the linterid edit links.

This is T140606: User preferences: Check raw signature for linter errors and T178879: Automatically (or manually, server-side) fix user signatures containing Lint errors.

This is probably fixed when T181287: Search results from sister site are always aligned under the main results is fixed.

En.WP thread is currently at VPT.

@ssastry Did Remex get turned on inadvertently? This is occurring on en.WP right now (when I thought the timeline was Q3 2018).

In T192033#4125781, @Od1n wrote:

I mean that the bold removal and the underline on hover are by design ;) But I may be mistaken.

Also, you are actually referring to the Minerva skin (used on mobile), not Timeless.

Nope. They were bolding before the changes in that timeframe.

Who is your audience for the blog posts?

Since the education program extension is going away on Wikimedia wikis, does it make sense to track that in this task (which I would guess is mostly pointed at Wikimedia wikis due solely to scope)? (wrt eparticle log)

@Esanders @Jdforrester-WMF @ssastry I'm still unable to get the lint error. Now, however, I don't have

In T49544#4124808, @ssastry wrote:

Once Tidy is replaced with RemexHtml (T89331: Replace HTML4 Tidy in MW parser with an equivalent HTML5 based tool), I expect this will be fixed. Let us revisit after that happens.

The right parent task, if there is one, is T28751: Extensions that should really be core functionality (tracking), but that precludes the option of turning authority control into an extension.

In T156474#4006373, @dcausse wrote:

Yes, but since this keyword will fail before all wikis are reindexed I think we should postpone any doc addition until the reindex is done. A task for adding it to the doc is good idea.

In T183804#3864220, @Tacsipacsi wrote:

Seems more like a bug in the Cite extension for me.

This task does not meet the criteria for high, nor even normal. Please do not set them unless you are a developer.

I would prefer to see it editable, not least because of the new and snazzy Ping People From Edit Summary.

Phabricator is for changes either to the MediaWiki software or configuration changes for the Wikimedia community.

I'm going to float an idea here to see about technical feasibility of a sketched idea (or maybe to spark a similar idea--maybe with Lua tables instead). (TheDJ's comments above are pretty cool idea too I think.)

In T157418#3985162, @PerfektesChaos wrote:

In general,

xxx<tag>  inside  </tag>yyyy

should be treated as

xxx <tag>inside</tag> yyyy

In T54564#3956902, @Alsee wrote:

And that foreign article needs to link to both English articles. Wikidata's faulty insistence on 1-to-1 realtionships causes problems for both editors and readers.

Thought of a technical solution, might as well throw it out there:

Either way, I think we should decline this and suggest filer take up the question at [[Mediawiki:Mobile.css]].