Reputation: 1594
Basically what I am asking is what is the point of giving my script tags an id attribute? Can the routines inside of them be called or referenced differently because of this identification? Could this cause any problems making the script/page act funny?
Upvotes: 14
Views: 17344
Reputation: 553
They might come in handy when you think of loading scripts lazily. Also, I remember I once used an ID on a script tag to facilitate the changes on meta content, per state change (it was a single page application).
With an ID on a script tag, you can check if on a particular instance, whether a script tag with a particular ID is there in the DOM or not. If it's not there, and if your route requires it to be there, you can load it then (given on certain conditions).
Suppose there's a script that you need to load lazily. Let's take an example of some chat widget. Cases can arise that may tend you to load the chat widget only and only whenever a user happens to click on, say, a chat button.
Here, you'll be lazily loading the chat. So, a possible case out of it can be: "if user clicks on chat button, inject the chat widget js into the DOM".
Simple? Hell yes. But, think about the case when a user clicks on the chat button again. What will happen? The same script would be injected again, but you certainly don't want that to happen, do you?
So, let's say the chat widget js goes into the DOM by:
<script id="chatWidgetScript" src="...whatever..."></script>
A good solution to tackle the "second click" problem on the chat button will be to see if the script already exists in the DOM, and if it does, don't let the same get appended twice into the DOM.
So, your button could be:
<button onclick="loadChatWidget()"> Chat! </button>
And your loadChatWidget() function could be:
loadChatWidget(){
if(document.getElementById("chatWidgetScript")){
//chat script is already there in the DOM, no need to load it again.
return;
}
/*
if document.getElementById("chatWidgetScript") returns null, this would
mean that the chat widget isn't there in the DOM, and you might want to
load the same now.
*/
// LOAD SCRIPT HERE
}
This is just one way of using an ID on a script tag, and it is useful too!
Upvotes: 0
Reputation: 1976
I used script
id
tag in a bookmarklet; I add the script
element via Javascript to DOM
alongwith a div
; then use it; & when/if user clicks the Close
button on my added div
; I find this script
element by ID & delete it from DOM to leave the page as I found it.
Upvotes: 0
Reputation: 10086
I found a very novel use for giving ID to a script
tag. I had embedded tawk.to script in my website to show its chat widget. The problem is, the widget does not hide when I want to print the page. So you would see the widget repeated on every page in the print preview, often obscuring the page contents!
In order to resolve the problem, I first observed how the widget is added. I found out that the widget is added right after the script tag. But the widget (encased in a div
tag) does not have any class, and it has a randomly generated ID which is different each time.
There had to be another way to catch hold of that widget (the div
tag) without relying on JavaScript tricks. That's when I learnt that CSS has an "adjacent sibling" or "next sibling" selector, which surprisingly has very decent browser support.
So first, I gave an ID for the script tag.
<script type="text/javascript" id="tawk-to-script">
Then I used the ID and the next sibling selector to apply CSS to the widget.
@media print {
script#tawk-to-script + div {
display: none !important;
}
}
Viola! Problem solved.
Upvotes: 0
Reputation: 29922
There is one use nobody mentioned: the id="test"
attribute sets the global variable test
pointing to the element itself. See:
Upvotes: 0
Reputation: 160
This might be useful for checking the existence of the resource file in the src url attribute in the server. For cache busting, reverencing the file name of .js and .css files are required. This will help in checking out if the file names has changed in the server and then do a reload via code via
$window.location.reload()
Code example (angularjs):
service.reloadApplication = function () {
var script = document.getElementsById("scriptAppMin");
if (!!script.getAttribute('src') && doesFileExist(script.getAttribute('src')) == false)
$window.location.reload();
}
function doesFileExist(fileUrl) {
var xhr = new XMLHttpRequest();
xhr.open('HEAD', fileUrl, false);
xhr.send();
return !(xhr.status == "404");
}
Upvotes: 0
Reputation: 14039
As the earlier answers have mentioned, once the code in the script tag runs, it's results will not be undo-ed by replacing/deleting the script node.
But the id can be useful if the code has not run till now. Following is such a script tag:
<script id="code1" type="text/myjs">.....</script>
Since the browser is not aware of this type of script, it will ignore it's execution but the tag and it's code will still be available in the DOM.
Working example: http://jsfiddle.net/sv_in/rt9Q2/
This is largely used for client side templates. A template, example for Mustache.js, is stored in such a script tag. When it is needed to be compiled, it is obtained from tag using it's id. Advantage with this approach is that the view (templates) and the model (js variable which contain data to be shown in the view) is completely separate.
Other than this practise, there is no general purpose use for an id for a script tag
Upvotes: 6
Reputation: 46
Adding an id attribute to your script elements serves 2 specific purposes:
1. you can recognise your scripts when reading the web page's source code;
2. the HTML reference says you should be able to overwrite the contents of an identifiable element (but experience teaches us that few browsers actually do that).
For instance, if you already have a script with id="myParticularScript", then adding a new script element with that same id should replace the old one, loading any new (or the same) source you specified in the src attribute.
While my experience with dynamic loading of javascripts proves that the new script does get loaded into the browser, no browser I tested managed to replace the older element that holds the same id.
So that just leaves the first purpose: easy recognition. In my work, we use systems to generate web pages, and we didn't always know which script (or css link, for that matter) is added by which component. We solved this by adding ids to both the script tags and the css link tags - ids that we were able to recognise and trace back to our systems.
Upvotes: 1
Reputation: 270609
The id
is just another accessor of the <script>
tag inside the DOM tree. You could in theory use document.getElementById()
to retrieve the <script>
node and delete it or add other attributes (though I don't believe you can modify the src
attribute once it has loaded in the DOM). The id
isn't required for those operations though -- it could have been accessed by any DOM function such as getElementsByTagName("script")
as well.
If you do need to access the <script>
tag with DOM manipulations, the id
makes it just a little easier. Otherwise, there is little benefit1.
1That is sort of true of adding an id
attribute to any DOM node, though nodes affecting presentation can also benefit from CSS targeting the id
, unlike a <script>
tag...
Upvotes: 14
Reputation: 2533
There is no meaning giving id to your script tags, the scripts on a page just execute in a sequence they are on the page.
Upvotes: 1