Stepping back a bit, I think we're struggling to ignore the elephant in the
room. This elephant is the fact that there's no specification (or API) that
defines (or provides facilities to control) when rendering happens. And for
that matter, what rendering means.
The original reason why <script> blocks execution until imports are loaded
was not even related to rendering. It was a simple solution to an ordering
problem -- if I am inside a <script> block, I am assured that any script
before it had also run (whether it came from imports or not). It's the same
reason why ES modules need a new HTML element (or script type at the very
list).
Blocking rendering was as a side effect, since we simply took the plumbing
from stylesheets.
Then, events took a bewildering turn. Suddenly, this side effect turned
into a feature/bug and now we're knee-deep in the sync-vs-async argument.
And that's why all solutions look bad.
With "elements" attribute, we're letting the user of the import pick the
poison they prefer (would you like your page to be slow or would you rather
it flash spastically?)
With "sync" or "async" attribute, we're faced with an enormous
responsibility of predicting the "right" default for a new feature. Might
as well flip a coin there.
I say we call out the elephant. We need an API to control when things
appear on screen. Especially, when things _first_ appear on screen.
:DG<