The goal is to escape things like javascript:foo are() allowing to inject JS execution in href

Good point!
In #2817 (comment) I've learned that it is ok to use html escaping in quoted attribute values:

example 1 is quite fine here, because your attribute value is quoted, and the html escaping strategy already escapes quotes.

The wrong cases are these one:

• using a dynamic attribute name
• using an unquoted attribute value

So for some attributes (like href), html_attr escaping should be used for the value, even if it is quoted.

The href attribute is indeed a bit special due to links allowing to execute JS

Even with html_attr the attribute name should never come from user input, because of onclick attributes etc.

The goal is to escape things like javascript:foo are() allowing to inject JS execution in href

{% set attr = "javascript:alert(1)" %}
<a href="{{ attr|e('html_attr') }}">Click</a>

will result in:

<a href="javascript&#x3A;alert&#x28;1&#x29;">Click</a>

(https://twigfiddle.com/n1rbba)

This is still executable javascript: https://jsfiddle.net/9ekxLy6u/

So I'm still not sure whether the : should be escaped in html_attr context.

Could also be relevant for #3760.
Which escaping strategies should the new html_attributes function/filter use for keys and values? Should it support attribute names like v-on:submit.prevent?

I am not using Vue.js myself, so I cannot tell for sure, but according to https://v2.vuejs.org/v2/guide/syntax.html#v-bind-Shorthand this might not only affect :, but also @ and square brackets [].

The HTML 5 spec does not exclude all those characters from attribute names (https://html.spec.whatwg.org/multipage/syntax.html#attributes-2).

XML processors will treat the colon as the XML namespace separator.

HTML 5 allows XML only on SVG and MathML elements, and only for pre-defined namespace-prefixes (https://developer.mozilla.org/en-US/docs/Web/API/Attr/localName#:~:text=That%20means%20that%20the%20local,different%20from%20the%20qualified%20name). For other something: prefixes, these will simply be passed on as part of the local attribute name.

According to https://engine.sygnal.com/research/html5-attribute-names, all current browser implementations handle at least the colon fine, and the aforementioned Vue.js documentation suggests that this is also the case for @.

So, if we'd want to support this, I think it should at least be introduced in a BC way, i. e. with a new escaping strategy name that lets users opt into the new mode with less escaped characters.