Lately I'm using a CSS structure that makes HTML much cleaner but I don't know if there's something wrong with this.
Instead of using:
.top { //properties }
.top-wrapper { //properties }
.top-logo { //properties }
And for HTML:
<div class="top">
<div class="top-wrapper">
Logo
</div>
</div>
I'm actually coding like this:
.top { //properties }
.top .wrapper { //properties }
.top .wrapper .logo { //properties }
And for HTML:
<div class="top">
<div class="wrapper">
Logo
</div>
</div>
Is it wrong to do this?
It is not wrong, but the more selectors you have, the higher the resulting specifity of your style. For more information about specifity see http://www.w3.org/TR/CSS21/cascade.html#specificity.
Imagine your example
.top .wrapper .logo { font-size: 10px; }
followed by this:
.logo { font-size: 20px; }
The <a class="logo"> will have a font-size of 10px, even though you specified it to be 20px for the second declaration.
It isn't necessarily "wrong" to do this, it works and if you find it easy to use I'd say go for it!
However - there are some drawbacks to this approach, for example your CSS file will end up larger, which will mean longer download times for anybody viewing the website (granted this effect may be negligible)
There's also the issue that, if you want to re-use the styles of top-wrapper on another element, you have to place that element inside a div with a top class, this ends up cluttering your HTML.
(For more information on the above point see OOCSS)
At the end of the day there are benefits and drawbacks to any approach, if you feel really comfortable with this approach, and it is working for you - then stick with it!
EDIT:
It should also be noted that you're second approach will take longer for the browser to render than you're first approach (the browser has to check multiple conditions instead of just one) for more info see this question
Nope.
What your second code is doing is saying, "target all the elements inside elements that have class top, that have the class wrapper and apply such and such properties"
On the other hand, your first code is only targeting the elements that have the class top-wrapper (or whatever) regardless of their parents class.
Depends how you will use that specified class
.logo { //general properties }
.top .wrapper .logo { //specific propery to top wrapper properties that overrides .logo }
.bottom .wrapper .logo { //specific property to bottom wrapper that overrides .logo }
HTML
<div class="top">
<div class="wrapper>
Logo
</div>
</div>
<div class="bottom">
<div class="wrapper>
Logo
</div>
</div>
Generally, it is better
It's not wrong, but it may get verbose and a little slower if you are have 10 levels of nesting. The result may also be harder to debug if both .logo and .wrapper .logo are styled.
On the other hand it may be nice to have a .button looking different in .content or in .menu. In general, use what makes sense in a specific use case.
No right and wrong here: everything depends on the site you are building, if you are in a team and what makes sense to you.
Personally I don't think the html is any cleaner now than it was previously (in this small example) but your CSS specificity has increased and that could have a detrimental knock on effect.
I now ask myself 'why do I want this element styled in this way?'. Sometimes it's because of inheritance, sometimes because it's a specific case that happens to be in a certain area. The example you use seem a good candidate for inheritance, but looking at the rest of the site might lead to a different conclusion.
Adding longer class names doesn't, to my knowledge, greatly decrease performance. I suspect the only effect would be marginal and is unlikely to be noticeable. Really dependant on the implementation
Additionally if you were 'reading' the html it may make more sense to read have class names like top-logo, other wise you need to look for the appropriate ancestor (bearing in mind there may be more than one that could be applicable).
I'm busy moving toward an OOCSS / BEM method (google these for more, so many resources out there...) myself because I believe it will make maintenance easier in the future, plus I find it makes more sense within a team environment. These are approaches that could lead to 'classitis' or otherwise 'messy' html. I don't mind that though and think the larger the site the more sense this makes. If you're making a 4 page site, maybe don't bother.
But this works for me and may not for you. So I go back to my original statement, there's no right or wrong here :)
Related
What's the best style, for styling 'main' header (or footer) in CSS?
I've styled just like:
header { ... }
but then I remembered, that there can be more than 1 header in html...
So I rewrote:
body > header { ... }
But it's rather not beautiful. To write in several places smth like body > header .search { ... }
2.nd possibility:
<header class="main-header">
But it's also not very beautiful.
Of course, it's possible just to ignore, that there can be several headers (footers). But I markup html/css not for myself, so it's possible, that smb will add new header/footer elements in html.
So, what is the best style? That is used in great companies like Google, StackOverflow, Microsoft, IBM and so on.
Hey! I've an idea! What's about to write for main header/footer simple header { ... } and for special headers/footers smth like .some-element header { ... }? Now it's obvious for me, that it's the best style. Am I right?
Have you heard about BEM? Which stands for block element modifier, that help you achieve a reusable component. I think you should use that, it will make your code as if style and a document ready.
more here
This is really about what do you prefer. I think the most simple and easy to read way could be the attribute selector.
header[main] {/*something*/}
Plus this:
<header main>Main header</header>
It’s important that we’re all focusing on the performance improvements that our users will really notice. So it is not about how beautiful it is rather than an optimized one.
For CSS, there are several things that we have to consider. In case of selectors, we have to focus on how CSSOM would construct (You can learn more from here, a course provided by team Udacity).
For a matter of performance, use classes instead of tags. Also, usage of two or more rules(like div>p>span) will cause more time to render the page.
I would suggest like as below, assuming you are using html5. keep as simple as possible instead to make it complicated. Also keep second level hierarchy as possible to read a code and faster css processing.
header{
/* enter your css properties */
}
header p{
}
footer{
/* enter your css properties */
}
You can simply write css code to write like this
header { }
or if you have many header on the dom then select the first child of the header:first-child {}
or you can write header:nth-child(1) {}
Hope it was help you
Thanks
SO I have a problem with OOCSS. It is supposed to be more portable but compared to how I usually do things, I'm finding it less so.
My example:
I have a widget testimonial. In the main content body (which has a white background) the testimonial has a black font. But in the footer (which has a blue background) the testimonial needs a white font.
Before OOCSS, I would do something like this:
#main-content .testominial {
color: #000000;
}
#footer .testominial {
color: #FFFFFF;
}
With this "old" approach, I could drag my widget from the content area to the footer and the colours would simply work - I wouldn't need to change my CSS or DOM classes of the widget.
With the new OOCSS/BEM, I am NOT supposed to couple the .testimonial class to the ID (or to the location), but rather I should subclass it like so:
.testominial {
color: #000000;
}
.testominial--footer {
color: #FFFFFF;
}
The problem with this is that I can no longer drag my testimonial from the content area to the footer without going into the DOM and changing the classes on the testimonial widget - It is LESS portable as it requires manual intervention by a developer; whereas before an editor could just drag it and the styling was automatic.
Am I missing something? There seems to be no solid real-world examples out there?
You need to consider dropping the testimonial naming as well as the footer.
Consider this example:
.primary-box { }
.primary-box--reduced { }
.primary-box--standout { }
In the example the classes are completely independent of their page context. The result is that the classes are completely re-usable. Any box on the page can take the classes above and expect to be styled exactly as defined.
For example, you could have:
<header>
<div class='primary-box primary-box--reduced'></div>
</header>
<div class='content-box'>
<p class='primary-box primary-box--standout'></p>
</div>
<footer>
<div class='primary-box primary-box--reduced'></div>
</footer>
Now when the designer comes back and tweaks the padding of the standout boxes you can go directly to those styles and tweak them, confident that the only areas that will be effected will be the areas that have those classes in the HTML.
Also, when you decide to move .primary-box--reduced from the <header> into the menu bar that sits above it, or into the footer, you can be confident that the styles will come along, completely.
When you need another element somewhere, perhaps a primary-box--standout, or just a default primary-box in the header, you just create it and add the classes, they styles will follow completely.
You'll never inherit unexpected styles either.
This is very much a real world example, a site I built recently was almost all built like this, I say almost all because I'm still learning, but I can guarantee the bits I had the least trouble with on a fast-moving project with very fluid designs were the ones with non-specific context.
What's important is the lack of context. In the first example, .testimonial--footer is very context dependent, you really need to use it on testimonials in the footer only.
And as if by magic CSS Wizardry cover this exact topic
EDIT: I added this example to help with a comment made on my answer. This isn't BEM, or OOCSS, though it is a bit closer to the SMACSS approach. It's how I tackle problems with css and is a hybrid BEM / SMACSS approach:
Loaded in order:
module files, such as .primary-box
page section files, such as .header or .call-to-action
page files, such as .about-us or .contact
Each file gets more and more specific, while simultaneously building more complex and modules. Building on the examples above and hopefully helping the OP, you could see styles like:
.header {
.primary-box {
color: #000;
}
}
which would over-ride the module styles using a more specific nested class notation. Please note, I would still avoid using a class name like .header - .banner-standout would be better as it's re-usable anywhere without confusion
Next, you could even see:
.about-us {
.header {
.primary-box {
color: #f00;
}
}
}
I find this works very well in real projects for context while retaining the context free power of BEM, though I would also urge as much as possible to push up this chain into the modules. Life is easier if I recognise a new generic page section or module and re-organise the naming and files appropriately. In a project where the code has been refactored with care I have nothing in page files.
With this "old" approach I could drag my widget from the content area to the footer and the colours would simply work - I wouldn't need to change my CSS or DOM classes of the widget.
If you "drag" the element .testominial from the container .main-content to the container .main-footer, that is you change the DOM. So you can also update the modifier in the CSS classes, there is no additional cost.
The purpose of BEM is to make CSS classes reusable. The following modifiers can be reused in various environments.
CSS:
.testominial {
}
.testominial--darkFg {
color: #000;
}
.testominial--lightFg {
color: #FFF;
}
HTML:
<main class="main-content">
<div class="testominial testominial--darkFg">...</div>
</main>
<footer class="main-footer">
<div class="testominial testominial--lightFg">...</div>
</footer>
With the old approach, you'll have to change the CSS code each time you need a new block .testominial in a new container. HTML and CSS are strongly coupled, and some CSS code will be duplicated.
With the BEM approach, you'll have to add some CSS code each time the designer will add a new variation of the block appearance. HTML and CSS are less coupled, and CSS is better reused.
I would like to know all the different types of div classes. I have a small amount of understanding of divs.
Here's an example of how I would use a div and then customise the content in the div using CSS.
div .header {
font-family: "Bebas";
font-size: 25;
font-color: #00FF00;
float: right;
position: relative;
right: 120px;
bottom: 1095px;
}
So, if you're not following my question(s), what I want to know is;
A. Does that code look alright?
B. How many div classes are there, and what are they called?
and C. Could someone give me a brief explanation as to what they are and more specifically, how to use them.
I'm mostly self-taught, in case you wondered.
To answer your question you can have as many div as you want. and you assign class or id to identify each div. just be aware id are unique, you can not assign the same id to more than one elements.
and your css format is right, but I am not sure why you declare right/bottom those will only render when your position is absolute with out float.
I would suggest you go through some tutorial at http://www.codecademy.com. it's free. and don't required any sign up, unless you want to save your progress.
As previously said, you can set as many div classes as you'd like, they're not preset. I would also recommend doing the Codecademy tutorials.
Looking at your code, you're telling the div to float: right; - fine. Then you use position: relative; followed by right: and bottom: values. Either float or position, no need to do both.
The way you've written the rule is probably not how you mean it. It's currently looking for this -
<div>
<div class="header">
<p>Content</p>
</div>
</div>
An element with the class header that's inside a div.
You should remove the space so your rule becomes -
div.header {
enter code here
}
Yes, the code you wrote looks fine. I don't know what you intended to do with this code, so going by just the syntax it looks fine.
Coming to your sub-question B and C,
div is block level element with almost no specific task or objective. They are general purpose elements used for most tasks. Block level elements act as containers and div is the most basic type of container we get.
We can use div to store other elements, design web document and proper indention of text and images and what not.
Let's answer your questions one by one:
A - Your code looks fine ( depending on your needs ).
B - You can use as many div classes as you like.
C - Simply you can use div classes to describe it's content like: div.header , div.body , div.footer and so on.
But i recommend to use the new HTML5 semantic tags instead, it is easy, clear and more powerful with search engine optimization.
For more clarification, kindly check the following link www.itibooks.com/html/html5-semantics .
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
It seems there are two major schools of thought on how to structure CSS and HTML. I was taught to keep the HTML as clean as possible, and all things stylistic should be on the stylesheet. This has served me well thus far, but with this approach I often notice redundancies and inefficiencies.
I read up on the atomic approach, and I really like the idea. It seems to be the method I naturally gravitate toward anyway.
My question:
Which way is really faster, considering the two following blocks of code:
HTML:
<div class="main">
<h1 class="m-10 theme-c1">header with margin and theme color 1</h1>
<p class="fz-1 theme-c1 m-10">paragraph with font-size 1em.</p>
<div class="m-10">
<p class="fz-1 m-10">blah</p>
<p class="sub-paragraph">Sub paragraph</p>
</div>
</div>
Stylesheet:
/*margin-left rule*/
.ml-10 {margin-left:
/*font-size rule*/
.fz-1 {font-size:1em}
/*theme color*/
.theme-c {color: #333};
/*display rule*/
.dps-blk {display: block}
/
/*sub paragraph styles*/
.sub-paragraph {
margin-left: 10px;
font-size: 1em;
font-color: #333;
}
Elements in the HTML above all get whatever style they need, and the styles above are non-descendants except for .sub-paragraph.
So is it faster for each element to cherry pick which styles it needs, or is it better to just give it a chunk of styles (like for .sub-paragraph)? With .sub-paragraph, I can see how it only takes one match to get all the styles. The trade off, however, is that there isn't much else you can do with that set of styles except use it on sub-paragraph, or override some of its properties with another rule when applied to something else.
I'm think with these two approaches, it's a decision on whether to the cost on data size or on processing time.
Edit
I appreciate all the feedback. I forgot to mention that I'm specifically interested in the processing speeds of the different approaches.
This is interesting nonetheless.
If you were to begin cherry picking individual styles, you would end up with a stylesheet like:
.red{ color: red; }
.green-background{ background: green; }
.w500{ width: 500; }
.ml20{ margin-left:20px; }
Which is not very maintainable.
It sounds like what you are looking for is a way to extend certain classes (i.e. .sub-paragraph) with pre-existing classes, adding the styles of other classes into .sub-paragraph. SASS's .extend directive is a great way of doing this.
Sass and other preprocessors are great at merging the ideas of maintainable code and semantic code together.
Edit 1:
If you are looking into which method (more classes/less properties or less classes/more properties) is faster, I would suggest doing some testing with Chrome Dev Tools' Timeline. The two methods of coding aren't the only thing that are going to affect how fast a page renders/paints, so it is always a good idea to test these if you are concerned about speed.
I organize my CSS by grouping certain types of classes together. When creating CSS classes I ask myself, am I going to reuse this class definition for anything else? Is it logical for me to separate this class' definition, will someone who has to read this after me want to shoot themselves?
Basically I would say, go for maintainability, an extra 1Kb on your Css will not choke anyone.
CSS is designed to use classes for certain groups of styles. The .sub-paragraph method is usually way better than the seperate classes method. If you are going to assign classes for each style seperately, you might as well just use inline styles, via the style attribute. You should usually try to avoid that for maintenance reasons though.
I think there is a place for both.
I don't feel that the abstraction belongs at class names like .p1-gr-brdr, though.
If you're writing very tightly-composed, atomic HTML partial-templates (for things like AngularJS directives), then you'd likely get more mileage out of .title, .subtitle, .just, .content, where you can specify very specific output for those components.
Changing those components will be very simple and straightforward, as they're so compact and self-contained.
And if you find yourself in a position where you need to override one, to compose an inherited class, then you either have the option of composing a new class-name, which now might not be 100% semantic/generic (".big-green-subtitle"), but is still 100% self-contained for those moments where you want your special-cases to feel loved, too...
...or you can then specify behavior with a second-level selector.
If your .header has a padding, but you don't want your .update > .header > .subtitle to be subject to that padding-bottom, on mobile-phones, in landscape orientation, on Tuesdays, then you can simply have an exception which states .update > .header { padding-bottom : 0; }.
Otherwise the cascade will continue as normal, and things will either pile on top of one another, or you will cancel out side-effects with specialized classes which cover the same properties...
Otherwise, I don't see why all CSS sheets don't look like:
.p1-br { border-width : 1px; }
.p2-br { border-width : 2px; }
.p3-br { border-width : 3px; }
.p4-br { border-width : 4px; }
.gr-br { border-color : green; }
.lgtgr-br { border-color : lightgreen; }
.sfmgr-br { border-color : seafoamgreen; }
.aqmr-br { border-color : aquamarine; }
.em1-wd { width : 1em; }
.em2-wd { width : 2em; }
.em3-wd { width : 3em; }
.rm1-wd { width : 1rem; }
.pc1-wd { width : 1%; }
...et cetera, until you've written out every atomic option you could possibly want, for any theme your project (and all of its components) might want to support, across all platforms.
That seems like a terrible use of your day, to write a unique class-name for every possible edge-case out there:
<div class="pos-rel
p1-br
p18-ng-tp
mrpc12-br-r
lggr-bg
bg-im-spr-id-123
pc15-bg-im-algn-lf
ofl-x-hd
ofl-y-aut
brd-bx">
Seems hefty for a single div, for instance.
This would not, however, be a bad idea, if you could write CSS rules, give them to classes, where you expect flexibility, and later had the hard-numbers to those rules.
Such that, say, you write out a class which expects to treat height in rems, margins in percents, border-radius in ems, will take a background-colour and an image-sprite (say it's a backdrop container for a corporate/retail site, with a watermark and logo, where other content will scroll above it).
Now you want to reuse that set of classes on the same component, but for a different client...
It would help if you could simply have some variables, which could live in a separate file, and be referenced by your classes, so that your units don't necessarily need to change, but you can modify all of your hard-coding stuff in one or two places, and swap different variable values in for different clients as easily as pointing at a different sheet...
...but that's what SASS already does, if you take the time to sit down and figure out how you want to engineer something, and make your build process adhere to that desired outcome.
I have long wanted to be able to include one style class within another. For example
med-font {
font-size:12px;
}
#message a {
style: med-font;
color: blue;
...
}
/* lots of other styles, some of which use med-font */
Obviously this is a stripped down example, but the key point is that all those anchor tags within #message shouldn't need explicit classes or ids. For now I either duplicate the font-size in each class that needs it or add classes to things that wouldn't otherwise require it. And since I want to easily control the font-size from one place, I usually start adding classes.
Another solution is to split up the definition of "#message a" in this example (below). This works ok for small projects, but for larger projects this is actually my least favoured solution. It makes site maintenance very difficult if you have many classes split apart and scattered around large style files.
med-font, #message a {
font-size:12px;
}
#message a {
color: blue;
...
}
So my question is two parts: 1. Does this annoy other people? 2. Does anyone know if this feature is/was being considered for CSS3?
Edit: Adding example of html body and more details...
The main point is that adding a class attribute to the 20 anchors below to set their font size is tedious.
<div id="username" class="med-font">schickb</div>
<div id="message">
<div id="part1">
text
<!--lots more tags and say 6 anchors -->
</div>
<div id="part2">
text
<!--lots more tags and say 8 anchors -->
</div>
</div>
<div id="footer"> <!-- footer anchors should be a smaller font-size -->
lala
<p class="med-font">Company Name</p>
<!-- other tags and 3 more anchors -->
</div>
Remember, an important goal is to have one place where "med-font" is declared so that it is easy to adjust. In my actual project, there are small, medium, and large font styles. I only want one declaration for each so that I don't have to search through the css to say change 12px to 11px.
The best solution currently is to add the "med-font" class to all the anchors in the body, and the "small-font" class to all the anchors in the footer. But I'd much rather do what I showed originally, and simply include the desired font in the styles for "#message a" and "#footer a".
Summary: I want CSS to be more DRY
No, it does not annoy me, because you can use multiple classes for an element and BOTH will match:
.idiot {
color:pink;
text-decoration:underline;
}
.annoying {
font-weight:bold;
}
/* and if you want to get REALLY specific... */
.annoying.idiot {
background-image('ann.jpg');
}
...
<div class="annoying idiot">
Ann Coulter
</div>
Personally, I find this a much more versatile solution to the problem. For example, in jQuery (or in another framework), you can add and remove these classes -- most commonly, you'll add a "selected" class or something that might do something like highlight a table cell, and when someone clicks to toggle it off, you just remove the "selected" class. Uber-elegant IMO.
In response to your edits, all you would have to do to remove the CSS from all of your A links would be to do something like this:
#message > div > a {
font-size:12px;
}
#footer > a {
font-size:10px;
}
Where the > symbol means "is a child of"
or, more generally (but this would also match an A directly inside #message and anything deeper -- the space means "is any descendant of")
#message a {
font-size:12px;
}
#footer a {
font-size:10px;
}
This is exactly what the Compass framework is good at. Sass allows variables, which makes coding/maintaining stylesheets very easy and a pleasant experience.
Have a look at SASS, which might do what you want. It allows for nested CSS structures, which can then be converted to CSS. I think.
In my opinion, the fact that you can't do this is perfectly OK because your CSS should remain as straightfoward as possible. On of the greatest advantage of CSS, as mention in Micheal Kay's XSLT reference (yeah xstl... I know), is that CSS is very simple and incredibly easy to understand.
I don't have to look at multiple places to know the styling effects of putting a class on a tag (well maybe but still).
So for me it would be a no for number 1. And as for 2, it has been discussed and I don't think it will be part of the standard.
css is not a programming language, it was never meant to be and (at this stage) never will be. what you're talking about has been discussed plenty of times before in W3C and WHATWG
oh and to answer 1) it doesn't annoy me
No, It doesnt annoy me, IE6 annoys me :)
It would be a useful feature to have, especially in a css framework, however, are we not being encouraged to lump all our css into one file now for "optimisation". I havent heard any rumours about such a feature in css3, but there is still a way to go on that spec yet, so who knows, it could make it in if you make enough noise now!