Содержание
It’s not wrong. It will cause an alarm on validators, but it will run on most browsers. It is not wrong, but it is not valid.
It won’t validate outside of the
@epalla: if you put the script right at the end of the body tag there’s no other content left to load by the time it gets there, so there should be little difference between placing it outside or just inside. You then have the added benefit of your page still validating, which was the point I was trying to make in my answer.
Yep, I was agreeing with you since your answer is good. I just wanted to add that there is a reason for putting JS at the bottom of the page instead of in the head as we’ve done for a long time.
@PHPst: well, invalid code may be subject to side effects in certain browsers. Either way, I don’t see how its indentation being one tab-width less than the code above it makes it look any cleaner.
@PHPst: I would expect browsers to cope with it if you really want to write your code that way. I’d still recommend writing your code to validate, however.
@technosaurus: there’s always
Only comments and the end tag for the html element are allowed after the end tag for the body.
You can confirm this with the specification or a validator.
Browsers may perform error recovery, and the HTML specification even describes how to recover in that situation, but you should never depend on that.
It is also worth noting that the usual reason for putting the script element at the end is to ensure that elements the script may try to access via the DOM exist before the script runs.
With the arrival of the defer attribute we can place the script in the head and still get that benefit while also having the JS be downloaded by the browser in parallel with the HTML for better performance.
This is a better answer. There are too many new browsers out there with mobile coming into play to risk doing it wrong when all you have to is cut and paste a single closing tag.
Note that defer only applies to external script files (i.e. you must also specify src attribute). You cannot «defer» a element that contains script.
As Andy said, the document will be not valid, but nevertheless the script will still be interpreted. See the snippet from WebKit for example:
void HTMLParser::processCloseTag(Token* t) < // Support for really broken HTML. // we never close the body tag, since some stupid web pages close it before // the actual end of the doc. // let's rely on the end() call to close things. if (t->tagName == htmlTag || t->tagName == bodyTag || t->tagName == commentAtom) return; . Internet Explorer doesn’t allow this any more (since version 10, I believe) and will ignore such scripts.
Firefox and Chrome still tolerate them, but there are chances that some day they will drop this as non-standard.
And yet Google does this in their example of how to do G+ sign-in, with «last updated April 10, 2014». I got it from the version for Java on the server (developers.google.com/+/quickstart/java) but presumably it is the same HTML+js for all.
Procedurally inserting an «element script» after an «element body» is a «parse error» by the recommended process by W3C. In «Tree Construction» create an error and run «tokenize again» to process that content. So it’s like an additional step. Only then can it run the «Script Execution» — see the scheme process.
Anything else is a «parse error». Switch the «insertion mode» to «in body» and reprocess the token.
Technically, by the browser, it’s an internal process how they mark and optimize it.
Yes. But if you do add the code outside it most likely will not be the end of the world since most browsers will fix it, but it is still a bad practice to get into.
Modern browsers will take script tags in the body like so:
Basically, it means that the script will be loaded once the page has finished, which may be useful in certain cases (namely DOM manipulation). However, I highly recommend you take the same script and put it in the head tag with «defer», as it will give a similar effect.
What would be useful is if script tags had a event attribute that could be defined to determine when to parse the script. So you have event=»load» event=»DOMContentLoaded» for running the script after the DOM is created or event=»beforeunload» on the window beforeunload event. Example, .
Putting it in the head with defer doesn’t have the same effect; with defer, in the head: The script is fetched asynchronously, and it’s executed only after the HTML parsing is done. Whereas if you put the script at the end of the body: The HTML parsing is done without any pauses, and when it finishes, the script is fetched, and executed.
@PeterMortensen it’s not wrong to do anything especially in something as lax as html 😂 I was referring to potentially unexpected behavior where the document hasn’t actually finished loading yet depending on where you put the script tag in the body.
Technically you shouldn’t be able to place the script tag after the body tag since rendering of the page content ends with the body (or is it the head?.)
But browsers are somewhat fault tolerant (although I wouldn’t depend on this as a universal truth because you just might never know) and they’d:
This norm is an accepted practice/convention and is guaranteed to remove any doubts.
Also while you are play safe and do the most [reasonable] thing, keep in mind that what you need to [then] worry about is the performance because the loading/downloading, parsing and interpretation of the internal/external sourced file(s) is/are dependent on where the script(s) tag occurs, even if you were using defer or async.
Content goes here
Content goes here