Changes between Version 1 and Version 2 of Ticket #12009, comment 100
- Timestamp:
- 05/09/2023 11:36:03 PM (18 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #12009, comment 100
v1 v2 37 37 The nice thing about the first option is that the deferred execution is automatic. The bad thing is that it forces ''all'' `after` inline script logic to run once the `defer` script is loaded. Perhaps you want some logic to run after but other logic to run before? (Then again, they could just use a `before` inline script for that.) 38 38 39 Nevertheless, note that there is a somewhat brittle connection here between the `after` inline script and the `defer` script: whether there is a `script` element in the page with the expected `id`. If there is an optimization plugin that tries concatenating `defer` scripts together, then any such `load` event handler will fail because the original `script` will be gone. 39 Nevertheless, note that there is a somewhat brittle connection here between the `after` inline script and the `defer` script: whether there is a `script` element in the page with the expected `id`. If there is an optimization plugin that tries concatenating `defer` scripts together, then any such `load` event handler will fail because the original `script` will be gone. (As such, the use of an `onload` attribute is also brittle.) 40 40 41 41 In this case, it seems perhaps the safest thing to do is to not wait for the `load` event on the `script[defer]` at all, but rather to just attach a `DOMContentLoaded` event handler to the `document` which runs after all `defer` scripts have been evaluated. (The only gotcha here is the `defer` script may have failed to load.)