in this page it's said :
When your webpage loads, the browser takes certain steps that
determine how the page will load (this is a simplified version, but
basically what happens): Browser downloads HTML file It parses (looks
through) the HTML It encounters something it must load (image,
external CSS file, etc.) and stops parsing HTML It loads the external
resource If external resource is CSS or Javascript it then parses that
file It then continues to parse the HTML until it comes to another
resource that must be loaded
So why alot people (and myself) were looking for a solution to capture load event on LINK and to detect When is a stylesheet really loaded as we can be sure that a browser won't dislpay a non-styled html if we place its css before it?
There may not be a need to detect this but plenty of reasons to do so. If your CSS is sizing an element, or using pseudo elements that add content to your document, you may wish to know when the CSS has completed loading before trying to manipulate those same elements.
For example, if your CSS is loading an image, and that image winds up resizing other elements on the page, you may not want your javascript interfering with that sizing before it's complete.
If you add elements with CSS ::before or ::after, you want those elements inserted before allowing javascript to manipulate them.
But if you aren't doing such things, then you don't need to detect them.
Related
I am looking for a simple way to make my website modular and extract common parts that appear often like header and footer into separate files.
In my case, I can not use any server-side includes with e.g. PHP. I also generally would like to avoid including big libraries like JQuery just for such a simple task.
Now I came across https://stackoverflow.com/a/691059/4464570 which suggests to simply use an HTML <object> tag to include another HTML file into a page, like this:
<object data="parts/header.html" type="text/html">header goes here</object>
I might be missing something important here, but to me this way seems to perfectly fit my needs. It is very short and precise, the <object> tag is well supported by all browsers, I don't need to include any big libraries and actually I don't even need any JavaScript, which allows users blocking that to still view the correct page structure and layout.
So are there any disadvantages I'm currently not aware of yet with this approach? The main reason for my doubts is that out of dozens of answers on how to include HTML fragments, only one recommended <object> while all others went for a PHP or JavaScript/JQuery way.
Furthermore, do I have to pay attention to anything special regarding how to put the <object> tag into my main page, or regarding the structure of the file I want to include this way? Like, may the embedded file be a complete HTML document with <!DOCTYPE>, <html>, <head> and <body> or should/must I strip all those structures and leave only the inner HTML elements? Is there anything special about using JavaScript or CSS inside HTML embedded this way?
The use of the <object> tag for HTML content is very similar to the use of an <iframe>. Both just load a webpage as a seperate document inside a frame that itself is the child of your main document.
Frames used to be very popular in the early days of web development, then in the form of the <frame> tag. They are generally frowned upon, however, and you should really use them as little as possible.
Why not to use this technique for displaying your own content
The HTML content in the child frame cannot communicate with the parent. For example, you can't use a script in the parent HTML to communicate with the child and vice versa. That makes it not very useful for serving your own content when you want to display anything but static text.
Why not to use this technique for displaying someone else's content
You can't use it to serve a lot of external content either. Many websites (including eg. SO) send an X-Frame-Options header along with their webpage that has the value SAMEORIGIN. This prevents your content from being loaded and displayed.
I have a JSP (a header, a body area, a footer, all with it's own CSS).
The body area is dynamically populated with HTML content from a database (it is archived mailing list emails).
The problem is, sometimes the email from the db is a fully-formatted HTML document with it's own CSS.
And sometimes that CSS (ex. a:link { color: #000;}) overrides the CSS in my JSP (ex. a:link { color: #FFF;}).
Is there a way to contain the wrap the dynamically loaded HTML in it's own container or something so it won't override the "external" CSS?
Simply wrapping the information from the DB in <iframe> tags should be all that is necessary to avoid the DB content's styles overriding the rest of the page's styles. This is because iframes function as a new browsing context, and will not be able to send anything additional up. However, if you need your styles to propagate into it, iframe will not be able to help- or at least, not by itself.
There is an attribute called seamless in the works that will potentially enable that, but browser support is poor (re: currently nobody big implements it), and it seems like it might need to be paired with another setting to prevent its CSS from escaping the iframe if I'm reading mdn right (the spec itself does not seem to imply this).
If you need to be able to have parent affect the content of the iframe, this question over here should be able to help. TLDR from there, you can force it by targeting the iframe itself in javascript assuming the content is not external, but CSS propagation is not going to be possible without adding your own style includes.
In the future, it might also be possible to use "scoped stylesheets" (mdn | caniuse), to where all you'd have to do is toss scoped onto any <style> tag in the file, however, you would still have any js executing on the full scope, and technically-invalid HTML (<body> inside <body>, etc) whenever you fetch a full page.
For more detailed information about iframes, see the mdn on it.
Also: Nico O from the comments on the question deserves the beer for answering, I just formalized it and added the note on scoped stylesheets.
You can use "!important" in your desired CSS file.
a:link {
color:green!important;
}
so that nothing can override it, even inline codes.
Check it live here
Google suggests to use very important CSS inline in head and other CSS inside <noscript><link rel="stylesheet" href="small.css"></noscript>.
This raises few questions in my mind:
How to prioritize CSS in two files. Everything for that page looks important. Display, font etc. If I move it to bottom then how it helps page render. Wont it cause repaint, etc?
Is that CSS is required after Document ready event? Got it from here.
How 'CSS can' go inside <noscript></noscript>, which is for script? Will it work when JavaScript is enabled? Is it browsers compatible?
Reference
Based on my reading of the link given in the question:
Choose which CSS declarations are inlined based on eliminating the Flash-of-Unstyled-Content effect. So, ensure that all page elements are the correct size and colour. (Of course, this will be impossible if you use web-fonts.)
Since the CSS which is not inlined is deferrable, you can load it whenever makes sense. Loading it on DOMContentReady, in my opinion, goes against the point of this optimisation: launching new HTTP requests before the document is completely loaded will potentially slow the rest of the page load. Also, see my next point:
The example shows the CSS in a noscript tag as a fallback. Below the example, the page states
The original small.css is loaded after onload of the page.
i.e. using javascript.
If I could add my own personal opinion to this piece:
this optimisation seems especially harmful to code readability: style sheets don't belong in noscript tags and, as pointed out in the comments, it doesn't pass validation.
It will break any potential future enhancements to HTTP (or other protocol) requests, since the network transaction is hard-coded through javascript.
Finally, under what circumstances would you get a performance gain? Perhaps if your page loads a lot of initially-hidden content; however I would hope that the browser itself is able to optimise the page load better than this hack can.
Take this with a grain of salt, however. I would hesitate to say that Google doesn't know what they're doing.
Edit: note on flash-of-unstyled-content (abbreviated FOUC)
Say you a block of text spanning multiple lines, and includes some text with custom styling, say <span class="my-class">. Now, say that your CSS will set .my-class { font-weight:bold }. If that CSS is not part of the inline style sheet, .my-class will suddenly become bold after the deferred loading has finished. The text block may reflow, and might also change size if it requires an extra line.
So, rather than a flash of totally-unstyled content, you have a flash of partly-styled content.
For this reason you should be careful when considering what CSS is deferred. A safe approach would be to only defer CSS which is used to display content which is itself deferred, for example hidden elements which are displayed after user interaction.
I have a 50x50px div I want to display on my homepage as fast as possible.
Is it faster for me to do
<div style="height:50px;width:50px">
Or to assign it a class to avoid the inline style:
<div class="myDiv">
And put the myDiv class in a CSS file in the HEAD section of the HTML page?
My thought was that the first one should be faster since it doesn't need to request and recieve a CSS? I guess ultimatley I'm asking if BODY and HEAD get rendered sequentially or in parallel.
Without HEAD loading first there can be no BODY.
Before your BODY gets rendered, it has has to be loaded first. And if it is loaded, then the HEAD has already been loaded.
You're probably interested in whether a browser can load simultaneously both CSS files and the HTML document itself. It will depend on the browser implementation, but I believe most can download at least two documents simultaneously.
One other important thing is that the more files a document consists of, the more chances the request for one of them gets lost. So by using inline CSS you make sure the CSS never gets lost.
But I must point out that inline CSS is considered a bad style. Once you have a sufficient amount of markup, you will find it increasingly difficult to update your pages all at once. You will inevitably be losing one or the other instance. It is a much better idea to declare all styles in a separate document and reference them from pages. This way, when you need to change some color, you do it in one place and not in 37 places to be found in your pages.
As others already pointed out, the right thing to do would be to put the styles in an external file and refer to it in the <head> part of your document.
But if you're going for fast (and this is what you were asking for) then you should use the inline-declaration like
<div style="height:50px;width:50px">
There are several reasons for that:
You don't have to load an external file. This is very slow (compared to the next reason) since there is an additional HTTP request involved which (on top of the request and download itself) might be held back by other external files like JavaScript, favicons etc.
So it will already load faster if you put your declaration in some <style> tags on the same document. But then there is the next reason.
The browser does not have to look through the DOM tree and search for nodes with the class myDiv to apply the styles to. It finds the <div> and immediately (or at the next render turn) applies the style information.
This second delay will hardly be noticeable but if you are going for high performance, this is the way to go.
I agree that these may somewhat be theoretical reasons but here you go. :-)
There are cases when this would be a "good" practice. For example, you have a high value landing page, that requires about 500 bytes of CSS to support, verses the 200K Style sheet.
While true, that they customer will have to download that file on the NEXT page, time to render is often most important on the landing page.
Also, AFAIK, browsers will not begin rending until the entire CSS file is downloaded, which is not the case for inline styles. But yes, Best Practices, and 98% of the time you want to put CSS in a single linked file.
Use an embeded css file. After the first request the file will be cached by the browser and won't have to be downloaded again. Making the page load faster and reducing the strain on your server.
Placing styles inline is not only ugly it also undermines the whole cascading thing.
The differences in performance will be imperceptible and should be irrelevent. Instead of worrying about premature optimisations like this be more concerned with doing the "right thing" - and in this case the right thing is to use external style-sheet files for your CSS as it is more maintainable and separates concerns.
I am working on an app for doing screen scraping of small portions of external web pages (not an entire page, just a small subset of it).
So I have the code working perfectly for scraping the html, but my problem is that I want to scrape not just the raw html, but also the CSS styles used to format the section of the page I am extracting, so I can display on a new page with it's original formatting intact.
If you are familiar with firebug, it is able to display which CSS styles are applicable to the specific subset of the page you have highlighted, so if I could figure out a way to do that, then I could just use those styles when displaying the content on my new page. But I have no idea how to do this........
Today I needed to scrape Facebook share dialogs to be used as dynamic preview samples in our app builder for facebook apps. I've taken Firebug 1.5 codebase and added a new context menu option "Copy HTML with inlined styles". I've copied their getElementHTML function from lib.js and modified it to do this:
remove class, id and style attributes
remove onclick and similar javascript handlers
remove all data-something attributes
remove explicit hrefs and replace them with "#"
replace all block level elements with div and inline element with span (to prevent inheriting styles on target page)
absolutize relative urls
inline all applied non-default css atributes into brand new style attribute
reduce inline style bloat by considering styling parent/child inheritance by traversion DOM tree up
indent output
It works well for simpler pages, but the solution is not 100% robust because of bugs in Firebug (or Firefox?). But it is definitely usable when operated by a web developer who can debug and fix all quirks.
Problems I've found so far:
sometimes clear css property is not emitted (it breaks layout pretty badly)
:hover and other pseudo-classes cannot be captured this way
firefox keeps only mozilla specific css properties/values in it's model, so for example you lose -webkit-border-radius, because this was skipped by CSS parser
Anyway, this solution saved lot of my time. Originally I was manually selecting pieces of their stylesheets and doing manual selection and postprocessing. It was slow, boring and polluted our class namespace. Now I'm able to scrape facebook markup in minutes instead of hours and exported markup does not interfere with the rest of the page.
A good start would be the following: make a pass through the patch of HTML you plan to extract, collecting each element (and its ID/classes/inline styles) to an array. Grab the styles for those element IDs & classes from the page's stylesheets immediately.
Then, from the outermost element(s) in the target patch, work your way up through the rest of the elements in the DOM in a similar fashion, eventually all the way up to the body and HTML elements, comparing against your initial array and collecting any styles that weren't declared within the target patch or its applied styles.
You'll also want to check for any * declarations and grab those as well. Then, make sure when you're reapplying the styles to your eventual output you do so in the right order, as you collected them from low-to-high in the DOM hierarchy and they'll need to be reapplied high-to-low.
A quick hack would be to pull down their CSS file and apply it to the page you are using to display the data. To avoid any interference you could load the page into an IFrame wherever you need to display it. Of course, I have to question the intention of this code. Are you allowed to republish the information you are scraping?
If you have any way to determine the "computed style" then you could effectively throw away the style sheet and, ****gasp****, apply inline styles using all of the computed styles' properties.
But I don't recommend this. It will be very bloated.