[HN Gopher] New layouts with CSS Subgrid
___________________________________________________________________
New layouts with CSS Subgrid
Author : joshwcomeau
Score : 284 points
Date : 2025-11-25 15:57 UTC (1 days ago)
(HTM) web link (www.joshwcomeau.com)
(TXT) w3m dump (www.joshwcomeau.com)
| Nathanba wrote:
| Isn't this also what container queries solve better? I guess
| maybe you want to be sure that the whole grid remains consistent
| instead of relying on individual containers possibly making their
| own decisions. So many new features to investigate, so little
| time :) https://codepen.io/web-dot-dev/pen/rNrbPQw
| webstrand wrote:
| Container queries don't solve the responsive to sibling sizes
| issue that grid/flex can solve. And frustratingly container
| queries force your container element to be a new stacking
| context, unlike flex/grid.
|
| I am sad that using containers and subgrids together doesn't
| work. Being able to query the size of the subgrid from a child
| element would be super powerful.
| webstrand wrote:
| Subgrid is really cool, but I want to note that for the first
| trivial example, you could make the children participate in grid
| layout by doing ul { display: contents }
|
| it's more efficient, if you don't need subgrid features, but
| still want the nested element structure for other reasons.
| Izkata wrote:
| And on the second one, you could use any other unit instead of
| fr for the image to set its width consistently, then fr on the
| text to have it use up whatever remains.
| bradly wrote:
| I also wasn't understanding the value looking at the first
| two examples, but the pricing packages example I do think I
| would struggle to implement in a clean way using traditional
| css.
| b2ccb2 wrote:
| I'd use <table>. It literally is a table. And for mobile
| just do a media query to turn it into a flexbox.
| PxldLtd wrote:
| Yeah the claim that tables are hard to style for such a
| simple design doesn't really hold up in my opinion.
|
| This took two seconds to make
| https://codesandbox.io/p/sandbox/5ry4rl
|
| I do agree though that subgrid makes the HTML more
| readable though so I'm all for it.
| moron4hire wrote:
| Yes, for that specific example it works. But in general, this
| essentially deletes the UL from the layout entirely. It won't
| be stylable[0] and it won't dispatch UI events that occur on it
| specifically.
|
| One example of a reason you might want such an element to still
| participate in layout is to use that element as an area
| highlighter. Or you might make it a scrollable section; subgrid
| makes sticky-header tables rather trivial to implement now.
|
| [0] Well, I can't remember right now if it's unstylable or if
| its height just ends up zero, but either way, it might not be
| what you expect.
| masterphai wrote:
| One subtle thing worth adding is that display: contents also
| changes how accessibility trees are constructed. The element
| is removed from the visual layout and from the accessibility
| tree in many browsers, so semantics like list grouping,
| landmarks, or ARIA roles can disappear unless you re-
| introduce them manually.
|
| That's why subgrid ends up filling a different niche: you
| preserve the DOM structure, preserve accessibility semantics,
| and still let the children participate in the parent's track
| sizing. It costs more than contents, but it avoids a lot of
| the accidental side-effects that show up once you start
| mixing layout, semantics, and interactivity.
| paulhebert wrote:
| Yeah this is a good callout. My understanding is that
| display: contents is not meant to impact the accessibility
| tree but there is a long and ongoing history of browser
| bugs that make me not want to use it for elements that have
| an accessible role
| webstrand wrote:
| From my testing, as far as I've been able to tell it no
| longer has any impact on accessibility. The element
| itself does not appear in the tree, this makes sense
| display:contents is non-interactive. But all of the
| children correctly appear in the accessibility tree as if
| they did not have that shared parent element. But I am by
| no means an expert at operating screen readers, do you
| know of any specific issues with it?
| webstrand wrote:
| Yeah, though I find in practice I use `display: contents` far
| more than I do subgrid. Contents effectively deletes the node
| for layout purposes, but it still participates in the CSS
| cascade so you can use it in selectors, even `:hover` works
| when a child gets hovered, or use it as the origin for
| inheritable properties.
| echelon wrote:
| I am continually in awe of Josh's blog posts, clarity of writing,
| sense of design, and fun interactive website.
|
| You're killing it, Josh. Thank you for writing and teaching us.
| paulhebert wrote:
| Agreed. I'm happy to be on his mailing list. I'm always excited
| for a new Josh article
| kumarvvr wrote:
| How is this different to, and better than using nested grids?
| psolidgold wrote:
| This is addressed in the article. This really shines when you
| have sibling dependent layouts.
| laszlokorte wrote:
| If you nest two grids, the rows and columns of two sibling
| grids are not forced two align.
|
| With subgrid the rows and columns of two sibling grids are
| aligned with each other by glueing them to the rows and columns
| of the parent grid.
| t1234s wrote:
| is grid intended to replace flex at some point or live side by
| side
| SquareWheel wrote:
| They're complimentary. As a general (though not exclusive)
| rule, consider flex for one-dimensional layouts, and grids for
| two-dimensional layouts.
| psygn89 wrote:
| Yeah, to expand on that... Flex is, well, flexible, whereas
| Grid is more rigid like a table. The rigidity of Grid allows
| you to span rows and columns (2D) just like you can with
| table cells (colspan/rowspan). Grid is usually used at a
| macro level for its more deterministic layout (no unintuitive
| flex quirks), while flex is usually used to lay things out at
| a component level where you don't care that the next row of
| items isn't perfectly aligned with the ones above (you will
| often see it hold some buttons or badges, or vertically align
| text to an icon), and Grid setting the layout of the app and
| container components (modals, cards, etc).
| taftster wrote:
| So is Grid supposed to be what we should use to replace the
| html <table> element? That I still use to this day for
| layouts because CSS still sucks to me?
| psygn89 wrote:
| Use <table> for tabular data, but for layout you should
| use grid. Grid doesn't have it's own element like table
| does, so you have to use css to apply that display to a
| div.
|
| CSS takes a bit of time to understand. It's cascading
| nature and how certain properties behave differently
| based on the html structure or display type or direction
| makes it tricky. I don't blame you sticking with tables
| for layouts for yourself - making layouts with floats was
| a pain. Bootstrap hid a lot of the layout pain. But today
| we have flex and grid to help us realize our layouts.
| antod wrote:
| There were back in CSS 2 display values for table, table
| cell, table row etc which meant you could make divs or
| other block elements layout like tables did. Of course it
| wasn't supported in a certain browser with 90% market
| share.
| Akronymus wrote:
| > Grid doesn't have it's own element like table does, so
| you have to use css to apply that display to a div.
|
| Well, OOTB, yeah. I personally like to make use of custom
| html elements a lot of the time for such things. Such as
| <main-header> <main-footer> <main-content> <content-
| header> etc, and apply css styles to those, rather than
| putting in classes onto divs. Feels a lot more ergonomic
| to me. Also gives more meaningful markup in the html.
| (and forces me to name the actual tags so I use much less
| unnecessary ones)
| moron4hire wrote:
| One of the many things I hate about React: can't easily
| create custom elements that truly exist in the DOM so I
| can style them in CSS.
| WorldMaker wrote:
| Recent React round-trips custom elements better now. You
| just have to remember the standard's rule that all custom
| elements need to be named with dash (-) inside them.
| paulhebert wrote:
| No. The table is meant to hold tabular data like a
| spreadsheet. It has special behavior for people who use
| tools like screen readers because they have vision
| impairment.
|
| CSS grid is a powerful layout tool. If you think CSS
| sucks I encourage you to brush up on the newer
| developments. Flex box and grid and many other newer
| tools solve a lot of the classic pain points with CSS and
| make it a pleasure to use if you invest the time to learn
| it
| dsego wrote:
| It's more like a comic book, you define the layout and
| the elements slot into that. You can define how many rows
| and columns your comic has and then you can make some
| panels fit exactly into one spot, or you can have panels
| that span more than one row or column. So it's more of a
| 2d design system.
|
| https://l-wortley0811-dp.blogspot.com/2010/10/comic-
| layoutsj...
| Brajeshwar wrote:
| I use this thumb-rule while explaining them -- Grid to Lay
| Layouts of distinct UI Blocks; while Flex is to layout
| contents, sometimes a continuous set of content.
| moi2388 wrote:
| Live side by side unfortunately. I personally however always
| use grid, flexbox sucks.
| system2 wrote:
| Can you get the same alignment properties with the grid? If
| so, I will use the grid more often.
| dsego wrote:
| Flexbox is great for stacking and distributing elements
| vertically or horizontally, especially when you don't know
| how many there are.
| herpdyderp wrote:
| On the other hand, I only use flexbox and I think grid sucks.
| N_Lens wrote:
| Have we wrapped all the way around to <table> layouts again?
| hackthemack wrote:
| I agree. I got really tired of hearing tables are for tabular
| data! For 20+ years. My reply was always, Who cares if it
| accomplished the layout you want. If the meaning of a word is
| what got people so hung up... why not go and make a new css
| term that did what tables did but improve on it. Now 20+ years
| later, that is pretty much what they did.
| strixli wrote:
| Screen readers do care. A lot. Grid and subgrid solve the
| problem without breaking DOM and semantics, which is a huge
| concern in accessibility.
| sussmannbaka wrote:
| Yes and no. <table> layouts were a hack that solved a real
| problem but came with massive downsides. People didn't tell you
| to not use <table> to lay out content because grids are bad
| (they are quite handy! take a look at Grid Systems by Josef
| Muller-Brockmann) but because <table> both posed technical and
| accessibility problems. A layout grid is not a table (or a
| <table >). A table (with and without <>) comes with attached
| semantics, hierarchy, reading direction etc. and is extremely
| rigid, which makes it a bad fit for differing screen sizes.
|
| It's true that this was a blind spot for a long time and that
| it was frustrating to not be able to efficiently lay out
| content in 2D when <table> was just there. But it was the wrong
| choice then as it is now and it has been baseline available for
| 8 years now. I hope it won't take another 8 years until the
| comparison stops :o)
| lelandfe wrote:
| > A layout grid is not a table
|
| Ain't it? Rows and columns get you a table.
| dwb wrote:
| A table is for tabulating data. They have quite different
| meaning and purpose, even if they share a couple of
| characteristics.
| lelandfe wrote:
| Tabulate means to organize by rows and columns.
|
| Layout grids organize data by rows and columns.
| dwb wrote:
| You have just restated the similarity I referred to. The
| ways they are different make them important enough to
| distinguish.
|
| "Tabulate" doesn't just mean organising anything by rows
| and columns, it means organising data for a particular
| purpose. And layout grids usually end up looking quite
| different to tables because although they have a broadly
| similar underlying structure, the purpose is quite
| different.
| sussmannbaka wrote:
| They don't! Layout grids are less about the rows and
| columns and more about the lines separating them (which
| is why those get a lot of attention in CSS grid). Take a
| look at how layout grids are used in design and you will
| quickly find examples that are extremely inconvenient to
| realize with HTML tables. I'm sure it can be done and I'm
| sure some poor email marketing dev had to, but the result
| would be entirely static and not able to reflow.
| pacifika wrote:
| HTML spec couldn't just have added a grid element?
| maqnius wrote:
| CSS grids are for presentation, HTML is for semantics.
| Ideally they are separated. That's why the use of
| <center> tag is deprecated.
| merb wrote:
| As far as I know <b> and <i> is not deprecated at all.
| It's just not recommended for 95% of the use cases.
| itishappy wrote:
| They're not quite deprecated, but they're also not quite
| not deprecated at all:
|
| > Historically, the <b> element was meant to make text
| boldface. Styling information has been deprecated since
| HTML4, so the meaning of the <b> element has been
| changed.
|
| https://developer.mozilla.org/en-
| US/docs/Web/HTML/Reference/...
| sussmannbaka wrote:
| I think CSS grid is too powerful to be represented in
| markup. I rotated the idea in my head for a bit but the
| most I could come up was elements that covered a small
| subset of CSS grid and which completely lost the entire
| appeal of being able to handle tracks dynamically.
| moron4hire wrote:
| This is a classic problem I identify across a wide
| variety of types of software. I call it "forcing a graph
| into a tree" and it comes up any time you have something
| that must be evaluated across multiple axises but the
| earliest assumptions (now invalidated) about the data
| restricted it to a tree, or the most really available
| tools to process it is with tree-like data structures and
| algorithms.
|
| HTML is a tree. It's really great at trees. But defining
| a grid layout sometimes requires organizing data by both
| the rows and the columns. That _can 't_ fit into a tree.
|
| I think a lot of people's complaints that "CSS is too
| complex, why can't we just do this in HTML" would go away
| if they could understand that CSS--being a rules-based
| system--can process the _graph_ , but HTML can only ever
| define a _tree_. There are things that will just never
| work in just HTML.
|
| This gets hard because trees are easy for people to
| understand. We have lots of examples of them: file
| systems (if you ignore symlinks). Family trees (if you
| ignore inbreeding). Tree of life taxonomies (if you
| ignore more than basic undergrad biology). You can
| probably guess by my caveats how much I feel it is
| important to study graphs. But graphs are "scary Computer
| Science" stuff to a lot of people, so they don't take the
| time to learn.
| dbbk wrote:
| How would that have been responsive?
| Boltgolt wrote:
| A table is a grid, but a grid does not have to be a table
| system2 wrote:
| Try to select a tr / td without pulling your hair.
| halapro wrote:
| <table> was a problem because it described content, not style.
| There's nothing wrong with creating grids.
| joduplessis wrote:
| Was going to say this too!
| dreamcompiler wrote:
| Yes. I built layouts like this with automatic server-rendered
| tables 25 years ago, and they _just worked_ with very little
| effort.
|
| Tables weren't responsive or accessible or any of the other
| things we now recognize as essential, but it has certainly
| taken a long time to reinvent the table wheel. And all the
| while we've had to listen to people screaming in our ears that
| tables were bad, while also listening to them argue about which
| of their incredibly difficult and patently subpar "solutions"
| we were supposed to use instead.
| lofaszvanitt wrote:
| When I see the grid syntax, I just wanna jump off a cliff. Who
| created this abomination and why? We need trials to check whether
| these were the output of humans or some synthetics pretending to
| be humans.
| hexasquid wrote:
| It's quite straightforward to find the discussions that lead to
| the specs, if you're interested in participating.
| lofaszvanitt wrote:
| So it went thru multiple people and they all said in unison:
| well, this is all ironed out, easy to use and looks ok. We
| did a great job!
|
| Just mind boggling. I get it, maybe they want to create extra
| jobs, by adding complexity, hence more people are required
| for a role, but why keeping up the illusion? Fucking alter
| the economic systems if this was the goal.
| alwillis wrote:
| Yes, the syntax takes a while to get used to; they were
| attempting to cover several different use cases.
|
| You can use ASCII art to "draw" your layout if you want to,
| which is quite accessible [1].
|
| [1]: "Grid: how grid-template-areas offer a visual solution for
| your code" -- https://webkit.org/blog/17620/grid-how-grid-
| template-areas-o...
| alwillis wrote:
| Layout Land [1] is a great set of videos that explains CSS Grid
|
| [1]: https://m.youtube.com/layoutland
| lofaszvanitt wrote:
| Why does it need explaining, when it has to be self
| explaining and not some overcomplicated mishmash. Like
| someone was under the influence of psychedelics when working
| out the specifics.
|
| We had to wait 15 years for proper positioning in css. Same
| shit repeated again.
| hollowturtle wrote:
| I sympathize with your comment and imagine the overflowing
| downvotes as soon you openly critic the web/css/javascript and
| their people doing the standard. I watched tons of videos and
| read a lot on mdn about css grid, I don't touch it for a while
| I need to go back at it again... After tables/floats/abs
| positioning eventually convoluted flex we should have stopped
| and review what the heck people were doing on w3c, it's
| artificial complexity we don't deserve that
| herpdyderp wrote:
| I simply ignore it and use flexbox without any issues.
| WorldMaker wrote:
| I think Flexbox is so much worse than CSS Grid. If Flexbox
| makes sense to you, it I don't think it should be that hard
| to learn CSS Grid, you'll already have many of the properties
| you need to understood learned. Grid just works properly in 2
| whole dimensions where Flexbox sort of gives up after 1 and a
| half dimensions.
| rckt wrote:
| I never found it comfortable to work with grids. The syntax and
| layout just feel off. Flexbox is a much more flexible and easy
| thing to work with.
| code_biologist wrote:
| There's plenty of overlap, but they solve different problems:
| flexbox when the content should control element sizing/fit,
| grid when the container should control element sizing/fit.
| alwillis wrote:
| Another way to think about it: flexbox is for alignment of
| boxes in one dimension: horizontally or vertically.
|
| CSS Grid is for two dimensional layout of rows and columns.
|
| Back in the day, developers wanted page layout instead of the
| hacks on top of hacks with table-based layouts, floats and
| positioning to create layouts.
|
| We've had CSS Grid designed for page layout on the web, in
| all browsers since 2017; as of 2022, only 12% of the top 1
| million websites used CSS Grid, which to me is ridiculously
| low.
| rckt wrote:
| I use flexbox for grid purposes, simply because the syntax
| is straightforward and easy to read. Yeah, it's one
| dimension, but if you nest it, it becomes two with no
| issues.
| laszlokorte wrote:
| With nested flexbox the nested dimensions are not aligned
| to each other. With grid the items are aligned across
| both each row AND each column. With subgrid even nested
| grids can be aligned across nesting levels.
| rckt wrote:
| True. But so far I haven't faced layouts that I could not
| implement using flexbox.
| ffsm8 wrote:
| But flex grow and align stretch exist, which moves control
| back to the parent...
|
| A grid really feels like a list flexes to me too,
| functionally.
| sings wrote:
| I agree. I occasionally turn to them to see if they work in a
| new setting, but find they never expose the features of a grid
| I would find useful. Everything must be manually placed, rather
| than allowing content to intelligently snap to multiple axes.
| Possibly I never have grasped some fundamental concept,
| possibly they are not suited to the sorts of layouts I usually
| work on. But more and more I feel they are designed to fulfil
| some purpose orthogonal to what I would need them to do.
| herpdyderp wrote:
| I also find it _much_ simpler to make responsive designs with
| flexbox than with grid.
| flowerthoughts wrote:
| This sounds useful, but the example of the feature rows reminds
| me how sad it is that CSS sometimes requires adding information
| about the document structure to make a layout work. In this case
| the number of rows.
| dsego wrote:
| Ideally, we would have a way to align elements even when they
| don't share a parent. Or maybe a flex container that can have
| its layout mimic another flex container so the distribution in
| them can line up. It seems that there are a lot of heuristics
| and edge cases though to keep a simple DX.
| Surac wrote:
| So we are back to grids after all the years put into css? We had
| this with html many years ago
| moi2388 wrote:
| Yes but now they cascade for even more fun bugs whilst styling
| your layout :D
|
| /s
| system2 wrote:
| This makes the content responsive way easier than any HTML grid
| could.
| buovjaga wrote:
| Random grid gotcha that drove me crazy some time ago: due to
| browser bugs we can't use <img> elements with percentage widths
| or heights as grid items. The grid cell dimensions get blown out
| to the ones of the original image. Seen in both Firefox and
| Chromium. Relevant FF bug is probably
| https://bugzilla.mozilla.org/show_bug.cgi?id=1857365 '<img> grid
| item with percentage height, "width: auto", "grid-template-
| columns: auto", and no track stretching makes column to have the
| same width of the original image's width' (although someone there
| claims it works in Chromium).
| bryanrasmussen wrote:
| so if the img has a specific size set in width and height
| attributes or via css, and that size is not percentile or auto,
| the problem doesn't exist?
|
| I'm just confused by the "original image's width".
| chrisweekly wrote:
| not OP but (unless silently edited) they wrote
|
| > "<img> elements with percentage widths or heights"
| scotty79 wrote:
| Have we reached the point where we can fully simulate quirks mode
| table behavior?
| hollowturtle wrote:
| From the example: .grid { display: grid;
| grid-template-columns: 35% 1fr 1fr 1fr; } .grid
| header { grid-row: 1 / 3; } .grid ul {
| grid-row: span 2; grid-column: span 3; display:
| grid; grid-template-rows: subgrid; grid-template-
| columns: subgrid; }
|
| I swear you that I had less hard time reading x86 assembly code
| or even c++ templates. I mean what the hell? Then if you go look
| at another example:
|
| > @media (max-width: 32rem)
|
| I know what rem means, I just don't know what the hell MAY mean,
| that alone in a big project will make you hate your job as
| sometimes it's more easier predicting what the response of an LLM
| may be than what styling an element will have on a live page
|
| [Edit] I'm not confusing rem with em, em are even worse, but
| still hard predicting what a rem might be, before arguing we
| shouldn't I'd like to stress out we should once it's used like
| that "@media (max-width: 32rem)"
|
| [Edit2] Instead of just downvoting why don't you reply with your
| counter arguments? I really am interested in hearing what you
| have to say
| joestrouth1 wrote:
| Put me on a C++/asm project and I'd have a hard time making
| heads or tails of it. So what? Your comment comes off as very
| angry without any meaningful critique of the article's central
| topic other than you had a hard time understanding it.
|
| 1rem is equal to the same number of pixels anywhere on a given
| page and, generally speaking, across pages on a given site. If
| you don't know what the value is it only takes a minute to find
| out. If you're writing CSS that'll be used on unknown pages,
| you either a) shouldn't care and just scale relative to
| whatever root font size the consumer set or b) should set your
| own size/scale, at build time or with custom properties. REMs
| have been around and standard practice for 10 years.
| hollowturtle wrote:
| > 1rem is equal to the same number of pixels anywhere on a
| given page and, generally speaking, across pages on a given
| site.
|
| That's not true, first of all the root font size might not be
| immediate to query and find out what it is, second it might
| change because of variables on the root or base font size
| might be percentage/rem based itself not necessarily in
| pixels and finally setting it in pixels doesn't take into
| consideration zoom levels, or OS-level font settings.
|
| > REMs have been around and standard practice for 10 years.
|
| I know but thanks for flexing it out, in fact I'm arguing
| that css is and has been bad for many years
| joestrouth1 wrote:
| My point was that there is only one root font size on a
| given page and it's trivial to find out what that is by
| looking in dev tools. It does not matter if it was set by
| the browser's user-agent stylesheet or an authored
| stylesheet or what units it was set in. You can simply look
| up its computed value.
|
| What use case is that not sufficient for? What kind of
| nightmare page are you styling where code you don't control
| is dynamically changing the root font size? Why do you need
| its exact computed value at all? The whole point of REMs is
| to style based on relative proportions to the text size
| e.g. when text is size X, buttons should have x padding on
| top/bottom and 2x on the sides. If the user sets their
| preferred font size to another value I do not care.
| hollowturtle wrote:
| I use rems I don't love them but it's less worse unit we
| have. My point was more on grid being convoluted and
| media queries with arbitrary values like media (max-
| width: 32rem)
| WorldMaker wrote:
| Grid is a DSL certainly, but it's a very useful DSL to learn.
| I'd even argue that people skip Flexbox or forget everything
| they (think they) know about Flexbox and just learn CSS Grid.
|
| One of the first callouts in the article is a suggestion to
| read the same site's interactive guide to CSS Grid if you
| aren't familiar with it:
| https://www.joshwcomeau.com/css/interactive-guide-to-grid/
|
| > I'm not confusing rem with em, em are even worse, but still
| hard predicting what a rem might be, before arguing we
| shouldn't I'd like to stress out we should once it's used like
| that "@media (max-width: 32rem)"
|
| `rem` is "just" the root Em, the em in the root font size (the
| font size of the `<html>` tag itself). In most browsers, with
| no `<html style="font-size: X;">` override (or `:root { font-
| size: X; }` stylesheet) that defaults to 16px.
|
| In the Bootstrap 3/4-era responsive breakpoints you often see
| something like `@media (max-width: 512px) {}` to mean "mobile
| width". The reasons to migrate those sort of breakpoints to
| `rem` units instead include 1) adapts to custom browser
| settings (a user may set their default font size larger, for
| instance, for visual acuity reasons, which can be a useful
| accessibility desire), 2) adapts _in some situations_ to zoom
| settings (browsers are allowed to style the website at a higher
| zoom as _if_ the user had chosen an equivalent larger base font
| size), and 3) in the "retina screen" world where resolutions
| on a phone screen may be higher than desktop resolutions
| despite smaller screen size, using "roughly 32 `M` characters
| wide" is a better intuition than "exactly 512px wide" (and
| mobile browsers can lie a bit less about their pixel widths to
| meet your breakpoint assumptions).
|
| You can back-of-the-envelope math `X rem * 16 px/rem` to get a
| pixel approximation if you need one, and that estimate will
| hold in a lot of cases in a majority of browsers, but leaves
| the browser more flexibility in adapting to adapting to user
| desires and hardware quirks than raw pixel counts.
| hollowturtle wrote:
| thanks for the lesson, not needed because i know how to do a
| multiplication, but oh well people need to flex their domain
| knowledge. You're missing the whole point: drid dsl is
| overengineered and convoluted with browser behaving
| differently on some cases. Css is a disease
| HenriTEL wrote:
| Ah yes, a new css concept! I love this kind of article that
| invariably contains this kind of statement:
|
| > This is mind-bending stuff, but it becomes intuitive with a bit
| of practice.
|
| The problem is not the language, it's just that you did not spend
| enough time to learn it the proper way.
| dsego wrote:
| The pricing UI example is exactly the type of thing I had to
| build a few years ago. Deceptively simple, two tables for
| comparison, but the rows need to line up.
|
| Impossible without subgrid, either you need to have fixed heights
| or calculate heights with JS, but neither is elegant or simple,
| especially if you have react components and adhere to modular
| design, and you need to have those components agree on sizing.
| kafkaesque wrote:
| Am I the only one who sees "content boxes"/divs with content
| displayed in different widths as poor design? At least in the
| example given, I would think you would want the image and its
| associated content box to be the same size for all four and not
| have its content vary in width based on how much content it has.
|
| But in terms of functionality, I'm sure there are plenty
| applications for this!
| herpdyderp wrote:
| Why do you put styles in the code playground HTML _and_ CSS file?
| I was staring at the first subgrid example's CSS file for ages
| trying to figure how anything special was applied to the ul
| element.
___________________________________________________________________
(page generated 2025-11-26 23:01 UTC)