Could this be done with saving previous colour by default (unless on hover)? I am fully supportive of this change on the grounds of accessibility, but right now basically everything in the watchlist is blue, which doesn’t help with hierarchical navigation.

I see several changes in rMW0a8e16d7cfe6: Make "→" link to page section on History page larger by adding section name to… that I think are for the worse.

• The section title should not be outside the <span dir="auto">
• The section title should remain inside the <span class="autocomment">
• If the section title contains wikilinks, the generated HTML will have nested links.
• The getDirMark() should probably still be between the arrow and the text; you probably re-broke whatever rSVN109086: Follow up to r105855 - now with updated phpunit tests. fixed.
  • Possibly that was something with using an RTL language and viewing LTR comments?

+1 to all of what Anomie said.

In T165189#4788128, @APerson wrote:

+1 to all of what Anomie said.

+1 too

In T165189#4787486, @stjn wrote:

Could this be done with saving previous colour by default (unless on hover)? I am fully supportive of this change on the grounds of accessibility, but right now basically everything in the watchlist is blue, which doesn’t help with hierarchical navigation.

Totally agree

This should be reverted to what it was while you are figuring out how to deploy it properly, if you even end up deploying it. Where is the discussion that said that this is something that needed to be done or wanted to be done?

@Nihlus: For each task, "the discussion" is in that very task as comments get added to a task.

So this is one of those changes that no one asked for? Is that what you are saying?

In T165189#4788873, @Nihlus wrote:

So this is one of those changes that no one asked for? Is that what you are saying?

The proposer of the task asked it, others approved it or didn’t object to it. There are concrete reasons for doing this change, namely, better accessibility compliance: 1) before screen readers probably read this like link, right arrow, now it is more descriptive, 2) link targets of extremely small size are not accessible to people with motor skills issues. Do you have any particular issues with this?

In T165189#4788305, @Legoktm wrote:

I think a few other people have also found the sudden blueness not helpful (via remarks I read on-wiki and IRC). @Izno referenced T125657, which indicates that the prior gray wasn't accessible, so I'm not sure that's the best color to go back to (though of course that's fine as a temporary thing while we discuss further if the blue is that off-putting).

Previous colour #72777d that was used for some time for section titles already (barely) passed WCAG 2.0 AA level requirements, but I don’t have any particular preference to it.
https://contrast-ratio.com/#%2372777d-on-white

In T165189#4788305, @Legoktm wrote:

I'm not sure what we should be doing about nested links, do you have any suggestions on how those should be handled?

We should just remove them from HTML markup, in my opinion.

@Nihlus: Every task has authors, subscribers, commenters who are free to add constructive comments. I hope that answers your rhetorical questions.

In T165189#4788873, @Nihlus wrote:

So this is one of those changes that no one asked for? Is that what you are saying?

Some people voted for this change also here.

In T165189#4788305, @Legoktm wrote:

I'm not sure what we should be doing about nested links, do you have any suggestions on how those should be handled?

We should just remove them from HTML markup, in my opinion.

I agree with that proposal

In T165189#4788305, @Legoktm wrote:

I'm not sure what we should be doing about nested links, do you have any suggestions on how those should be handled? When I use my watchlist, if there's a section that has a link in the header, I'm rarely interested in the destination of the link, and more interested in the section itself. Are there workflows where the link in the section header is the primary destination people will want to click on?

I've used the links sometimes when my bot reports an error like on https://en.wikipedia.org/w/index.php?diff=870565800&oldid=870424083. But I don't consider that so compelling a use case that I'd care if the link went away.

I don't know if others have other use cases.

I also want to cross-link T210822: Reconsider section heading marker ("→") in edit summaries, which proposes getting rid of the arrow now that it is no longer required for including a section link - I assume that subscribers to this task might also be interested in discussing that.

If the autocomment section link is visually distinct[1] from an edit summary that happens to begin with a link, sure. If "/* Foo bar */ baz" and "[[Foo bar]]: baz" look identical at first glance until you hover and see the different targets, that would be annoying.

[1]: e.g. restoring the grey, or some grey that's accessible while still also being accessibly distinct from plain text.

Yeah, probably WCAG-compliant gray would be cool

In T165189#4788873, @Nihlus wrote:

So this is one of those changes that no one asked for?

https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Miscellaneous/%22%E2%86%92%22_links_to_sections_should_be_easier_to_click though I don't know if this wish is what spurred the implementation. But anyway, people have asked for it.

In T165189#4787486, @stjn wrote:

