Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
You know, being completely honest, I hadn't thought of it. But I did just spend a few minutes playing around with it, and my initial impression is that it wouldn't get the job done without requiring a few layers of wrapper <div>s and a lot of finicky margin, padding, and border styles, and at that point it's basically just HTML tables, but implemented with <div>s and a huge amount of CSS.
But take this with a grain of salt, because I admittedly have very little experience using display: table and its ilk. If you have more experience, please give it a shot, fork one of my pens up there and see what you can do! I'd love to learn about it, I really haven't seen it used very often
Hm. Do you have the HTML <table> implementation as a pen? It does let you skip setting anything to display:table-row so at the very least it could skip one nesting level.
I used CSS tables more back when I had to fully support IE8, but other than that, they’re mostly obsolete.
Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
So, funny story, I played around with it a bit more, and it tickled my memory enough to remember (because I encountered the same problems again) that I actually had tried to use the display-table method when I was implementing basically the same layout for my job. There are a few different ways to approach this, and each has a fatal problem. In all cases, I'm using display: table for the <main> element (so that the table includes all the cards) and display:table-cell for the counts.
If you don't use display: table-row anywhere, it sort of just doesn't work. The problem seems to be that the .article-card element, which is display: block by default, gets in the middle and breaks the CSS table. Looks like it's true that you can skip explicit table rows in a CSS table, but only if the table cells are direct children of the table element. pen
If you make give cards display: table-row, the browser wants to put all children on the same line. Which, honestly, produced kind of an interesting layout that I'll keep in mind for future experiments, but doesn't match the mockup. Another issue is that the cards now inherit a lot of the same issues that make working with HTML table rows hard, mainly that rules like margins, borders, and padding aren't supported. pen
Just to see if I could make it work, I tried giving the article cards display: contents and adding wrapper elements around different parts of the card with display: table-row. Ignoring the problems I mentioned in the display: contents part of the article, I also ran the problem you mentioned earlier: the absence of a colspan type rule. The problem is that the header is wider than any count, but ends up in the same column as one of the counts. pen
CSS Tables are cool, and might even be a valid solution to this sort of situation if the contents of the card could be a single line, using the cards-as-rows approach with some tweaking for style. But if you need multiple rows within your cards with different sized elements on the different rows, the lack of a colspan is gonna be a problem 😕
Wow, super in-depth follow-up. Thanks for your time!
The lack of borders and padding might/could be fixed with display:table-row-group and border-spacing.
Making the headers full-width might work by leaving them out of the table layout algorithm — leave ’em as block, and reorient where the cells start by abusing writing-mode. (I’ve done things I’m not proud of.)
…but all that’s definitely deep in the weeds of hackiness. (And let’s not talk about display:table-caption, which hoists the child box out of the border-box of its parent.)
If the CSS Table Layout specification had equivalents to colspan and rowspan, we would have been halfway to Grid in 2009. But I can’t blame them for underspecifying the weirdest, most browser-specific layout system ever accidented.
Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
Good idea, forgot about display: table-row-group, that does make the borders somewhat work again.
But leaving the header and .top wrapper as a block doesn't fix the colspan problem, which is now manifesting in a really weird way... Without checking the spec, it feels like the children of a table-row-group are in some sort of all-or-nothing pact, where if any one of them is given display: table-row (and has at least one table-cell child?), they all act like table-rows with table-cell children. But if none of them have a table display type, they act like blocks, even if one has table-cell children...
Yeah, I have mixed feelings about CSS Tables. I almost think it's better that it was kept small and arguably incomplete; maybe its holes helped motivate CSS Grid? Maybe if it had been more complete, people would have continually pointed to tables whenever someone brought up Grid, the same way some currently point to display: contents when someone mentions subgrids. But on the other hand, if we're going to have a table layout system anyway, might as well make it fully functional. Maybe they could augment it now to complete the picture.
Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
By the way, thanks for the replies, it's been very interesting! I forget that CSS Tables are a thing, and they're worth remembering for those odd corner cases
Ken, thanks for giving a great and detailedwrite-up on the need for subgrid.
I've been frustrated by the lack of subgrid on grid frameworks for a while now.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You know, being completely honest, I hadn't thought of it. But I did just spend a few minutes playing around with it, and my initial impression is that it wouldn't get the job done without requiring a few layers of wrapper
<div>s and a lot of finicky margin, padding, and border styles, and at that point it's basically just HTML tables, but implemented with<div>s and a huge amount of CSS.But take this with a grain of salt, because I admittedly have very little experience using
display: tableand its ilk. If you have more experience, please give it a shot, fork one of my pens up there and see what you can do! I'd love to learn about it, I really haven't seen it used very oftenHm. Do you have the HTML
<table>implementation as a pen? It does let you skip setting anything todisplay:table-rowso at the very least it could skip one nesting level.I used CSS tables more back when I had to fully support IE8, but other than that, they’re mostly obsolete.
So, funny story, I played around with it a bit more, and it tickled my memory enough to remember (because I encountered the same problems again) that I actually had tried to use the
display-tablemethod when I was implementing basically the same layout for my job. There are a few different ways to approach this, and each has a fatal problem. In all cases, I'm usingdisplay: tablefor the<main>element (so that the table includes all the cards) anddisplay:table-cellfor the counts.If you don't use
display: table-rowanywhere, it sort of just doesn't work. The problem seems to be that the.article-cardelement, which isdisplay: blockby default, gets in the middle and breaks the CSS table. Looks like it's true that you can skip explicit table rows in a CSS table, but only if the table cells are direct children of the table element. penIf you make give cards
display: table-row, the browser wants to put all children on the same line. Which, honestly, produced kind of an interesting layout that I'll keep in mind for future experiments, but doesn't match the mockup. Another issue is that the cards now inherit a lot of the same issues that make working with HTML table rows hard, mainly that rules like margins, borders, and padding aren't supported. penJust to see if I could make it work, I tried giving the article cards
display: contentsand adding wrapper elements around different parts of the card withdisplay: table-row. Ignoring the problems I mentioned in thedisplay: contentspart of the article, I also ran the problem you mentioned earlier: the absence of acolspantype rule. The problem is that the header is wider than any count, but ends up in the same column as one of the counts. penCSS Tables are cool, and might even be a valid solution to this sort of situation if the contents of the card could be a single line, using the cards-as-rows approach with some tweaking for style. But if you need multiple rows within your cards with different sized elements on the different rows, the lack of a
colspanis gonna be a problem 😕Wow, super in-depth follow-up. Thanks for your time!
The lack of borders and padding might/could be fixed with
display:table-row-groupandborder-spacing.Making the headers full-width might work by leaving them out of the table layout algorithm — leave ’em as
block, and reorient where the cells start by abusingwriting-mode. (I’ve done things I’m not proud of.)…but all that’s definitely deep in the weeds of hackiness. (And let’s not talk about
display:table-caption, which hoists the child box out of the border-box of its parent.)If the CSS Table Layout specification had equivalents to
colspanandrowspan, we would have been halfway to Grid in 2009. But I can’t blame them for underspecifying the weirdest, most browser-specific layout system ever accidented.Good idea, forgot about
display: table-row-group, that does make the borders somewhat work again.But leaving the header and
.topwrapper as a block doesn't fix thecolspanproblem, which is now manifesting in a really weird way... Without checking the spec, it feels like the children of atable-row-groupare in some sort of all-or-nothing pact, where if any one of them is givendisplay: table-row(and has at least onetable-cellchild?), they all act liketable-rows withtable-cellchildren. But if none of them have a table display type, they act likeblocks, even if one hastable-cellchildren...table-row: pen.countshastable-row: penYeah, I have mixed feelings about CSS Tables. I almost think it's better that it was kept small and arguably incomplete; maybe its holes helped motivate CSS Grid? Maybe if it had been more complete, people would have continually pointed to tables whenever someone brought up Grid, the same way some currently point to
display: contentswhen someone mentions subgrids. But on the other hand, if we're going to have a table layout system anyway, might as well make it fully functional. Maybe they could augment it now to complete the picture.By the way, thanks for the replies, it's been very interesting! I forget that CSS Tables are a thing, and they're worth remembering for those odd corner cases
Thanks for the write-up and for not flaming someone for mentioning CSS tables. Open inquiry has not been the norm and you're doing good work here.
Ken, thanks for giving a great and detailedwrite-up on the need for subgrid.
I've been frustrated by the lack of subgrid on grid frameworks for a while now.