I hope I'm not the only one who has nostalgia for tables and frames. There was only one way to center content and it always worked. Now there's a hundred and none ever work without a bunch of Googling and troubleshooting.
I started learning web development back in the day of IE6 and table-based layouts. It's actually incredible how many modern designs I see today that are portraying a table, but have recreated the <table> element (and its associated <tr> and <td> elements) in a soup of flex layout divs and such.
With that said, centering is not difficult. The difficulty comes in not realizing that flex layout is essentially the same rows and columns you used before, but with better controls for wrapping elements (tables can't do that easily).
Edit: Some more nostalgia: Cutting out rounded corners and shadows in Photoshop with the slice tool because there was no border-radius or box-shadow at the time :)
The reason I personally prefer using divs with flexbox is responsiveness, and it gives me more control overall. I've always hated tables, even for tables, let alone to structure a whole page.
Tables are special. The width of a cell is determined by the widest cell in the column. The height of a cell is determined by the tallest cell in the row. I have yet to see a convincing replication of the simplicity of the native <table> element with a flex layout. Consider the colspan and rowspan attributes for additional complexity.
You are right that flex offers much more... flexibility. But tables adhere to a certain set of rules that I don't think is easily implemented with flexbox.
"The width of a cell is determined by the widest cell in the column. The height of a cell is determined by the tallest cell in the row"
I've achieved the same with css grid. I genuinely don't think table are needed anymore, unless you're building a page to display data and don't care about responsiveness.
A grid also has a nice property of maximum 1000 rows, which holds back from bad practices of showing tables entirely. Much easier to find data by paging and a special search box rather than searching through the page.
To my knowledge, there is no implementation for rowspan or colspan attributes in a flex grid. Also, to note, I am not advocating for table-based layouts for non-tabular data.
Parent was talking about grid. You seem to be talking about flexbox but calling it “flex grid” instead – you know grid and flexbox are two separate things, right? Grid definitely has the equivalent of rowspan/colspan.
Yes, and there is no equivalent for rowspan/colspan in a grid or flex grid without resorting to CSS modifications in the former and nested containers in the latter.
What are you referring to when you say “flex grid”? There’s no such thing as “flex grid” in CSS. There’s flexbox, and there’s grid. These are two separate things.
I’m not sure what you mean by “resorting to CSS modifications” – surely that’s a given, considering we’re talking about writing CSS?
You don’t need nested containers to do the equivalent of rowspan / colspan with grid. It’s pretty fundamental to the entire feature. You can tell the browser where an element begins and where it ends with grid-column and grid-row. That doesn’t have to be a single grid cell, it can be many – it can span across multiple rows or columns.
My biggest problem with tables is that I can't control in which columns the additional space goes with a table wider than content, e.g. when table has style width:100%
Often this should be the "description" column and not the "number of items" or "price" columns.
I'd really like a "flex-grow" for table columns.
(And I can't use display:grid as it doesn't have running headers/footers for PDF files)
I was having so much fun also with Coffee Cup HTML Editor and its "DHTML" widgets. Slice in Dreamweaver, export, open in Coffee, add useless widgets, re-export, drag and drop the horrendously generated HTML file in random ftp program and voila, you have something that maybe works on a specific version of IE but a lot of fun.
> It's actually incredible how many modern designs I see today that are portraying a table, but have recreated the <table> element (and its associated <tr> and <td> elements) in a soup of flex layout divs and such
To play devil’s advocate, <table> can be frustratingly inadequate even for tabular data, if you want to add some bells and whistles.
Things like resizable/reorderable columns aren’t too tricky, but if you want things like sticky rows or columns things get very messy very quickly.
I’m convinced that the negative qualities of modern web development stem from the built-in controls being largely stuck in 1995.
nothing which has been done since table-based layout has an intuitive and cross-browser way for doing vertical and horizontal centering. that's what i think GP meant.
i do not want to see tables back but i do admit that they did exactly, and intuitively, what you would expect of them.
<div class="box">
<div>this is centered vertically and horizontally</div>
</div>
also, using tables for layout isn't semantically correct. it's like using `map` as a for loop. also, consider folks with disabilities who rely on screen readers.
Centering has been an easily solved problem with both flex and grid for years. If you’re having trouble with conflicting styles, you can revert them with, well, revert. You can even revert all of them with revert: all. But I don’t recommend that. If you’re still having trouble centering things I’d recommend getting familiar with the cascade and removing styles that conflict with what you’re centering.
Definitely! For all the knocks against tables for layout, we're only beginning to approach the simplicity of that approach after many years. (It's even a stretch to call CSS Grid and Flexbox simple.) You could get so far with a few tables and spacer gifs -- if you looked past the semantics.
i know I’ll get downvoted for saying this because there are a lot of front end developers on here who fail to question the sanity of their tools but the current mess with <table> (and most of front end development) is an acute suffering from not invented here syndrome.
Why have a construct purposely for tabulated data when you can reinvent the wheel with a nightmarish array of divs and complex CSS. /s (honestly though, before anyone does mod this post down, pause for a moment and ask yourself this question. If you have a good answer then I’d love to hear it).
The problem is web development went too far down the CSS “all the things” route and instead of using it for styling, developers use it for near enough the entirety of web layout. Which makes no sense when you have data that needs to be structured in specific ways (namely tabulated data). In those scenarios the layout is as much a part of the content as the data itself. Thus CSS there should be used to make the tables attractive rather than using CSS to construct the tables themselves.
I’m not saying <table> doesn’t have its warts but really what should have happened was those warts fixed rather than creating a whole new set of warts and complexity with divs. Again, before anyone votes me down, pause and try to answer this question yourself.
Obviously divs do have their benefits elsewhere in web design; I don’t miss using tables for general purpose layouts. But for tabulated data tables are absolutely the right tool… or at least that should have been the case if sensible people were left to define pragmatic web standards.
I'm not saying there aren't some devs who fit in the box you describe, but semantic HTML is an important part of web dev and many front end devs still ascribe to it. As you said, tags have meanings and we should use the appropriate one for the appropriate thing.
And there are most definitely ways to use even the table tag responsibly (and responsively, although that is harder).
And that is absolutely the standard. Just because people ignore it doesn't mean the standards don't exist. Random blog posts do not change that.
The article we are commenting on was specifically written around 2006 to discourage tables from being used for layout, which was a common approach at the time.
Some people can construct tables from P tags for all I care. It doesn't mean it's common amongst professional developers and it doesn't mean it's correct.
Up until CSS was a viable thing, people built websites in a very different way to our modern approach.
In order to get things to line up, everything was put in a table with invisible borders. If there was a gap, a transparent spacer.gif image was used to plug it.
A lot of people liked this way because it was easy to understand, and they were used to it .. but we were effectively hacking the main semantic purpose of a table element to use it for layout ...
.. also there was no separation between the presentation and content layers.
CSS Zen Gardens signalled a turning point, and was designed to help show the power provided by CSS.
That doesn’t answer the question though. I doubt many developers would be in favour of using tables for layout over divs. however the same doesn’t apply for why one must use divs for tables (ie actual tabulated data) instead of tables.
Bugs me when people use divs to do tabular data display when there’s a perfectly excellent <table> tag. Copy pasting div based tabular data from a web page into a spreadsheet or document is made nightmarish. For layouts, sure, use flex or whatever, but not for data!
I do have this nostalgia remembering my first tr/td spaghetti codes. However, it was never really usable for visually-impaired people, and flex/grid give me proper responsiveness now that 4:3 displays aren't the only way to browse content.
You aware that you can just define a container as display: table-cell and then center stuff in it the old way - at least i remember doing this 10years back or so to solve centering issue I just couldn't get right... (Pardon if above isn't valid css)
I don’t mean to be rude, but if you can’t center content without googling and getting frustrated, you might just need to slow down and take 5 minutes to actually learn how to do it, and let it sink in once and for all. It’s been very straightforward for several years now. The idea that it’s difficult is just an old meme at this point.
Zen Garden is a great demo that shows what you can do with the self-imposed restriction of "you're not allowed to change the HTML", all your styling fits into a single small self-contained CSS file and you only need to style an article, navbar and some side panels but this doesn't make it a good approach for styling highly custom responsive designs for single page apps that have many UI components when working in large teams.
Experienced developers that understand CSS well have tried for years to make the Zen Garden approach work for complex cases but solutions like e.g. Tailwind and Bootstrap (where semantic HTML tags should always be used regardless) have been invented and risen in popularity as they scale well to complex cases. It's not because developers are lazy, don't understand CSS and aren't aware of current (and always evolving) best practices.
When screen readers and search bots will still understand the semantic HTML tags no matter what styling approach you use and you don't need swappable themes as a core feature of your site, why would you impose the restriction on yourself that you can't modify the HTML as you're changing the styling if you find it comes at a cost to development efficiency? Your docs and data are usually going to be stored and marked up in JSON, XML, Markdown, a database etc. then transformed into semantic HTML so you're still keeping data and presentation separate in this sense (and styling this core content of articles and blog posts is the easiest part of styling), but why try to separate content and styling further than this?
Can we flip this for a bit? What would be of web as an application development if swappable themes was a requirement?
- Wouldn't it be easier to have WebComponents as an actual useful technology?
- Wouldn't it be easier for browser engine developers to have an "strict mode" of sorts that could run optimized code for actual apps?
- Wouldn't it be easier to develop client-side code for other languages that would deal with nothing but business logic, instead of forcing us to come with something like WASM?
- Couldn't web clients perhaps come bundles with a set of these web components and styling themes, and wouldn't perhaps the browser be efficient enough to allow us to ditch mobile-clients?
- By not having to support multiple clients and platforms, wouldn't we be able to avoid re-inventing JSON as a poor version of X(HT)ML?
- Wouldn't the web be a lot more programmable and mash-able and lead to a lot of these server-side functionality to not be needed in the first place?
Hmm, if we were to really support user-swappable themes, one of the first major problems that comes to mind, is how do you split what the user should change vs what they shouldnt. Where do you draw the line, and then how do you make sure the user doesn't break things, only styling, and styling in a manner that leaves the interface still fully workable, with the worst offense being it might be "ugly".
Honestly, I am not even thinking about user-styling, only about setting some stricter separation between styling and structure for the browser. My dream world would be one, like in Zen Garden, be based on two principles:
- the designer has no way to alter the document body structure, only the header for CSS file declarations.
- Any kind of feature/effect that the designer could only achieve by changing the structure should be considered a P0 bug by the CSS engine developers.
Maybe if CSS had more features to work with pseudo element hierarchies rather than just ::before and ::after it might be viable to have the markup be the bare minimum semantic elements.
> it might be viable to have the markup be the bare minimum semantic elements.
Why is this goal worth prioritising though? It doesn't impact screen readers or search bots for example.
The major problem with CSS + HTML in my opinion is how to write it in a way that's easy to maintain and extend. More CSS pseudo elements could easily make that worse.
This reminds me of a small experiment I did with a friend, where we asked different people to independently write the HTML and CSS for a website (without communicating), and then put the HTML and CSS files together to see how well they worked. https://kach.github.io/generative-adversarial-web-developmen...
Back then it was more about getting people to use CSS better (learn about it) and to use separate files (use classes not inline styles).
Back then, pages were rendered on the server and in many cases there wasn't much templating either. People would normally have their sql query code, their business logic, and the html in the same function in a file >5k lines long.
Bsck then it made perfect sense. Now, considering everything else that's going on in Web development (JS explosion), perhaps not so much.
Weirdly where I honed my CSS skills was as a Reddit moderator. You had no control over content, but could style anything and everything, and a lot of subreddits had very custom styles. I’ve never done so many :after and !important hacks in my life.
basically the major difference being that you have a css editor inline so you can prototype and see changes immediately, save it to gist and publish a URL so others can see your changes too. No PR process needed to some central authority!
I spent winter break in 2011 reading Zen Garden and learning CSS! It was so useful in the next seven years of my career to be able to write CSS as easily as English.
Was introduced to the site my freshman year of university ~2016. Our web professor used it as a project for getting everyone more familiar with CSS in the intro web course, and each student had to come up with a different design. I ended up making the page look like a text editor and REPL if I remember correctly. It was a lot of fun and a good learning experience!