Could this be done with saving previous colour by default (unless on hover)? I am fully supportive of this change on the grounds of accessibility, but right now basically everything in the watchlist is blue, which doesn’t help with hierarchical navigation.

Agreed. Highlighting on hover would be fine, but apart from that please restore the gray that used to be. Section titles don't have to draw such a great amount of attention, esp. since there may be wikilinks in the edit summary, and these make much more sense. See also MOS:SEAOFBLUE (one may argue that there's a colon separating the links, but then again the total blueness all around is nothing but the sea).

• I am fine with fully clickable link.
• On wikilinks within section title: The fragment shall be shown and linked, the same as in TOC. Nested wikilinks should not be a problem, markup should be stripped off entirely and the link on outer pages should get the same appearance as TOC within target page, but dropping bold and italic. Automatically generated /*...*/ does not contain any markup.
• The leading arrow people are used to is fine and may be kept as part of the link.
• There might be some more space filled with I18N robust stuff between section link and begin of summary. If summary starts with wikilink, summary will start in blue as well. Something visible in black should create a widened gap between blue section link and blue comment start.
• There are people who did not learn over years that the arrow is blue and might be clicked. That feature has been introduced some five or eight years ago, and oldtimers as of 2005 never noticed that there is a link. On the other hand, newbies shall identify that feature immediately.
• Therefore, blue colour is necessary to clarify the behaviour. No other colour than every other link targetting such pages.
• If anything changes, even clearly improving, always some guys complain loudly that their wiki experience crashed now since they were forced to learn something. One year later nobody recalls.

In T165189#4790084, @Mike_Novikoff wrote:

In T165189#4787486, @stjn wrote:

Could this be done with saving previous colour by default (unless on hover)? I am fully supportive of this change on the grounds of accessibility, but right now basically everything in the watchlist is blue, which doesn’t help with hierarchical navigation.

Agreed. Highlighting on hover would be fine,

No, it would not. Violation of accessibility requirements, touch-device-inappropriate styling, and violates the entire point of the change (which is to make it more visible).

In T165189#4790322, @PerfektesChaos wrote:

• There are people who did not learn over years that the arrow is blue and might be clicked. That feature has been introduced some five or eight years ago, and oldtimers as of 2005 never noticed that there is a link. On the other hand, newbies shall identify that feature immediately.
• Therefore, blue colour is necessary to clarify the behaviour. No other colour than every other link targetting such pages.

Absolutely. Fully agreed.

In T165189#4790322, @PerfektesChaos wrote:

• There are people who did not learn over years that the arrow is blue and might be clicked. That feature has been introduced some five or eight years ago, and oldtimers as of 2005 never noticed that there is a link. On the other hand, newbies shall identify that feature immediately.

For a feature of such minor benefit, IMO this argument should be given low weight compared to the "sea of blue" counterargument.

• Therefore, blue colour is necessary to clarify the behaviour. No other colour than every other link targetting such pages.

I disagree with this. The section title autocomment is less important than the actual comment and should be deemphasized, while making it link-blue adds emphasis to the detriment of the actual comment.

In T165189#4790357, @Jdforrester-WMF wrote:

No, it would not. Violation of accessibility requirements, touch-device-inappropriate styling, and violates the entire point of the change (which is to make it more visible).

In my comment (not saying about Mike) I was saying about any active states, of course (so, focus/active/etc.). I disagree in your assessment of rationale of this change, as it wasn’t proposed or made for better visibility of the feature, but for enlarging the clickable area for users.

In T165189#4790562, @stjn wrote:

I was saying about any active states, of course (so, focus/active/etc.).

Yes, it's a rather obvious implication. Any active states.

And the original request was about improving the clickability, not visibility.

In T165189#4790365, @Anomie wrote:

The section title autocomment is less important than the actual comment and should be deemphasized, while making it link-blue adds emphasis to the detriment of the actual comment.

Exactly.

In T165189#4790322, @PerfektesChaos wrote:

• Therefore, blue colour is necessary to clarify the behaviour. No other colour than every other link targetting such pages.

Absolutely not.

In T165189#4789628, @MusikAnimal wrote:

In T165189#4788873, @Nihlus wrote:

So this is one of those changes that no one asked for?

https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Miscellaneous/%22%E2%86%92%22_links_to_sections_should_be_easier_to_click though I don't know if this wish is what spurred the implementation. But anyway, people have asked for it.

So why we are implementing something for a currently active Community Wishlist Survey that's not even in the top? This process was started before that entry, so I would like to know what started this in the first place.

In T165189#4790365, @Anomie wrote:

In T165189#4790322, @PerfektesChaos wrote:

