[wp-trac] [WordPress Trac] #12009: Add support for HTML 5 "async" and "defer" attributes

WordPress Trac noreply at wordpress.org
Tue Jun 20 10:00:51 UTC 2023


#12009: Add support for HTML 5 "async" and "defer" attributes
---------------------------------------------+--------------------------
 Reporter:  Otto42                           |       Owner:  10upsimon
     Type:  enhancement                      |      Status:  assigned
 Priority:  high                             |   Milestone:  6.3
Component:  Script Loader                    |     Version:  4.6
 Severity:  normal                           |  Resolution:
 Keywords:  has-patch has-unit-tests commit  |     Focuses:  performance
---------------------------------------------+--------------------------

Comment (by azaozz):

 > We actually considered relying on the `DOMContentLoaded` event to run
 the after inline scripts, but the problem with this is that existing
 inline after scripts may be attempting to define something in the global
 scope without explicitly setting it on the window. For example:
 >
 > `wp_add_inline_script( 'foo', 'var fooHasLoaded = true;' );`
 >
 > Such an after inline script would break if it were automatically wrapped
 in an event handler callback.

 @westonruter And how hard would it be to fix/improve that script when
 transition it to use `async` or `defer`? :)
 Also, ideally the developers will wrap their inline code in an event
 callback or lambda function or something similar, not just "dump it" in
 global scope. So the transition to using `async` or `defer` could actually
 be used to improve their JS too.

 > in many cases it is correctly used by developer to pass data from PHP to
 javascript

 @spacedmonkey The "after" snippets were never intended for passing data
 from PHP to JS. The "before" inline scripts are for that. All cases where
 data is passed from PHP to JS in an "after" script should be considered
 "doing-it-wrong".

 There are several reasons for this architectural decision. Perhaps if you
 wish we can discuss them at length somewhere else.

 > At this point, I'm starting to wonder why you are against supporting a
 feature of the API that has existed for years and is still widely used?

 @joemcgill I'm not against supporting this feature. I'm against supporting
 it in an outdated way that promotes mediocre JS code/architecture.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/12009#comment:134>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list