...Screenshot of my abomination
jsFiddle: http://jsfiddle.net/ELZD8/
It was looking fine, until I needed to change the fieldset size: and since I was using position:relative for literally every element on the page, changing the fieldset screwed everything up, bad. Forgive me but I'm pretty new to CSS and I know I'm using wayyy too much code.
So, as you can see in the imgur, it looks like hell now. What's the quickest way to fix this? I know it probably has to do with floats and margin:left and margin: right, but could someone provide some insight before I go bananas?
Any input is appreciated, cheers.
Easy fix:
You need to use proper div sectioning, that is, make each section a div and then place elements inside each div, otherwise it becomes a clusterfuck. You also need to list your elements in your css file by order of appearance in the html, otherwise it's painful to look for things...
Don't use massive amounts of <br>, use padding and margin css rules instead
Yes, you may use position:relative, but since you asked for advice, I am strongly against it, it takes longer to build, longer to update, longer to fix, etc. Use sections, floats and keep it simple, Simple is your friend.
I also suggest strongly against using fieldset, use <form> instead, its a major html/css breaker imo.
Here's a chopped up example after cleaning/tweaking the code considerably. There's still a thousand ways left to clean and refine it but at least now it looks more like what I suppose you wanted:
http://sotkra.com/stackoverflow/positionrelative/index.html
Related
Here you can see what I'm trying to do: http://jsfiddle.net/smogg/QFa4J/2/embedded/result/
I was trying to achieve this look so hard, and right now this code may be really confusing. If you have some tips which may clarify that, please tell me. It is all made by trial and error.
Anyway, this looks good. The only problem is my text inside .article is not selectable. Borders inside .article:before cause this problem. How can I solve this? Or maybe I should take some different steps to achieve this look (right now, with my solution I have to define height of articles which is problematic).
#edit:
I forgot about this. I can't use z-index cause my #mainhas shadow on it (which is not included in jsFiddle to clarify code) and then shadow shows on top of border. If I use borders without :before then my #main gets wider, which is not what I want.
There are cleaner and easier ways to do this. Enjoy!
http://www.css3d.net/ribbon-generator/
http://www.pvmgarage.com/2010/01/how-to-create-depth-and-nice-3d-ribbons-only-using-css3/
http://www.webresourcesdepot.com/creating-nice-3d-ribbons-with-pure-css3/
I stumbled upon this article
http://www.thefloatingfrog.co.uk/css/my-hatred-of-br-clearall/
When would one need to use that ?
Why is it evil ?
I don't understand the substitute syntax can you explain ?
Setting clear to both with not allow other elements to float on either the left or right side of the element. The class below is an easy way to add this anywhere.
.clear {
clear:both;
}
So when you want to clear something (that is, if you were to float the next element to the left, it would be below the current element and to the left, instead of left of it) you'd simply add the .clear class.
The problem with the following code is that if later on you decide that you don't want to clear everything after the 'something' class, then you have to go through your HTML and remove the br clear="all" wherever you have that 'something' class.
<div class="something">Cool content.</div>
<br clear="all">
<div class="other">Cool content again.</div>
Instead you could do something like this:
.something {
float: left;
}
.other {
clear :both;
float: left;
}
<div class="something">Hi!</div>
<div class="other">Hi again from below!</div>
That way if later on you decide to float all blocks with the 'other' class then you can just remove the 'clear:both;' from the CSS once.
I was about to post something snarky about you not reading the article, but when I saw that it was just a page of vitriolic rage with no explanation, I figured I'd answer.
It's because there are better ways of doing what you want to do -- namely, by using CSS in the way he does in the article, he has separated the semantics of the elements he's displaying from how he's displaying them. Why is this a big deal? Well, for one, he can more easily transform how his page looks when it's shown on different platforms (mobile, desktop) and media (screen, print, a screen reader for the blind), simply by editing CSS and not having to touch the document itself. This feature of CSS is pure gold.
On the other hand, if you use a construct such as this, you put in a hard constraint about your document's presentation that sticks around no matter what media or platform you're dealing with. What makes him so mad? Because once a developer has come in before him and used <br clear="all">, he has to take it out in order to get the benefits I just mentioned. That's why it's so frustrating. One bad developer can disable a whole host of development scenarios for every other developer who comes after.
As far as CSS goes, I have to say that it's a very difficult subject to just pick up without reading all about how it works. It's hard to explain how the clear attribute works if you don't understand floats. I had quite a hard time myself until I bought a great book on the subject.
When you have floated elements, the parent element can't calculate it's dimensions effectively and sizes incorrectly. Other items that follow floated items may also sit out of position. By clearing an element at the end of your floats, you correct alter this behaviour.
EDIT
Actually correct is probably the wrong word to use as this is what is supposed to happen and using the word correct suggests it is broken.
The author is just going off on a crazy rant about how the same thing can be accomplished using CSS on the DIV elements themselves. He's saying that br class="clear" is unnecessary.
It's also not a good practice because it mixes content with presentation. If a web designer wanted to re-theme the web application, he or she would need to modify the HTML to pull out all of the br clear elements, whereas if this was done as the author suggested, then the CSS files could be swapped out independently of the HTML, making their jobs easier and giving them one less thing to rant and rave about.
The rant is of course justified, as these simple, silly lines of code can actually cause a lot of headaches.
The idea is that your markup describes the information, and the CSS formats that information.
A dummy tag to clear floats isnt semantic, as it's only purpose is for layout reasons. There are other semantic ways of clearing floats that keep this separation. As commented below but here for clarity this is a good resource for semantically clearing floats http://css-tricks.com/the-how-and-why-of-clearing-floats/
Does anybody know of a way to use {text-overflow: ellipsis;} on a piece of text that's wrapping to a second line?
Adding:
{whitespace: nowrap;}
makes text-overflow work, but I need the text to wrap so I really can't use that.
If you know the content is going to wrap to two lines every time this solution will work. Use ::after and content: '...'; and then position it over the bottom right corner of your type (which should be a block level element). This will only work if you are working against a solid background color as you need to set the background of the ::after to match.
The only downfall is the limited parameters this can be successful in and the fact that it will cut a character in half if things don't line up right (which they probably won't).
I am fairly sure that what you are trying to do is impossible in a pure CSS solution. However there is a way of hacking together a similar result. Here is what I did:
http://cce.usyd.edu.au/courses/Business+%26+Management/Business+Communication
See the fade on the block of text introducing each course? That was done by firstly restricting the overflow in the usual way and then placing another div over the top of the last line and implementing the fade in CSS. Instead of a fade you could also insert an ellipsis or some other visual clue.
So, not exactly solving it the way you want, but achieving a similar UI result to ensure the user is aware that content is truncated. Personally I think it is quite pretty :-)
Is this going to cause me untold grief if I stick it at the top of my stylesheet?
* {position:relative}
Is this going to cause me untold grief if I stick it at the top of my stylesheet?
Yes. You will not be able to work with absolutely positioned elements any more, for example - the absolute positioning will always be relative to the parent element, which is almost never the desired result.
I could imagine there are even more side-effects field of z-index settings.
Not a good idea IMO.
And no, position: static is not deprecated, after all, it is the default setting :)
Wildcards can cause performance issues when not used carefully. That would probably not be the case in your example, but it's a bad habit to develop.
But more importantly, it's rare that you can conclusively say you want any behavior to apply to all elements.
With relative positioning, you will at best achieve nothing and at worst create many headaches for yourself trying to troubleshoot things that would normally "just work".
Relative positioning definitely has its uses. Apply it when you need it.
It's a bad idea imho as it changes the default behaviour of elements without clear indication and it will have unforseen consequences.
If you really want to have most elements positioned relative, you might want to think about just making div and similar relative.
Just to give the other side of the coin, I have used this setting quite a lot, and have found it useful. Main advance being the easiness of using positioning properties (top, left, right, bottom) without having to define relative positioning to parent all the time.
It's true that this setting will make it impossible to use absolute positioning in relation to anything else than the parent right above, but I find this to be a good thing. Because the first parent with 'position: relative' is visually de facto parent of any child with 'position:absolute', then it is only logical to make them direct children also in the HTML hierarchy.
In short * {position:relative} forces a convention that makes it easier to reason how positioning works.
Caveat 1: Event if the new convention simplifies things to new comers, it's different from what seasoned CSS developers are used. Prepare to face opposition if you start using this in big project with many frontend developers.
Caveat 2: Performance issue should be tested properly. I have tried turning this setting on and off on some big sites without noticing any difference, but no real tests with real numbers exist (to my knowledge).
Final note: First line in the second paragraph is not quite true. You can always overwrite wildcard definitions, setting position: static some mid level node, if you really need to.
Answering title question:
This is the current CSS 2.1 spec:
http://www.w3.org/TR/CSS2/visuren.html#propdef-position
Accepted values include static, relative, absolute, fixed and inherit.
I'm not sure about CSS 3 (it's still work in progress) but they don't seem to mention static:
http://www.w3.org/Style/CSS/current-work#positioning
Whatever, I wouldn't really care yet :)
Answering body question:
The default is static so you'd be changing the property for every single item in the page. The best you can achieve is nothing. The worse is that you'll be probably creating weird side effects you won't even notice at first sight.
Also (this is pure speculation on my side), it can't be good for performance. I'm sure rendering engines are optimized for having a majority of static elements.
I have been experimenting with the Majestic template at freecsstemplates.org. So far so good; I really like the look (or to be more specific, my boss really likes the look).
However, I am noticing that the CSS that drives this template seems very brittle; small changes can cause really radical breakage. In particular, if I reduce the size of the header in the CSS (to eliminate some of the empty space at the top of the page), both of the outside columns suddenly disappear.
With small websites, sometimes I cry uncle and just use tables for layout. I realize this is heretical; should I be leaving the design to the professional designers? Or maybe I'm going about this the wrong way, and someone can set me straight.
I honestly think this layout has been made pretty badly. The width of the elements seems to change where they appear on the page, and they're all need to be pixel perfect for everything to be centred.
For some bizarre reason the whole page has been placed inside the div element marked 'header'... This doesn't make much semantic sense for a start.
However, it seems if you decrease the width of every element which has one, then everything does get smaller, and nothing should disappear.
I would recommend looking at some other more sensible layouts, since I don't think this is a very good way of attaining that style -- as you've said, it's brittle. Have you tried using the extension Firebug for firefox? It allows you to make on-the-fly changes to the css, and see how it affects the style, which will help you learn fast.
CSS is delicate, but still easier to deal with than a site full of table layouts. I found Dave Shea's book CSS ZenGarden to be a great help in learning CSS from a designers perspective.
Often in layered templates there are a few places where changes to CSS can be made, and it can be really confusing to follow which selectors are controlling the element you wish to manage. There are many tools out there that can help, but some that have been useful to me are:
Google Chrome and its Inspect Element option
Selector Gadget - a bookmarklet that will help you visually determine the selectors that affect an element
Firefox's Web Developer plug in
One other tip is to learn about the !important modifier - it can come in handy to force a particular property setting when there are multiple CSS selectors affecting the same element.
CSS in my experience is easy to understand in concept, but takes a long time to master.
Brittle CSS can be very brittle, but good CSS can be wonderfully flexible.
As it stands CSS can either make layouts wonderfully simple and flexible or it can make the simplest of tasks an absolute nightmare.
Purists will tell you to use CSS no matter what, a pragmatist will tell you to use what works. If using a table or non-CSS solution makes something infinitely easier to do, then use it!
Personally I try to use pure CSS as much as possible, but there have been times when I want to do nothing but swear when something glorious in FireFox looks awful in IE. This is where the hacks come in. It is these hacks and work arounds that tend to make CSS brittle in the first place.
Half the problems with CSS would go away if all the browsers did precisely what the CSS spec says they should do. Alas, this is yet to happen so we have to live with either using tables, or on occassion, brittle CSS.
The best solution is to make the design as simple as possible. If you find you have a hundred divs and lots of CSS trickery to do something straight-forward, stop. Re-think how you are approaching it and try again.
At the end of the day your website users don't really give a monkeys what your website looks like as long as they can get at the information they want with minimum effort. Successfully manage that and they will not care how photorealistic that shiny nav bar is, or how well the borders line up etc.
That's my 18pence at any rate :)
I agree most css template is hard to read, and different people may have a very different approach to the same layout strategy. Since there are too many hacks/tricks/techniques in css it is really fragile when you try to modify those existing one since almost all cases, the styles are very dependent to each other.
Css doesn't break as long as you don't break it ;) It's a language. Just like a regular one, if you don't use proper grammar people won't understand what your saying.
If a layout doesn't work or suddenly your page looks rubbish, I'll guarantee you it's your fault. Css isn't brittle, the code you wrote with it might be.
So start by learning the basics and don't just dive into some file you found online which might (in your case, does) contain very bad code.
If you end up wanting to use tables for everything may I suggest you start looking at some grid systems like http://960.gs/ and ease your pain.
Gideon