Hi!
Yes, of course. Which is why one would simply write:
Then this is not an option to implement, and we'll put it in the head.
I'm merely advocating what I consider to be good practice here. Also, although I hate to play that card, there are other systems out there that can do without inline CSS and JS, so why can't we?
Which ones? Wordpress has it in the head...
garvinhicking wrote:HTML is a glue language, its form should follow function
Erm. That's exactly the approach that makes people use stuff like <div class="headline"> instead of <h1> etc. That's the way of argueing which got us constructs like <a ...></a><br /><a ...></a><br /> instead of a proper list element.
No, what you are referring to is really something abusive. There is a headline element, so people should use it. But in this JS placement case, putting it before the closing body means losing possibilities and functionality only due to some "higher standard".
Maybe this a topic which should be discussed more hands-on, using actual code in an example environment instead of theoretical discussions whether it might work or not? I mean, we can spend a lot of time discussing this on a meta level, but it might be way easier to just give it a shot. We can still drop it if it doesn't work out, but let's at least give it a try.
Okay, then an example. I'd like to create a plugin that fetches the associated tags to each entry that is displayed on any page. Then I want to use jquery to by default hide all entries on the page that do not have at least 2 tags.
To do this with inline JS would be easy; use PHP code for the entry_display loop to echo a script section that fills in a JS array, and then simply use some javascript if/else structure to utilize a hide/toggle function.
To put this as inline JS into the head is not possible, because frontend_display is executed earlier, so it has no knowledge about the entries that are displayed later on.
To put it into its own external js file is not possible, because the content is dynamic.
But much more important to me is this: With the current solution, you can do either inline or head or whatever else methods - it's up to the authors to adhere to their standards - with your propsed solution, this would make inline scripting quite error-prone.
If you want to create a template that has jquery before the closing body that's okay; you can disable the internal s9y core output (use config.inc.php and simply unset($serendipity['core_events']['frontend_display']['jquery']) and output your own. Of course, this would crash all plugins that would depend on this functionality, so templates like these would only be good to use if you have full control over your own site.
In the end, I also want this because i do NOT want to rewrite every plugin to not use inline scripting, because currently they all just work perfectly fine. Even if we're talking about s9y 2.0 this is a step I don't really think would benefit anyone. The more compatible is still better, which is why the very strict XHTML routines are now abandoned. Why now begin the same war on JS side? JS and PHP are both so popular because they leave so much open to the user, and quick&dirty solutions are possible and easy to use.
Wasn't there also a problem with the google analytics javascript, that in some cases you need to have it in the head for certain functionality?
Regards,
Garvin
YL[/quote]
