Change 990775 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] Add 'typeof="mw:Heading"' to wikitext headings

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

Change 990776 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/services/parsoid@master] Add 'typeof="mw:Heading"' to wikitext headings

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

Change 990777 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/VisualEditor@master] Allow 'typeof="mw:Heading"' on Parsoid headings

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

Change 990778 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/DiscussionTools@master] Detect HTML headings using 'typeof="mw:Heading"'

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

Change 990775 abandoned by Bartosz Dziewoński:

[mediawiki/core@master] Add 'typeof="mw:Heading"' to wikitext headings

Reason:

I'm not working on this at the moment.

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

Change 990776 abandoned by Bartosz Dziewoński:

[mediawiki/services/parsoid@master] Add 'typeof="mw:Heading"' to wikitext headings

Reason:

I'm not working on this at the moment.

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

Change 990777 abandoned by Bartosz Dziewoński:

[mediawiki/extensions/VisualEditor@master] Allow 'typeof="mw:Heading"' on Parsoid headings

Reason:

I'm not working on this at the moment.

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

Change 990778 abandoned by Bartosz Dziewoński:

[mediawiki/extensions/DiscussionTools@master] Detect HTML headings using 'typeof="mw:Heading"'

Reason:

I'm not working on this at the moment.

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

I forgot to note this here at the time, but I talked to some folks from the Content Transform team after I proposed these patches, who didn't like them very much because the semantic meaning of these attributes wasn't clear and it would also require changes to the Parsoid HTML spec with backwards-compat implications. Their counterproposal was adding some class name or some other attribute to only the "raw" HTML headings instead (internal Slack link: https://wikimedia.slack.com/archives/C024Z8K9CAU/p1705359054223579 – sorry, not publicly accessible). I'd be happy with that too, I just didn't get around to trying to implement it.

Substantially the same idea was also proposed in T13555#9896561 by @Od1n.

It does seem a bit strange though to simultaneously push for all media files to have a convoluted typeof-based syntax and for headings to not have typeof-based syntax. Though I do think that <figure> conversion as implemented was a massive mistake and we ended up with a lot of CSS bloat because of it that could’ve been avoided if classes were used, so I don’t have a problem with using them generally.

Change #1113861 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] OutputTransform: Mark HTML headings with class="mw-rawheading"

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

Maybe we can try doing it like this. This patch uses a class instead of typeof. It's also much simpler and less risky by adding it in the output transform, rather than in the parser itself – the tradeoff is that we can't distinguish == … == from <h2>…</h2> (with no attributes), but maybe nobody really cares that much about that case? (nobody seemed to mind it much when the same thing came up in T353489).

In T68637#10490325, @matmarex wrote:

the tradeoff is that we can't distinguish == … == from <h2>…</h2> (with no attributes)

While developing JavaScript gadgets, I have encountered the following needs regarding section headings:

• Adding a link next to the title (the position to insert varies depending on whether it's a regular or raw heading, if the section has an "edit" link or not, what skin is used, if MobileFrontend is present or not…).
• Getting the section's anchor (i.e., the value of the id attribute).
• Getting the section's title.
• Selecting the section content (essentially, all elements following the section heading, up to a stopping element: next section heading, navbox…), with the use case being a toggle to show/hide the content (more specifically, a blur effect to hide spoilers).

Additionally, there's a need to exclude the h2#mw-toc-heading element (as it would not have the mw-rawheading class, this issue would be resolved as well).

For these use cases, the code differs significantly depending on whether the headings are regular or raw, but we don't need to concern ourselves with what wikicode has been used. What's important is supporting both structures of outputted HTML. Thus, I would say the tradeoff you mentioned is not an issue.

(For additional context, you may see my comments starting from T13555#10040671)

Change #1113861 merged by jenkins-bot:

[mediawiki/core@master] OutputTransform: Mark HTML headings with class="mw-html-heading"

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

The distinguishing class name has been merged, and it is called class="mw-html-heading". I documented this on the previous documentation page, please review: https://www.mediawiki.org/w/index.php?title=Heading_HTML_changes&diff=prev&oldid=7602007

Change #1295065 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):

[mediawiki/core@master] Parser/Handle*SectionLinks: "html" syntax headings don't need an attribute

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

Change #1295357 had a related patch set uploaded (by Gerrit Patch Uploader; author: Anne Haunime):

[mediawiki/core@master] Parser/Handle*SectionLinks: Test fixes for Change 1295065

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

Change #1295357 abandoned by C. Scott Ananian:

[mediawiki/core@master] Parser/Handle*SectionLinks: Test fixes for Change 1295065

Reason:

Thanks! Squashed into Ieb7fb4806458e7756d00e76eb92594882d0c7148

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

Change #1295065 merged by jenkins-bot:

[mediawiki/core@master] Parser/Handle*SectionLinks: "html" syntax headings don't need an attribute

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

I'd like to note that Gerrit 1295065 introduced a subtle, but problematic change in a specific case.

First, for clarity, here is a summary:

Before Gerrit 1295065

After Gerrit 1295065

My concern is in the specific case "bare <h2> + talk page": these headings now have both the container mw-heading and the mw-html-heading class, whereas these elements were previously mutually exclusive. Therefore, the mw-heading container is no longer a reliable way to determine that the heading is not an HTML one. To put it otherwise: previously, mw-html-heading elements were never wrapped in a mw-heading container, under any circumstance.

Still, Gerrit 1295065 is overall an improvement (that behaviour difference between the <h2> having attributes or not was terrible), and it may be argued that mw-heading and mw-html-heading may both make sense at the same time.

But it brought issues, as we encountered on frwiki: 236985289, 236985443 (which I then radically solved: 236986429, 236986430, 236986938 – still a very slight bit tricky, but much, much less than before). (As an aside, my HeadingsTweaker.js script could have been impacted: it hasn't been affected, by luck. In case of an HTML heading wrapped in a container, we want to consider its container (i.e. handle it like a wikitext heading), as the purpose of this script is to provide an abstracted way to inject links in headings.)

I think there would be a simple way to address this: in case of an HTML heading, never wrap it in a mw-heading container.

Proposed fix (never wrap HTML headings in mw-heading)

There would be a change only in the specific case "bare <h2> + talk page", and this would bring consistency with the 3 other cases: "bare <h2> + subject page", "<h2 style="..."> + subject page", and "<h2 style="..."> + talk page", therefore achieving full consistency. Furthermore, it may be argued that a desired effect of using HTML syntax is precisely to avoid adding this container (no "edit section" link), and that the markup structure should remain as in the page source (i.e. keep a direct <h2 [attrs]>, just adding this nice mw-html-heading class).

CC @Escargot_rouge in case you are interested in watching this.

Briefly noting that we need to deploy
https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/1300235

And the definition of isHtmlHeading in DiscussionTools needs updating to match
https://github.com/wikimedia/mediawiki-extensions-DiscussionTools/blob/master/includes/CommentFormatter.php#L100-L125

As a follow-up to my previous comment: I'm having a hard time understanding why, in certain namespaces (e.g. Wikipedia:), headings end up carrying DiscussionTools-related markup (ext-discussiontools-init-section, data-mw-thread-id, etc.), even on pages that are clearly not talk pages.

Perhaps DiscussionTools is enabled on that namespace as a whole, since some Wikipedia: pages do host discussions.

But shouldn't the check be at the page level rather than the namespace level? A non-talk page in a mixed namespace still has no business carrying discussion-related markup.

@Od1n DiscussionTools uses a fairly-complicated heuristic to determine whether a page "could be a discussion" since some discussions happen outside of the Talk: namespace. If you give specific examples I could probably check to see exactly what is triggering the heuristic in that case.

@cscott For example, the main page of Chinese Wikipedia.

I was about to indicate that on frwiki this happens across the whole Wikipédia: namespace (and a few others), including our home page — but I just noticed a change that landed today:

• HTML-syntax headings are no longer wrapped in a mw-heading container.
• They still carry a bit of leftover DiscussionTools markup, though — which is clearly erroneous.

I don't know where this change that landed today comes from, and any insight on that would be much appreciated. There might be a Phabricator task or a Gerrit patchset somewhere that forgot to reference this task?

The patches were tagged with T417531: Section wrapping should use precise information about HTML-syntax headings

Thanks for the pointer to T417531, @cscott.

If I understand correctly, the concern I raised above (T68637#12015627) — HTML headings ending up wrapped in a mw-heading container on talk pages — has been resolved, which is great news. Can we assume this specific point is now settled for good?

That said, the other DiscussionTools-related concerns I raised remain open:

• the talk-page detection heuristic that is too broad (e.g. flagging non-discussion pages in namespaces like Wikipedia:/Wikipédia:)
• HTML-syntax headings still carry leftover DiscussionTools markup (data-mw-thread-id, data-mw-comment-start, data-mw-comment-end) even though they shouldn't be processed by DiscussionTools at all