css defaults pt2
Remember last week's article on css browser defaults? Impressed by the simplicity of the concept? Wondering where the catch is? Well, we wouldn't be front-end pros if we didn't expect something to go wrong, right? Time to get cynical (again) and see what happens when taking the concept of css browser defaults for granted. Because like everything else front-end related, there are some annoying pitfalls up ahead.
give me an I, give me an E
I'm currently working on a project developed in SharePoint 2010. Apparently this version of SharePoint goes a long way in tinkering the html code, but the dynamic pieces (called webparts) are still happily spewing out table tags. Not too big a deal though, I needed the wrappers anyway since in this particular case graceful degradation was not an option. This led to the following (simplified) css setup.
table, tbody, tr, td, th {display:block;} /* additional testing code */ table, tbody, tr, td, th {padding:0.5em;} No time to beat around the bush, IE (all of them) is one of the main fuck-ups here. The code above is supposed to turn the most common table-related tags into block elements. Following the concept of css defaults these elements should behave like any other simple block element out there. But when applying a padding (and a different background color to each element), you'll notice that both properties won't affect the tbody and tr elements. Worse still, it doesn't even set the table container to a default 100% width.
When going back to ie7 and ie6 you'll see that even the padding on the table element can't be applied. So while you might have expected that the styling of these elements comes straight from css (and should be easy to overwrite), there seem to be some exceptions left and right. Apparently table elements feature some extra fixed clauses that prevent them from acting like regular block elements, even when stated explicitly in css.
Note that a position:relative declaration won't work on tbody and tr elements either (when set to display:block), so if you plan on using some absolute positioning tricks, those won't fly either.
webkit saying hi
If you think it's just IE being a bitch, think again. Front-ender in crime Mathias Bynens uncovered more issues in Webkit. Apparently the background styles applied on a tr are repeated through all nested tds. The bug is already filed, you can check out the test page for a live example, the bug can be spotted in Safari/Chrome on both Windows and Mac.
Once again, this seems proof that not all visual styles of html elements are solemnly applied through css. It makes you wonder what other hacks, workarounds and shortcuts exist within these rendering engines, doesn't it?
conclusion
Opera and FireFox seem to be handling everything just fine. As for Webkit, let's hope for a quick and simple fix in the near future. The IE legacy is a much bigger problem though, and it's even more alarming that even ie9 doesn't seem to behave like one would expect. Not that I like working with tables and turning them into block elements, but when necessary I do want these things to be possible.
If anything, this is just another lesson that front-end development is never easy, not even the simple parts. Somehow, somewhere, something has to go wrong. It makes our job what it is, so all you can do is sigh, file a bug report and go on to fix the next issue on your way.