Luke Underwood wrote in with an interesting question:
What are the best practices for default
<table>
styling?
I guess there are three possibilities:
- Have default styles
- Don’t
- Somewhere in between
Luke elaborates:
Our office is split on the idea. In our base templates we currently have no styles being applied to tables by default. You need a class to get it looking pretty (with borders, background colors etc). We use this class primarily on tables used in main content areas.
We front-end devs decided this is best because it means we can easily style custom tables without having to override any default styling. This includes having to override media queries that reduce padding on smaller screens, which would be annoying. We also think it would be important to have a selector on these content tables in case we need to implement JavaScript solutions like responsive table plugins.
The back-end programmers are continually frustrated that they can’t just “dump a table on a page” without it looking good and insist that default table styles are the way to go. Apparently adding a simple class to every table can be difficult, and they think we should have to deal with writing extra css to get around it.
To summarize:
Benefits to having default styles
- You can just “dump a table” in the HTML and have it look good
Benefits to requiring a class
- You can have multiple table styles without having to fight against the defaults
- You may need the selector to find these certain tables
I would add a few other considerations.
What’s the context?
One is to think about the context. Are these tables being stored and displayed as content? Like in articles, documentation, etc. I like staying as class-free inside content as I can. I find classes don’t last as long as content does. Someday, perhaps your .striped-table { }
isn’t a thing anymore and a tables revert to some style-less state unintentionally. Default styles would save you from that.
Perhaps your content is stored in Markdown, which I highly recommend for long-lasting content. Markdown doesn’t even give you a great way to apply a class to a table, so that’s a consideration.
Is scoping a possibility?
Another consideration is scoping. Perhaps globally you could avoid default styles, but styles that are obviously inside content output areas do have them.
/* Scoped styles to articles */
article,
.this-is-content-or-whatever {
table {
}
th, td {
}
}
Kinda like opt-in typography.
Are light default styles a possibility?
In addition to the typical user-agent stylesheet, these go a long way in making a table look presentable:
table {
border-collapse: collapse;
}
tr {
border-bottom: 1px solid #ccc;
}
th, td {
text-align: left;
padding: 4px;
}
That’s not much to fight against in the case of custom table classes.
What do other sites do?
Luke did some research! Thanks Luke.
Website | Default table styles? |
---|---|
Mozilla | No |
MDN | No |
CSS Tricks | Yes |
Wikipedia | No |
No | |
eEbay | No |
Smashing Magazine | No |
Awwwards | No |
No | |
jQuery | Yes |
Modernizr | No |
GitHub | No |
W3C | No |
CodePen | No |
InvisionApp | No |
Apple | No |
Yahoo | No |
Amazon | No |
PayPal | No |
NetFlix | No |
DropBox | No |
StackOverflow | No |
CNN | No |
Microsoft | No |
Gumtree | No |
No | |
News.com.au | No |
Bureau of Meteorology | No |
ABC | No |
RealEstate.com.au | No |
Tumblr | No |
IMDB | No |
Seek | No |
Commonwealth bank | No |
ANZ | Yes |
The Verge | No |
BBC | No |
SA gov | No |
MailChimp | No |
Adobe | Yes |
Telstra | No |
Target | Yes |
JB Hi-fi | No |
Seems like it’s popular not to use default table styles.
What about resets?
The most popular reset does:
table, caption, tbody, tfoot, thead, tr, th, td {
margin: 0;
padding: 0;
border: 0;
font-size: 100%;
font: inherit;
vertical-align: baseline;
}
table {
border-collapse: collapse;
border-spacing: 0;
}
That feels a little heavy handed to me.
Normalize doesn’t touch them, which is telling. It means that there isn’t very significant differences (none?) in how default tables are rendered cross-browser, so not much to worry about.
What about the big frameworks?
- Bootstrap hardly touches default styles for tables, but offers
.table
,.table-striped
, and a handful of others you can opt-in to. - Foundation does style default tables right off the bat.
50/50 split.
Thoughts
Personally, I lean toward having default styles for tables, at least in a scoped-to-content-areas way. I don’t use tables for anything but tabular data, and I don’t tend to need a ton of variations on how that tabular data is presented. Even if I did, creating some variations classes wouldn’t be a particularly difficult task.
On every project there will be a point where you need use a table, without or with minimum styling, its much harder to undo those styles than it is to add a class – I learned this the hard way, we now use .presentation-table and presentation-table–zebra :)
Personally I think overriding browser computed styles and build up styling using contextual classes is the safer option for tables used in large web apps. Its quite rare that one particular table style will be sufficient for all tables.
The solution is rather self-evident once you think about it.
Also, in case someone really REALLY wants to be able to build upon those default styles:
OK, fine, we’ll be extra-considerate, but if your app is outputting empty
class
attributes, you should seek professional help. :pThis is definitely the most flexible approach & I was all ready to suggest it but you beat me to it! I like the idea of having a “default plus” class option, too.
I loved your suggestion here… I like the idea of having a default style, but would hate to override it later, so, using this approach is definitely something I can consider… thanks
What if you want a table, that isn’t similar enough to your .default_style to warrant using it, but you do want to style it – that inevitably involves adding a class, which then applies the default style, which you then have to undo (same issue as applying it by default) or add ANOTHER exception to the rule.
9/10 being clever in css comes back to bite you in the ass. KISS.
@Brendan I’m not sure what you’re getting at. Could you post an example with code?
I think it’s better to use an opt-out class, rather than only apply default styles to tables without any class. That means adding this class only to tables that don’t need normal styling. It also means you never have to write styles that undo the default styles, you add the undefault class.
If you keep the default styles minimalistic, using this class should be a rare exception.
Default table class (.table). I know it’s not technically a default, but it’s trivial to add or take away for custom styling. It’s also less intrusive than a hard CSS reset, which I’ve started to find annoying.
I’m all for the scoping option. We reset styles globally, and then style most presentation elements (tables, ULs, OLs, etc) based off content sections that a client would have control over. For example, any area that a client can add content via a WYSIWYG, we add either a class or data attribute and style off that.
using a data attribute helps knock the specificity down a bit so it is easier to overwrite later if needed.
Our WYSIWYG editor allows insertion of tables but strips any classes we don’t want – so having default table classes is essential.
I think you should be able to use any element anywhere on a site without classes and for it fit in with the site. That includes all typography and any HTML element accessible from the CMS.
I’d definitely go with a
reset
rule and then use a specificclass
for the tables themselves. Many times I had to use different table styles within the same website/webapp and overriding the default styling is not something handyWhy not utilise the :not selector and set default styles for all tables that do not contain the class of table for example.
We do have default table styles.
Because we’re a state agency, we have a huge site with a lot of data tables. Consistency (and accessibility) is a big deal for us so we don’t want a bunch of customized tables. And we want to make it easy to spot tables that haven’t been coded properly.
The worst part is when trying to brand a third party service. It blows my mind how many of these services use tables for layout – and badly too. For some, every header is a table.
How about a hybrid approach? Use a class for table styles, then mix it in for editor-based content areas:
This isn’t much of a direct solution to the problem, but this really stuck out to me when reading the problem:
Why not remove the Back-End from the markup equation? To that end, there are a ton of different template engines or frameworks for a myriad of languages that can help you separate presentation/markup from the data. This lets you and the Back-End devs focus on what you guys do best.
I have no idea what your tech stack looks like to know if this is a possibility for you. But if I were you, I’d be jonesing for some data API’s :)
Good luck Luke!
Thank you so much for sharing this. I’ve been mulling over this same issue as it relates to normalize.css and sanitize.css. Also, the current (as of this writing) stable release of normalize.css does reset tables, but this was an opinionated reset (and browsers do handle the default table styles consistently) which is why it has been removed will be this way in the 4x release.
I use default styles on my tables in over 90% of the projects I make. Clients and generally people that use the site and fill the content don’t often know how to make things right. So doing it for them is the main issue here. And not only that but I often use jquery to tame the table responsiveness because when I user makes.. Lets say a 12 column table, it gets really messy B-)
I use normalize, and then different classes (e.g — .Table–thin, .Table–wide, etc.) for different styles of table. This habit comes from a previous project where we had many different table styles which had separate requirements. Avoiding a styled default allowed for easier management of the separate styles, less overriding, less confusion all around.
I am in favour of keeping the root table css clean. Where reasonable, I try to avoid scattering child css classes that require the knowledge of their parents.
Not only does overstyling the root table element make it difficult to override (as mentioned), but it also makes modifying the styling of that root table element more difficult at a later date, which I think is an even bigger issue. For example, say if at some point you wish to add alternating row colours to your default table styling. Now, instead of simply updating one class, you now need to go through the website, and ensure that adding &:nth-row(2) { … } didn’t break any of the overrides. With certain larger and more distributed projects, this would become a hassle, especially if a developer is new to the project, and especially if the css is reused on multiple code bases.