Yes, there's nothing to be done about that without introducing templates that output the set of styles for a table and then changing all the template uses to manually added classes. There is no fix to the parser or any other system that corrects the issue.

Won't parser unification fix this? I imagine Parsoid would hoist the stylesheet to some valid position in the HTML tree.

It does not. Parsoid stuffs the escaped content into a data-mw attribute value.

Theoretically this could be resolved by putting the tag after the first bar character in the template, but then your style tag impacts sortability (I think). So then you're looking at putting it after the word in the template, and then you've definitely lost the objective of ensuring the styles come before the thing they're supposed to render.

I think Tgr is talking about what is possible with Parsoid, not what it currently does. It does seem possible for the DeduplicateStylesDOM implementation to hoist style tags out from tables.

I guess the problem here is that the style tag isn't really inside the table (in which case it would have to be hoisted, or "refostered" per the HTML5 spec which I'm sure Parsoid follows) but inside a HTML attribute, at which point it isn't even a tag anymore.

In T411550#11426253, @Izno wrote:

Theoretically this could be resolved by putting the tag after the first bar character in the template, but then your style tag impacts sortability (I think).

Assuming a reasonable implementation (based on innerHTML), it shouldn't.