Hey, yesterday the patch implementing human-readable section IDs [0] was merged (thanks, Tim!). The new feature has already been enabled on beta cluster and you can try it yourselves, e.g. on [1] - some pages might still have old HTML cached though and require a null edit to update.
What's next? We can probably flip it on testwiki after Wikimania, but further deployments depend on Reading Web, Apps and Parsoid teams. We, however, can already encourage editors to check it out in staging.
Unanswered question: do we really need to percent-encode the IDs? There is extensive discussion of that in the aforementioned task, concluding that percent-encoding is probably more "correct". However, not escaping it gives much better browser compatibility (close to 100%). We can change this at any time because no links will be broken due to the way browsers handle percent-encoded fragments.
What's the impact for end users? When the commit above goes live, there will be no user-visible changes, and almost no HTML changes at all (only some interface IDs/classes generated from MediaWiki messages might slightly change, but no links will be broken). When we migrate we will initially enable new IDs as a fallback. After 1 month, the new IDs will become default while old ones will be used as a fallback. This way, old links will continue to work, and we have no plans to disable the fallbacks in the foreseeable future.
What's the impact for developers? Sanitizer::escapeId() has been deprecated, all code should migrate to escapeIdForAttribute(), escapeIdForLink() or escapeIdForExternalInterwiki(). Warning: unlike escapeId(), these functions' output is not guaranteed to be HTML-safe so it must be escaped. Our security guidelines say that everything should be HTML-safe anyway, so even escapeId() should be properly escaped. The same deprecation happened in JavaScript, mw.util.escapeId() is also deprecated.
---- [0] https://phabricator.wikimedia.org/T152540 [1] https://ru.wikipedia.beta.wmflabs.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0...