• There are people who did not learn over years that the arrow is blue and might be clicked. That feature has been introduced some five or eight years ago, and oldtimers as of 2005 never noticed that there is a link. On the other hand, newbies shall identify that feature immediately.

For a feature of such minor benefit, IMO this argument should be given low weight compared to the "sea of blue" counterargument.

• Therefore, blue colour is necessary to clarify the behaviour. No other colour than every other link targetting such pages.

I disagree with this. The section title autocomment is less important than the actual comment and should be deemphasized, while making it link-blue adds emphasis to the detriment of the actual comment.

This.

The devs need to listen to the community when it's clearly rejecting their changes.

It's worth to read previous comments (such as T165189#4789628) before pretending that somebody could speak for "the community".
Please take meta-level discussions (such as 'developers and communities') somewhere else. It's off-topic here. Thanks.

In T165189#4790872, @Nihlus wrote:

So why we are implementing something for a currently active Community Wishlist Survey that's not even in the top? This process was started before that entry, so I would like to know what started this in the first place.

The first was probably a discussion on the Czech Wikipedia before May 2017. Unfortunately I don't remember where (and forgot to mention the link here), as far as I remember this task came up from multiple users there agreed on the same thing (the arrow is hard to click).

Sorry, I had a busier day IRL than expected. Will post some patches shortly.

In T165189#4788833, @Nihlus wrote:

This should be reverted to what it was while you are figuring out how to deploy it properly, if you even end up deploying it. Where is the discussion that said that this is something that needed to be done or wanted to be done?

There were two relevant discussions that turned into this happening. I first became aware of this at WikiConference NA 2018, when Enterprisey gave a talk, showed us a script that implemented this feature, and we discussed integrating some of his UI enhancements into MediaWiki itself (T207569). After I filed that task, I became aware of this one, and the aforementioned community wishlist proposal by Dvorapa. Overall, this is a big win for accessibility.

I have yet to hear from anyone who thinks that these section headers should *not* be linked. Is that what you're proposing? ("sea of blue" concern aside, which is fixable by other means, if we want to).

In T165189#4790872, @Nihlus wrote:

<snip>
Absolutely not.
<snip>
The devs need to listen to the community when it's clearly rejecting their changes.

There are a lot of experienced developers and community members participating in this discussion. Rhetoric aside, I think your comments would be significantly more helpful if you backed them up with evidence.

Change 477024 had a related patch set uploaded (by Legoktm; owner: Legoktm):
[mediawiki/core@master] Restore old HTML structure for history section links

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

Change 477025 had a related patch set uploaded (by Legoktm; owner: Legoktm):
[mediawiki/core@master] Don't link wikilinks in section heading autocomments

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

Change 477030 had a related patch set uploaded (by Legoktm; owner: Legoktm):
[mediawiki/core@master] Restore gray coloring for autocomments

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

An option would be to just change the style. But for this, please make this section link have it's own CSS class, to allow both MediaWiki and users to style it differently than other links.

For example, the font size could be smaller, and with different color and or background. It would give a hint that it's something clickable and also visually distinguish from everything else:

In T165189#4790971, @Aklapper wrote:

It's worth to read previous comments (such as T165189#4789628) before pretending that somebody could speak for "the community".
Please take meta-level discussions (such as 'developers and communities') somewhere else. It's off-topic here. Thanks.

I'm sorry, but the community (including myself) has every right to provide their input here or wherever when it is clearly affecting them. Pulling the wool over our eyes or telling us to go elsewhere is inappropriate.

In T165189#4791010, @Legoktm wrote:

There are a lot of experienced developers and community members participating in this discussion. Rhetoric aside, I think your comments would be significantly more helpful if you backed them up with evidence.

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Something_new_in_our_edit_contributions.

Where exactly was this proposed in the https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2017? Can't find it. Alternatively, any other community-based consensus/decision for this change,

I personally strongly disapprove of this change, as this makes Recent Changes and Watchlist just more unusable.

In T165189#4791179, @Pruem wrote:

Where exactly was this proposed in the https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2017? Can't find it.

https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2017/Archive/%E2%86%92_link_to_page_section_is_hard_to_click now.

Thank you. I am still convinced that this issue could have been solved differently than by rendering the whole section title as blue link, which breaks functionality.

In T165189#4791103, @Nihlus wrote:

In T165189#4790971, @Aklapper wrote:

It's worth to read previous comments (such as T165189#4789628) before pretending that somebody could speak for "the community".
Please take meta-level discussions (such as 'developers and communities') somewhere else. It's off-topic here. Thanks.

