Feature Proposal: New macros to simplify & formalize adding of JS/CSS to a page

MichaelDaum: ArthurClemens, been looking at jammit. frankly I'd prefer what drupal did and add %ADDJS and %ADDCSS with optional merge + compress

MTempest

ArthurClemens: Thank you

MichaelDaum

having img's inside html is interesting but scarifies bandwidth for latency as you reload the same img in different pages again and again...not sure which amount of inlined imgs makes sense.
(or img's inlined in css)
maybe we can have ADDCSS and ADDJS as part of this BrowserBoosterPlugin: there's all the logic to gather css and js in there already.

MichaelDaum: an %ADDCSS{merge="on" will have to take care to unify linefeed encoding as well as charset
same for %ADDJS

CDot: damn, the %ADDTOHEAD technique works for most of the JS, but not the bits generated using foswiki macros

MichaelDaum

well then it is up to the %MACRO to make a Foswiki::Func::addToHEAD on demand

CDot

yeah. Or I can put the dyna-data into hidden divs
which is cleaner anyway

*

MTempest has joined #foswiki

JanD72

Hm, so trying to disable mod_perl ... :-/

CDot

oh, cute. Put the pages that generate the JS into a topic. Then get the topic with ?content-type=text/javascript
<script type="text/javascript" src="https://foswiki.org/System/JsStuff?contenttype=text/javascript;skin=text"> works

-

CDot is feeling evil after that

pharvey_

CDot: Tricky
For some reason I've never liked the idea of dynamically generated JS code.
Not for the purpose of setting up per-session state stuff anyway.

MichaelDaum

CDot, anything requiring perl slows it down. best is to let apache see some static file and redirect the 404 error page to an AttachContentPlugin page.

CDot

MichaelDaum: right now I don't care about the speed; I just want it working

CDot

actually, I could even add the JS to a hidden div and eval() it

MichaelDaum

try jquery.metadata for that
can read json objects from html attributes like the class attribute but also dom nodes

pharvey_: MichaelDaum: What issues are there to take existing usage of ADDTOHEAD and extend its implementation so that ADDTOHEAD could transparently combine all JS and CSS files? I think: access control (via viewfile). CSS and JS would become one continuous chunk, whereas before it was possible for a JS ADDTOHEAD to requires=some CSS
and.... parsing out the text= to be added so it can automagically understand that you meant to simply load a JS or CSS file, that's messy I suppose

MichaelDaum

pharvey_, basically you don't specify the css source directly using ADDTOHEAD, you add some link or script tag.
this in itself is error prone
best would be to just specify the files to be combined and then generate the necessary markup after concatenating them

pharvey_

Yes, I mean <script src="foo.js"></script> tags, we would have to parse that out.

MichaelDaum

... which is not the best approach imho

pharvey_

no

pharvey_

So new ADDTOHEAD params, or a new tag...
ADDTOHEAD{file="foo.js" requires="bar.js"}

MichaelDaum

js files should not be added to the head. they should go to the end of the document to improve loading time.
means: we could create an ADDTOBOTTOM
however
I'd prefer to "register" a css or js file to some internal service that then takes care of all of the rest.

Babar

or make ADDTOHEAD clever. js => bottom, CSS => top
but ok, sometimes you want your JS to go on top
anyway, that's not the point here

pharvey_

register, so not in TML?

MichaelDaum

how about two new macros %ADDCSS and %ADDJS
paralleled with an appropriate Func api

Babar

yeah, as for IE, %ADDCSS should use @import to avoid the 20 files limitation
EugenMayer: what does Drupal do?

EugenMayer

For what? reading log

MichaelDaum

Babar, the idea was to concatenate ann added css into one. same for all registered js code

Babar

EugenMayer: for adding CSS and JS files from pages
MichaelDaum: with transparent minifier calls?
oh... I remember this discussion...

MichaelDaum

and gzip

EugenMayer

Babar: they use drupal_add_js / drupal_add_css

MichaelDaum

EugenMayer, bingo

pharvey_

nifty

EugenMayer

similar to the current Foswiki implementation, but a bit more poweful. (mergeing, caching, unqiue loads only)

MichaelDaum

there u r

Babar

MichaelDaum: iirc, the problem we had was, among others: how to deal with addjs a, addjs b, addjs c, vs a c b. Will it make the same file?

EugenMayer

important feature is, that you can use it this way
drupal_add_css('module','eugen','eugen.css')

MichaelDaum

Babar, obviously order matters

Babar

and also, concatenating into one single file is silly imho because you might loose caching. in fact, you most certainly will

EugenMayer

that would be also something interesting for us

Babar

MichaelDaum: then you will kill caching
therefore I'm strongly against concatenation

EugenMayer

Babar: well it depends what you merge

pharvey_

Babar: The idea was that each permutation of load orderings would be concatenated into a unique HEX.js file

Babar

yeah, so you will end up loading 20 times the same js file when you already have it

pharvey_

a has of the files required would generate the HEX id to load... if not exist... then generate

EugenMayer

Babar they e.g. merge theme css, but don't merge plugin css

pharvey_

maybe you're right

Babar

if you set your expire headers properly, you'll load your JS and CSS files once every other week or so

EugenMayer

but this is all in the settings, you can switch merge on and off
The have a internal cache-api anyway

pharvey_

Perhaps closer study of drupal is required

EugenMayer

We should often do, yes. They seem to have good ideas

Babar

and to have manpower to code them :)

pharvey: Babar: started hacking a StaticFilesPlugin, which used templates for URI version decoration
TMPL:DEF{"StaticFilesPlugin::Type::JS"}%<script type="text/javascript" src="%FILEPATH%%FILEVER%"></script>%TMPL:END% - or something like that
used when you do an ADDJS, or as I started to do it, ADDFILE{"/pub/Something.js"} (magic file extension detection)
this way if you want HTML5 output you can redefine the DEF to the minimal HTML5 boilerpalte