Make WordPress Core

Changes between Version 1 and Version 2 of Ticket #12009, comment 100


Ignore:
Timestamp:
05/09/2023 11:36:03 PM (18 months ago)
Author:
westonruter
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #12009, comment 100

    v1 v2  
    3737The 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.)
    3838
    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.
     39Nevertheless, 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.)
    4040
    4141In 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.)