I used to make redesign projects without using normalize css or any other form of reset. Therefore I got accustomed to editing all the margins and paddings myself. Now, I'm currently making an online portfolio for myself and included the normalize css(due to all the benefits I hear) but I noticed that the margins are slightly different. For example, when I did a redesign project, I'd always have a * {margin: 0; padding: 0;} to start my css and build from there. Now that I've included normalize, any given element wont start the same and gives off an odd margin at the top and its throwing me off, even if I include the * {margin:0; padding:0;}. So Im wondering, what are the potential pitfalls of not including the normalize css? Can I get away with using my usual technique and not using normalize css at all?
Following the web standards, allmost every element has a little default styling. Setting margin and padding to 0 for every element is expensive and really not necessary.
I created Initialize.css, a collection of best practices like normalize and made it configurable with scss (there is a css version as well). In this case, you could set your own margins to elements like paragraphs and headings.
http://jeroenoomsnl.github.io/initialize-css/
Related
I have been googling and doing some research since 3 days to figure out (or make) cross-browser, css normalization file but I am not very close to that.
I know that there is "normalize.css" but this isn't fully effective. For example, you gotta set margins for ul li elements or line-height for the website to make it cross-browser and these are not even set in normalize.css, so this isn't fully cross-browser. Also, another problem is checkboxes or radio buttons are not aligned with labels.
It would be perfect to have css file that normalize all the html tags, like bootstrap does. But bootstrap uses classes for normalization, which is not what I need. I need something like foundation, it normalize html tags with applying css on html tags. So, for your projects you can create your own mixin, helper classes which won't collide with framework's.
So, is there any normalization file like that? I don't wanna use any framework because they are unnecessarily heavy.
I got a lot of repeating CSS conditions (with only numerical differences) in my CSS file. I'm wondering how I can make it have less conditions?
ps. I know LESS or SASS can make it easier, but it will still generate the same amount of CSS in the end.
FIND CSS HERE
Any other feedback is also welcome!
There isn't really much you can do. In the end the browser will interpret the css as it is looking in your file.
You could do the following though:
1.Group selectors together. This may affect the readability and structure of your css.
.row div.gutter-lg-10,.row div.gutter-md-10 { padding-right: 10px; }
2.You can minify your css for production which will save you some bandwidth.
What you're doing is the absolute opposite of Good CSS(tm).
The point of having CSS next to HTML is the separation of semantics and presentation. This is achieved through anchoring CSS rules to generic markup so the HTML is not polluted by presentational concerns. This of course only works if you use generic classes and IDs that are relevant to semantics. So for example:
<p class="red-background-with-bold-font">This is extremely wrong</p>
<strong class="error">This is extremely right</strong>
The second example is good because it does not imply anything about presentation, and you might change it to italic green one day without breaking semantics, or touching HTML.
Now have a look at your CSS:
.row div.gutter-xs-60 { padding-right: 60px; }
div[class*="col-"][class*="-x-10"] { width: 10px; }
div[class*="col-"][class*="-p-35"] { width: 35%; }
What you're essentially doing here is making a huge-ass CSS monster to avoid having to use inline styles. There is however absolutely no added value in that, since the HTML is still hardcoded in the end: you cannot change the meaning of -x-10 to have a width of 20px one day without causing major obfuscation, meaning there was never separation of concerns to begin with.
So in the end - inline styles are not always wrong as is sometimes taught. If you are rendering some custom elements, just use them, it's what they're there for:
<div style="width:20px;padding-right:60px">This is far better and clearer...</div>
<div class="row-x-20 gutter-xs-60">...than this draconic invention</div>
And it renders a lot faster too, avoiding the hundreds of partial-classname selectors, and saves tons of bandwidth in mostly unused CSS.
I would like to add something. As I can see there many repeating styles in your CSS which can be generated by a javascript code using simple loops and conditions, this way you can achieve much smaller CSS file (just in case you want to save bandwidth).
You can see here how you can do that here : How to dynamically create CSS class in JavaScript and apply?
Ofcourse this may lead to a performance issue(because you will generate that script every time you load that page) but that will be negligible to notice. Give it a try :)
This can be one of ways of having "less conditions in you CSS file".
Just got a new webpage with css for a fancy box popup from the design team;
And they don't know or don't care to look for existing classes and ids;
I need a working solution without any IFRAME
The problem is that there are already over 20.000 css lines in the main css file, and at some point something will get overwritten and the entire website will do a big BANG!
This new webpage has very common class and id names, and I am talking about almost 100 tags with css properties;
I want to know if there is a method to encapsulate this new css properties and the future ones;
And if there is a way to do this, how can it be done?
With this webpage I got lucky, I pasted the tags with content and just before this, I used the style type"text/css' tag; But i will not always be lucky;
Just because we get webpages with css code written by different people, it does not seam fair to me to create new css classes if some of the properties or names or ids intersect with each other.
I now have about 10 classes for the a tag and im most part, the properties are the same;
Use targeted rules and let the cascade take care of it for you. Put your popup in a wrapper with as detailed of a name as you like.
<div id="myPopupDivWithCommonIds">
<!-- rest of popup -->
</div>
And target your css rules to that div.
#myPopupDivWithCommonIds .error { color: bright-pink; }
#myPopupDivWithCommonIds #main { width: 93.21%; }
Etc. etc. This takes care of the css rules and prevents your new stuff from overflowing. You will have to take care to make sure none of the other rules trickle down; the best way for that is to judiciously overwrite any properties that are defined (what Pekka said). You could also go nuclear on it and include a custom 'reboot' or 'bootstrap' stylesheet and again re-target all of its rules to your new popup div (like you said, it's difficult for 20k lines of css; but including another file with the resets rules targeted to your div by appending the #id selector as above helps a little).
Oh, and that still doesn't address the problem of repeated ids technically being invalid markup and very likely to interfere with any JavaScript you're trying to run on that page.
If this sounds like a mess, well, it is. Your developers and designers have got it to that point and short of a serious refactoring, you're not going to get back to a clean solution. An iFrame may seem like a hack or impossible for your use case, but it really would clean up a lot of your correctly foreseen problems.
In creating CSS styles one approach seems to be a fully qualified style such as
#pnlImage div.ipd-imageInfo div.ipd-tags span.ipd-tag
compared to a shorter definition such as
div.ipd-tags span.ipd-tag
which would uniquely identify the style as well. However, if the site is expanded or changed the 2nd style runs the risk of not uniquely identifying the element.
Is there a performance hit from fully qualifying a style, i.e., it is longer? Are there some guidelines/best practice references for style naming?
Thanks
Google (not a search, actually them) seems to think that it does cause a performance hit.
Also, the Mozilla foundation has an article "Writing Efficient CSS for use in the Mozilla UI" that outlines the possible performance pitfalls of CSS selectors in their browser(s), and how to optimize your style rules for their rendering engine. Their article has tons of examples of what's good and what's bad. Please keep in mind this is only relevant to their browsers, though.
There are also some benchmarks publicly available, about CSS selectors affect on rendering speeds:
http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/
http://blog.archive.jpsykes.com/153/more-css-performance-testing-pt-3/
I, however, think this is, for the most part, horse manure. You can effect FAR greater change on your page's loading/rendering speed by using some other simple optimizations. I believe that your sanity, and a well-organized code base should come first. If this were as big of a deal as some make it out to be, we'd all be back using HTML < 4 attributes (bgcolor=, border=, etc) to style our web pages.
Looking up an #id is fast.
Looking up a tag is a bit slower.
Looking up a .class is the slowest.
Starting your selectors with a faster lookup will reduce the number of lookups required for then next part. That is, if I wrote p.myClass, then the browser can very quickly find all the p tags and then it only has to loop through those to check for the class name.
That said, it would rate the maintainability of your CSS file higher than its rendering speed. Blah blah blah premature optimisation blah blah.
You might be interested in David Baron (Mozilla)'s Google Tech talk.
I have a site where another designer used heavily qualified styles and maintenance is a nightmare. (the qualified styles are only one part of that)
Basically, you can't touch or simplify the html structure without it breaking half the styles, and the styles often don't cascade properly to new content additions. If you add new css you in turn have to qualify your new rules heavily or half of them end up overridden by some existing rule because it contains so much specificity.
So from a maintenance standpoint it's not efficient. Also not efficient from a typing standpoint either.
I don't see how a theoretical answer is possible: the answer is implementation-dependent; so I suggest you profile it to be sure.
Is there a performance hit from fully qualifying a style, i.e., it is longer?
Yes, on every dynamic change of the DOM-tree, the CSS-expression has to be rematched against at least some nodes. I doubt this will lead to any noticeable delay, though.
Your stated objective (making the selectors robust against changes to the page structure) is not quite solid: hardcoding intricate details about the site structure into the CSS will just mean that you'll have more statements to maintain and update when the page structure changes.
If it's under your control, stick with simple classes (even if you have more of them) and as few levels as possible (doing some relative sizing of fonts is the only use case where I have used several levels, and even this was somewhat superfluous). It just wastes too cognitive capacity to keep track of the page structure in your head.
Although your question is about the performance, (and I would suggest, measure it..) I would really like to add that you should always try to use the shortest definition possible to identity the correct elements.
The reason is not the file size, but the ability to extend your site without altering the main css.
For example you've got this part in your html site:
<div id="Header">
<h1>Css example</h1>
<h2>Welcome to the css example site</h2>
<p>An example page by davy</p>
</div>
and this is the css:
#Header
{
background-color: #ffeedd;
padding: 1em;
}
#Heading h1
{
font-size: 3em;
color: #333;
}
#Heading h2
{
font-size: 1.5em;
color: #666;
}
#Heading p
{
margin: 0 0.5em 1.5em 1em;
font-size: 1.1em;
color: #999;
}
And later on you'd get to a page where you'd like your header to have a different background.
Had you chosen to use div#Header in you main css file, you'd either have to change the html (which depending on your system might mean creating a different template/masterpage) to add an extra class, or create a more qualified css selector such as body div#Header.
Using the shortest selector you could still use div#Header { background : ... } to change your header. You can either create an extra css file and load that into your header on that page (if allowed) or add a style definition directly to your <head> section. The nice thing about this is your css file does not grow with selectors for each different page, and you can keep clear of classitis.
You could also use it to switch the sizing method of your page (static/fluid) so that one template/masterpage uses the default css, and the other derives from that template/masterpage and just links a css called FluidWitdth90.css to change the template to 90% width fluid layout.
You're creating an HTML layout. Let's assume that you don't need the benefits of multiple stylesheets, that a small increase in HTML size is not a concern, and that you have a style which will only be used once. I'm often in favour of using an inline style here, as I view the repetition of your CSS class name or ID as the cost of an abstraction you don't currently need, and may not ever use.
Standard doctrine these days is to always create HTML layouts using semantic markup and CSS styles, so am I missing something here? Please let me know your thoughts.
Even if you only use a particular style once there are still benefits to keeping it with your other styles and not putting it inline. First, there is the separation of concerns that leads to improved maintainability. If you know you are going in to make only a style change, there is a single place to look for any changes. Another benefit is the self-documentation from having to type out the class name. By giving that style a name, even though it is used once, it makes the semantic code below more declarative -- you can read that not only is this random p a paragraph, it is also, say, the intro paragraph.
This is, of course, assuming that you are never going to use that particular style again. If you might than there is even more reason to factor it out into a named style. Inline styles aren't evil, but they are somewhat of a gateway drug.
Ideally your CSS should be "Object Oriented" (at least, as OO as CSS can be). You should "inherit" from classes that set common properties and create new classes when you define properties that could be used elsewhere.
Take a look at the OOCSS project which is trying to espouse these principles (or re-introduce them as it were).
To quote Welbog:
... It seems to me that "OOCSS" is just CSS that isn't written haphazardly. Much the same way you can write non-object-oriented designs in OO languages, you can easily mess up the fundamental ideals upon which CSS was created. OOCSS seems to be saying, "Let's not screw up anymore, guys."
One advantage of keeping the HTML and CSS separate is that you can re-skin the webpage without changing any of the HTML.
Steve
There are some situations in which I usually neglect creating a new class for a simple style change on a single element. It is usually pretty clear when you are doing it that there's a low-to-zero chance of you needing to apply that particular style to something else later down the road. The most common case for me is when I need something to have a particular padding/margin to be in the right place but it's not an element important enough to have its own ID.
This may not be a popular opinion here, but in those scenarios I don't think an inline style is evil.
Personally, I've found that I have an element or two and I would put an inline style in, go back and see that I need more than that element, so I'd change it to a class or forget about it and be not able to change it.
You could also try putting a certain div / page class, and write descendent styles for that in the stylesheet instead of inline elements.
Also, if you ever decide to add javascript, you won't already have a well-labeled class there and you'll need to change it.
Usually this isn't much problem with dynamically generated websites, but it can become a large problem when you go overboard and have tons of inline tags to switch out. It also can make it harder for people if they wish to disable styles for accessability etc-- you usually can overcome this by using a class.
Say, using <b style="color:red">bold</b> instead of body.products div b {color:red}.
I'm personally a fan of selectors, not using too many classes. They are more reusable, and you can edit the whole site in one place with the stylesheets.
But this is overkill <p style="font-weight:bold;font-size:1.2em; text-index:20px;">Indented Bold Paragraph</p> so it this <p class="indent bold larger">text</p> instead you can door ``<p><b></b></p>.
"A foolish consistency is the hobgoblin of little minds"
So, in this case is which is the foolish consistency? :) Why does DRY take precedence over the separation of markup and style?
Can you be sure that your CSS rule will only be used once? More over, how can you be sure that it won't need to be changed in the future, and how can you be sure that you would be the person needing to make the change? Are you sure you even need to add a class or id to target this unique element?
I guess I am having trouble seeing how adding
<input type="submit" style="border: 1px solid red;"/>
is some how "superior" to 12 or so more characters
<input type="submit" class="b-red">
.b-red {border: 1px solid red;}
or to a potentially equivalent character count
input {border:1px solid red;}
Of course there are situations where every rule of thumb can and should be violated. The question is, what do you gain from following DRY that outweighs the importance of following markup/style dichotomy?