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
I have this extension which injects HTML as a notification, the problem is that every site renders this HTML different since my HTML code inherits all the css rules.
so I wondered if there's a way to inject this HTML and keep it from rendering different in every website.
I would personally tag up all parts of my html and include inline css rules that specify exactly how I want the html to appear.
Not including any styling information puts you at the mercy of the designers od each site.
We have an single-page web app that displays emails. Some of the emails we're viewing contain style elements that, when loaded into the DOM, affect our entire app. What's the best way to prevent this from happening? I'm currently removing style elements using the HtmlAgilityPack as shown in the post below, but I'm wondering if there's an easier way.
Regex to remove body tag attributes (C#)
Use iframes. That will put the message into a separate document, and there will be no styling interference.
Since you said html emails, the only way to make the Css work is to give inline css style's. External CSS will never work on html mails.
Let's say we have an HTML page with a single stylesheet <link>. How does the browser take the rules in this stylesheet and apply it to the HTML? I'm not asking about how to make it faster, I want to know how the rendering itself is handled.
Does it apply each rule one-by-one as it parses the stylesheet and render the result progressively? Or, are the CSS file's contents completely downloaded, then fully evaluated, and then applied to the HTML all at once? Or something else?
I ask this after posting an answer earlier on a question about CSS rule order affecting rendering speed, with the assumption that the styles were rendered as the stylesheet loaded, so the first rules would be applied before the last ones, and not all at once. I'm not sure where I picked up the idea, it's just something I have always thought.
I tried a demo on my server that looked like this:
<!DOCTYPE html>
<html>
<head>
<title>Test</title>
<link rel="stylesheet" href="test.css" />
</head>
<body></body>
</html>
test.css contents:
html { background:green }
/* thousands of lines of irrelevant CSS to make the download slow */
html { background:red }
Testing in Firefox 5, I expected to see green at first, then turn to red. It didn't happen. I tried with two separate stylesheets with conflicting rules and got the same results. After many combinations, the only way I got it to work was an inline <style> block in the <head>, with the conflicting rules coming from a <link> in the <body> (the body itself was completely empty except for the link tag). Even using an inline style attribute on the <html> tag, and then loading this stylesheet did not create the flicker that I expected.
Are repaints affected in any way by the CSS, or is the final output applied all at once after the entire stylesheet is downloaded and it's rules computed to what the final output should be? Do CSS files download in paralel with the HTML itself or block it (like script tags do)? How does this actually work?
I am not looking for optimization tips, I'm looking for authoritative references on the subject, so that I can cite them in the future. It's been very difficult to search for this information without turning up tons of unrelated material. Summary:
Is all CSS content downloaded before any of it is applied? (reference please)
How is this affected by things like #import, multiple <link>s, inline style attributes, <style> blocks in the head, and different rendering engines?
Does the download of CSS content block the downloading of the HTML document itself?
How does the browser take the rules in this stylesheet and apply it to the HTML?
Typically this is done in a streaming fashion. The browser reads the HTML tags as a stream, and applies what rules it can to the elements it has seen so far. (Obviously this is a simplification.)
An interesting related Q&A: Use CSS selectors to collect HTML elements from a streaming parser (e.g. SAX stream) (a diversion while I search for the article I have in mind).
Ah, here it is: Why we don't have a parent selector.
We often think of our pages as these full and complete documents full of elements and content. However, browsers are designed to handle documents like a stream. They begin to receive the document from the server and can render the document before it has completely downloaded. Each node is evaluated and rendered to the viewport as it is received.
Take a look at the body of an example document:
<body>
<div id="content">
<div class="module intro">
<p>Lorem Ipsum</p>
</div>
<div class="module">
<p>Lorem Ipsum</p>
<p>Lorem Ipsum</p>
<p>Lorem Ipsum <span>Test</span></p>
</div>
</div>
</body>
The browser starts at the top and sees a body element. At this point,
it thinks it's empty. It hasn't evaluated anything else. The browser
will determine what the computed styles are and apply them to the
element. What is the font, the color, the line height? After it
figures this out, it paints it to the screen.
Next, it sees a div element with an ID of content. Again, at this
point, it thinks it's empty. It hasn't evaluated anything else. The
browser figures out the styles and then the div gets painted. The
browser will determine if it needs to repaint the body—did the element
get wider or taller? (I suspect there are other considerations but
width and height changes are the most common effects child elements
have on their parents.)
This process continues on until it reaches the end of the document.
CSS gets evaluated from right to left.
To determine whether a CSS rule applies to a particular element, it
starts from the right of the rule and works it's way left.
If you have a rule like body div#content p { color: #003366; } then
for every element—as it gets rendered to the page—it'll first ask if
it's a paragraph element. If it is, it'll work its way up the DOM and
ask if it's a div with an ID of content. If it finds what it's looking
for, it'll continue its way up the DOM until it reaches the body.
By working right to left, the browser can determine whether a rule
applies to this particular element that it is trying to paint to the
viewport much faster. To determine which rule is more or less
performant, you need to figure out how many nodes need to be evaluated
to determine whether a style can be applied to an element.
So why was the stylesheet content not applied progressively (green first, then red)?
I think the answer is that external stylesheets are parsed as they are downloaded, but not applied until the entire stylesheet has been parsed. Surely, in parsing a stylesheet, the browser optimizes away unnecessary and redundant CSS rules.
I don't have any proof to back that up right now, but that explanation sounds reasonable to me and agrees with what you're seeing, both with external and inline styles.
The first and most important thing to understand is that browsers cannot begin painting a page until all CSS is downloaded. (Keep in mind, the W3C spec says that CSS links are only allowed in the head, so when you start linking to stylesheets in the body tag as you did, different browsers will handle this situation differently.)
Now, a web page is read as a stream, and CSS rules are applied to HTML elements as they get fed into the page. To quote the Google article linked below:
As the browser parses HTML, it constructs an internal document tree representing all the elements to be displayed. It then matches elements to styles specified in various stylesheets, according to the standard CSS cascade, inheritance, and ordering rules.
So to now address your questions:
Does it apply each rule one-by-one as it parses the stylesheet and render the result progressively? Or, are the CSS file's contents completely downloaded, then fully evaluated, and then applied to the HTML all at once? Or something else?
Downloads all CSS, then begins painting the document from the top-down.
Testing in Firefox 5, I expected to see green at first, then turn to red. It didn't happen. I tried with two separate stylesheets with conflicting rules and got the same results.
This is because the CSS is all downloaded first, then when it encountered your element it only applied the red style, because of how the cascade works.
After many combinations, the only way I got it to work was an inline <style> block in the <head>, with the conflicting rules coming from a <link> in the <body>
While I cannot say exactly why this happened, I imagine the browser did not look for CSS in the body tag, began painting, encountered the body CSS, then repainted.
Are repaints affected in any way by the CSS?
I would honestly be more worried about JS caused repaints. But if you have a very large DOM, it makes sense to structure your CSS in such a way that you are not causing reflows due to odd positioning. #Matt gave you some good links covering that issue
Some good resources:
http://www.dayofjs.com/videos/22158462/web-browsers_alex-russel
Alex Russell goes into great detail about 36 minutes in about how webkit parses CSS, how reflows and repaints work, and what triggers them.
http://code.google.com/speed/page-speed/docs/rendering.html
This is a basic article on how to optimize CSS rendering
I am not sure about the marked answer. I doubt it's correctness.
As per this link from Google Developers the browser first downloads the HTML file and when it sees a CSS file linked to external resource it starts downloading the CSS file while it simultaneously creates the DOM structure for the given HTML file as CSS is not going to affect the DOM. Note that it doesn't apply any styles to the document when the browser is downloading the CSS file.
After downloading the CSS file (assume there is no script files) and if the DOM construction is complete, the browser starts mapping the CSS properties to those nodes in the DOM tree. After this it creates another tree called Render tree which builds all the objects which should be displayed, as rectangle boxes. Only after completing the render tree it starts painting on to the screen.
To summarize:
The browser downloads the CSS file completely.
The browser doesn't apply any styles to the page when it is downloading. Only after the donwload is complete it starts mapping the rules.
The rules are applied only during the render tree construction stage.
Downloading the CSS file doesn't block HTML download. You have to note that the browser
First downloads all the html files and then style and script files are downloaded.
You can use the chrome's Developer console to check these. Use the timeline tab to see all this.
A sample of the timeline image is shown here. The link i posted at the beginning of this answer explains everything.
I have a website that allows a user to create blog posts. There are some backlisted tags but most standard HTML tags are acceptable.
However, I'm having issues with how the pages get displayed.
I keep the HTML wrapped in its own div.
I would ultimately like to keep the HTML from the user separate from the main sites stylesheets so it can avoid inheriting styles and screwing up the layout of the originating site where the HTML is being displayed.
So in the end, is there anything I can apply to a div so its contents are quarantined from the rest of the site?
Thanks!
You could use a reset stylesheet to reset the properties for that specific DIV and it’s children. And on the other side, you’ll probably need a CSS parser to adjust the user’s stylesheet for that specific DIV.
You can do it in a frame or an iframe. That will keep it separate in every way.
Could you format each user-generated content with a div of class 'username' in addition to any other classnames you may add automatically?
Then they -I assume 'they'- can format and style as they please, can have all their styles prefaced like so: div.username selector.
Otherwise, you may be able to use iframes.
You could use an iframe to keep them completely separate if you really wanted to be extreme about it.
Or, you could restrict them to only writing inline styles so that they can't affect your page's stylesheet:
1) strip out any style tags html the user creates. This way they can't override your styles.
2) validate their code and either fix or reject things like unclosed tags or elements that shouldn't be inside a div (like head or body tags) and make sure it all gets closed properly so it can't mess up any html from your page after the div it's contained in.