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
Update (March 14, 2012): In the comments
Steven mentions an excellent point about why collapsing margins
are intuitive, contrary to what I said below.
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.
Source : http://www.impressivewebs.com/css-the-bad-parts
No comments:
Post a Comment