I've tried a quick test to see if you can exploit the #HTML5 inclusion of #SVG to have a <switch>. It doesn't really work as expected, so you have to do a double wrapping:

svg > switch > [foreignObject > your HTML here]+

which obviously doesn't work as expected …

You can _almost_ implement the #SVG `switch` element in pure #HTML + #CSS with something like:

switch > * {
display: none;
}
switch > *:lang(...) {
display: initial
}

with only one issue: there's no way to put in that :lang() pseudo-class “whatever the user asked for”. So you still need some #JavaScript or server-side assistance to bridge the gap between the user language selection and the styling.

So close …

Oh boy this is a problem. Different UAs apply the #SVG #switch element in different ways when user asks for multiple language support.

So: the switch element is typically employed together with the systemLanguage attribute as a way to display different content depending on the language choice of the user. Per the spec, the element should select “the first child that matches the user's language preference”.

Now, there are two ways to do this when the user accepts multiple languages.

One is: for every language accepted by the user, find the first matching element.

The other is: find the first element that matches any of the user languages

Firefox seems to use the first strategy, WebKit and Blink browsers the second.

Which one is correct?

If I look at the SVG spec https://www.w3.org/TR/SVG/struct.html#ConditionalProcessingSystemLanguageAttribute, the systemLanguage attribute says:

> Evaluates to "true" if one of the language tags indicated by user preferences is a case-insensitive match of one of the language tags given in the value of this parameter, or if one of the language tags indicated by user preferences is a case-insensitive prefix of one of the language tags given in the value of this parameter such that the first tag character following the prefix is "-".

OTOH, the spec also says:
https://www.w3.org/TR/SVG/struct.html#SwitchElement

> In SVG, when evaluating the ‘systemLanguage’ attribute, the order of evaluation of descendant elements of the ‘switch’ element must be as if the 'allowReorder' attribute, defined in the SMIL specification [SMIL] always has a value of 'yes'.

This means that a UA can reorder them so that the match with the highest q has priority, and this is correct too …

Now, why is this important for me? Because I have to choose which strategy to implement in my JS of the polyfill for the #SwitchElement in #HTML: so far I've implemented the “fast” way (no reorder), but should I support the other one too?

To clarify, the difference is that with reordering, the reader has priority in choosing the version, without reorder it's the writer that chooses.

Anyway, I implemented the polyfill with reorder too.

One of the interesting advantages of the polyfill is that at least conceptually it can be overridden, for example providing interactive elements to allow users to force a specific language without changing the browser preferences. I'm not sure this is possible in SVG.