tags:

views:

181

answers:

7

Generating inline JavaScript in HTML has always made me feel dirty and after having used YUI a bit I get the sense that it's best to leverage HTML elements as an alternative. Would it be insane to use a hidden <ul> to store keys and values to be used by static JavaScript which would only act when it found the <ul> rather than using inline JavaScript?

What practices are common out there and what practices have the most merit with regards to avoiding inline JavaScript?

A: 

I'm not sure I understand the question. Are you trying to add dynamic JavaScript arrays from the server side and inject it into the page?

If so, wouldn't it be easier to use some Ajax and return some JSON?

contagious
That's certainly a workable solution. I don't have a specific problem to solve I'm just interested in hearing some new ideas. I suppose the downside to this strategy is the extra request.
camomileCase
A: 

Another possibility is to dynamically generate your .js files, just like you dynamically generate your .html (or whatever) files.

Domenic
Then those .js files can't be served from a CDN or leverage caching, defeating the purpose of moving them to a separate file.
Frank Schwieterman
Well, it still is somewhat cleaner than polluting your HTML with inline script blocks (as the accepted answer suggests).
Domenic
+1  A: 

Depending on the nature of the dynamically generated JavaScript, it might not need to be placed inline. You can simply make a PHP file that will take some parameters and produce JavaScript code, and then just call the PHP file with the needed parameters by using the script tag in your header, something like <script src="foo.js.php?a=b&c=d&x=y&foo=bar">. That's how I handle my dynamic JavaScript generation needs.

code_burgar
A: 

I think it's plenty reasonable to insert JavaScript into a document, particular when you're populating data that changes dynamically with the page. I don't think there is any advantage to storing that data in HTML tags rather than putting in inline script.

What you should do is minimize the amount of inline script needed by factoring out code that can be moved to a separate JavaScript file.

Frank Schwieterman
+3  A: 

One of the things I'm doing when possible is to output (from PHP) some JSON inside some SCRIPT tag that will be later used by my JS code. Something like this:

<script type="text/javascript">

var db_data = <?php echo json_encode($db_data); ?>;

process_db_data_from_js(db_data);

</script>

I believe Flickr is using something like this for their search suggest.

Ionuț G. Stan
This is an interesting approach.
camomileCase
A: 

If you need to get some data from your server-side application into your JavaScript, I've found it's just best to use Ajax.

Sure, you can put it into HTML elements, but that's finnicky and makes for bad semantics in your HTML. Also, people using lynx will see it as part of your page.

You can also dynamically generate the JavaScript itself, but that leaves a whole other host of problems you have to defend against, possibly even JavaScript injection.

Apreche
While in some cases this is good (e.g. pages in a CMS like in the original post), in many it is overkill, e.g. letting JS know what the current username is. I guess for "dynamic server-sided data" Ajax makes sense, but for just "data that only the server-side knows about" I'd rather write it out to JavaScript.
Domenic
+2  A: 

You could add attributes to your elements, then have non-static or static JS that looks for them.

<div id="..." extraAttribute="whatever">
</div>

Using JQuery, this is easily found.

var extraDivs = $('div[extraAttribute]');

(I highly recommend JQuery for this sort of coding.)

John Fisher
If you start your attributes with `data-`, it's valid HTML5! We use this all the time for localization, e.g. `<form data-error="<%: GetResource("ErrorMessage") %>"> ... </form>`.
Domenic