Just thinking about it, XHTML1.1 spec and by extension, HTML5 (assumed)... well Markup is designed so that unless otherwise specified, "order" isn't supposed to matter.
Everything in the Body tag obviously is ordered a specific way for the browsers rendering engine to interpret, but the HEAD and BODY tags themselves conceptually have nothing to do with render order (despite their name, and except includes in HEAD; if an include depends on another include obviously that must be loaded in first), and thus follow the same rules as any Markup language.
Throwing the HEAD tag block below the BODY tag block works (at least in WebKit based browsers anyways) but all I've been able to do so far is test that te Title tag works as it should. Not a totally conducive test, but as I write this on my phone, I didn't have time to go any further with my thought process.
I'm wondering how doing this would affect SEO, and worse yet: loading of Script and CSS files typically handled in the HEAD. I understand a practice lately has external loading of script files happening at or near the bottom of the markup to ahem delay their loading for when the page is ready, would this react any differently?
Basically I'm asking, What are the *repercussions * of having a website where the HEAD block is located below the BODY block?
<html>
<body>
Test
</body>
<head>
<title>Test</title>
<script src="test.js" type="text/javascript"></script>
<link rel="stylesheet" type="text/css" href="test.css" />
</head>
</html>
It would only have a negative effect on SEO, if any at all.
First off, your proposal results in incorrect HTML. The HTML4.01 DTD, which strictly defines the structure of HTML documents mandates that <head> becomes before <body>:
<!ENTITY % html.content "HEAD, BODY">
(If the order didn't matter, then it would be <!ENTITY % html.content "(HEAD|BODY)+">
Secondly, I'd wager most spiders look for a <head> element as quickly as possible, if it can't find one before the <body> element then it will probably discount your document at best, if not completely ignore it. I suspect most spiders would ignore any <head> elements encountered after <body>.
Third, it ruins the user experience. Sometimes pages can take a while to load, but a browser parses the HTML as it downloads. As soon as it sees <title> it displays it to the user so the user knows the page has at least partially loaded (even if it hasn't been rendered yet). Without this ability your users might close the browser tab/window out of frustration if it loads too slow, as they'd think the site was completely unresponsive.
Interesting question but I strongly believe that HTML structure is very much similar with human anatomy (Head-Body-foot), what happen and how its look if it’s not in proper structure?? Looks ugly, difficult to identify the particular person, here browser act accordingly to the universal structure (like head-body-footer) so these are few predefine structure that we need to follow for best result.
Regarding SEO, offsite SEO work in such a case that how are we following structure, and of course it will effect to Google spider and many more thing .
Related
There is very old thread where people state that you should never include CSS in body, however MDN states that is is allowed. So is it considered good or bad practice to include CSS in the middle of the page?
For example, let's take a structure like this:
<html>
<head>
<link href="global.css" rel="stylesheet">
</head>
<body>
<h1>Some title</h1>
<p>Some content</p>
<img src="some-image.jpg" />
<link href="specific-component.css" rel="stylesheet">
<div>
Specific component that requires the style
</div>
<p>Other content</p>
</body>
</html>
What are disadvantages of including specific-component-style.css mid page comparing to including it to head section?
How page will be rendered with it? Will it be:
Start loading global.css, some-image.jpg, specific-component.css (in this order).
After global.css is loaded start rendering page until specific-component.css <link> element.
Finish loading specific-component.css
Render the rest of the page.
Or will it be:
Wait for both global.css and specific-component.css finish loading and only then start rendering the page.
What if there are 20 images before specific-component.css, will browsers prioritize CSS file or not?
There are two major disadvantages:
you lose maintainability of code
if that CSS affects any element before it, you might experience FOUC.
Theoretically, there's also a minor performance loss, but it's negligible: rendering is paused when a new stylesheet resource is met. A clear difference should be made between "render blocking" and script execution or DOM building blocking. The browser will continue to do whatever else it can and will block any script requesting repaint(), until the resource resolves, at which point, CSSOM is rebuilt, all existing DOM elements are checked against the new CSSOM and all pause scripts are continued.
If your <style> refers to an exception only met in that particular view/component/page, it makes sense to add it there, before the element affected by the rules. But if you make a habbit out of it, sooner or later you'll wish you had all your styles in one place; your project will become harder to maintain.
On general principles, you should not do it.
It also greatly depends on the scale of your project. On small projects it's irrelevant. In huge projects, involving large teams, it's completely forbidden, as nobody will remember your exception. So it's sometimes valid ground for losing your position or at least your standing. ツ
Last, but not least, especially if you're not regarded as an expert, it's something that can be interpreted against your interest by people assessing your work (as in, people knowing less than you might see it as a sign of you not doing your job properly).
With that being said, the browser doesn't care. If it validates, it's applied and rendered.
Another minor technical issue (in the case of <style> tags, not <link>s) is that inline CSS is never cached. It gets loaded each time, together with the markup, while regular CSS in loaded stylesheets does not eat up bandwidth anymore. But, again, if we're talking a few lines of code, it's irrelevant.
Safari and Edge will render content before the <link>, then continue rendering once the linked CSS has fetched.
Firefox will render content before and after the <link>, then update the page once the linked CSS has fetched. You can make it behave more like Safari/Edge using <link … ><script> </script> (the space between the script tags is necessary.
Chrome will block rendering as soon as it discovers the <link>, meaning it may also block content before the link element. The plan is to align with Safari & Edge https://bugs.chromium.org/p/chromium/issues/detail?id=481122.
If you find that your CSS is fetching too late, you can use <link rel="preload" as="style" href="…"> to load it sooner.
If you give img{width:100px;} in global.css And img{width:150px;} in specific-component.css, In this case work specific-component.css because he render after global.css and it overwrite of global.css.
If you give img{width:100px !important;} in global.css And img{width:150px;} in specific-component.css, In this case work global.css because we set img width important in global.css and it don't overwrite by specific-component.css.
And If you give important in both, then work specific-component.css.
And css engine always compile first specific-component.css.(look in inspect element)
In my opinion this depends on how you work. If you load a complete page (whether it's manual HTML, or generated through CMS like Wordpress) - it is recommended that the style will load before the body, to allow the rendering to be smoother and faster.
HOWEVER, since the use of component libraries like React and Vue (for example) is becoming more and more popular, it's acceptable to connect the CSS to the component, and not load component-sepcific CSS with the general style (this should generally allow faster loading time, especially in one page sites that have dnamically changing elements.
As per rendering order, by default, CSS/JS is the highest priority to load, and after that you get media elements (images, videos, audio etc.). Check this link or this to read more about priorities in the browser.
I was reading some style guides and saw a conflicting recomandation
regarding the Optional Tags.
Google says:
Omit optional tags (optional). For file size optimization and
scannability purposes, consider omitting optional tags. The HTML5
specification defines what tags can be omitted.
(This approach may require a grace period to be established as a wider
guideline as it’s significantly different from what web developers are
typically taught. For consistency and simplicity reasons it’s best
served omitting all optional tags, not just a selection.)
W3CSchools says:
Close All HTML Elements In HTML5, you don't have to close all elements
(for example the <p> element).
We recommend closing all HTML elements:
And
We do not recommend omitting the < html > and < body > tags.
This means Google prefers:
<!-- Recommended -->
<!DOCTYPE html>
<title>Saving money, saving bytes</title>
<p>Qed.
W3CSchools prefers:
<!DOCTYPE html>
<html>
<title>Page Title</title>
<body>
<h1>This is a heading</h1>
<p>This is a paragraph.</p>
</body>
</html>
it is also considered "bad looking" to write this whereas google would recommend it.
<section>
<p>This is a paragraph.
<p>This is a paragraph.
</section>
I found it very interesting that W3CSchools makes a difference regarding the head tag
Is there any good reason to stop using the optional Tags ?
Personally I found the code then less readable but that is purely opinion based and I guess with some training I would prefer one over the other.
Google stated that its for size optimization and scannability purposes but is that really a good reason ? The articles below stated some suggestions but seemed to me more opinion based and I am looking for good reasons to stop using the optional Tags
Here the resources:
Google Style guid
HTML5 Style Guide
html-include-or-exclude-optional-closing-tags
Omitting optional tags of html
Many times we use the optional closing tags because it makes the document more readable. As Google says, removing them reduces file size but, then, most of us don't have the traffic Google does. That suggestion is for those who do. Then, again, reducing download size is always a good thing.
I often leave out the body tag altogether because even the opening tag is optional in most cases. However, there is a danger that leaving that out, and leaving out closing tags, may cause issues later on. I would say putting body tags in and closing all elements removes the possibility of causing those issues. For example, you can only leave the html and body tags out under certain situations.
Reading the spec:
An html element's start tag can be omitted if the first thing inside
the html element is not a comment. An html element's end tag can be
omitted if the html element is not immediately followed by a comment.
For some, this is very important. To others it's not.
It can be more of an issue for dynamically generated sites where the content is created on the fly and the surrounding elements may not be known. Does one really know that the following element will cause a div element to be closed?
Another opinion:
If your site uses gzip compression, DO go out of your way to include the optional tags, speaking at least if in very large tables where so many cell tags are repeated.
If omitted, the original file size is smaller, but then the receiving browser just has to spend time putting every optional tag back in. They will be in the displayed html file. Look at the displayed page source and you will see this is true. So omission is a balance of faster download speed and slower display recovery speed.
But if gzip and the tags are included, gzip compression will compress away the repeated tags, and the transmitted file is no larger than if not included (so absolutely no download savings). And then the browser does not have to spend any time adding every one of them back in. And they ARE going to be added back in. And if hundreds or more cells in a table, this time might add up.
So if gzip, omitting HTML optional tags seems a minus for speed, not a plus (certainly at least in the case of very large tables). Your web host likely provides an feature to add gzip compression.
Single tags like /body or /tbody can't matter to speed, but /td and /tr can be very numerous in large tables.
The tl;dr version is why does html that doesn't close tags properly still work error free?
I'm learning more and more HTML each day but I'm still quite a beginner. So I don't understand why badly written HTML without properly closing tags still works. I was using an email template for a task at work and was curious about the HTML behind it so I loaded to code into an editor.
I came across 9 separate tags that don't close: <td> <center> <div> <p> <div> <td> <tr> tbody> <table> The code starts with an <html> tag as it should, but in the <body> after a <table> and <tr>, it starts another <html> <head>... etc set of tags. In the two <style> tags, they both say say the same thing and have an extra closing brace li { margin-bottom: 10px; } }.
When I load just this code into my browser the page still visually appears how it is supposed to. In Firebug though, after the first body tag, it skips table, tr, html, head, and body, and goes straight to just showing the first <div>.
Why is it that a webpage (because I'm sure this must be a somewhat common thing out there) that has missing closure tags, extra <html> and <body> tags, etc still able to function properly?
I think this is an application of the Robustness Principle.
Be conservative in what you do, be liberal in what you accept from others
I'd argue this is an inevitable outcome in a landscape of competing browsers. If an HTML error prevents a site from working in browser A, but browser B is able to guess a correction, users will tend to use browser B, as A appears to be broken. This has been going on since Netscape 3 or earlier.
Misformed HTML does not work correctly - browsers try to guess the intent of the HTML structure and display whatever the result of the guess is. This is the result of an unfortunate decision to allow poorly-formed HTML to display, rather than rejecting it and forcing the author to fix such problems.
When you see misformed HTML looking correct on the screen, it's not the result of correct behavior: it's the result of a lucky guess on the part of the browser (obviously, a tiny problem is easier to fix by guessing than a massive structural problem that spans the entire HTML structure).
It comes down to treating HTML as content (which it is not), rather than a formal language (which it is): content authors were (and are) considered non-technical people and forcing them to fix problems with "content" was seen too hard a requirement.
Google PageSpeed Insights recommend us to defer loading of secondary stylesheets by placing them after the closing </html> tag. Code example from that page:
<html>
<head>
<style>
.blue{color:blue;}
</style>
</head>
<body>
<div class="blue">
Hello, world!
</div>
</body>
</html>
<link rel="stylesheet" href="deferred_stylesheet.css">
This strikes me as odd, because I would expect Google to recommend standard practices instead of non-standard practices.
Is the code above legit? Do the HTML5 standards provide consistent rules for browsers to parse these sort of code?
What problems will we (or our users in fact) encounter if we use the tags as such?
It isn't correct to put anything outside the HTML tags however all browsers try to sort the mess they get served.
Almost all browsers e.g. Firefox, Google Chrome, Internet Explorer, etc will sort this out for you. Some self written browsers maybe won't do this.
However you can better write it in between the head tag for performance (because then the browsers don't need to sort out the dirty coding).
This means users will encounter almost no problems.
First, you're missing your <!DOCTYPE html> declaration at the top, which is required for HTML5 documents.
Second, you're also missing a <title> tag in your head.
Finally, no, tags after the closing </html> tag are not allowed. If you run your doc through the w3 validator service you'll see:
Line 14, Column 54: Stray start tag link.
<link rel="stylesheet" href="deferred_stylesheet.css">
This error is unrecoverable.
I would expect to face browsers either totally ignoring it or loading it. Depending on the browser, the version and the platform. Since you can't be sure it'll work (and since it's non-conforming), you shouldn't do it.
UPDATE
This is non-valid HTML, however user-agents are allowed to parse it and include in the body. But they are not required to since they can define their own rules for parse errors
Is this correct or even allowed structure?
No. It is incorrect to place elements outside the <html>tag.
Oh dear! Will it land me in problems?
No. Browsers will fix your bad code as best as it can. This is no problem for the browser.
Should I do it?
Well ... it's complicated. Short answer is "no, probably not". As developers, it is our responsibility to ensure that our code is correct (machines can't be trusted, that will be our downfall!). The rules are there for a reason. On the other hand, as hackers, we can some times break and bend rules, if it makes sense in the situation and you know what the consequenses will be.
HTML hacking? What the hell are you talking about?
Browsers will always try to render the document as best as it can. Interestingly, you don't even have to give the a <html> tag – the browser will figure it out for you.
Here's an example page – inspect the rendered DOM, and the view source. I've almost not given it anything to work with, and it has kindly created all missing tags. Neat! You do need a DOCTYPE declaration and in most cases a <title> tag.
But, I digress ...
So, the browser will definitely render it correctly. It is, however, incorrect as per the specs, and the document will not validate (if you care about that). For the most part, it's a good idea to follow the specs, unless you have a good reason.
Now, I can't see why Google wants you to place it outside the <html> tag. It sounds strange, however I guess they know what they're doing. My guess is, that they want to make absolutely sure, that the ressource is loaded last.
does it matter at all what order the <link> or <script> or <meta> tags are in in the <head></head>?
(daft question but one of those things i've never given any thought to until now.)
Optimization
According to the folks over at Yahoo! you should put CSS at the top and scripts at the bottom because scripts block parallel downloads. But that is mostly a matter of optimization and is not critical for the page actually working. Joeri Sebrechts pointed out that Cuzillion is a great way to test this and see the speed improvement for yourself.
Multiple Stylesheets
If you are linking multiple stylesheets, the order they are linked may affect how your pages are styled depending on the specificity of your selectors. In other words, if you have two stylesheets that define the same selector in two different ways, the latter will take precedence. For example:
Stylesheet 1:
h1 { color: #f00; }
Stylesheet 2:
h1 { color: #00f; }
In this example, h1 elements will have the color #00f because it was defined last with the same specificity:
Multiple Scripts
If you are using multiple scripts, the order they are used may be important if one of the scripts depends on something in another script. In this case, if the scripts are linked in the wrong order, some of your scripts may throw errors or not work as expected. This, however, is highly dependent on what scripts you are using.
The accepted answer is kind of wrong, depending on the encoding of the document. If no encoding is sent by in the HTTP header, the browser has to determine the encoding from the document itself.
If the document uses a <meta http-equiv="Content-Type" … declaration to declare its encoding, then any ASCII-valued character (character code < 128) occurring before this statement must be an ASCII value, as per HTML 4 spec. Therefore, it's important that this meta declaration occurs before any other element that may contain non-ASCII characters.
It's recommended to put the meta tag with the character encoding as high as possible. If the encoding is not included in (or differs from) the response header of the requested page, the browser will have to guess what the encoding is. Only when it finds this meta tag it knows what it is dealing with and it will have to read everything it has already parsed again.
See for instance Methods for indicating the character set.
One important thing to note: if you're using the Internet Explorer meta X-UA-Compatible tag to switch rendering modes for IE, it needs to be the first thing in the HEAD:
<head>
<meta http-equiv="X-UA-Compatible" content="IE=7" />
<title>Page title</title>
...etc
</head>
meta does not matter, but link (for css) and script matters.
script will block most browser from rendering the page until the scripts are loaded.
Therefore, if possible put them not in the head, but the body.
css link will not block page rendering.
It is usually recommended to have the <script> tag as lower down the page as possible (not in the head but in the body).
Other than that, I don't think it makes much of a difference because the body cannot be parsed unless you have the <head> section completely loaded. And, you want your <link> tag to be in the head as you want your styling to occur as the browser renders your page and not after that!
If you declare the charset in a meta element, you should do it before any other element.
Not a daft question at all.
CSS above Script tags for reasons already mentioned.
CSS is applied in the order you place the tags - the more specific the stylesheet, the lower down the order it should be.
Same goes for scripts - scripts that use functions declared in other files should be loaded after the dependency is loaded.
Put the meta tag that declares the charset as the first element in head. The browser only searches so far for the tag. If you have too much stuff before the meta element, the charset might not get applied.
If you use the BASE element, put it before any elements that load URIs (if desired).
It would only matter if one of the linked files (CSS/Javascript) depended on another. In that case, all dependencies must be loaded first.
Say, for example, you are loading a jQuery plugin, you'd then need to first load jQuery itself. Same when you have a CSS file with some rules extending other rules.
As already pointed out meta describing content charset should be the first otherwise it could actually be a security hole in a certain situation. (sorry i dont remember that situation well enought to describe here but it was demostrated to me at web security training course)
I recently was having a problem with a draggable jquery ui element. It was behaving properly in Firefox, but not Safari. After a ton of trial and error, the fix was to move my css links above the javascript links in the head. Very odd, but will now become my standard practice.
For the purposes of validation as XHTML, yes. Otherwise you're probably going to care about the optimization answers.
Nope, it doesn't matter, except for CSS linking or inclusion, because of CSS inheritance and the fact that it overwrite what was already styled (sorry for my english, i think my sentence is not really clear :-/).