CSS Zen Garden: A demonstration of what can be achieved through CSS-based design
csszengarden.com
csszengarden.com
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 :)
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.
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.
Please just make it optional to show all, I already have a regex search extension.
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.
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)
Dreamweaver and it's auto-slicing and table layout function was insane. So many bad web designs were created by me with it.
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.
.box { display: flex; align-items: center; justify-content: center; width: 500px; height: 500px; }
.box div { width: 100px; height: 100px; }
<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.
.. nicely triggered for a moment!
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.
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.
I really don't understand what you're trying to say.
There’s plenty of comments in this discussion from developers saying they specifically don’t use <table> even for tabulated data.
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.
If you don’t care what those other developers do then why bother replying to me in the first place?
That's why.
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.
CSS gardens was created specifically to stop people from using tables for layout.
CSS Zen Gardens is from around 2006.
I know when Zen Gardens was released. That fuck all to do with the discussion though.
And can you please limit your replies to one thread rather than spamming the same comments on multiple threads.
You chime in with a point that's not actually related to what I was talking about.
I let you know.
You get annoyed.
I think you need to simmer down.
Have you done a 'View Source' on the HN page?
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?
- 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?
- 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.
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.
CSS Zen Garden - https://news.ycombinator.com/item?id=22627018 - March 2020 (217 comments)
CSS Zen Garden relaunched - https://news.ycombinator.com/item?id=6076163 - July 2013 (47 comments)
CSS is for design, HTML is for content - CSS Zen Garden - https://news.ycombinator.com/item?id=811468 - Sept 2009 (3 comments)
We almost had a P2P semantic web. (Web 3.0)
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.
url: https://svelte-zengarden.netlify.app/?path=https://gist.gith...
video: https://twitter.com/swyx/status/1220895891860676608
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!
So many ::before and ::after's though...
TO answer your question, these were written by hand and you can see that from the code.