I'm sorry, but the community (including myself) has every right to provide their input here or wherever when it is clearly affecting them. Pulling the wool over our eyes or telling us to go elsewhere is inappropriate.

Input yes, insults no.

In T165189#4791010, @Legoktm wrote:

There are a lot of experienced developers and community members participating in this discussion. Rhetoric aside, I think your comments would be significantly more helpful if you backed them up with evidence.

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Something_new_in_our_edit_contributions.

How are devs not listening there ? Just because a few people talk and other people are not giving you what you want within 10 minutes doesn't mean they aren't listening. Please dial down the rhetoric, while some BRD'ing takes place. This isn't critical, the encyclopedia will still be there tomorrow and the week after, while refinements are made. Our software cycle takes place in week increments, this is NOT a wikipage we are changing here.

In T165189#4791199, @TheDJ wrote:

I'm sorry, but the community (including myself) has every right to provide their input here or wherever when it is clearly affecting them. Pulling the wool over our eyes or telling us to go elsewhere is inappropriate.

Input yes, insults no.

Please point out where I insulted anyone.

In T165189#4791199, @TheDJ wrote:

How are devs not listening there ? Just because a few people talk and other people are not giving you what you want within 10 minutes doesn't mean they aren't listening. Please dial down the rhetoric, while some BRD'ing takes place. This isn't critical, the encyclopedia will still be there tomorrow and the week after, while refinements are made. Our software cycle takes place in week increments, this is NOT a wikipage we are changing here.

The devs are being defensive and dismissive in their replies here, @Aklapper especially. Those are prime examples of not listening.

In T165189#4791103, @Nihlus wrote:

In T165189#4790971, @Aklapper wrote:

Please take meta-level discussions (such as 'developers and communities') somewhere else. It's off-topic here. Thanks.

I'm sorry, but the community (including myself) has every right to provide their input here or wherever when it is clearly affecting them. Pulling the wool over our eyes or telling us to go elsewhere is inappropriate.

@Nihlus: Again, please see and follow https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette (which explains where to have meta-level discussions and how to criticize) if you'd like to be active in Wikimedia Phabricator. Thank you!

In T165189#4791103, @Nihlus wrote:

In T165189#4791010, @Legoktm wrote:

There are a lot of experienced developers and community members participating in this discussion. Rhetoric aside, I think your comments would be significantly more helpful if you backed them up with evidence.

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Something_new_in_our_edit_contributions.

I read through the entire discussion (before you linked it even), and I can't see any consensus that linking the full section is problematic, and should be reverted. People have indicated that the "sea of blue" is problematic, and there's a patch in Gerrit to address that, while keeping the full section linked. Multiple people noted that they didn't realize the arrow was a link, and welcomed the change. And there's some meta feedback that this shouldn't have been implemented before the community discussed it, which is misguided since this is coming from a direct request from community members.

In T165189#4791234, @Nihlus wrote:

Please point out where I insulted anyone.

Probably T165189#4790872, T165189#4791103, and the latter part of T165189#4791103. But that's a bit off-topic.

In T165189#4791199, @TheDJ wrote:

How are devs not listening there ? Just because a few people talk and other people are not giving you what you want within 10 minutes doesn't mean they aren't listening. Please dial down the rhetoric, while some BRD'ing takes place. This isn't critical, the encyclopedia will still be there tomorrow and the week after, while refinements are made. Our software cycle takes place in week increments, this is NOT a wikipage we are changing here.

The devs are being defensive and dismissive in their replies here, @Aklapper especially. Those are prime examples of not listening.

Honest question, who do you think "the devs" are? In T165189#4790872 you quoted one of the most experienced MediaWiki developers and agreed with their position (and I agree with them too), and then claimed in the very next line that "the devs" weren't listening to the community. I'm at a loss of what comments you think are "defensive and dismissive" given that I think what you're asking for is being implemented (abating the sea of blue).

I would note that a decent amount of people have commented for lots of different positions in a perfectly fine manner, but repeatedly, multiple people (myself, TheDJ, and Aklapper) have told you that your comments and rhetoric are problematic - I suggest you take a step back and reflect on why that is. At least I don't plan on engaging with you any further.

Please at least add a class to these links. Currently I would like to use a custom css style on them and I don't see how I can.

In T165189#4795475, @Framawiki wrote:

Please at least add a class to these links. Currently I would like to use a custom css style on them and I don't see how I can.

You should be able to use the autocomment class once my first patch is deployed. Given the summary /* External links */ removed bogus entries, the HTML will look like:
<span dir="auto"><span class="autocomment"><a href="#External_links">→‎External links</a>: </span> removed bogus entries</span>.

