[wp-trac] [WordPress Trac] #30579: wp_enqueue_style in footer
WordPress Trac
noreply at wordpress.org
Fri Dec 19 17:00:12 UTC 2014
#30579: wp_enqueue_style in footer
-------------------------------------------------+-------------------------
Reporter: spacedmonkey | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting
Component: Script Loader | Review
Severity: normal | Version: 2.6
Keywords: good-first-bug has-patch needs- | Resolution:
testing | Focuses: template,
| performance
-------------------------------------------------+-------------------------
Comment (by spacedmonkey):
Replying to [comment:7 evasivesoftware]:
> Good point, I just think it sounds slightly messy. Utilizing DOM to
create the link and inject into <head> is valid with either HTML4/5 and
seems more robust (still hacky, none-the-less)
>
> As you mentioned, rejecting things queued after wp_head() would be
ideal. I don't see any situation where a stylesheet cannot be registered
before wp_head() in cases that they are required before in-footer. How
much cleanliness should be sacrificed to support lower level developers?
I completely disagree with your point here. There are lots of reason to
add css into the footer of a page. If for example, you are using a
shortcode and you only want to output the css files if the shortcode is
loaded. Removing styles that are loaded after wp_head, removes
functionality and breaks compatibility with plugins and themes that may
already be doing this. It is impractical to remove it now, it could break
so much stuff.
wp enqueue style and wp register style functions should be have a in
footer option, to bring them inline with wp enqueue script. If you call wp
enqueue script after wp_head it just puts it in the footer, even if in
footer isn't set to true.
kevdotbadger patch seems workable to me.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/30579#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list