Additional Hardening: Handle edge cases

[typhonrt]

Hi @devknoll et al.

I definitely appreciate the work done on this great polyfill. I'm aware that it is maintenance mode, but there are a couple of edge cases to work out for non-trivial use cases / deployment issues that aren't currently triggered in the local test cases. I have made a fork that solves the problems, but it would be great to have the updates considered for the official release.

The problems:

• Using the old school image hack to detect when style elements are updated w/ new data blobs fails in production when there are many style elements to update or styles are of significant sizes and / or a combination of both cases. When this occurs styleSheet.refresh() will be invoked before the style sheet is updated and when accessing{ style } it will be null and any selector data for CQ replacement will not be registered causing the polyfill to fail. I have had success on the latest Firefox using the load event on the style element via addEventListener swapping out the image hack. This particular code point is the only "weak spot" to an otherwise well coded polyfill.

• "When you have a hammer everything is a nail". In complex production environments where there are only a few style files / elements that need updating for CQ support only style files that have CQ should be updated. Currently the polyfill will attempt to transpile and swap out all style elements regardless if they need to be transpiled for CQ support. This is problematic for production environments with many style files as it obfuscates the style element names and is confusing to other developers inspecting styles through the dev console.

---

Please give a look at my fork here: https://github.com/typhonjs-svelte/container-query-polyfill

You can see that not too much is changed:
main...typhonjs-svelte:container-query-polyfill:main

---

I have yet to setup comprehensive browser tests via WPT and browser stack on my fork. While I'm familiar w/ GH actions I have not worked w/ the other resources yet.

---

My production use case is delivering a forward looking Svelte based UI framework on Foundry VTT which is an online virtual tabletop / TTRPG platform w/ a 3rd party developer API. I don't control the platform, but deliver software onto it. There are many developers using my UI framework and of course many 3rd party modules. In this environment there can be many style files / elements enabled up to N 3rd party modules enabled (IE 60-100) in larger cases. The old school image hack fails when there are as low as 3-5 style links. Re: the obfuscation aspect of not transpiling / or at least swapping out style files when they don't contain CQ selectors, well, you can get an idea that this would cause a lot of havoc for other 3rd party developers on a shared platform trying to view style info in the dev console and not being able to locate their style files given the broad transpiling of all style links.

I appreciate any help in getting these hardening aspects into the main polyfill as while CQ support is imminent now in Firefox the polyfill is necessary for the next 6-12 months, etc.