That’s an interesting idea.

There is one caveat to consider: on some discussion pages, the topics are already listed in reverse chronological order, i.e. the newest topics appear at the top. If the topics were then reordered by DT, the topics would appear in the wrong sequence. This can be partly resolved by making DT recognise the template:New topics at the top. If DiscussionTools finds such a template, it should realise the newest topics are already at the top.

Alternatively, a rule could be introduced stipulating that, in the code, topics must always be in chronological order: the oldest at the top and the newest at the bottom. This would ensure that DT always expects the same behaviour from discussion pages. However, this would require modifying thousands of discussion pages, including the vast archive pages of forums where the order is reversed (newest at the top).

That's a good idea :) Just remember to include settings for anonymous users. That's a good idea :) Just remember to set up settings for anonymous users. And don't forget to provide API access, if needed, for third-party scripts like Convenient-Discussions.

• DiscussionTools could disable re-ordering if its parse detected any non-discussion sections.

I’m not sure if it’s a good idea. Sections may be detected as non-discussion for various reasons: in addition to they indeed not being discussions, this may happen because of date format/timezone changes (DT only detects timestamps using the current timestamp format as timestamps, T246047), non-conforming signatures, or simply comments not being signed (this can happen if the user didn’t use DT, e.g. because the comment was written a decade before DT was invented – this often happens on low-traffic article talk pages, which never get archived).

There is one caveat to consider: on some discussion pages, the topics are already listed in reverse chronological order, i.e. the newest topics appear at the top. If the topics were then reordered by DT, the topics would appear in the wrong sequence. …

I don't think this will be an issue as ultimately we'll sort by actual timestamp. The planned proof-of-concept however would exhibit this caveat.

DiscussionTools could disable re-ordering if its parse detected any non-discussion sections.

I’m not sure if it’s a good idea. Sections may be detected as non-discussion for various reasons …

Noted. I think for this task, we will have to rely on the data DT can provide, i.e. what you see when testing with Special:DiscussionToolsDebug. Beyond that, I suppose things will have to be dealt with piecemeal, such as manually fixing timestamps.

I agree that the implementation should rely on DT data and only on that. However, as far as I understand the description, you propose completely disabling the sorting on pages with sections not detected as discussions – that’s what I disagree with; instead, I think we should do the best we can, sorting sections detected as discussion topics, and leaving other sections somewhere (e.g. moving them to the top).

I’m not sure if POC is purely for demonstration purposes as it’s unclear from the task text but, if it’s not, please be aware that changing the order of the sections with CSS does not change the accessibility tree of the elements, so any potential section-swap should only happen server-side for accessibility reasons.

So where will the control reside, where will the user preference be? I imagine it will be the kind of preference that you might want to change often and depending on context (the page). Do you see it the same way or differently?

An obvious place to control the sorting order is the table of contents, e.g. something like this:

An open question: What to do you if there are <h1>s on the page? Sort inside them, don't sort? Sort <h1>s themselves?

What are the typical uses for <h1> on talk pages?

In T422073#11906027, @Jack_who_built_the_house wrote:

What are the typical uses for <h1> on talk pages?

In my experience, it’s usually used to create higher-level sections (for example, on a noticeboard to hold different kinds of requests), so that topics within them are <h2>s and thus can use the standard new topic button. If my experience is correct, <h1>s should not be sorted.

On the other hand, there are noticeboards where the higher-level sections are <h2>s and individual topics are <h3>s, so the <h3>s should be sorted on them. However, on usual village pumps, talk pages etc., <h3>s are used to further structure topics and should not be sorted… I guess a generic opt-out (__NO_REORDER__) would not be enough, and a more detailed per-page configuration is needed.

In T422073#11908310, @Tacsipacsi wrote:

On the other hand, there are noticeboards where the higher-level sections are <h2>s and individual topics are <h3>s, so the <h3>s should be sorted on them.

Is this justified though? Maybe it would be easier for them to switch to using h1-h2? h3's are non-subscribable on top of that.

This is all wonderful feedback!

In T422073#11905706, @stjn wrote:

I’m not sure if POC is purely for demonstration purposes as it’s unclear from the task text but, if it’s not, please be aware that changing the order of the sections with CSS does not change the accessibility tree of the elements, so any potential section-swap should only happen server-side for accessibility reasons.

Noted! Yes, it would have been purely for demonstration purposes. It sounds like everyone sort of understands the idea though, so maybe it's not even worth building and we can instead focus on the actual requirements, as the CSS-only solution has its obvious flaws. Thanks for pointing out the accessibility factor. I think that's something we will be able to address in the JS implementation.

In T422073#11905978, @Jack_who_built_the_house wrote:

So where will the control reside, where will the user preference be? I imagine it will be the kind of preference that you might want to change often and depending on context (the page). Do you see it the same way or differently?

An obvious place to control the sorting order is the table of contents, e.g. something like this: F80692575

The designers are still working on it as understand, but yeah, I think we'd likely add something to the UI directly on the talk page (as opposed to having to go to Special:Preferences).

In T422073#11909267, @Jack_who_built_the_house wrote:

In T422073#11908310, @Tacsipacsi wrote:

On the other hand, there are noticeboards where the higher-level sections are <h2>s and individual topics are <h3>s, so the <h3>s should be sorted on them.

Is this justified though? Maybe it would be easier for them to switch to using h1-h2? h3's are non-subscribable on top of that.

I don't want to state anything as fact as I'm not sure, but I think we'd want to lean towards conformity with the DiscussionTools system, which I believe is that "normal" discussion pages are supposed to use <h2>s. If you can find an example discussion page with <h1>s or other weirdness, you can test how DT interprets it using Special:DiscussionToolsDebug. Perhaps we will be able to offer sorting of the <h2>s within each <h1>, or maybe we'll need to ignore <h1>s altogether.

Keep the feedback coming! :)

In T422073#11909267, @Jack_who_built_the_house wrote:

Is this justified though? Maybe it would be easier for them to switch to using h1-h2? h3's are non-subscribable on top of that.

Easier, but using <h1>s is non-conforming HTML, and it has always been that (before Parsoid, there were no <section> elements, and by the time Parsoid becomes the default parser, using <h1>s in <section>s has also been deprecated). Honestly I have no idea why the wikitext parser allowed that in the first place, why is = … = recognized as a heading. However, it’s now there, and wikitext syntax is extremely hard to get rid of, so it’s probably going to remain.

The subscription is again something the more detailed per-page configuration (e.g. a parser function) can address.

In T422073#11909507, @MusikAnimal wrote:

If you can find an example discussion page with <h1>s or other weirdness, you can test how DT interprets it using Special:DiscussionToolsDebug.

What I directly had in mind is https://hu.wikipedia.org/wiki/Speciális:DiscussionToolsDebug/Wikipédia:Bürokraták_üzenőfala. It looks okay (however, as I wrote above, the real page is actually non-conforming HTML).