> There is also absolute and fixed positioning as a hack to bypass layout.
They're not hacks, and they don't "bypass" layout. `absolute` and `fixed` are two of five options for positioning that dictate how an element is placed and behaves in the flow of the document, or within a specific container. https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...
That's a useful MDN page, and it's even the third page of the "CSS Layout" section of "Learn Web Development."
And yet, how many people reading these comments have ever seen that page? I'll admit that I hadn't seen it!
Sometimes it's nice to read the docs of your tools from the top down, rather than relying on whatever local section of documentation Google sends you when you're solving a specific problem. There are a lot of great docs! (If you use Git every day, when was the last time you browsed the Git manual? How about JavaScript? CSS?)
You're talking about docs here as if they're like a textbook on Calculus. Thorough, constant and unquestionably effective.
Online docs are nothing like this.
First, they can change as frequently as every few weeks, so there's no point in studying them exhaustively if they'll be useless after the next update.
Second, they're often inferior to Google's answers on the topic, especially if you're using your question as the search query.
Third, even if they are current and the best text resource available, they may still be bad. Halfhearted explanations or even whole pages saying "content should go here." Often worse than simply asking for an explanation in a Slack or a Discord.
I don't think that would be true of an engineer with a physical tool, but it's often true of software tools.
Well, it's not so much that people don't read docs, but that they don't keep reading them. Most people probably read (or at least skim) the manual cover-to-cover when learning a new tool. But once you're actively using it, the main interaction with its docs is when you land on a specific page to solve your immediate problem. I'm advocating for periodically reading the docs of your most commonly used tools, as if you were a new user. You'll pickup something new nearly every time you do that.
> I'm advocating for periodically reading the docs of your most commonly used tools, as if you were a new user. You'll pickup something new nearly every time you do that.
> CSS layout [...] has 4 different layout systems: table, the oldest one, still used for email [...].
Nooot exactly? Literal HTML table markup is indeed probably the oldest way of laying parts of webpages side by side and is still used for email, but that has little to do with CSS.
In CSS, you have display: table and related values, but IIRC they were less usable on old IE versions than floats and received fairly limited use; certainly not nearly as much as literal non-semantic tables. I haven’t noticed them receive much use on the modern Web, either, and I don’t really know why—perhaps the requirements on the surrounding markup are too stringent (there’s no way to reorder things, for example, and if you need multiple rows you’ll need to include some sort of elements in your HTML to play that role).
Table isn't a CSS layout system. Table layouts abused the HTML table element because CSS didn't support such layouts. The problem was it became impossible to distinguish between a real table in a document and one that is just used for layout.
Personally I find grid more complex - but perhaps I just haven't used it as much compared with flexbox. The vast majority of the time, I find that elements within a particular component (here meaning chunk of UI, not a React/Vue/Svelte etc module) naturally fit along a single axis.
> Floats can be used to position boxes to the left and right edges of their container box
No, that's not exactly what float means! Yes you can accomplish this using floats, but we haven't since flexbox and grid landed. The element is taken out of the normal flow, and this is a confusing way to build layouts for those studying CSS.
`float` is more of a typographic tool. If this article calls itself pedantic, it needs more pedantry.
Any introduction to HTML/CSS really should explain the fact that when these technologies were created, they were solely meant to render documents online. It was basically created to be like a Microsoft Word but for files on another person's computer. So most of the early properties (like float) were for typographic layout.
It is, after all, HyperText Markup Language. The modern app-based web is incredibly far out of scope of the initial vision of “text documents that link to other text documents.”
CSS and HTML are loaded with legacy warts that can never be removed without breaking backward compatibility.
Old HTML/CSS might be out of scope for a modern web app but I’m pretty sure if you were to write a layout engine from scratch today, it wouldn’t look any different from modern HTML/CSS
Honestly layouting an app in code just looks like HTML/CSS but with functions.
All elements in a container floats to the top of the container and right or left (depending on the text direction ltr or rtl) of the previous element. If there is no space left it will move below the previous elements.
If an element has `display: block`, it will fill up all horizontal space so every element after it will float below that element.
That is why it is called `float`. It's how the position of elements is calculated.
If you use `float:left|right` it forces the float of that element to float left or right before all other elements in the same container.
That is what float means.
But of course this does not work anymore if your container uses flex or grid.
A large portion of Chapter 1 (https://book.mixu.net/css/1-positioning.html#float-positioni...) is dedicated to the intricacies of floats and their special flow, explaining how their behavior can be carefully reused and adapted for alternative purposes. I'd say that's as pedantic as anything can be, especially given the lack of flexbox/grid layout when it was written.
I'm not sure how I’d position, say, sidenotes/marginal notes without using floats. Particularly when the note must align with a reference in the middle of a paragraph.
I find articles like this daunting, even when it predates CSS Grid which has made CSS Layouting even more complex. I have been a web developer for 10 years, and I still feel out of depth about CSS. How it all works, obscure edge cases, internals, and the sheer number of features in there. I wrote about it recently [1]
> I hadn’t even completely caught up with the intricacies of Grid Layouting, when subgrid and container queries were shipped. Several of the newly added properties handle cases so specific that I hardly believe I would ever use them (hanging-punctuation and font-palette, for example).
> Here’s more: there are at least three properties related to hyphenating paragraphs. You might have used the filter property, but did you know that it supports an entirely different class of filters using SVG? Or that you can tweak the image scaling algorithm? Or border-radius support elliptical corners?
Of course, you can say that about any technology, but CSS is different. It handles too many things, in too many ways, and changes too much, too fast.
> I have been a web developer for 10 years, and I still feel out of depth about CSS.
What do you mean by this? I've been dealing with CSS for even more years than that and can't for the life of me remember if its align-items or justify-content cause I won't even try to.
Grid I remember even less! But I still don't feel out of depth because I can get it to do what I want easily enough with a couple of scoffs and WTFs here and there.
I've heard this about CSS so many times, but honestly, I find it kind of easy to do get the layout I want without too much effort most of the times, I just don't remember CSS in the same way I remember how to do JS.
If you're interested in CSS layouting, consider learning Flexbox and then CSS Grid first. These are both relatively straightforward with good documentation and relatively few quirks (esp. grid).
You don't really need flow layout at all these days. And you can certainly skip floats and table layouts entirely (use them only for their originally intended purpose of floated images within textual content and literal tables).
My perennial problem with frontend work is that all the articles are written for an audience of people who have been keeping up with the state of the art for the last 15 years.
The first time I wrote actual frontend things in exchange for USD, I was generating "DHTML" (my fingers stumbled over even typing the abbreviation because it's flushed so far out of my muscle memory cache) directly from perl. I know frontend stuff like a six year old knows calculus, and I feel like there's no way for me to catch up now.
The big shift has been to Single Page Applications (SPA) either indirectly using a framekwork like React, or Angular or using the Javascript fetch() directly. So this also means that links (within your website/application) go away. This avoids page reloads, and it feels more like a desktop application.
The foundation is modern Javascript, another big new concept is async/await, combined with the fetch() calls so the entire screen doesn't lock up while your'e waiting for it to return
The other big shift is using CSS framekworks. Big ones now are Bootstrap and Tailwind.
I'm actually working on making a video with a live coding experiment making a small social networking site with some modern practices.
But some people still persist in doing the old way - e.g. Wikipedia. And Hacker News isn't an SPA from what I understand
Also, the "old way" has started to make a comeback with Server Side Rendering, as the compiled Javascript files using frameworks can get up to several megabytes and its taking too long to load the site.
There are so much changes for the last 15 years. You don't need to learn all that path. You need to learn modern web development from scratch, ignoring history.
Right now, modern web development is:
- Yarn/PNPM as package manager
- TypeScript as a programming language
- React as UI framework/library
- React Router for navigating multiple pages
- UI kit (I personally have good experience with React Material UI - https://mui.com/; there is also https://tanstack.com/)
- Something to deal with fetching data (tanstack query client is cool, provides caching out of the box)
- Something to deal with forms if you have that
- Maybe a store for managing data when it's too complex (see https://redux-toolkit.js.org/api/createSlice)
- And ofc, there are some templates/frameworks that bring something of that together (https://create-react-app.dev/; maybe https://vitejs.dev/) - google for templates.
I recommend finding some friend with modern experience or at least some youtube tutorials or at least some learning course. That would help you to catch up on the best way to bootstrap your first project. Then you can practice.
There's a whole lot of frontend content written for complete newbies, as well as stuff written for people who have been keeping up; if you are an experienced programmer who hasn't been keeping up with frontend stuff, you'll probably need to use a mix of stuff written for people with less programming experience than you have and stuff written for people with more frontend experience, but catching up isn't making up for the intervening time you weren't engaged, because while a tiny fraction of the knowledge of frameworks that has come and gone went into shaping context for the "always current" people learning the new stuff, a large fraction of it is just knowledge that is no longer relevant.
I develop a lot UI apps (mostly Angular) and these days I just use a framework like Bootstrap or Foundation. The myriad of layout options in pure CSS is overwhelming and mind boggling, especially when it comes to responsive design. I have tried using pure CSS but find myself writing lots of boilerplate code and coming up with amounts to a mini framework. Unless you’re designing a custom bespoke designer web site, I don’t personally see the need for constantly reinventing the wheel.
There's still some boilerplate, but I'm a big fan of Open Props[0] because it takes a hybrid approach. CSS isn't necessarily reinventing the wheel, but allowing for easier / more powerful approaches to difficult layouts or things that would otherwise require JS. Bootstrap is fine but troubleshooting advanced layout issues involves a lot of inspecting elements to see what styles are actually being applied (at least in my experience, YMMV) so I'd personally always bet on CSS.
A new feature that I'm excited about is the `@scope` rule which is going to make scoped styles a lot easier.
Yes and no. The key selling point of Bootstrap (and similar) was that a design-blind (so to speak) backend dev/eng could use it and would have to work very hard to "design" something that was ugly, hard to look at, hard to use, etc.
Sure there are a bunch of helper classes, and such, but the key is an end product that does look like a backend dev/eng built it.
The core of CSS, and principles that new CSS features follow, haven’t really changed in decades. It’s just been built upon and refined.
Given these articles are looking an underlying principles of the CSS layout process, I wouldn’t worry about it being out of date. Everything it covers certainly hasn’t changed (because so many websites would be very broken if they had), and new CSS will be built on the fundamental principles laid out here. So even if it doesn’t cover stuff like grid, it will definitely provided much need background information to help you understand the details of how grid works, generally build a better intuition around how both old and new CSS features work.
The core of CSS absolutely has changed. Unless you're building a mobile-only site, you're likely using media queries today to target multiple viewport sizes, which wasn't on anybody's radar in 2006.
Much of these changes in CSS have simply beeen obscured by improvements in cross-browser compatibility and use of layout frameworks that hide all the complexity behind simple class names.
In the 2000s, sites were built with the <table> element to simulate a grid.
In the 2010s, it changed twice, first by using floats and CSS reset methods to create responsive columns. Then that went away in favour of Flexbox and Grid, which now have wide browser support.
If you're building sites for IE6 compatibility, then things probably haven't changed much.
> The core of CSS absolutely has changed. Unless you're building a mobile-only site, you're likely using media queries today to target multiple viewport sizes, which wasn't on anybody's radar in 2006.
These two sentences don't really follow from each other? Gaining additional features isn't necessarily the same thing as the core of a technology changing. The actual core of CSS would be things like its box model, stacking contexts, specificity, etc.
And ironically you can in fact achieve responsiveness without using media queries. That's arguably the entire point of more sophisticated layout algorithms like flexbox and grid.
> And ironically you can in fact achieve responsiveness without using media queries. That's arguably the entire point of more sophisticated layout algorithms like flexbox and grid.
Flexbox and Grid? They're certainly helpful, but not required! I remember trying to achieve a responsive layout in IE6 that IIRC only had limited support for min-width/max-width. It was possibly even back then, although I can't remember how it was done off the top of my head.
Definitely! When I say it's the point of flexbox and grid, I mean that they remove the need for the dev to do the manual width and bounds calculations (much like being able to just say how items should be aligned in both axes removes the need to do margin or positioning shenanigans). But it was all very possible with basic flow layout
This article prioritises understanding older layout techniques which has some value when dealing with a legacy code base, but should be avoided on new projects
I've found the best way is to build things over and over again. That may reflect a certain learning style but actually manipulating styles and layouts really helps hammer home the practical aspects of how it works.
I also approach writing CSS with the goal of writing as little as possible. Not because I don't like it - I tend to think it gets an unfairly bad rap - but because it teaches you how to more effectively style layouts without layering too many declarations.
I feel like this type of thinking is why 99% of people don't understands css though, when you are just building things you make up rules that don't exist and ignore the ones that do. And its not as straight forward as programming languages are so its very hard to tell when something is "wrong".
Yeah, maybe my suggestion could've been better stated. I'm not suggesting that you can ignore documentation and other forms of writing that explore paradigms and methodologies. I meant there's only so much you can read before actually writing CSS and practicing making layouts becomes a necessary part of learning CSS in depth.
And, to play devil's advocate a little: You can't make up a rule that doesn't exist. Either your CSS will work or it won't. And if it works it's not wrong.
> You can't make up a rule that doesn't exist. Either your CSS will work or it won't. And if it works it's not wrong.
So much this. Over the course of years, I've gone from writing my CV in Word, TeX, and (finally) straight HTML. Word processors are fairly straightforward -- and yet -- for more complex layouts you will eventually encounter internal sizing constraints that require messing with the global template.
This reality - combined with the fact that MS Office is a gigantic monster which is barely tolerable on macOS, led me to TeX. Plaintext -- more or less -- and good support for integrating with version control systems made it an easy choice.
Fast forward a few years and I'm all HTML + a handful of CSS rules w/ @print at this point. Cryptic error messages and the care and feeding of a BasicTex install just became too much work to bother with. At least in HTML, save for a showstopping error, your document will render something and the errors are usually pretty obvious.
Not so much in TeX...
Modern layout also meant I could ditch floats for nearly everything - flexbox will create reasonable page headers with much less gnashing of teeth.
This week I am refreshing my front-end skills, so I did a little market research.
The best resource on CSS basics, I have found, is https://web.dev/learn/css. It includes flexbox and grid.
For design guidelines I recommend Refactoring UI. It is full of actionable advice, which books such as The UX book is lacking.
In my project I use TailwindCSS (by the author of Refacturing UI) with Daisy UI components, so I don't actually write raw CSS. At first TailwindCSS feels like a step backwards to inline CSS, but it is just better than the alternative. I recommend giving it a chance.
The former is not meant as a learning resource for new web devs. And the latter (which is neither official nor authoritative) usually has information about the "baseline" support and browser compatibility tables.
The former, I'm not really new just looking to increase my understanding of some concepts and learning from that has not been too fun. I don't think MDN goes in depth as much as I'd like it to.
Learn flexbox. Learn the box model (especially when to use margin vs padding). Learn how style cascading works (and why we use SCSS and component development to mostly avoid thinking about it). Learn media queries and how to target different screen sizes. Most of all, don't ever feel badly about doing a web search “how to do x in css”, the spec is huge with tons to remember and you won’t memorize everything without using it regularly for an extended period of time.
I attempted CSS back when you had to float anything/everything for positioning and found it extremely confusing. I recently picked it back up, and flexbox and grid make it sooo much easier. I feel like I'm finally getting it.
Learn page layout and graphic design principles. A lot of CSS is spec'd to support these disciplines and it will make a lot more sense if you are familiar with them. The main reason developers have so much trouble with CSS is that they don't understand the problems it is trying to solve.
Best way to learn is to build sites with experimental layouts. You'll get stuck and thats when you'd want to look around the documentation or Stack Overflow. MDN docs are the incredibly dry, so avoid them until absolutely necessary.
> How can you do web development or even React if you don't understand CSS?
I wrote my first line of CSS more than 20 years ago, have dug my way through CSS specs and browser quirks a countless number of times, write a ton of CSS in my day job, and even I wouldn't claim to really understand CSS.
There are just too many hidden rules, too many edge cases, to really ever be certain you have now understood everything there is to understand.
EDIT: I mean, consider this guy's recent blog post[0] for instance. He claims that CSS is logical and, presumably, that he understands that logic. Yet his article contains a number of factual errors, as mentioned in the HN comments. Nevertheless, he writes about CSS on a regular basis, so I'm sure he understands a great deal about it. In other words: In the world of CSS, even experts and experienced veterans are prone to not understand everything in detail.
>I wrote my first line of CSS more than 20 years ago, have dug my way through CSS specs and browser quirks a countless number of times, write a ton of CSS in my day job, and even I wouldn't claim to really understand CSS.
There are just too many hidden rules, too many edge cases, to really ever be certain you have now understood everything there is to understand.
Complete ditto. Been using it daily for a decade plus, and I could literally lay out a page perfectly while blindfolded at this point. But I would never claim to be a CSS "expert". Simply too many gotchas.
> he writes about CSS on a regular basis, so I'm sure he understands a great deal about it.
Don't be so sure. The world is full of people that excel at the fake it til you make it skill. As long as you say it loud and full of confidence, people will just tend to accept whatever you're saying. Anyone that comes along and challenges will just be dismissed as a hater or similar. In software dev, these types tend to migrate upwards into management
Because understanding of CSS doesn't helps you in the most cases.
Just return to the ages when we needed to support Chrome+Safari+Firefox+IE+custom mobile browsers (it wasn't long ago). All those engines had so many bugs. Understanding CSS won't help you deal with cross-browser compatibility. This is why we have things like caniuse.com and autoprefixer.
Go a little more back in time. CSS doesn't have a lot of capabilities. Some things can't be achieved at all. Other things can be done quickly via mix of CSS and JS code to update layout; otherwise you need to spend a week to achieve something worse with pure CSS. Even now, we have things like react-motion, react-transition-group - libraries to solve cases that CSS transitions&animations can't solve. (Should we talk about DND?)
In past CSS didn't had Flex-layout widely adopted. This is why there were JS libraries solving layout stuff. We still have libraries that provide list virtualization. Even with the CSS `contain` property (which arrived in 2017 and wasn't widely adopted even in 2021), working with DOM is not cheap.
We didn't have calc() and CSS variables. We still don't have CSS nesting widely adopted. This is why we have LESS & SASS. (Should we talk about CSS modules?)
And ofc, CSS is pretty useless for quick prototyping, you need a UI kit. UI kit means a conceptually different approach than using raw CSS - you don't need to do CSS a lot, but you need to learn UI kit a lot.
Finally, if you are building a product, you deal not only with styling. It's not a landing page, it's not a one week hobbie project -> you need to code a lot. If you are bad at styling, you are bad at ~10% (maybe ~20%) of your work. And considering all the things that we said before, if you are bad at understanding CSS, you are bad at ~1% of your work.
To sum up. You can make beautiful products with little CSS knowledge because CSS alone is useless.
Kind of unrelated but if you want to build nice modern layouts and if you are one the 10 people in the planet that doesn't use Tailwind take a look at sub grids. It's really underrated given how well supported and nice to work with it is.
To me, CSS frameworks break the whole point of CSS, generally add a lot of bloat, and aren't useful except in some instances where rapid prototyping is needed.
Tailwind exists largely because programmers don't like CSS. We no longer need frameworks for compatibility. The era of browser testing is over. And we don't need them to do things CSS can't do, as in the past couple of years nearly all browsers are handling the newer features.
My big gripe is simply that it makes a lot of sense to keep your structure, styles, and scripts separated. If something looks off I don't want to have to wonder whether it's classes, CSS, or scripts.
And ultimately, I don't think Tailwind does make things faster. I could come up with custom CSS helper classes AS NEEDED, and avoid all the problems I mentioned above. And the one I didn't mention is that this makes your code look like incomprehensible garbage. Tailwind HTML files using BEM are just not OK.
Keeping my html and CSS separate make everything I do faster and lighter. Most importantly, CSS is now mature and finally does all the things for all the browser that make the frameworks just enough less useful that they become bloat.
My two cents. I'm sure Tailwind is helpful for many. But I gotta preach the basics.
A lot of people seem to approach Tailwind as a set of helper classes, but I think this is a misunderstanding of what Tailwind is doing.
It's clearer to think about Tailwind as a DSL for writing CSS directly in your templates. If that sounds like a thing you don't want to do in the first place, then Tailwind probably won't add anything useful for you, but for a lot of developers, it's a very convenient way of encapsulating style, structure (and potentially behaviour) in a single unit. You can then compose these units together to create larger systems.
Like I say, that's not the only way to develop for the web, you can also take the approach of separating out style, structure, and behaviour, and there you're not really going to see much benefit from Tailwind directly.
Specifically, I think a lot of the success of Tailwind comes from the fact that it's very agnostic about how you build your units. A lot of tools for CSS encapsulation have typically either been bound to a single framework, or at least very bound to the Javascript ecosystem. For example, CSS Modules do in many way a very similar thing to Tailwind, but they're heavily connected to the JS concept of importing and bundling - they can't easily be used in Python, for example. On the other hand, Tailwind is just text - if the Tailwind compiler finds a file where you're using its DSL, it can build the correct CSS files from that, regardless of how the file has been written. This allows you to use Tailwind from HTML, JS, but also from arbitrary custom templating formats, or even other programming languages.
I don't think Tailwind has so much to do with "basics vs helper methods". To do a lot of useful things in Tailwind, you need to know CSS in the first place, and it really is just a DSL around arbitrary CSS declarations (although the more complex those declarations become, the less pleasant Tailwind becomes to use - it is by no means perfect, or even my favourite tool for encapsulated CSS). It's more a question of how you want to write your CSS: do you want to write it coupled to HTML in components, or so you want to write it decoupled as a whole-page stylesheet?
Appreciate the suggestion, got to the 7th paragraph and re-read it- and started to question why learning from the mdn docs is not as easy as w3schools (I know much of hn has hate for that, and for some legit reasons but that's not the point) -
While thinking about actually understanding how this works and why it's good or not good compared to other non-sub-grid things, I decided to see if youtube kevin css guy had done an explainer, found https://www.youtube.com/@KevinPowell/search?query=sub-grid
So I will be diving into those.
Started a new website project just writing css / html last week, so I'm one of the 10.. I've done a couple projects with tailwind, it's fine, but it's not perfect.. I can see why/how it's kind of the new bootstrap for people who don't want to learn css.. If I had to use a pre-canned thing today it would be Bulma or Skeleton maybe.. I was poking about the search engines a couple weeks ago to look for any new 'lightest weight css frameworks' / minimal resets..
The search engine results for these are meh for me, it's like finding a bunch of recipe sites.
A nice grid chart showing the names, dates and mb/kb and pageload / time to interaction delay / JS required or not for base things - would be nice, but rather than wasting too much time searching I just started building from scratch with no package needed, just html and grid css.
Seems to me that more / better css grid template examples would be nice, maybe they exist but my ggl / ddg just keeps finding that same old stuff that is meh.
if you buy into Tailwind you probably won't think of using sub grids. But it is really nice to use sub grids and css variables to achieve amazing results
Totally aside, but the article reminded me. Does anyone remember when Firefox showed you the stacking context of elements on a web page? It had an exploded 3d view of all layers on a web page.
Not sure if any extensions or browsers still have that feature?
Chrome and Safari has the Layers panel in devtools that is actually a 3d model you can rotate but it's very simple compared.
But yeah i also remember that feature fondly and if anyone has a better tool i'd be very interested! Super weird it isn't more used, but then again it's weird there isn't more 3d / 2d diagramming being standard in programming.
I hate that every time that I want to use it to fix something I feel like I wasted my time. And then I remember Firefox's implementation and I want it back.
- table, the oldest one, still used for email
- float, for articles with inline images
- flexbox, most used one today
- grid, modern alternative to table
There is also absolute and fixed positioning as a hack to bypass layout.