When Ethan Marcotte conceived RWD, web technologies were far less mature than today. As web developers, we started to grasp how to do things with floats after years of stuffing everything inside table cells. There werent many possible ways to achieve a responsive site. There were two of them: fluid grids (based on percentages) and media queries, which were a hot new thing back then.What was lacking was a real layout system that would allow us to lay things out on a page instead of improvising with floating content. We had to wait several years for Flexbox to appear. And CSS Grid followed that.Undoubtedly, new layout systems native to the browser were groundbreaking 10 years ago. They were revolutionary enough to usher in a new era. In her talk Everything You Know About Web Design Just Changed at the An Event Apart conference in 2019, Jen Simmons proposed a name for it: Intrinsic Web Design (IWD). Lets disarm that fancy word first. According to the Merriam-Webster dictionary, intrinsic means belonging to the essential nature or constitution of a thing. In other words, IWD is a natural way of doing design for the web. And that boils down to using CSS layout systems for laying out things. Thats it.It does not sound that groundbreaking on its own. But it opens a lot of possibilities that werent earlier available with float-based layouts or table ones. We got the best things from both worlds: two-dimensional layouts (like tables with their rows and columns) with wrapping abilities (like floating content when there is not enough space for it). And there are even more goodies, like mixing fixed-sized content with fluid-sized content or intentionally overlapping elements:Native layout systems are here to make the browser work for you dont hesitate to use that to your advantage.Start With Semantic HTMLHTML is the backbone of the web. Its the language that structures and formats the content for the user. And it comes with a huge bonus: it loads and displays to the user, even if CSS and JavsScript fail to load for whatever reason. In other words, the website should still make sense to the user even if the CSS that provides the layout and the JavsScript that provides the interactivity are no-shows. A website is a text document, not so different from the one you can create in a text processor, like Word or LibreWriter.Semantic HTML also provides important accessibility features, like headings that are often used by screen-reader users for navigating pages. This is why starting not just with any markup but semantic markup for meaningful structure is a crucial step to embracing native web features.Use Fluid Type With Fluid SpaceWe often need to adjust the font size of our content when the screen size changes. Smaller screens mean being able to display less content, and larger screens provide more affordance for additional content. This is why we ought to make content as fluid as possible, by which I mean the content should automatically adjust based on the screens size. A fluid typographic system optimizes the contents legibility when its being viewed in different contexts.Nowadays, we can achieve truly fluid type with one line of CSS, thanks to the clamp() function:font-size: clamp(1rem, calc(1rem + 2.5vw), 6rem);The maths involved in it goes quite above my head. Thankfully, there is a detailed article on fluid type by Adrian Bece here on Smashing Magazine and Utopia, a handy tool for doing the maths for us. But beware there be dragons! Or at least possible accessibility issues. By limiting the maximum font size, we could break the ability to zoom the text content, violating one of the WCAGs requirements (though there are ways to address that).Fortunately, fluid space is much easier to grasp: if gaps (margins) between elements are defined in font-dependent units (like rem or em), they will scale alongside the font size. Yet rest assured, there are also caveats.Always Bet On Progressive EnhancementYes, thats this over-20-year-old technique for creating web pages. And its still relevant today in 2025. Many interesting features have limited availability like cross-page view transitions. They wont work for every user, but enabling them is as simple as adding one line of CSS:@view-transition { navigation: auto; }It wont work in some browsers, but it also wont break anything. And if some browser catches up with the standard, the code is already there, and view transitions start to work in that browser on your website. Its sort of like opting into the feature when its ready.Thats progressive enhancement at its best: allowing you to make your stairs into an escalator whenever its possible.It applies to many more things in CSS (unsupported grid is just a flow layout, unsupported masonry layout is just a grid, and so on) and other web technologies.Trust The BrowserTrust it because it knows much more about how safe it is for users to surf the web. Besides, its a computer program, and computer programs are pretty good at calculating things. So instead of calculating all these breakpoints ourselves, take their helping hand and allow them to do it for you. Just give them some constraints. Make that <main> element no wider than 60 characters and no narrower than 20 characters and then relax, watching the browser make it 37 characters on some super rare viewport youve never encountered before. It Just Works.But trusting the browser also means trusting the open web. After all, these algorithms responsible for laying things out are all parts of the standards.Ditch The Physical CSSThats a bonus point from me. Layout systems introduced the concept of logical CSS. Flexbox does not have a notion of a left or right side it has a start and an end. And that way of thinking lurked into other areas of CSS, creating the whole CSS Logical Properties and Values module. After working more with layout systems, logical CSS seems much more intuitive than the old physical one. It also has at least one advantage over the old way of doing things: it works far better with internationalized content.And I know that sounds crazy, but it forces a change in thinking about websites. If you dont know the most basic information about your content (the font size), you cant really apply any concrete numbers to your layout. You can only think in ratios. If the font size equals , your heading could equal 2, the main column 60, some text input 10, and so on. This way, everything should work out with any font size and, by extension, scale up with any font size.Weve already been doing that with layout systems we allow them to work on ratios and figure out how big each part of the layout should be. And weve also been doing that with rem and em units for scaling things up depending on font size. The only thing left is to completely forget the 1rem = 16px equation and fully embrace the exciting shores of unknown dimensions.But that sort of mental shift comes with one not-so-straightforward consequence. Not setting the font size and working with the user-provided one instead fully moves the power from the web developer to the browser and, effectively, the user. And the browser can provide us with far more information about user preferences.Thanks to the modern CSS, we can respond to these things. For example, we can switch to dark mode if the user prefers one, we can limit motion if the user requests it, we can make clickable areas bigger if the device has a touch screen, and so on. By having this kind of dialogue with the browser, exchanging information (it gives us data on the user, and we give it hints on how to display our content), we empower the user in the result. The content would be displayed in the way they want. That makes our website far more inclusive and accessible.After all, the users know what they need best. If they set the default font size to 64 pixels, they would be grateful if we respected that value. We dont know why they did it (maybe they have some kind of vision impairment, or maybe they simply have a screen far away from them); we only know they did it and we respect that.And thats responsive design for me.