<HTML><HEAD><META content="text/html; charset=UTF-8" http-equiv="Content-Type"></HEAD><BODY><blockquote type="cite"><BR>
And one more enqueue isn't <BR>
going to be a perceptable difference in processing time in 99% of <BR>
scenarios.<BR>
</blockquote><BR>
<BR>
Disagreed. Even if the server serves the script in 1ms, with no extra load, it would still be one more HTTP request, which could be from 100ms-500ms.<BR>
<BR>
That's not a trivial difference.<BR>
<BR>
Shinra Web Holdings wrote:<BR>
<blockquote type="cite"><BR>
I'm torn on this. On the one hand creating and hooking a function to <BR>
invoke another function to include a file that is 1 line long just <BR>
feels wrong. It's like the US spending a million dollars to make a pen <BR>
that writes in space when the Russians just used pencils.<BR>
<BR>
On the other hand, the enqueue system is great and exists for a reason <BR>
(plus it keeps code neater for ocd people). And one more enqueue isn't <BR>
going to be a perceptable difference in processing time in 99% of <BR>
scenarios.<BR>
<BR>
On the third hand, why allow users to print "raw" css for custom <BR>
headers and backgrounds when this could also be wholly accomplished by <BR>
enqueuing a bootstrapped php file with CSS headers as a style sheet? <BR>
What's good for the goose, etc.<BR>
<BR>
While performance differences are trivial, they are real, and unless <BR>
there's a compelling reason for not allowing people to include one <BR>
line scripts directly or by hooking and anonymous function that echos <BR>
the script (is that any better?), I think it should be up to the theme <BR>
author.<BR>
<BR>
On Oct 16, 2012 12:49 PM, "Otto" <otto@ottodestruct.com <BR>
<mailto:otto@ottodestruct.com>> wrote:<BR>
<BR>
On Tue, Oct 16, 2012 at 12:08 PM, Chip Bennett<BR>
<chip@chipbennett.net <mailto:chip@chipbennett.net>> wrote:<BR>
> Is there any particular reason that such a script can't be<BR>
enqueued like<BR>
> most other scripts, that would warrant such an exception?<BR>
<BR>
No, but I would still advocate allowing it for small scripts. Define<BR>
"small scripts" arbitrarily. Say, less than 8 lines.<BR>
<BR>
The biggest reason to allow it is simply one of speed. Enqueuing<BR>
forces you to have the script in a separate file, and adds the<BR>
overhead of an extra HTTP request for the most common cases. For a<BR>
single line of JS, this is a lot of unnecessary extra overhead.<BR>
Especially when the script has no dependencies and is simply a shiv to<BR>
do one particular thing. In this case, he's wanting to change no-js<BR>
classes to js classes, via js, which makes sense for allowing pure CSS<BR>
to handle the no-js case gracefully.<BR>
<BR>
The thinking is along the same lines as the "data URI" scheme, where<BR>
you can include binary data like images inline to CSS or HTML as<BR>
base64 text. For small files, the setup and teardown and data transfer<BR>
overhead of an HTTP connection is quite a bit slower than simply<BR>
always serving the file. You lose caching benefits in some cases, but<BR>
at a certain point of smallness, it's worth that minor overhead to<BR>
eliminate a larger overhead.<BR>
<BR>
-Otto<BR>
_______________________________________________<BR>
theme-reviewers mailing list<BR>
theme-reviewers@lists.wordpress.org<BR>
<mailto:theme-reviewers@lists.wordpress.org><BR>
http://lists.wordpress.org/mailman/listinfo/theme-reviewers<BR>
<BR>
_______________________________________________<BR>
theme-reviewers mailing list<BR>
theme-reviewers@lists.wordpress.org<BR>
http://lists.wordpress.org/mailman/listinfo/theme-reviewers</BODY></HTML>