In T210871#4814751, @Mvolz wrote:

Well- we ARE a robot. So probably technically the things that can be done would involve pretending we are not a robot...

In T182041#4813636, @Pkra wrote:

Div meets the intent of block math better. It might even be reasonable to mark it up as a paragraph in HTML 5.

While display equations may be block content that is not always the case.

That's true. But if you mark up your <math> wikitext with <math display=block>, you as the author of a wikitext document are *way* obviously meaning for the math to display as a block. Are you familiar with that functionality? That's what this task is about. Arguing without that context or seemingly without that context seems to miss the point of the task.

Div meets the intent of block math better. It might even be reasonable to mark it up as a paragraph in HTML 5.

It started happening with me right around Firefox 60 also. No issue before then. I mostly experience it with WTE17. It seems to impact the Linter extension also by not loading the linted wikitext, which does not load WTE17 but instead WikiEditor 2010.

In T92432#4772701, @Whatamidoing-WMF wrote:

This has been proposed as part of the 2019 Community Wishlist: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Citations/VisualEditor:_Allow_references_to_be_named It's too early to know whether it will make the top 10 (voting will be open until the 30 November 2018), but it's currently among the more popular items, which suggests that solving this problem has widespread community support.

On an aside, I don't find the original report compelling for allowing this behavior. That's its own issue (T3584: Need method for multiparagraph list items, continuing numbered lists, and assigning specific numbers to list items especially the first item in the title) and should probably have its own fix. (Which, I may have falsely closed one or another in that duplicate chain....)

I'm going to copy the description from my T202083: First-class wikitext support for ordered list item value:

W3schools points out that progress bars should use <progress>, not <meter>. A better use of <meter> would be for Template:Rating.

I know @TheDJ has poked around here. I'm pretty sure I've seen a task for this elsewhere (not just for Timeless).

In T210822#4798570, @PerfektesChaos wrote:

• The current purpose is to indicate that here is a link which is not coloured in blue as every other link does.
• There are people editing since 2005 with 100.000 edits who never noticed that some five or eight years ago a link feature has been introduced. They learnt it two weeks ago when it all became blue and a debate started whether it shall remain blue or grey again as within the years ago.
• The arrow has been blue the last years, but nobody discovered the colour of that little arrow.
• If you are new in Wiki world you have no idea that somebody is hiding a clickable link, something greyed out just before the user summary. That is signalling inactivity, used for deactivated things.
• The arrow is the only thing which might give you a clue to hover at this part of the interface.

In T211044#4798766, @Isarra wrote:

Okay! So we really just want the behaviour consistent with other skins - not necessarily bold, that doesn't matter one way or the other, but sizing/spacing.

; is for definition lists, it's supposed to act as the header for : items. We need consistent headeriness. https://meta.wikimedia.org/wiki/Help:Wikitext_examples?useskin=timeless#Organizing_your_writing should match https://meta.wikimedia.org/wiki/Help:Wikitext_examples?useskin=vector#Organizing_your_writing in terms of effect.

May also be worth looking into header styles in wikitables and fieldsets and such, too, as all of these should ideally behave the same.

1. What is the purpose of the arrow? Is it discoverability alone?
   1. Is that necessary? I don't think so. I don't think the arrow here does any good to serve discoverability, and conflates the discussion ongoing in T125657 anyway.
2. Is it only to demarcate "in <section of interest>: <summary>"?
   1. Is that necessary? I doubt so--clearly there are people who missed the usefulness of the arrow, which inspired the change that set off all this discussion.
3. Is it both?

In T210822#4791734, @AfroThundr3007730 wrote:

In T210822#4789323, @Dvorapa wrote:

It could also help to restructure the order of items. Currently we have (watchlist):

 diff    _ hist .. tag    _ page _ time   .. size   .. author _ talk   _ contribs _ ->section _ summary
(change _ page .. change _ page _ change .. change .. change _ author _ author   _ page      _ change )

I would restructure it like this:

 page _ section _ hist .. tag    _ summary _ size   _ time   _ diff    .. author _ talk   _ contribs
(page _ page    _ page .. change _ change  _ change _ change _ change .. change _ author _ author  )

In T210822#4789383, @Nirmos wrote:

If the diff link is not the first item in the list, or in different places depending on whether a section was edited or not, that would be the end of counter-vandalism.

I agree with Nirmos. This would indeed have a significant impact on those who have to regularly scan through those history pages to reconstruct an editor's actions.

The diff, date, time, etc. are the same length and line up consistently in the article history and contributions, and should stay at the beginning of the line. If they were re-ordered with variable-length data like page and section name first, the layout would become significantly more chaotic, and less easily parsed by the reader. The variable-length data should always appear at the end of the line to maximize legibility.

In T165189#4796030, @gerritbot wrote:

Change 477428 merged by jenkins-bot:
[mediawiki/core@wmf/1.33.0-wmf.6] Restore gray coloring for autocomments

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

Since the other task is making everything the same gray again, reopen this one.

I actually really like the serif font in these rather than the bold, though it does take some getting used to.

In T148701#4417283, @Izno wrote:

Is this still a problem with RemexHtml ?

In T210831#4788695, @Aklapper wrote:

Please explain which exact behavior you would have expected instead to display that revision (expected outcome) and what exactly is "malformed" (actual outcome).

Invalid with T165189: "→" link to page section on History page can be hard to click, should be larger somehow I think. 😃

Yeah, this is not likely to be changed. Use syntaxhighlight with lang=moin and inline if you want this behavior.

Are there any wikis where it makes sense for NEWSECTIONLINK to work in mainspace that shouldn't instead be configured in the wiki configuration for global new section links?

Sticking our heads in the sand and declaring that the current svg render is already perfect (when it manifestly is not) does not advance that cause.

Related task over at T8089: Section edit button shows up for transcluded protected page (also not the same).

Well, found a duplicate just above; T15079: no edit links for transcluded sections on protected pages is similar but not the same.

Not quite the same as T11394: Section "view source" on protected pages but figured I'd relate them in the comments.

This is either a duplicate of T92432: Come up with a better way to auto-label references or of T52568: VisualEditor: Be able to name references manually in the reference dialog.

This seems like a bad idea. Render modes would spread into the wild, which makes it harder to use math everywhere else and get expected results according to user preference.

I've narrowed the scope for the request to annotations per the last comment by the ticket author.

Just want to link T155732: Provide a Preview panel that doesn't obscure the wikitext box and maybe the skin's sidebar (?) and T153306: Have Show preview and Review your changes more directly accessible in the New Wikitext Editor here as relevant.

I see the insect as the 4th result in Google in a private tab on Firefox.