Change 477024 merged by jenkins-bot:
[mediawiki/core@master] Restore old HTML structure for history section links

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

Change 477025 merged by jenkins-bot:
[mediawiki/core@master] Don't link wikilinks in section heading autocomments

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

Change 477030 merged by jenkins-bot:
[mediawiki/core@master] Restore gray coloring for autocomments

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

In T165189#4795625, @Legoktm wrote:

In T165189#4795475, @Framawiki wrote:

Please at least add a class to these links. Currently I would like to use a custom css style on them and I don't see how I can.

You should be able to use the autocomment class once my first patch is deployed. Given the summary /* External links */ removed bogus entries, the HTML will look like:
<span dir="auto"><span class="autocomment"><a href="#External_links">→‎External links</a>: </span> removed bogus entries</span>.

Note that autocomment is used for different things now. When you create a new section on a talk page, you get something like "→ sectionname: new section", and only the new section text gets the autocomment summary. Do you mean now both texts will have the autocomment class? That's not what is requested here. See also T165189#4791055

In T165189#4795692, @Ciencia_Al_Poder wrote:

Note that autocomment is used for different things now. When you create a new section on a talk page, you get something like "→ sectionname: new section", and only the new section text gets the autocomment summary. Do you mean now both texts will have the autocomment class? That's not what is requested here. See also T165189#4791055

You seem to be confused. When you create a new section on a talk page, the edit summary is the same as if you had entered "/* sectionname */ new section" (see this API output, for example, or this one from last year). For the "new section" part to have been enclosed in the autocomment class, that would have had to be "sectionname /* new section */" instead.

Since it seems to be somewhat unclear to people:

/* External links */ removed bogus entries

<a href="#External_links">→</a>‎<span dir="auto"><span class="autocomment">External links: </span> removed bogus entries</span>

<a href="#External_links">→External links</a>‎<span dir="auto"><span class="autocomment">: </span> removed bogus entries</span>

<span dir="auto"><span class="autocomment"><a href="#External_links">→‎External links</a>: </span> removed bogus entries</span>

With the newest version, you'll be able to change the color of the autocomment link with a CSS rule like

.autocomment,
.autocomment a,
.autocomment a:visited {
	color: #72777d;
}

BTW, the just-merged changes will likely be backported to the wikis by tomorrow morning (US time) at the latest.

Change 477426 had a related patch set uploaded (by Legoktm; owner: Legoktm):
[mediawiki/core@wmf/1.33.0-wmf.6] Restore old HTML structure for history section links

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

Change 477427 had a related patch set uploaded (by Legoktm; owner: Legoktm):
[mediawiki/core@wmf/1.33.0-wmf.6] Don't link wikilinks in section heading autocomments

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

Change 477428 had a related patch set uploaded (by Legoktm; owner: Legoktm):
[mediawiki/core@wmf/1.33.0-wmf.6] Restore gray coloring for autocomments

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

Change 477426 merged by jenkins-bot:
[mediawiki/core@wmf/1.33.0-wmf.6] Restore old HTML structure for history section links

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

Change 477427 merged by jenkins-bot:
[mediawiki/core@wmf/1.33.0-wmf.6] Don't link wikilinks in section heading autocomments

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

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

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

If we're making everything gray again, how will someone discover that the whole item is a link? (This is a WCAG concern.)

(Also, I reopened the task about that specific color.)

Mentioned in SAL (#wikimedia-operations) [2018-12-03T23:51:36Z] <legoktm@deploy1001> Synchronized php-1.33.0-wmf.6/includes/Linker.php: Restore old HTML structure for history section links (T165189 part 1) (duration: 00m 47s)

Mentioned in SAL (#wikimedia-operations) [2018-12-03T23:53:23Z] <legoktm@deploy1001> Synchronized php-1.33.0-wmf.6/resources/src/mediawiki.legacy/: Restore gray coloring for autocomments (T165189 part 2) (duration: 00m 47s)

OK, so all three changes are deployed now. The sea of blue should be gone now, but the full section name will be linked, with similar HTML.

There are two follow-up tasks where we should move discussion to:

• T210822: Reconsider section heading marker ("→") in edit summaries
• T125657: Gray used in .autocomment in RC and watchlist is not accessible against background and hinders link discovery

Is there anything else that needs addressing?

I'll leave this task open for another day or two in case there are any remaining problems before closing it as resolved. And thank you everyone who provided feedback and commented as we figured out how to improve the original feature.