Getting script-tags out of head

Topics: Feature requests, General
May 18, 2011 at 10:51 AM

Since its a good thumb rule NOT to put scripts in head but load them at the very bottom of the page, it hurts my heart to see that Composite C1 encourages editors and authors to follow bad practices. I therefor suggest that either

  1. A new <scripts> node is added next to the existing <head> and <body> where script includes should be added. On the page template you would insert a <rendering:scripts /> somewhere near the bottom where all these includes will be inserted. As a fallback, if <rendering:scripts /> is not present they can still be appended to <head>
  2. Let people continue adding the scripts as usual, but then loop through all the nodes and move <script> tags to the <rendering:scripts /> IFF its present. Otherwise just let them be in head.
Oct 13, 2011 at 3:03 PM

Hi,

Uploaded a patch...

mzZzl,
Jambo

Feb 24, 2012 at 12:49 PM

@nuFaqtz In you patch, you're moving all<script> tags from <head> to end of <body>, that solution will work for some simple web sites, but isn't a good solution in general because there could be some <script> tags inside body that are relying on some scripts that have to be executed beforehand.

Modern browsers support defer="defer" attribute, which postpones execution of a script until the page has finished parsing.

Other solutions would be to have some kind of attribute on script which would tell where it should be rendered, so you have an option, but that's exactly what defer="defer" does.

 

 

 

Feb 24, 2012 at 1:54 PM

The attribute defer="defer" work for <script src="..." /> tags, while it does not work for inline scripts.

There is pretty wide browser support for defer="defer" now: http://caniuse.com/script-defer

I guess that this attribute fix most issues?

Feb 24, 2012 at 5:19 PM

Hi,

I can live with that.
Parsing script within the body however is something to be discouraged as it will hold up page rendering.
That was the base premise for my patch and the fact that i liked to put the jquery library at the bottom which did break all kinds of packages as those
put dependent scripts in the head. Basically the same dependability issue you mention. Moving those scripts from the head to the bottom in the same order
served me well on many sites.

I can understand that you want to keep the possibility open for users to DO use scripts in the body and not apply the patch.
I will probably keep using it however.

Maybe, expanding on burningice idea, we could have something like a <rendering:script /> node with a "src" attribute and a "moveToBottom" Boolean attribute,
which will move scripts to the bottom when true.

Thank you for evaluating my patch.
JamBo 

Feb 24, 2012 at 8:33 PM

I think that we're making it too complicated. If the starter sites are built with good practices, they will provide a good example of how to do things in a more efficient way.

Composite doesn't PREVENT devs from creating a content area at the bottom of the layout and putting all your scripts in there. Once you go down the slippery slope of making decisions for the developer to force them to use a preferred way of doing things, you risk it all breaking down the road when things change.

Isn't that why Asp.Net WebForms can be a nightmare to Style with CSS? It was too abstracted and the developer got too far away from the metal.

Feb 24, 2012 at 8:42 PM

@oneproton amen, brother!

Feb 24, 2012 at 8:42 PM

Of course the cms doesn't prevent you from doing it, but its for sure not encouraging it either. All examples and packages emphasizes the wonders of putting things in <head> in your functions, and that is of course what most developers then will do.

I agree that good examples is one of the best way to teach others - but i don't see how a package creator should be able to put his scripts in his package at the end of <body>, if the underlying cms doesn't supports a universal way for his functions to do that. 

Mar 2, 2012 at 9:05 AM
Edited Mar 2, 2012 at 9:06 AM

While defer is 'pretty' wide supported it is almost not on mobile browsers, and there it matters the most!
How about modifying the patch to move scripts to the bottom only when the defer property is set?

In that case package creators could use the defer property to move scripts to the bottom, and the patch would leave scripts in place if not. Also then browsers that do not support 'defer' are supported.
The patch already did leave scripts in their original position (and order) when set from templates.

mzZzl,
JamBo

Mar 2, 2012 at 12:53 PM

It's my impression that Opera is the only mobile browser (from recent years) which do not support defer (?)

I do not know this for a fact, but got the impression from these links:

Mar 2, 2012 at 1:25 PM

The problem on mobile is that users can have a wide variety of phones, with a wide variety browser versions that do not get updated (I speak from experience).
Developing for mobile requires also testing on iPhone 3gs par example which does not support defer. Not to speak of all the different (older) Android versions out there.

While in the far future 'defer' would hopefully be a solution, currently it is not sufficient 9by far).
I think Composite would positively stand out when it (we) address this issue.

mzZzl,
JamBo 

Mar 2, 2012 at 2:21 PM

Your argument about the existing body of browsers not supporting defer sounds very plausible, so I can see a need to address this - I'd just hate to have the CMS "do stuff to your HTML". We pride ourselves for not messing with your markup by default, so I'd definitely prefer an opt-in model. It's a huge plus that this would act on a std. html attribute and be functionally as valid (and an improvement for old browsers).

It will be pretty easy to create an asp.net request filter which "push down" all script tags with the defer attribute to the end of the body tag - you can create this as a package, and anyone installing this you should be good to go. We will happily put it on the package server for everyone to enjoy.