Every programming language has its good parts and its ugly parts. CSS (I know, it’s not a programming language, but whatevs) is no different.
In this post, I do nothing but vent. I’ve been coding websites for almost 12 years, and I’ve been doing CSS layouts for nearly half that (yeah, I was a late bloomer). I’ve come to realize what is good and bad about CSS, and here are what I consider “the bad parts”.
The “Standard” Box Model
This has been discussed enough but deserves more ranting. Although we all eventually got used to it, having to recalculate the width of an element every time we wanted to adjust the padding is just awful.
The box-sizing property has helped this along, and with good browser support, and the fact that IE8 supports it, we can finally start to leave the W3C box model behind us.
Font Shorthand
I’ve talked about this before, but what gives with this property? The six properties that can be declared in the font property have no business being in a shorthand value.
For most shorthand properties, shorthand is not a problem. You declare what you want, and if any optionals are omitted, those are set to their initial values. So who cares if they’re reset? For example, anything left out of list-style or background 99% of the time isn’t inheriting anyhow, so it doesn’t matter if the values are reset.
But many typographic properties are expected to inherit values from a parent. So when you use font shorthand, things can get messed up. And if you’re not familiar with the property’s intricacies, you can be left scratching your head.
In other words, if I declare bold text on the <body> element, then I expect it to be bold, even if I use font shorthand.
Floats
Yes, we use them all the time, and we’ve grown accustomed to laying out our pages using the only method we know. But the truth is, float-based layouts have many of the same problems that table-based layouts did — albeit not as large, and with greater benefits.
The main purpose of the float property is to allow inline content to wrap around a floated block-level element. Creating columns using floats is, more or less, a hack. So similar to how we repurposed the <table> element to create entire pages, we’ve likewise repurposed float.
That having been said, floats do not have the accessibility problems, maintenance issues, and performance proplems that table-based layouts do. So we are in much better shape.
But floats are annoying. They cause content to disappear. They require clear fixes. They have been at the core of many IE margin bugs (but that’s obviously more of a vendor issue, but hey, this is a rant, right?). And they don’t do what we really want them to.
Although CSS Regions and flexbox are in the pipeline, it will still be a long time before we’re able to completely abolish float-based layouts and their many quirks.
Vendor Prefixes
Does this one even need an explanation?
IDs as Styling Hooks
Yes, you can still use IDs. But please don’t use them for styling hooks. Many people still don’t agree with me on this. But there is no reason to use them. A class can do anything an ID can do, and with numerous benefits to boot.
IDs should be used almost exclusively for fragment identifiers, and for scripting hooks. So you should still have plenty of IDs in your markup, but my advice is use the class attribute to define your styling hooks, and you’ll magically see your CSS files become a pleasure to work with. And best of all, you can completely forget about the problems of specificity.
Vertical Align
This is one of those properties that sounds so simple. But it’s not. It can come in handy in rare circumstances, but for the most part, it’s not very useful.
The one area where it works very well is on table cells, because it does pretty much what the old valign attribute did, so it’s easy to understand in that context.
But when you consider the fact that vertical-align seems to do something completely different inside a table cell compared to when it’s applied to other elements, well, this makes it one of CSS’s true annoyances.
Collapsing Vertical Margins
This concept is quite unintuitive, and I don’t know the reason it happens. But basically, in certain specific circumstances, if the bottom margin of a block element is touching the top margin of another block element, the smaller of the two margins will collapse to zero.
And there’s a whole slew of gotchas and whatnot that help you to understand when this happens, and when it doesn’t. The good thing is, it generally doesn’t pose a problem. But in those rare cases, it does seem bizarre to negate, for no apparent reason, something that is explicitly defined by the page author.
Width: 100%
Similar to vertical-align, this is another one of those CSS techniques that doesn’t do what we want it to do. However, when you understand how percentages work in CSS, it’s not a very difficult concept to get used to.
When beginners start using CSS and they want a box to fill some horizontal space, their first reaction is to try “width: 100%”. It sounds like it’s going to cause the element to fill the remaining space, and there will be no need for calculating the width. But that’s not what 100% does.
Percentages in CSS are always relative to other settings in your CSS (like a parent element). “Width: 100%” actually does exactly what it sounds like it does. It doesn’t fill “100%” of the remaining space; it fills 100% of all the space, besides any margin and padding settings.
So this property/value pair will often have undesirable results, which is probably why it’s not used very often.
Border Images
Of all the new CSS3 features, I have a feeling this one will be one of the most unused and ignored. I wrote an article for SitePoint to try to promote it as a useful technique, because most of the examples I’d seen using border-image were so ugly.
But more and more I’m starting to think that I’ll never use this property, and if it got removed from the spec, most developers probably wouldn’t even notice.
And today, even after writing a whole tutorial on it, and reading the entire specification on that subject, I still can’t code a box with a border image without consulting a reference and pulling my hair out.
CSS Counters
Seriously? Does CSS still have these? Another one that I wrote about, hoping to learn it better myself, and hoping to promote its use. But I’ve never used it on any project, and I bet I never will.
The code is so convoluted and unintuitive, that it leaves us scratching our head wondering “Isn’t this what the <ol> element is for??”
CSS Comments
Remind me again, why I can’t do a simple single-line comment using a double forward slash? I’m sure it has something to do with the way forward slashes are parsed. But it would be so much easier if we could comment and uncomment a single line the same way we can in JavaScript, using a double slash at the start of the line.
Double-Colon for Pseudo-Elements
To differentiate between pseudo-elements and pseudo-classes, in CSS3 all pseudo-elements have a double-colon syntax. So instead of: :before, you do ::before.
As I’ve explained before, this is nonsense. All browsers are going to support the single-colon syntax, pretty much indefinitely, to abide by good design principles.
So that means we won’t be using the double-colon syntax until all browsers that don’t support it (including IE8, the current browser leader) are completely gone — which might not be for at least 2 or 3 years, and probably more.
What Else?
Whew. I’m glad I was able to get all this off my chest. You’ll notice that this list has nothing to do with browser inconsistencies (well, except the vendor prefix part), but is more focused on legitimate features of the language.
So feel free to offer your own CSS pet peeves, and things you find about CSS that are not very intuitive or easy to understand. And please — we already know that everyone hates Internet Explorer and all of it’s bugs, so let’s keep this focused on actual features of the language, and not vendor implementations of it.
Wrong link for box-sizing-property in paragraph ‘Standard box model’ . A ‘c’ is missing.
Thanks for your great site.
That’s what I get for typing it manually. :) Thx.
Great article! I agree with pretty much everything but counters… I’ve actually used them even though the syntax is definitely convoluted.
PS: of course you’re cheating with the “current browser leader” :-) There have been three new versions of Chrome and Firefox during the timespan you considered… those should be summed (as opposed to IE versions that should not). If you consider only this week, with no new Chrome or Firefox version recently released, we can see that the current browser leader is the latest Chrome). I know I’m just nitpicking and being annoying, but somebody reading the article might actually *believe* that IE8 is still the most used browser in the world. Luckily those days are gone.
That’s a good point about the browser versions. I’m actually planning an article on a related topic, probably for next week.
I don’t agree on class only styling.
IDs are useful when you need to style a unique element: they’re faster (the browser know it has to find and style only one element and not an unknown number). And speed may be not a problem on a modern Mac/PC, but on a mobile device it becomes very important.
IDs make your stylesheet easy to read: you know exactly what element you are styling, with classes, if you name them reasonably, you know only what kind of style you are applying.
In my opionion: ids to style a unique element, classes to style multiple ones
IDs are not faster to style at all. Browsers go through *every* element and apply any appropriate styles. So if it finds
<div class="example">then it applies the style instantly.IDs are faster.
With faster I mean that with an appropriate use of IDs the page rendering requires less time compared to class only CSS.
As you said browsers go through every element, the difference is how much time the browser need to find *appropriate* style for a given element.
Just think what happens in a database: IDs are like a primary key, they’re the fastest way to find something using an exact match
That would be great if that were how browsers workes, but it’s not. Most (all?) browsers will look for and style ALL instances with a given id, not just the first.
As Oli Studholme notes, per every 1000 rules, ID selectors are 1.2 milliseconds faster than classes, that is, by such a infinitesimal amount that it’s not worth worrying about. And it’s hardly a valid argument in favor of IDs.
The other thing to note, is that the browsers don’t assume perfect syntax, and as such go through every element to find duplicate ID’s is applicable. If they did assume perfect syntax
The other reason ID based styles are annoying is when you are writing automated web tests. Being able to allow these tests to leverage ID’s to leverage field values makes tests simpler. Complicating simple automated tests is bad practice, and in turn creates more overhead to create test tests.
Additionally, these tests will break if a designer changes ID’s for styling purposes, and the styles will break if these ID’s are changed for functional purposes.
By giving the HTML dev’s authority over the realm of ‘class’ and by giving the functional dev’s authority over ID, the separation of concerns allows both streams to work (for the most part) independently.
Inside a CSS file, IDs are nothing like a primary key. You can declare the same ID selector as many times as you like within a CSS file and IDs could be inside other selectors (e.g.
.special #myid {}), meaning the browser still has to check every rule to see if it applies.What about :target selector? it is incredibly useful and needs IDs. The point is that IDs have various use cases – a landmark in the page, a connection for accessibility (aria-labeled-by, labels) so whilst I agree that for plain styling reasons they might be overkill I very much disagree with the sweeping notion of demonising them. Building a web product is using HTML, CSS and JavaScript. IDs are a thing understood by all.
I don’t think anyone here is suggesting a blanket ban on IDs. This discussion is strictly about IDs as styling hooks.
id’s make your styling to specific. You can’t reuse your css.
are two examples of being to specific
is much better since you can style a <button><input><a> with it.
Id’s and tags in your selectors prevent this or require you to do additional typing like: a.btn, input.btn, button.btn
Regarding selector performance, I think Paul Irish said it best:
Except he was talking about the universal selector (*), not “any selector” which I’ve inserted into the quote.
Re vertical-align, I use this a bit. Once you remember that you can use inline-block instead of floats for certain situations (not full columns, but just lists of blocky things) then vertical-align is pretty useful.
My gripe with is with the name – we have text-align for aligning horizontally, but vertical-align for vertically.You’d never guess both properties apply to the same types of content (text and inline-blocks). I’d much prefer having
text-halignandtext-valignfor those, then two new properties ofblock-halign(equivalent of margin:auto) andblock-valignto do the vertical aligning that everyone actually wants.Also, too many property names are long and verbose. Why not
bg:green?For me the worst thing is the !important, it’s just a goto in disguise. If you find yourself needing it, then I guess that you did something wrong
You obviously got the wrong idea about Collapsing Vertical Margins. Margin-top: 20px actually means, that there will be 20px gap between this element, and element above – it omitts top element margin…
No, that’s not correct. According to SitePoint’s reference:
If I have two elements, the first with a bottom margin of 30 pixels, and the bottom one with a top margin of 20 pixels, they are both honored. The gap between the two elements is the greater margin. A margin basically states that you always want that amount of empty space around an element.
If the the two were combined so there was a 50 pixel gap between the two, styling headings and paragraphs lists and blockquotes so you had sensible spacing would be a total pain in the butt.
That’s a good point. I’ll update the article to include a note about that. Thanks.
However you are right that “A margin basically states that you always want that amount of empty space around an element.” but CSS should not bother about it. It must do what it has told to do. The problem of the addition of margins should be solved by the designer.
How would Space Before and Space After not be preferable if you desire typographic control? This is how styles are done in the print world.
OT: Why can’t we have tab stops like in the print world?
The problem is that collapsing margins can be broken by somewhat unrelated properties (like overflows). Or they can fail when the wrapper doesn’t have a border (which sucks too). The concept is great, the practical implementation is way too complex
The long version:
http://www.onderhond.com/blog/work/collapsing-margins-improvement
How is applying a 30px margin honoring a request for a 20px margin?
I haven’t knew about this margin collapsing issue. Another useful knowledge GET! Thank you!
My number one pet peeve is relative font-sizes (and by extension, treatment of other dimensions specified in em). Having to include values like `1.167em` when what you’re aiming for is 14px is ridiculous. CSS should have a way of specifying if you want to inherit ems from the parent element, and default to inheriting from body.
Also, the lack of a built-in clearfix method, indicating that an element should clear all the floats it contains (rather than all preceding floats, which is what `clear` does)
you might want to try using rem units
Nice! I had never heard about rem’s. How did I miss that? (if only that…or really any CSS3 ended up in IE8).
If you want text to be 14px, put 14px. It’s that simple.
I also agree with this statement, using px sizes for font’s is perfectly acceptable, but if for some reason you must use relative units, the rem unit is a viable alternative.
Try setting the font size on the body to 62.5%, then from now on 1em = 10px, 1.4em = 14px etc etc
Makes lifes so much easier
Thank you for including the lack of single line commenting via double forward slashes in your rant. I was beginning to think that perhaps I was the only one on this planet who’s been craving for that! I do a lot of programming in languages like C# and Java and my biggest gripe while writing CSS is when after typing in a line and hitting the semi-colon if I wanna jot down something off the top of my head, I hit //, type my idea down and then realize I forgot the damn /* */ Oh! The frustration! :-@
— seems to work for me
--double dash, that isThe “Standard” Box Model is useful and I use it a lot. Some times I need a width for the text independent of the (visible) margins and paddings.
It’s a love / hate relationship.
As of earlier this morning, current pet peeve is the difference in line-height rendering between mozilla and webkit :(
The parts of CSS that are a niggling frustration to me lie around the manipulation of text.
* font-size affects the total height of the font, not the x-height.
* when combining the above with multiple font families with different x-heights, your fallback fonts can be unreadable.
* the layout of your site will suffer as a result should you be using ems.
* there is still no nice way to wrap pre-formatted code. Yes, it is pre-formatted, but scrolling horizontally and breaking the page flow and continuity is a far worse prospect.
* it’s still not easy to constrain text to boxes in certain positions. Having to explicitly set widths on boxes to encourage text wrapping is a pain.
* kerning!
* text-shadow-color does not exist!
Good additions, Chris. But not sure what you mean by “text-shadow-color does not exist”? No, it doesn’t exist as a separate property, but it is part of the allowable code for text shadows:
http://dev.w3.org/csswg/css3-text/#text-shadow
Were you referring to something else?
Consider that for borders, text color and background color, I can change them and only them when the state of the selector changes. Instead of respecifying border-left: 2px solid black in my hover, I can just say border-color: black. I am not afforded the same leniency and ability to decouple colour from appearance with either text shadows or box shadows.
Ah, I see. Well, I guess you can just declare the whole property again on hover.
But yeah, definitely not the most efficient and intuitive way to do something.
Inline-blocks being whitespace sensitive is quite annoying.
Mine is the lack of being able to center things… Like a nice logo on a splash page. (No, not a list of centered text!) What’s even crazier to me is that there is a way to do this, it’s to use:
margin: auto
what??? really? and as mentioned before the margin stuff in CSS is completely dependent on what’s happening to the outlining container, so you can get some crazy results trying to do this.
You include Counters in your bad features but the do come into their own when the the media type is print. Links don’t work so referencing sections by chapter number, illustrations by figure number, knowing which page something is on, Table of Contents etc. all become sort of important. I used Prince8 to convert my HTML to paper for university submission and these features seemed to be well supported and easy to use. I agrree that for screen output they just complicate things.
Concerning the commenting annoyance…if I want to comment a line of CSS I just put an “X” in front of it, for example:
X.myheader { border:1px solid red; }
It’s dirty and does not validate, yet I use this in development only, and obviously not to comment instructional comments, only actual lines of CSS. I also use this inside a CSS rule, since I typically do not position each rule on a new line.
How about opacity?
A developer can’t have a CSS 2.1 compliant style sheet, cross-browser compatibility when he needs to use opacity. It’s either or.
I find that specially annoying for modal popup development. Inexperienced people will scratch their heads for a long time before they find the correct cross-browser solution. There are rare articles that cover this completely.
I think I cover most of the relevant cross-browser issues on opacity in this post:
http://www.impressivewebs.com/css-opacity-reference/
As mentioned by Chris Heilmann, for me one of the most important (and sadly neglected) uses for id is for matching form controls with label elements for accessibility (using the for= attribute in the label).
Good article, I still find it hard to understand why floats should be so difficult. I think perhaps it is like trying to use real floats in a swimming pool and getting the perfect arrangement every time.
It’s so nice to see someone else rant about the many issues that CSS has (besides me!) I’m pretty sure CSS was designed by a committee of non-pragmatic pedants instead of being designed by a group of people who were actually interesting in making something easy to use that meets most common use-cases. But I digress…
One thing (I think) I disagree with you on is the styling of IDs. For example, it seems preferable to style
#contentfor a page that has one main content block than it is to style.content, especially when#contentwill be used with Javascript. Given the use of Javascript selectors you can have just<div id="content">instead of<div id="content" class="content">.Or maybe I’m missing something? I’d be interested to know why you recommend against. Thanks in advance.
It’s because IDs are too specific, and can’t be reused. I know, in the case you mentioned, reusability doesn’t matter. But then, who says a class can’t be used only once? There’s nothing that
#contentcan do that.contentcan’t.Mainly, IDs are avoided (in selectors) if you use OOCSS, which you can read more about in my article on SM:
http://coding.smashingmagazine.com/2011/12/12/an-introduction-to-object-oriented-css-oocss/
And this post is also relevant to the issue of using IDs:
http://www.impressivewebs.com/css-specificity-irrelevant/
I think Id selector is best for defining style for a particular element. It helps to identify that the defined style is applied to only 1 specific element. It is particularly useful when we have a very large webpage. Also it helps to identify/find that particular element when we look at the code after some months/years or someone else is editing the code. Programmer/designer should take care when applying id attribute & its value in HTML so that duplicate ids don’t get applied.
That”s good !I’m a frontend in China !
Font Shorthand: you have to declare the properties in a certain order. Still a pain, but that’s why you may have not seen the results you wanted.
You must include both size and family and in that order. And, to get really smelly, if you include any of the other keywords (except line-height), they have to come BEFORE the required ones. So, the minimum font shorthand is something like:
font: 12px sans-serif;
adding other keywords like bold and italic needs:
font: bold italic 12px sans-serif;
Eric Myer breaks it all down in Smashing CSS.
Line-height… well you can use that as in the print world nomenclature such as:
font: 12px/14px sans-serif;
Optional of course, but if you do include line-height, it has to come before the size and next to the forward slash. Check out that book.
Here’s a HUGE one. “Developers” vs Evangelists vs Designers… one is supposed to separate content from presentation from interaction, right? HTML for mark-up/structure, CSS for presentation and jQuery/javascript for interaction. BUT, classes and id’s are supposed to describe the content, not “.redModuleBox” so the naming is more like ‘muscle in on the mark-up layer’ …then CSS3 is including transitions! Heavens! One may argue that sliding content in/out could be related to presentation but it’s an action which means, that’s right, it should be on the interaction layer…but OH! CSS is for presentation….standards/best practices etc, etc are only guidelines and in the real world are usually compromised at some point. Doesn’t mean we should just ignore but when creating css or anything else, the best is what works for the task at hand!
FYI – For font shorthand, the line height comes after the slash, not before (maybe that’s what you meant to say?).
Because of how confusing it can be for beginners, I made a cheatsheet for font shorthand.
You suggest that using ‘float’ for structural layout is a Bad Part, but do not suggest an alternative.
Before css, detailed layout using nested tables and spacer.gif was all that was available.
And then came css, and all that nested mess was not required
But why was using a table for structural layout also thrown out, incorrect, not PC ?
Why is…
</div><div class="maincontent">any more semantic/understandable/logical/correct than…
</td><td class="maincontent">Using floated div’s for structural layout seems ridiculous – very clever, but why ?
As you say, the float was meant for in-line images. The rendering engine, if possible and there is space, should try to wrap following content around it.
The rendering engine programmers must be amazed and in awe of what css designers are doing.
But what is wrong with using a 3 column table to do a 3 column layout ?
It works, it’s fluid; works with screen readers; column 1 is always first, followed by column 2, 3; background colours and borders can be set. Even handheld’s can now do tables
To misquote Samuel Johnson (and leaving out his reason for the quote)
It is like a dog walking on his hind legs.
It is not done well; but you are surprised to find it done at all.
The reason that table layouts are wrong is threefold:
1) They cause problems for screen readers.
2) They don’t load as fast as divs (although this might primarily be a problem with nested tables)
3) They are much harder to maintain (i.e, make changes/additions to)
I know I didn’t offer an alternative for float layouts. But that’s because there isn’t one! But that’s not my fault. Blame CSS. Blame the W3C. But don’t shoot the messenger. :)
Also, it’s wrong to do a three-column layout with tables for the reasons mentioned above (although the problems may not be as extreme with something that simple), and also because creating a three-column layout with floats is really not that difficult. And you get the potential accessibility, speed, and maintenance benefits — especially if you end up nesting your divs/tables or making additions and alterations later on.
Thanks for your reply.
I wasn’t intending to shoot the messenger at all, excellent advice on your site, much appreciated..
Is this true for screen readers ? They seem to be able to interpret data output in tables.
What does a simple 3 column ‘structural’ table sound like ?
Do you know of any tests on rendering speed comparisons of floated div and table ?
But a programmers ‘rule’ is to forget speed (at least initially) – first get the code right and maintainable. (same as the ID or CLASS question)
And my main question would be ‘maintenance’
Why is …
<table class="container"> <tr> <td class="menu">more difficult to maintain than…
<div class="container"><div class="menu">And taking it account those extra div’s to clear, and suchlike, I would suggest that a simple structural table is much easier to maintain.
If you are talking about output from a database I can’t see the difference in wrapping output in a <div> or wrapping in a <td>
And it is just a different tag to the browser.
Raising ‘maintenance’ brings up another point – the sparcity of css commenting. can be quite amazing, even on quite serious sites.
(but perhaps we are only seeing minified/processed css.)
How is the css being maintained ?
Or are we changing so fast it never will be maintained – it will be re-designed first.
From my understanding (and I’m not an expert on this), a screen reader will read table-based content in a different way, identifying it as ‘tabular data’. I don’t know all the details, but that’s the gist of it.
And regarding table maintenance: A simple three-column table isn’t hard to maintain, as long as you don’t plan on adding new table rows, new cells, etc. If that’s all you have, then it’s probably more maintainable than divs. But the problem arises when you try to nest content within content. If you start nesting tables, adding new cells, etc. then maintenance gets quickly out of hand.
In that case, it’s much easier to use floats and positioning to easily throw a nested element in there. So with that in mind, and if the table poses accessibility problems, then it’s much better to use divs/floats.
Most screen readers will make a distinction between a table used for layout and a table used to present data. Layout tables will be read ignoring the underlying structure (the table), data tables will be read notifying the user of the elements of the table.
The markup used is observed to decide whether the table is layout or data. Usually you only have to use <th> in your table to make sure the screen reader will read it as a data table.
Check this help page of JAWS to read more about how tables are handled by a screen reader: http://www.freedomscientific.com/Training/Surfs-up/Tables.htm
—
Your 3 arguments against table layouts are wrong, I don’t wish anyone to continue using tables for layout but this doesn’t mean we shouldn’t be objetive about the reasons why.
1) Tables don’t cause problems to screen readers, bad web authors cause problems to screen readers. You can do as much harm with floats as with tables.
What’s actually wrong is that we insist on calling them “screen readers” when what they actually read is the code, not the screen. Web authors make the mistake of thinking that a web page is what we see rendered on screen, when that is just one interpretation of the code underneath.
2) The performance issue is actually a “feature” of IE’s table rendering algoritm, which requires the whole table to be known before rendering it. This performance penalty is exponentially increased with each level of table nesting.
Other browsers use algorithms that progressively render the table, performance wise they are not perfect either but it’s almost the same as doing it with floats. In IE table-layout: fixed can be used to improve the performance of table rendering.
3) The maintenance problem is subjective: it depends on whether you use html as source code or machine code. If you’re writing the html yourself, layout tables add verbosity and complexity to the code that harm readabilty, and therefore are harder to maintain. But if your html is being generated by authoring tools… there is not a maintenance issue, on the contrary layout tables are generally easier to maintain by authoring tools that have a graphical approach.
What changed is the paradigm of web authoring, before html was considered the machine code that web browsers use, now is thought as the source code of a page, that which a web author writes himself. Saying now that table are harder to maintain is paradigm bias.
—
So why use floats instead of tables? The problem with this question is that it’s presented as a dichotomy, a false dichotomy. There is no answer that won’t be biased.
Why use tables? You know why, everybody knows why, most of the web is written with tables, but that paradigm has grown stale, don’t expect any innovation on this front!
Why use floats/divs/css? Because it’s a relatively new paradigm, with new features coming and going. If you want the cutting edge stuff, I won’t say you have to do it this way but you’ll find it’s easier here, because most of the new stuff for html is thought from this paradigm.
Thanks for the info, Martin. Definitely some good points in there.
This is quite relevant to this discussion:
http://juicystudio.com/article/layout_tables_repair_techniques.php
Louis, I was looking into the current state of CSS comments and came across this article. I wrote a quick post about it here: http://creativeandcode.com/the-crappy-state-of-css-commenting/
I was surprised to find you can use double forward slash to comment single lines of CSS. Doesn’t validate, but works in all the modern browsers I tested.
An alternative to floats: The alternative I’ve used in a few cases has used inline-block, widths of 200% and 50% and some fancy margining techniques. Best way I’ve found to do a mix of fixed and fluid width columns especially.
If you want to use divs instead of spans you’ll have to override inline-block to inline for old IE versions.
I hate the Opacity property’s value format. Instead of 0 to 1 it will be better if we can use 0% to 100% IMHO. However IE’s
filter: alpha(opacity=50%)is very long method to specify opacity. So it should be simply:opacity: 50%.The same thing should also be applied to
line-heightproperty. But the good thing here is thatline-heightproperty also supports%as unit. So what just need to do isline-heightproperty’s value must always be specified with a unit (%, px, pt, …), this property should not work ifline-height‘s value is specified without any unit. In simple thinking, the value without any unit seems ambiguous.After seeing your article http://www.impressivewebs.com/understanding-css-shorthand/, I got 1 more property which I hate. It is
background. There are too many values for the shorthandbackgroundproperty and we have to specify all of them if we want to specify just 2-3 values otherwise it replaces previously defined value(s) with the default value(s). At some point it also applies toborderproperty. For this reason, I mostly use full property names, eg.background-color:#abc; background-repeat: no-repeat.I also don’t like the long word “background” it should be shortened to “bg” or “back”; or something else, more suitable name should be preferred.
For background, the replaced values in the shorthand syntax don’t really matter because you don’t expect them to ‘inherit’ their values like you do with ‘font’.
Thx for the “good” article! :-)
No seriously the article is great even though it’s topic is sad.
But I do have another stupid and annoying thing that I hate.
What about the whole height: 100% issue?
Oh man …
yeah right there it is again.
First of all almost everything you said about the width 100% problem is about the same here.
But the most strange part is to make a fluid layout for the height.
I mean come on, is it obviousto define 100% height for the body and even the html-tag?
Absolutly not, in my opinion.
Oh but wait there is more.
Imagine, you have a side that is scrollable because of its vertical length. (Like this on right here)
So imagine even further you want a sidebar right next to the scrollbar which has a nice background to it.
And you also want this sidebar to be as long as your content.
The first thing that comes to my mind, is set the sidebar to 100% height.
Nothing happens because I forgot to set 100% for the HTML-Tag in the first-place.
Okay okay, but even after doing that you will see, you will find yourself with another problem.
100% is the viewport in this case. So if you scroll down, your sidebar is not as long as you want it to be.
You could use a super dooper padding-bottom: 1337em in combination with margin-bottom: -1337em;
But you have to set overflow: hidden, for the parent element, which is the body element in this case.
So and we all know that this cannot be the right thing to do.
(BTW: it causes the scrollbars to disapear)
Sure you could use 100% height on the sidebar and position it “fixed”.
But by doing that, you’ll find yourself using javascript for mobile browsers, a few minuits later.
So I think height 100% should be right up there in that list.
And if someone has a solution to this problem I mentioned please write me an eMail, or talk to me via twitter.
I use ID’s to organize and separate different parts of the page. It also lets me focus on specific parts directly. Can classes do that? If you don’t use IDs’s for CSS hooks, what do you use them for?
Yes, classes can do the exact same thing that IDs can do. Also, you can use IDs for JavaScript hooks and for fragment identifiers. There’s nothing wrong with dividing your page into sections using classes. It will have the exact same result, except without the drawbacks of IDs (high specificity, trouble with maintainability, etc).