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...
Thanks for letting us know Max! Just a couple of questions from me at this point:
1. Will this be included in the tech news? 2. How will the behavior of anchorencode change? Should it be removed from templates after the new IDs become default?
Strainu
2017-08-03 3:46 GMT+03:00 Max Semenik maxsem.wiki@gmail.com:
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...
-- Best regards, Max Semenik ([[User:MaxSem]]) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Aug 3, 2017 at 12:26 AM, Strainu strainu10@gmail.com wrote:
- Will this be included in the tech news?
Yes, I've added it.
- How will the behavior of anchorencode change? Should it be removed
from templates after the new IDs become default?
Anchorencode should not be removed: it still encodes links, just in a different way.
Hello, Am 03.08.2017 um 02:46 schrieb Max Semenik:
to escapeIdForAttribute(), escapeIdForLink() or escapeIdForExternalInterwiki(). Warning: unlike escapeId(), these functions' output is not guaranteed to be HTML-safe so it must be escaped.
may I ask why the methods are named escapeSomething, when their result is not escaped?
Sincerely, DaB.
On Thu, Aug 3, 2017 at 3:48 PM, DaB. wp@dabpunkt.eu wrote:
may I ask why the methods are named escapeSomething, when their result is not escaped?
They still escape the ID (even if as lightly as converting spaces to underscores).
wikitech-l@lists.wikimedia.org