I have a website created by a designer entirely in a table format. I am embedding another table within its cell, the thing is my table has its own stylesheet. When I link mine externally, the entire site get warped. All I want is my Stylesheet to work on my table.
How do I include this stylesheet without causing a conflict or override on the entire site?
If there's no better option, then give your table an id or specific class. Then use this in all your CSS declarations, ensuring the styles within will apply to only your new table. This article explains the idea of pseudo-namespacing further, which is worth considering.
So instead of:
td { border: 1px solid black; }
You would have, e.g.:
.myClass td { border: 1px solid black; }
There are two kinds of things to take care of: 1) preventing your style sheet from affecting the table used for formatting the entire table, and 2) preventing the formatting of that table from affecting your table. Your style sheet must be modified for this.
Start from assigning a unique id to your table and then using the corresponding selector in all rules of your stylesheet (see Rob W’s answer). This suffices for 1). It mostly suffices for 2), too, but not always. You should test it and have a look at the overall style sheet. There is no quick way here.
To illustrate the problematic point, suppose that you want your table to have borders around cells. For this you could have table#foo td { border: solid; }. But if the overall style sheet has td { border: none !important; }. That’s not good practice, but such things are used; authors often use !important for no good reason. In this case, if the overall style sheet cannot be changed, you would need to use !important in your style sheet, too. In extreme cases, you might even need to use !important and write selectors so that they are more specific.
Related
I am using a stylesheet in my code to stylize proprietary widgets, therefore I don't have access to alter the base stylesheet (nor is that really good practice anyway). One of the styles is causing problems in my application and I determined that the margin: 0 property needs to be removed entirely from this CSS rule:
.esriBasemapGallerySelectedNode .esriBasemapGalleryThumbnail {
border: 2px solid #F99;
margin: 0;
}
Is there a way to do this? Since I cannot view the stylesheet in a formatted way, I cannot get the index of this rule. The styles aren't in-line so I don't think I can use the .css() method. If I can't remove it, the only alternative I can think of is setting it to 1px (which I tested and it removed the problem that's occurring) but I'm not a big fan of that solution.
You will need to expand the specificity of your element if you do not wish to override css rules. The easiest way to do this is to add an id on an element and then write a css rule for that element using the id instead of the classes.
Read more here:
https://css-tricks.com/specifics-on-css-specificity/
I know that in a stylesheet div#name and #name do the same thing. Personally I've taken to using div#name for most styling I do, with the reasoning that it's slightly faster, and means that I can identify HTML elements more easily by looking at the CSS.
However all of the big websites I seem to look at use #name over div#name (stack overflow included)
In fact I'm finding it very difficult to find many websites at all that use div#name over #name
Is there some advantage to doing #name that I'm missing? Are there any reasons to use it over div#name that I don't yet know about?
Since the div part of div#name is not required (because ID are unique per page), it makes for smaller CSS files to remove it. Smaller CSS files means faster HTTP requests and page load times.
And as NickC pointed out, lack of div allows one to change the HTML tag of the element without breaking the style rule.
Since ID's have to be unique on the page, most ID's you'd run into would only ever appear once in your style sheet, so it makes sense not to bother including what element it would appear on. Excluding it also saves a few characters in your style sheet, which for large sites which get visited millions and millions of times a day, saves quite a bit of bandwidth.
There is an advantage to including the element name in the case where a division with ID "name" might appear differently than a span with ID "name" (where it would show a division on one type of page and a span on another type of page). This is pretty rare though, and I've never personally run across a site that has done this. Usually they just use different ID's for them.
It's true that including the element name is faster, but the speed difference between including it and excluding it on an ID selector is very, very small. Much smaller than the bandwidth that the site is saving by excluding it.
a matter of code maintainability and readability.
when declaring element#foo the code-style becomes rigid - if one desires to change the document's structure, or replace element types, one would have to change the stylesheets as well.
if declaring #foo we'll better conform to the 'separation of concerns' and 'KISS' principals.
another important issue is the CSS files get minified by a couple of characters, that may build up to many of characters on large stylesheets.
Since an id like #name should be unique to the page, there is no reason per se to put the element with it. However, div#name will have a higher precedence, which may (or may not) be desired. See this fiddle where the following #name does not override the css of div#name.
I would guess that including the element name in your id selector would actually be slower – browsers typically hash elements with id attributes for quicker element look up. Adding in the element name would add an extra step that could potentially slow it down.
One reason you might want to use element name with id is if you need to create a stronger selector. For example you have a base stylesheet with:
#titlebar {
background-color: #fafafa;
}
But, on a few pages, you include another stylesheet with some styles that are unique to those pages. If you wanted to override the style in the base stylesheet, you could beef up your selector:
div#titlebar {
background-color: #ffff00;
}
This selector is more specific (has a higher specificity), so it will overwrite the base style.
Another reason you would want to use element name with id would be if different pages use a different element for the same id. Eg, using a span instead of a link when there is no appropriate link:
a#productId {
color: #0000ff;
}
span#productId {
color: #cccccc;
}
Using #name only:
Well the first obvious advantage would be that a person editing the HTML (template or whatever) wouldn't break CSS without knowing it by changing an element.
With all of the new HTML5 elements, element names have become a lot more interchangeable for the purpose of semantics alone (for example, changing a <div> to be a more semantic <header> or <section>).
Using div#name:
You said "with the reasoning that it's slightly faster". Without some hard facts from the rendering engine developers themselves, I would hesitate to even make this assumption.
First of all, the engine is likely to store a hash table of elements by ID. That would mean that creating a more specific identifier is not likely to have any speed increase.
Second, and more importantly, such implementation details are going to vary browser to browser and could change at any time, so even if you had hard data, you probably shouldn't let it factor into your development.
I use the div#name because the code is more readable in the CSS file.
I also structure my CSS like this:
ul
{
margin: 0;
padding: 0;
}
ul.Home
{
padding: 10px 0;
}
ul#Nav
{
padding: 0 10px;
}
So I'm starting generic and then becoming more specific later on.
It just makes sense to me.
Linking div name: http://jsfiddle.net/wWUU7/1/
CSS:
<style>
div[name=DIVNAME]{
color:green;
cursor:default;
font-weight:bold;
}
div[name=DIVNAME]:hover{
color:blue;
cursor:default;
font-weight:bold;
}
</style>
HTML:
<div name="DIVNAME">Hover This!</div>
List of Css selectors:
http://www.w3schools.com/cssref/css_selectors.asp
I found this CSS minifier (http://www.lotterypost.com/css-compress.aspx). There is a section at the bottom of that page labelled "What does the CSS Compressor purposely NOT do?" There are four things, two of which I couldn't understand why they might be destructive:
Combining individual margin, padding, or border styles into a single property.
margin-top: 10px;
margin-right: 0;
margin-bottom: 8px;
margin-left: 30px;
Becomes
margin: 10px 0 8px 30px;
And combining styles for the same element that are specified in different style blocks.
#element {
margin: 0;
}
#element {
color: #000000;
}
Becomes
#element {
margin: 0;
color: #000000;
}
I think CSSTidy does both of these. Is the web page above correct? Are there situations where these types of minification might be a problem?
I'm the developer of the CSS Compressor that is the subject of this question (http://www.lotterypost.com/css-compress.aspx), so I'll elaborate with an example of how a compressor can break the CSS cascade if a tool aggressively re-writes it.
There are many ways of targeting elements in a style sheet, and because a CSS compressor does not have intimate knowledge of the page’s DOM structure, classes, ids, etc., there is no way for a compressor to know if an optimization that crosses bracketed definitions will break or not.
For example, a simple HTML structure:
<div class="normal centered">
<p>Hello world.</p>
</div>
And some CSS:
div.normal p {
margin: 10px 0 10px 0;
}
div.centered p {
margin: 10px auto;
}
div.normal p {
margin-bottom: 5px;
}
The uncompressed code would produce a centered paragraph with a 10px top margin and a 5px bottom margin.
If you run the CSS styles through the CSS Compressor, you'll get the following code, which maintains the order and cascade of the original uncompressed styles.
div.normal p{margin:10px 0}div.centered p{margin:10px auto}div.normal p{margin-bottom:5px}
Let's say you want to aggressively compress the styles further, by combining the margins of the two div.normal p definitions. They both have the exact same selector, and they appear to redundantly style the bottom margin.
There would be two ways to combine the margins: you can either combine the two margin definitions into the first (top) div.normal p style or combine them into the last (bottom) one. Let's try both ways.
If you combine the margins into the first (top) div.normal p style, you get this:
div.normal p{margin:10px 0 5px}div.centered p{margin:10px auto}
The result of combining the margins that way would result in the bottom margin being incorrectly set to 10px, because the "centered" class would override the bottom margin (because the "centered" style defintion now appears later in the cascade).
If you combine the margins into the last (bottom) div.normal p style, you get this:
div.centered p{margin:10px auto}div.normal p{margin:10px 0 5px}
The result of combining the margins that way would result in the paragraph no longer appearing as centered, because the bottom "p" definition would override the left and right margins of "auto" that are defined in the "centered" class.
So we can see that by combining style definitions that even have the exact same selector can cause some pretty bad problems.
Would you personally ever write code like this? Maybe or maybe not. Because of the various "weight" rules of the cascade, it is possible to fall into this type of code trap without ever realizing it.
Furthermore, given the fact that in today's Web pages, multiple CSS files are often combined into one file to hit the server with fewer downloads, it is easy to imagine the CSS Compressor royally screwing up the cascade by re-writing multiple style sheets (possibly written by different people) that are appended together into one file.
In fact, I wrote the CSS Compressor for this very scenario on my Web site, Lottery Post. Each Web page has many style sheets supporting various jQuery and other components, and the CSS Compressor is used to automatically compress all of those style sheets into one single download. All pages on the site have at least 10 different style sheets combined together, and most pages have more than that.
For example, if you look at the code behind the CSS Compressor page itself, you will find the main style sheet in the head that looks like this:
<link rel="stylesheet" href="http://lp.vg/css/d11019.0/j2HKnp0oKDOVoos8SA3Bpy3UHd7cAuftiXRBTKCt95r9plCnvTtBMU2BY2PoOQDEUlKCgDn83h16Tv4jbcCeZ(gupKbOQ9ko(TcspLAluwgBqrAjEhOyXvkhqHA(h5WFDypZDK2TIr(xEXVZtX7UANdFp6n1xfnxqIMR8awqGE)vrwUgY2hrCGNNTt1xV7R1LtCSfF46qdH1YQr2iA38r1SQjAgHze(9" />
The gobbledeegook in the URL is actually an encrypted string containing all the style sheets to combine on the server. The server compresses them and caches the result.
The space- and time-saving techniques on that one style sheet call include:
Combining many style sheets into one file/download by simply appending them all together
Compressing the combined style sheet using the CSS Compressor (without messing up the cascade!)
Using a different domain name (lp.vg) for the style sheet download, which improves the browser's ability to download in parallel
Using a very short domain name (lp.vg)
GZip compression is applied to the style sheet on the Web server
The version number of the style sheet is embedded into the URL (".../d11019.0/...") so that if any style is changed in any of the multiple style sheets, I can change the version number and the browser will never use the version it has cached. (Note that the version number should be part of the URL path, not in the query string, because some proxy servers do not look at the query string to determine if a page should be retrieved from cache.)
I hope this better explains things and is helpful to those looking to improve page performance!
-Todd
MORE INFO:
To add to the above, imagine if we take your color example, and combine style definitions with the same selectors.
Here are some uncompressed styles:
div.normal p {
margin: 10px 0 10px 0;
}
div.centered p {
margin: 10px auto;
color: blue;
}
div.normal p {
color: black;
}
The CSS Compressor produces the following output:
div.normal p{margin:10px 0}div.centered p{margin:10px auto;color:blue}div.normal p{color:#000}
If we were to apply aggressive combining of style definitions that have the same selector, we will get the following code.
Method 1, combining both into the first definition, would incorrectly make the text color blue:
div.normal p{margin:10px 0;color:#000}div.centered p{margin:10px auto;color:blue}
Method 2, combining both into the second definition, would incorrectly make the text left-aligned:
div.centered p{margin:10px auto;color:blue}div.normal p{margin:10px 0;color:#000}
The only time combining style definitions with the same selector is 100% error-free is when the definitions appear directly one after the other, but in every other case this technique risks corrupting the cascade of styles.
I couldn't imagine a case where any developer would write code in this manner (two style definitions with the exact same selector, one immediately after the other), so I concluded that the amount of effort required to code it, and the possibility of an additional point of failure in the compressor, was not worth it by a long-shot.
Frankly, I would be very concerned about a CSS compressor that combined styles from different definition blocks, because the cascade is a very fragile thing, and it is extremely easy to break the cascade.
The page has a section on 'reason not used' that describes why it doesn't do these two things.
And on top of that, I would assume it's not trying to do these things because it isn't a complete CSS parser/interpreter, and would start to bork stuff like CSS conditional blocks.
By 'destructive' I presume you mean 'the CSS does not work as expected'.
Combining long-hand rules such as your first example can be done without any ill effects at all.
In a plain old stylesheet with no media blocks or other fancy stuff, the second example will also not cause any problem.
The reason #2 is risky is because changing the order of rules, or folding rules together without taking the Cascade into account, can result in breakages.
Some CSS compressors can reorder rules alphabetically, or by selector type. These are very risky because moving rules around may break cascaded behavour the author created.
Minifiers like the YUI compressor don't do any of these, opting for safer strategies like removing whitespace, redundant semi-colons and zeros, and the like.
With more CSS containing media blocks and other CSS3 code it is likely that many of the current CSS compressors won't work correctly at all. Most do not have a proper lexer for parsing the code - they use context aware byte-by-byte (Tidy) or regexs (most of the rest) to process the code.
When selecting a compressor I would suggest finding something that will do it locally and is backed with good test suite so you can see what case are (and are not) handled correctly.
Is there a way to make an entire CSS Style sheet take precedence over another? I know you can do the !important but can I do that with one line rather than modify all thousand properties on the sheet?
Thanks!
Make sure the stylesheet you want is called last (or a specific style you want is called last). For example, using this:
span { color: red; }
span { color: blue; }
...will turn all text in <span>'s blue. Take a look here.
Rules with identical specificity that come later will overrule previous ones, so if both style sheets contain the identical selectors, you should be able to do this by just loading the one before the other.
If they contain different selectors, like
#navigation h3 { color: red }
and
.mainpage .navmenu h3 { color: blue }
you are likely to get specificity conflicts. The only blanket solution for that is indeed !important (although that is really, really terrible architecturally. Are you sure you need this? Maybe explain why, it's possible somebody is able to come up with a better solution.)
There is, however, no single-line directive to elevate the "importance" of one style sheet over the other.
We're using a template for joomla where creators defined the rule in constant.css
table
{
border-collapse:collapse;
border:0px;
width:100%;
}
When I need my own table with a custom params (width, border and so on), a nightmare begins. If I use general html params, they don't work since css rules are more important (CMIIW). If I use style= param, I suppose I can't control how the table looks for IE up to 7 inclusive.
So is there a general approach to work around this or I just need to comment the rule (as I already did).
And also, am I right if I say that creators of joomla templates should not define such general rules as width:100% by default? I mean if they don't want users of their template to complain.
Method 1
Put a class on all tables that you create, and create a selector like table.classname that overrides the properties. Since you should only use tables for tabular data, adding a class name makes sense because it's easier to apply additional styles (colours, borders) to all your tables.
To override border-collapse: collapse, use border-collapse: separate along with border-spacing: 4px (or whatever value). This doesn't work in IE6 and may not work in IE7 either.
For a border round the table just add a border rule. If you want borders on individual cells, target table.classname td and put the border rule there.
To reset the width, use width: auto or put an explicit width.
Method 2
An alternate method would be to find all the tables used in the template, add a class to them instead, and change the original rule to use that class. Then, any tables without that class will use the default table properties.
This is probably going to be quite difficult to implement because Joomla templates often have module and component overrides, meaning there will be many tables in many places. Good luck! :p
You're correct, setting those styles (well, width at least) on a generic table element is a bad idea for a template. Although the fact they're probably using tables for layout isn't a good sign anyway.
table{
border-collapse:collapse;
border:0px;
width:100%;
}
The following should override the above css rule:
.classofyourtable
{
width:50%;
}
#idofyourtable
{
border:1px;
width:20px;
}
Please note also of the following CSS cascading precedence(1 being the highest):
inline
ids
class
tagname
Rules with less precedence will be overriden by the higher ones.
Applying the style to a class or id both override the style in the general tag style.
There's a number of ways to do it. As Marius says, a class or ID will help.
Lets say you put an id on the body element (<body id="foo">), then you could override the built-in table style using
#foo table {
width: auto;
}
Or if you only want to restyle certain tables, try using a class (<table class="foo">):
table.foo {
width: 25em;
}
But yeah, why not just edit the template's CSS to do what you want?
Apply another rule below the existing one:
table
{
background-color: Navy;
width: 100%;
}
/* override existing rule: */
table
{
width: 960px;
}
When a CSS rule is specified twice, the browser will use the last one.
And yes, you are correct--The proper way for Joomla go about this is to implement namespacing using classes. Overriding default CSS rules is bad practice.