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
Related
Today I was trying to create a dummy css rule for testing and investigation.
.dummy {
some-style : somevalue;
}
Ideally the class should have no visible effect. I want to be able to apply the class to elements but cause the least visible effect possible on any elements it is applied to. For example
<div class="dummy"> should look and behaves as much as possible like <div>
I did not want the class to be empty. Can anyone suggest a style that I could add to the class that would have the least visible impact when applied to a general html element? I can't think of anything completely harmless.
UPDATE: I wanted to add the style to some existing html. The reason was to use the style as a marker for diagnostic purposes. It would help me see when and where styles and stylesheets were getting loaded/cached and where and why some styles were getting overridden, sometimes by the browser defaults which seemed odd. At the time I didn't have exclusive use of the system I was working on so I wanted something that was going to be invisible to other users but I could see in Developer Tools.
UPDATE 2 : the html/css wasn't written by me and I didn't have my own environment in which to work. I was trying to investigate some problems in-situ in someone else's system. I had tried using DevTools in the browser but wasn't getting anywhere with that. I wanted to be able to make some small changes to their html/css to aid my diagnostics. I didn't want them to have any obvious effect on the system for other people (except in DevTools, viewed by me).
It was a Wordpress site and they only had two environments, one for live and one for testing. I was working with the test system. There were other people testing at the time, though mainly checking content.
The real thorny problem was why was the font-size in the calendar widget much larger than everything else on the site? Inspecting using DevTools I could see the font-size style was getting overridden by the browser default style when it seemed to me there were other css selectors that should have taken precedence. It looked bizarre. In the end it turned out to be a missing !DOCTYPE tag in the html. So nothing to do with the css itself.
I didn't like this way of working, fiddling in someone's system, but there wasn't much else to do and it did help to resolve the problem for them.
Hopefully I don't have to do this again, but ever since I have been wondering what was the most harmless style that I could have used?
I thought I would ask here as there must be people who know CSS better than me.
You can use this:
.dummy{
min-width: 0;
min-height: 0;
}
If you just need anything beeing set you could assign rules that are default anyway. For block elements like div set
.block-class { display: block; }
And for inline elements like span
.inline-class { display: inline; }
Of course it could be an issue doing so in some rare cases but in general it's quite harmless I guess.
In principle, for any property you can have an arrangement like this:
div {
some-style : a-valid-value-for-some-style;
}
.dummy {
some-style : a-different-valid-value-for-some-style;
}
And .dummy's style will have an effect, no matter what some-style is.
Your best bet is to make use of CSS variables. These are custom properties and start with a double hyphen. so
.dummy {
--dummy-style: foo;
}
will make --dummy-style a property with value "foo". So long as you don't employ the variable as the value in another property, it will have no visible effect.
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.
Is there any problem creating a CSS class like this:
[test] { font: 13px; }
and use it in an HTML attribute as this:
<div test></div>
Would the performance in some browsers be affected by using this method?, I've tested it with Mozilla Firefox and Google Chrome and they seem to work with no problems.
Your custom attributes are not valid HTML. You must use data-* attributes if you want to put custom data on your elements. This makes what you are doing bad practice.
In addition, there are CSS classes already that should meet your needs, unless there is more to your question than you have described.
While there is no problem in applying styles this way, and sure it does work in the browsers, you have to understand that this is not a standard way of applying styles.
Since you have also asked from a 'practice' perspective, then, yes, this surely is not the right practice. The idea is: HTML is used to define the elements to be shown within the browser window, CSS is used to apply any styling that needs to be applied on these elements and JavaScript is used to perform any 'action' on it. So, from a practice perspective, this surely is bad practice!
On another note, why the reluctance to create a class and apply it on the div? After all, this class can be reused as and when required. If you need it only once, then why not create an id selector?
HTML:
<div class="rightApproach">The right way of applying styles</div>
CSS:
.rightApproach { color:Red; }
See this fiddle where you can see your approach as well as the correct way of applying styles, be it class selector or id selector.
http://jsfiddle.net/JkRPt/
It's better to use classes. This way will not work in older browsers and it's not professional.
However it doesn't have any performance issues.
HTML:
<div class="test">
CSS:
.test { font:13px; }
its good to use classes. Example:
<div class="module accordion expand"></div>
/* All these match that */
.module { }
.accordion { }
.expand { }
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 :)
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!