[HN Gopher] Help us invent CSS Grid Level 3, a.k.a. "Masonry" la...
___________________________________________________________________
Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
Author : achairapart
Score : 453 points
Date : 2024-04-23 09:32 UTC (13 hours ago)
(HTM) web link (webkit.org)
(TXT) w3m dump (webkit.org)
| pimterry wrote:
| A really nice feature here is that if you view the demos in a
| browser that doesn't support this (i.e. all current stable
| browser releases without special flags enabled) because they're
| building directly on grid layouts, they still appear in a pretty
| reasonable fixed-row format: https://webkit.org/demos/grid3/.
|
| In each case it'd look much nicer with a proper masonry layout
| but it's still very usable otherwise (and of course you could
| feature detect to provide a better fallback if you're not happy
| with that anyway).
| mg wrote:
| If one wants to do a "Masonry" layout, what's wrong with
| calculating it via JavaScript?
| xrisk wrote:
| I'd rather have browser vendors responsible for a correct
| implementation. This seems like a rather nuanced feature.
| jampekka wrote:
| With browser vendors you have to get them to do the same
| implementation. With JS/WASM it'll work across browsers given
| the more fundamental APIs work the same.
| tambourine_man wrote:
| It's less smooth, uses more power, requires more bandwidth,
| etc.
| nolok wrote:
| You're asking "why render it correctly when we can render it
| wrong and then fix it afterwards".
| datascienced wrote:
| An argument I would take more seriously if infinite scrolling
| was not a requirement too.
| isodev wrote:
| Because why introduce a custom abstraction to implement
| something with an imperative scripting language when you can
| achieve the same result with a declarative language built
| specifically to address this use case?
|
| You'd rather maintain all the maths and JS dependencies for
| this than have browsers just render what you want?
| pavlov wrote:
| It's been nearly 30 years now that we've heard this refrain
| about CSS. Somehow the dream of "just tell the browser to
| render what I want" still remains elusive.
|
| But maybe it's just a few dozen more properties and mini-DSLs
| away this time! Pay no attention to those sirens and false
| prophets who still believe in anti-CSS "tell the computer how
| to do exactly what you want" programming...
| isodev wrote:
| I'm no prophet and CSS, just like any other language has
| its quirks. And yeah, generally it is my job to try and
| tell computers what to do so I like powerful tools that let
| me do what i want :)
| pavlov wrote:
| You're missing the irony in the second paragraph. CSS
| proponents are ideologically opposed to simply telling
| the computer how to do what you want.
| sham1 wrote:
| Well, as far as I at least understand it, the argument is
| that by using JS for this, you are indeed telling the
| computer what you want, you're just doing it by telling
| the computer it by telling it exactly _how_ to do it. In
| contrast, in CSS, you 're telling the computer what you
| want by... telling it what you want, and letting the
| browser engine worry about the how.
|
| CSS isn't perfect, but it certainly works nicely for
| declaring layouts most of the time. It's of course alsp
| easy to get wrong, but doing all of the layout logic
| manually doesn't seem like a proper solution.
| jampekka wrote:
| I agree that there should be an "escape hatch" to
| implement stuff that evaded the great wisdom of the
| commitees. The Houdini project may become such:
| https://developer.mozilla.org/en-
| US/docs/Web/CSS/CSS_Houdini
|
| But I do also see the benefit of a declarative system for
| most cases. Adaptive layouts are hard to do with
| imperative code, and very easily lead to e.g. infinite
| loops, so it's nice to work with a declarative system
| that guarantees a stable layout. That said, CSS is far
| from an ideal such system with so much ad-hoc and legacy
| baggage.
| blowski wrote:
| Is it easier to build a layout with CSS compared to 20
| years ago? Yes. Can we further improve CSS? Yes.
| crote wrote:
| The question is, where do you draw the line?
|
| It's obviously not viable to implement literally every single
| design imaginable straight in CSS. If I want to do something
| silly like placing my content on the faces of a hypercube it
| wouldn't be realistic for me to expect that to be part of
| CSS. Having me write some JS is completely acceptable -
| that's what it is for, after all!
|
| It's not a matter of "would this be better in CSS", the
| answer to that is painfully obvious. The relevant question
| here becomes "is this common enough that it warrants a CSS
| implementation". And honestly? In the case of Masonry I am
| not convinced it is.
| isodev wrote:
| I totally agree, and it does make sense to make adjustments
| that would make layouts more accessible. Mansonry-like
| layouts are common ("make it look like Pinterest") and so
| why not facilitate this entire class of use cases? The
| alternative is for everyone to either look for libraries or
| hax-together something that looks like Masonry but don't
| look too close and don't resize the view port too much.
|
| Honestly, I'd say kudos to the WebKit folks for opening the
| discussion and being transparent about the process and the
| tradeoffs. It can certainly help refine (or inspire) future
| proposals.
| mvonballmo wrote:
| As they explain in the article, a row-less layout with
| columns is quite common in the non-web world. They
| acknowledge that some people are arguing that it's not
| needed because nobody's using it (on the web). Nobody's
| using it (on the web) because it's not possible in CSS.
|
| The argument is that the popularity of the layout in
| contexts where it's possible is a strong argument for
| enabling it on the web as well. This is not a layout that
| they just thought of and are trying to invent.
| crote wrote:
| I'm not seeing any evidence for that, though.
|
| Row-less layouts with columns are indeed quite common in
| the non-web world - see for example newspapers or other
| dense text. But that can already be done with _current_
| CSS features, and the row-first placement makes this
| proposal completely unsuitable for that. Masonry actively
| makes that worse, because it screws with the regular
| reading order.
|
| They argue that nobody is doing it because it can't be
| done in CSS. I would argue that nobody is doing it
| because _it 's a bad idea_. We've seen people work around
| it not being in CSS by using Javascript to make galleries
| for years now, if there were other use cases they'd
| surely have done the same?
|
| With the exception of Pinterest-style galleries (and lets
| be honest, that's not exactly the pinnacle of UX either)
| I really don't see a widespread use for this feature.
| Their three other demos sure aren't convincing me.
| jampekka wrote:
| It'll probably end up slow and buggy. And likely explode when
| used with other layouting mechanisms. And it won't benefit from
| the quite awesome CSS debugging tools we have nowadays.
|
| But yes, more powerful "client side" layouting functionality
| would be very welcome so we wouldn't have to wait the commitees
| for a decade to center an element etc. And there is the
| "Houndini" project to get this going, but the browser support
| is still extremely poor: https://houdini.glitch.me/
| iainmerrick wrote:
| The main problem is that JS runs in a single thread and blocks
| the browser. Browsers jump through a ton of hoops to do
| scrolling and rendering on background threads while still
| allowing JS hooks and callbacks as required by web standards.
|
| But, I think it's really the ONLY problem, and if you solve
| that problem, doing this stuff in JS would be the right answer.
| You'd be much more likely to get consistent behavior
| everywhere, without browser-specific quirks.
|
| And part of the solution exists already! JS doesn't have to
| block the main thread any more, because you have things like
| Web Workers and WebAssembly.
|
| Rather than adding another specific layout type, we should add
| a general-purpose way of hooking into the layout engine from a
| background task.
|
| _Update to add:_ just saw from another comment in this thread
| that there 's already an effort underway to do this, called
| Houdini: https://news.ycombinator.com/item?id=40130487 Cool!
| mmis1000 wrote:
| You can actually make a working masonry layout with css
| alone(even make it work with browser resize), if you do know
| the aspect ratio of each item. The hard part is handling the
| column count change and item prepend/insert because that
| would always require js to do.(since tha would change the
| position and column of every item)
|
| There is no logic of js required to do handle whatever screen
| resize.
|
| https://codepen.io/mmis1000/pen/gOyZJqE
| rezonant wrote:
| There is no reasonable fallback when JS is not present or
| hasn't yet executed, and that's not acceptable.
|
| I can't stress enough how important this is for content
| experiences. Your content must display reasonably before all
| bells and whistles load, and when the bells and whistles load,
| your content had better not shift dramatically (ideally not at
| all).
| sebzim4500 wrote:
| I would expect most browsers that aren't running JS do not
| properly handle state of the art CSS extensions.
| rezonant wrote:
| Such browsers can also get by based on the semantic
| ordering of content within the document, which will more
| closely match the visual reality when a masonry type layout
| is used. The alternative of defining several columns leads
| to at least one column being shoved all the way at the end
| of the document after the previous column, whereas in a
| masonry layout that wouldn't be the case.
|
| This is where a proper solution to this problem shines:
| After all, when you are on mobile (at least 60% of your
| users), they will get a single column anyway. Any solution
| that doesn't solve for them is a nonstarter.
|
| That being said, it is the slow loading of JS and the folks
| using truly modern browsers with JS turned off that are
| more common, and for those people this isn't a problem.
| jampekka wrote:
| JS masonry libraries, e.g. masonry.js, can and typically
| do use the HTML for the content and just lay it out
| similarly to what CSS does.
| rezonant wrote:
| But the screen size is an important part of how the
| library will lay out the bricks, and that isn't known
| until JS runs (this can kind of be done with client
| hints, but not on initial page load)
| jampekka wrote:
| I was referring to the document still having the semantic
| structure. E.g. masonry.js also supports relative sizing,
| so it doesn't need to know the screen size beforehand.
| kevincox wrote:
| Or is your average email client? Many of these support
| modern HTML with scripting and remote content disabled.
| greasyphalanges wrote:
| By doing it in CSS you eliminate the need to re-render your DOM
| and make your JavaScript do more useful tasks, and make your
| website more resilient to scripts crashing, freezing, or being
| disabled by the user. Also, one would think that a pipeline of
| JavaScript + rendering engine falls short to a more direct
| solution, as browsers cheat by not using JavaScript ;)
| m3h wrote:
| I am wondering whether it makes sense to keep adding more
| "layout" options to CSS, given that we have the legacy floats and
| then the modern flexbox and grid layout. If there are still cases
| that are not covered, perhaps a better solution to to have one
| final constraints-based system that covers all layout cases, even
| if it comes at the cost of complexity. The CSS frameworks and
| utility libraries will then be built on top of it to provide the
| next generation of "masonry" grid, etc.
| seumars wrote:
| The whole point of this initiative is to stop using out of date
| float-hacks, or soon-to-be out of date hacks to CSS grid or
| flexbox. Firefox's masonry layout is in fact implemented in
| such a way that basically covers all layout cases by simply
| adding a new attribute that collapses grid rows.
| m3h wrote:
| >Firefox's masonry layout is in fact implemented in such a
| way that basically covers all layout cases
|
| That's good to know.
| Terretta wrote:
| > _Firefox masonry... by simply adding a new attribute that
| collapses grid rows_
|
| Not just Firefox, the proposal here is
| grid-template-rows: off;
| zarzavat wrote:
| JavaScript is the final layout system. No declarative language
| can ever handle every use case. Fortunately I rarely need to
| resort to JS since grid came out.
|
| I'm not sure a constraint based system would do much good as it
| would sit awkwardly in the middle of grid and JS.
| baryphonic wrote:
| > No declarative language can ever handle every use case.
|
| Prolog would beg to differ.
| jampekka wrote:
| And CSS https://accodeing.com/blog/2015/css3-proven-to-be-
| turing-com...
| baryphonic wrote:
| This research is cool, but I always feel it needs an
| asterisk. Requiring a click or event or some external
| clock feels like a cop out. I've seen a similar thing
| with PowerPoint.
|
| It would be a bit like saying a language with iterations
| but neither first-class functions nor recursion is Turing
| complete as long as an external stack is provided. Or
| maybe it allows a stack (or recursion) but requires
| external intervention for function application.
|
| Cool hacking nevertheless.
| wizzwizz4 wrote:
| Prolog has well-defined execution order with side-effects.
| It's an imperative language masquerading as a declarative
| one.
| baryphonic wrote:
| MiniKanren, then?
| seanclayton wrote:
| So would LISP, Haskell, and Erlang.
| PhilipRoman wrote:
| With great power comes poor performance. I can immediately
| tell when a page uses JS for layouting (or replacing other
| browser functions like scrolling) as there is a noticable
| latency increase and the page lags about 200-300 ms behind
| when resizing the window.
| bazoom42 wrote:
| You can always generate the layout in javascript if you have
| some requirements which aren't directly supported by CSS
| layout.
| meandmycode wrote:
| I'm dubious that a constraints system would ever be considered,
| CSS has so far had some strong goals around it's predictably on
| layout cost.. that said, Houdini layout proposal is the closest
| to your comment, offloading layout to an isolated js context
| https://github.com/w3c/css-houdini-drafts/blob/main/css-layo...
| .. but honestly flex and grid, plus other things like
| containment have solved so many things for folks now that
| there's just far less demand for improvement than the days
| before flex
| cnotv wrote:
| It IS grid, lvl 3. You can achieve it with:
| display: grid; grid-template-rows: masonry;
|
| This is however limited to webkit. I implemented it and ditched
| in October 2023 already for my private news feed in gallery
| mode.
| qingcharles wrote:
| What do you use instead?
|
| I have it behind a CSS test for the existence of the CSS
| property so it is only enabled if the browser supports it.
| pimterry wrote:
| For more background, and some detailed discussion of the opposite
| argument ("display: masonry" over "display:grid"+"grid-template-
| rows: masonry") see https://github.com/w3c/csswg-
| drafts/issues/9041
| rezonant wrote:
| Oh yes please. Masonry is definitely the missing piece right now.
| And I run into cases where designers give it to me pretty
| regularly-- I don't want to crush their dreams but without a JS-
| free masonry solution, the dreams are getting crushed.
|
| OK, having read a lot more, here's my thoughts.
|
| I love the possibilities that can be raised here when masonry is
| built into grid, but you can target specific rows and columns for
| specific elements in grid. This is a useful thing for some
| layouts, but when the rows are truly non-existent (unlike the
| related auto fill/fit stuff we've had until this point) I feel
| like the abstraction begins breaking down. As much as I love that
| we have Apple pushing to get this done, I do think it is probably
| better to go with a net new masonry display type :-/
| mickael-kerjean wrote:
| 100% for masonry as well, couldn't care less about the approach
| as long as the selected one doesn't see the same fate as websql
| and it becomes a viable solution in a reasonable amount of
| time.
| rezonant wrote:
| Yes that's where I'm torn. I love seeing vendor interest
| either way.
|
| But grid is already extremely complicated, and so easy to get
| wrong it's a meme at this point. Creating even more confusion
| about how it's fundamentals work feels like the wrong path
| :-/
| chrismorgan wrote:
| I strongly dislike the megamenu demo
| <https://webkit.org/demos/grid3/megamenu/>, and feel masonry is
| completely inappropriate there. It makes a complete mess of flow
| direction, badly breaking expectations.
|
| The reading order you'd _expect_ :
| https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-2.....
|
| What the demo actually gives you:
| https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-1.....
| This affects correct reading order and tab indexes. Basically,
| sighted users will _always_ read things in the "wrong" order.
| This just drives home that there is no structure, it's just an
| unstructured bag of links. Except... actually if you go through
| them in numbered order, it looks like there _was_ some fairly
| logical ordering. It's just been utterly demolished by
| inappropriate masonisation.
|
| (I've turned on "number items" in those screenshots. Normally,
| it'd look more like normal columns with no backgrounds.)
|
| The way it _should_ be implemented is with columns, but adding
| `break-inside: avoid` on each section, which their demo has
| missed.
|
| The newspaper demo is also a little dubious for similar reasons,
| but it's a much smaller deal.
|
| Now images and such media which are in more independent blocks
| and where reading order isn't such an ingrained thing, masonry
| layout _does_ work better there. There are still patches where
| things can be a bit iffy, mostly around tab indexing, but it's
| not _obviously wrong_ any more.
| rezonant wrote:
| So you're saying the a11y tree and tab ordering is bypassing
| the actual ordering of content and instead traversing the
| columns one by one? I'd call that a bug. In a masonry layout
| the expectation of a sighted user is that there is no
| continuity from column to column, but instead through the
| visual line. And the "unexpected" (disagree) ordering you show
| does that. I think the issue would be that tab ordering is
| ignoring the raw ordering of the content and instead trying to
| emulate something visual, almost certainly some kind of hold
| over of the implementation as it currently exists.
| chrismorgan wrote:
| The problem here is that users will look at the end result
| and see a series of columns, but that the use of masonry
| makes it not that at all.
|
| I'm saying that masonry is _risky_ if you're using it purely
| visually, specifically _because_ it's purely visual. It's the
| same deal with the CSS `order` property: it can be useful,
| but you have to be careful not to break expectations.
|
| CSS is _almost_ purely visual. There are a few cases where it
| influences the accessibility tree (e.g. `display: none`,
| `speak-as`, `appearance` in some user agents), but never in
| anything like order.
| ptx wrote:
| Maybe it's just me, but as a sighted user I have no idea how
| to read this kind of layout. My expectation would be that any
| sane designer wouldn't use this kind of layout in the first
| place.
|
| What's the "visual line" in the first example? It goes 1, 2,
| 3, 4; then down to 5; then a sudden break in the line as it
| jumps over 3 to the left to reach 6?
|
| Are we supposed to mentally sort the boxes by the top edge
| coordinates before reading? That would almost make sense of
| the second example, except that it doesn't explain why 9
| comes before 10. Maybe sort by the coordinates of the bottom
| edge instead? But then 5 should be first. How do I read this
| thing?
|
| Edit: Actually box 9 seems to start 1 pixel above box 10, so
| sorting by top edge does work! So a sighted reader simply has
| to zoom in to the pixel level and carefully measure the
| coordinates of all the boxes to find the reading order.
| amenhotep wrote:
| My experience with it has mostly been on Flickr, and I
| hated it for this exact reason, even though that was mostly
| pictures not text. Sure, it's very pretty if you just want
| to look at the site and not engage with it in any detailed
| way, like professional designers seem to intend for us, but
| I always wanted to look at a page of pictures and scan my
| attention over them systemically, finding those that
| interested me, being distracted by them briefly, then
| returning to the scan and knowing where I'd left off.
|
| Trying to do this with the "masonry" was _horrible_. What
| direction do you go in? Horizontally? Then how do you track
| which elements belong in which row, where you 've already
| been? They're all interleaved. Vertically? Have fun
| scrolling down and down and down forever as the page loads
| more and more content dynamically. No, neither of those is
| how you're meant to engage, you're supposed to simply sit
| quietly and look at the big wall of pretty pictures.
|
| Giving designers a non-javascripty way to do it is nice, I
| guess, but I really hope the effect is that the bad layouts
| we already have are at least better executed
| technologically, rather than that the better technology
| encourages designers to use bad layouts more often.
| rezonant wrote:
| Well no, the idea is that these are not related pieces of
| content. It's less of a newspaper article and more about
| independent items that are placed across the page. You
| don't have to follow the flow exactly as a user, but
| following the visual line is "more correct" than following
| through all of column A, then column B, etc.
| madeofpalk wrote:
| Well, the idea with this layout is that there isn't really
| an inherit order to the children. You would use it where it
| doesn't matter which order you 'read' the items.
|
| If the order was important, you would use a 1D or 2D
| layout.
| sebstefan wrote:
| That's just a random demo. It's not particularly relevant for
| the concept they're trying to gather feedback on
| chrismorgan wrote:
| The demos should be motivating the feature. A bad demo is
| destructive to that effort. This is a very bad demo.
| hombre_fatal wrote:
| If you open the demos in a browser like Safari that doesn't
| support the feature, the demos remain as normal grid-
| aligned cells.
|
| There I realize that masonry mainly works when your cells
| have such different heights that to grid-align them creates
| a lot of vertical dead space. Images and news blocks with
| images make sense for masonry for this reason and it feels
| good.
|
| But text-only cells where the cell heights don't differ
| much, they seem better without masonry. The megamenu demo
| also works much better as a normal grid because they start
| with a header so grid alignment lets you scan the headers
| left to right easily.
|
| A text-only newspaper could make sense with masonry because
| you aren't trying to navigate relationships between the
| items, and presumably the content can vary the cell height
| a lot.
| KTibow wrote:
| Focusing solely on sighted users, I think the current ordering
| makes sense. What you propose would require often scrolling up
| and down to view the items in order, and would have large
| layout shifts if more items are added.
| mattbessey wrote:
| > This layout creates uniformly-sized columns, without any rows
|
| I find it amusing that they've decided to refer to this as
| masonry layout. If you actually built a wall like this (as
| opposed to uniformly-sized _rows_ , without any _columns_ ) it
| would be a structural engineering disaster.
| cfj wrote:
| Probably influenced by the most popular JavaScript library for
| achieving this type of layout, Masonry[0]. The author notes at
| the end of the article:
|
| > But do expect the name of this value to change in the future.
| And perhaps prepare for a future where we call this "columnar
| grid" or "Grid Level 3" instead of "Masonry".
|
| [0] https://masonry.desandro.com/
| joenot443 wrote:
| I expect this is the case, if I had to describe that layout
| in iOS-land I'd also call it "masonry".
|
| It's a pretty common descriptor in the Wordpress world -
| grids/scrapbooks will often have masonry as one of their
| layout styles. Maybe 100 years from now when people are
| browsing in their neurodisplay they'll be able to think
| "masonry" and have their photos tile the way they like, never
| having heard of Javascript or CSS in their lives. Language is
| neat like that.
| rezonant wrote:
| But masons build floors like this all the time, and it is not
| an engineering disaster. That's the metaphor.
|
| The reason you think it would be a disaster is the load of
| gravity against it, a concept they have not yet introduced into
| CSS, thankfully.
| 627467 wrote:
| "masonry layout" is a term used for at least a decade[0]
| Pinterest is probably the most famous implementer of this
| layout
|
| [0] https://www.sitepoint.com/understanding-masonry-layout/
| account42 wrote:
| Most _infamous_.
| Terretta wrote:
| > _amusing that they 've decided to refer to this as masonry
| layout_
|
| They haven't decided this. Keep reading!
|
| TL;DR:
|
| _Perhaps the best syntax could be grid-template-rows: none; to
| convey "please do not give me any rows". Sadly, it's too late
| to use this name, because none is the default value for grid-
| template-* and means "please give me only implicit rows, no
| explicit ones"._
|
| _Instead we could use the name off to convey "please turn off
| the grid in the row direction, and give me only columns"._
| grid-template-rows: off;
|
| _But do expect the name of this value to change in the future.
| And perhaps prepare for a future where we call this "columnar
| grid" or "Grid Level 3" instead of "Masonry"._
| rezonant wrote:
| This is creating a mode of grid where we say "it's not
| actually a grid" and is my biggest problem with this
| philosophically. It makes more sense to treat it as it's own
| display type, where the row/column targeting don't exist.
| It's not just that row targeting doesn't exist, it also makes
| no sense to target columns.
| datascienced wrote:
| Might be ok for a footpath?
| FalconSensei wrote:
| Masonry layout is pretty common for streets, sidewalks,
| driveways, etc, at least in Brazil
| georgesimon wrote:
| I think, in structural engineering terms, it refers to old
| natural stone wall [0] construction methods. Some bridges
| around me are made like this, and they're over a thousand years
| old.
|
| But I agree that it's not a good adjective because I had the
| exact same first thought. Both "natural" and "stonewall" would
| be better, and they're not great names either.
|
| [0]https://duckduckgo.com/?q=natural%20stone%20walls&ko=-1&iax=
| ...
| HPsquared wrote:
| Surely they would not build like this. You want to avoid
| vertical shear planes.
| rezonant wrote:
| There's no gravity here, so the comparison makes no sense. In
| walls masonry construction produces sheer lines horizontally,
| an axis gravity is not bearing upon. This feels like taking
| the metaphor just a tad too literally.
| georgesimon wrote:
| I didn't think so, of you look at old stone walls, there's
| an absence of continuous horizontal or vertical patterns.
| (However the discussion was a fork, about wall building, so
| it was quite literal)
| mewpmewp2 wrote:
| I associate masonry with the old ages, since this is one of
| the technologies you research in Civ games and back then I
| think people did have stones in non-standardized shapes and
| were just trying to fit things together. I'm not native
| English speaker, so I first heard this term from the games.
| georgesimon wrote:
| Yes, it has that association in English.
| treflop wrote:
| Masonry just refers to working with bricks. It's old as time
| but we still make stuff out of bricks and you can still be a
| mason today.
|
| https://en.wikipedia.org/wiki/Masonry
| georgesimon wrote:
| It seems your are saying it is only relates to bricks? But
| it's not, it's any stone, cut or formed.
| treflop wrote:
| I suppose I'm using brick by its informal definition as
| just a construction block.
|
| https://en.m.wikipedia.org/wiki/Brick
|
| But yes, historically brick meant just one type and style
| of material.
| ryanblakeley wrote:
| "Dry stack" is another term for that, a stone wall without
| mortar.
|
| In my opinion, thinking of this as a grid is misguided. It's
| barely different than flex columns. I would want to be able
| to have some objects take up more width than one column, or
| not have clean columns at all. Like "space filling" and
| "mosaic".
| exyi wrote:
| I think this is just transposed masonry, the wall looks ok if
| gravity is on the left. "Transposed" is redundant though, since
| I assume it will work in both grid-template-columns and grid-
| template-rows
| wongarsu wrote:
| Maybe there should be a grid-template-masonry-direction? Just
| quickly surveying a couple of sites, "masonry" and "horizontal
| masonry" seem to be about equally common.
|
| On the other hand horizontal masonry is constructed very
| differently: Flickr fits thumbnails into a row until it reaches
| some predefined total length, then scales everything down
| slightly so the total row width matches exactly (resulting in
| rows of different height). Deviantart does something similar,
| but shuffles the images for better fit so that the different
| row heights are barely perceptible.
| chuckadams wrote:
| Filling rows without any defined columns is more or less what
| flexbox already does.
| dkdbejwi383 wrote:
| Wonder if they'll add support for `masonry-arrangement:
| flemish-bond;`?
| wildpeaks wrote:
| It makes sense they'd pick this name, it refers to the jQuery
| plugin that was popular for doing this kind of layout back in
| the 2010s, so it's a convenient shorthand.
| lloydatkinson wrote:
| Heavens help us if we are naming features after an
| accidentally popular library like jQuery.
| sausajez wrote:
| Accidentally? How can something be intentionally/
| unintentionally popular?
| PurpleRamen wrote:
| Marketing makes something intentionally popular.
|
| Accidentally, seems harder. It kinda smells for people to
| intentionally make it not popular by actively working
| against fame, or something like that..
| robertlagrant wrote:
| > Accidentally, seems harder. It kinda smells for people
| to intentionally make it not popular by actively working
| against fame, or something like that..
|
| It's not harder; it's the only thing that works for
| tools. Tools cannot be good for long because of
| marketing. Marketing is the thin layer of paint over the
| Ferrari. Very nice paint, but if the car doesn't work or
| go very fast very quickly then that's that.
| kreetx wrote:
| It's often referred to as the masonry layout, so why not?
| chickenchase-r wrote:
| because every new construction requires a solid
| cornerstone? every archway a keystone? dont forget to put
| your boots in the trunk and your trunk in the boot.
| Nucular aluminum? I dunno
| lloydatkinson wrote:
| I made the mistake of forgetting HN simultaneously hates
| the web and JavaScript but worships jQuery
| The_Colonel wrote:
| JS DOM API is still abysmal and jQuery API is still
| great. No worshipping needed.
| recursive wrote:
| Really? Genuine question, which part? If there are too
| many to name, how about just one? It seems pretty good to
| me.
| The_Colonel wrote:
| My favorite is this comparison for checking whether an
| element is hidden: $(el).is(':hidden')
|
| vs. !(el.offsetWidth || el.offsetHeight
| || el.getClientRects().length)
|
| DOM API has other problems like lack of chaining which
| forces you into a very imperative style of programming,
| e.g.: $(".alert").hide();
|
| vs. for (const el of
| document.querySelectorAll(".alert")) {
| el.style.display = 'none'; }
| recursive wrote:
| I've never had a case where I didn't know the reason or
| mechanism by which an element would be hidden. In my
| code, I use the `hidden` property. In that case it
| simplifies from $(el).is(':hidden')
|
| to el.hidden
|
| It's not quite as succint as your jquery, but you also
| could have written this.
| document.querySelectorAll(".alert").forEach(el =>
| el.hidden = false);
|
| Is it less imperative? I mean I guess it doesn't have an
| explicit loop, but I don't really see why that's good or
| bad.
| The_Colonel wrote:
| > I've never had a case where I didn't know the reason or
| mechanism by which an element would be hidden.
|
| Unfortunately, I usually don't keep the whole codebase in
| my head (including libraries), so I often don't know the
| reason.
|
| The more general point is that I don't want to have to
| know, because the mechanism of how it is hidden is not
| what I care about.
|
| > It's not quite as succint as your jquery, but you also
| could have written this.
|
| Yes, it's more than three times as long as the jQuery
| variant.
| recursive wrote:
| Ok, I get it. Fair points. I'm not a jquery hater. In a
| lot of cases, I'd rather write jquery than react for
| instance.
| troupo wrote:
| jQuery has a fluent interface and often
| shorter/smaller/more convenient APIs on top of that.
|
| DOM APIs are quite literally 90s era Java-style APIs.
|
| While DOM APIs have pulled in a few niceties over the
| years, some of them are really anemic (e.g.
| querySelectorAll does not return a proper Array-like
| object). Worse is _combining_ them. Almost every API is a
| single-shot tedious step-by-step chore.
| throwup238 wrote:
| That ship sailed with _JAVA_ script in 1995.
| robertlagrant wrote:
| It wasn't accidentally popular. It was just very good.
| londons_explore wrote:
| From a structural engineering point of view, this is because of
| the extra 1G of force keeping the rows together, but nothing
| keeps the columns together.
|
| Since bricks have some tensile strength, but mortar (the 'glue'
| between rows and columns) has ~none, that means that, if you
| must have lines of weakness, you would prefer they be
| horizontal than vertical.
| mrighele wrote:
| Nothing that a transform(90deg) cannot solve :-).
|
| More seriously, what you describe is quite doable with flexbox
| (flex-direction: row, flex-wrap: wrap and flex-grow: 1).
|
| Interestingly, even the Masonry layout was already doable using
| a simple multi-column layout, the "only" issue is that instead
| of having the items left-to-right, top-to-bottom (ordered by
| row) you have them top-to-bottom, left-to-right (ordered by
| column) which is not what you want most of the times
| hennell wrote:
| There's a CMS I use that has a photo search option. It loads
| in images in a column ordered masonry layout, which when you
| scroll down adds new images to the columns, so all the
| pictures move about and you've no idea where you are.
|
| It's infuriating.
| paulddraper wrote:
| Thank you. I was confused as well.
|
| A name for the _inverse_ I suppose
| Menu_Overview wrote:
| If you read it to the end, you'll see their note on the name.
| That is also something they want up for debate.
| pavlov wrote:
| If the designers of Unix had seen the light of CSS, they wouldn't
| have bothered with shells and file descriptors and C and Awk and
| all that composable flotsam.
|
| They'd just created a single program, call it the "Central
| Software System", and defined thousands of properties that let
| you control its state machine to produce the output you need.
|
| Presto! The perfect computer. If for some reason someone needs a
| new kind of output, it can be added to the Central Software
| System via a friendly decade-long committee process.
|
| And if the properties happen to conflict in how they define some
| output, well, the one company in the world who has actually
| implemented all of this "open standard" can decide what happens
| in that case.
| sebstefan wrote:
| You can say that about almost any abstraction layer
| gwervc wrote:
| The WPF has easy to use grids and layouts, a sane default
| styling yet is very to completely overhaul. CSS is a failure
| by design.
| sebstefan wrote:
| Yes, but that's a completely different point
| smokel wrote:
| They would probably also use regular expressions and
| incomprehensible $ and \ escape codes to retain some of the
| fun.
| datascienced wrote:
| Is this a sysvinit vs systemd rant?
| HeckFeck wrote:
| $ /etc/init.d/initwar start Starting initwar (via
| systemd)
|
| _Sad sysadmin noises_
| dartos wrote:
| Nixos?
| afavour wrote:
| It's almost - _almost!_ - as if the designers of Unix and of
| CSS work in completely different scenarios and with completely
| different constraints! Almost!
| pavlov wrote:
| And with this convenient domain excuse, CSS has managed to
| become a system that's not a fit for any domain.
|
| It's incomprehensible to visual designers, incomprehensible
| to programmers, and incomprehensible to document authors.
|
| On the upside, it provides a massive moat of sunk cost and
| implicit implementation dependency around Chromium, so at
| least there's that.
| afavour wrote:
| I'm a web programmer and I find it comprehensible. Sure
| there are times I need to go to the docs but vast majority
| of the time I can work with it just fine. I'd agree that it
| probably is incomprehensible to many visual designers but
| unfortunately so is code in general. CSS _is_ complex,
| especially these days, but I feel like those who don't work
| with the web every day simply don't get to experience it
| often enough to know that it does make sense within its
| domain.
|
| But sure, if you want, CSS is a conspiracy theory to ensure
| the dominance of Google.
| Joker_vD wrote:
| Of course it is, there is even the word "masonry" in
| TFA's name!
| pavlov wrote:
| It's not a conspiracy. It's a well-intentioned but poorly
| thought-out design for basic 1990s word processing
| layouts that accidentally blew up to describe entire
| application GUIs, and now it's not in the interest of the
| stakeholders to try to do anything about it.
|
| It's the same kind of growth pattern as government
| bureaucracies. Those are largely not conspiracies either,
| despite the occasional optics.
| afavour wrote:
| What you're describing is the organic growth of a
| platform. The web is undeniably more complex than it was
| twenty years ago but needs are more complex too. Yes, the
| complexity does benefit major players but that isn't the
| reason the complexity exists.
|
| It's ironic you're saying that CSS is some form of vendor
| lock in. I have to imagine that if Google proposed a new
| layout engine for the web tomorrow they'd be roasted to
| kingdom come for their attempt at taking over the web.
| miunau wrote:
| Maybe you need better glasses. This proposal is coming from
| the Webkit team, ie. Apple. CSS is plenty comprehensible
| and using it gets better with every browser release as they
| are focused around yearly interoperability efforts.
| jampekka wrote:
| I happen to quite like CSS (in comparison to any other
| layouting system out there), but I really wouldn't
| characterize it plenty comprehensible.
|
| I'm quite certain there's no human on earth that could
| reliably predict the outcome of most non-trivial real-
| life CSS layouts given just the code. And even though the
| situation has improved a lot, it's still common to have
| to use clearfixque hacks that definitely weren't
| envisioned by the commitees.
| echoangle wrote:
| Isn't that true for most software? Do you think you can
| simulate the outcome of a semi complicated Python
| Codebase just by looking at it? That's just an intrinsic
| property of the problem you're dealing with, adaptive
| page layout will always be complicated and not easily
| understandable just by looking at code.
| jampekka wrote:
| I think I'd have a lot better shot with a semi-
| complicated Python codebase to be correct. Even with GUI
| stuff if using something like e.g. Qt box layouts.
|
| Yes, CSS is a lot more powerful than those kinds of
| systems. Perhaps comparable to constraint satisfaction
| layouts that tend to be quite surprising.
|
| But even so, there are so many settings and their
| combined behavior in CSS that it's, for me at least,
| totally infeasible to try to code much CSS "up-front"
| without constantly checking the result of the changes.
| And I don't mind it that much, but I'm quite certain that
| a more "predictable" equally powerful layouting system is
| entirely possible.
|
| It could be an interesting challenge to show people some
| layouts and ask them to produce them using CSS without
| being able to iterate the results.
| pavlov wrote:
| AFAICT, practically nobody picks WebKit over
| Blink/Chromium for new projects.
|
| The reasons why Apple still maintains their own browser
| engine have to do with corporate prestige and expensive
| insurance policy. They can afford it because Apple is
| literally the world's richest corporation.
|
| Nobody else does anymore. Even Microsoft gave up on their
| own browser engine despite having 97% market share two
| decades ago. And Mozilla is bankrolled by Google as their
| own kind of insurance policy.
| miunau wrote:
| Safari has 24% of the browser market.
| pavlov wrote:
| Not on merit but simply by being the only allowed option
| on iOS. Nobody chooses Safari because it runs WebKit
| instead of Blink.
| FartinMowler wrote:
| What would you propose instead that is comprehensible to
| visual designers, programmers, and document authors?
| cqqxo4zV46cp wrote:
| The inane and utterly incomprehensible toolset that they
| happen to be more familiar with, obviously. Some people
| take their ball and go home after they can't work out how
| to centre a div, after decades of having "HTML and CSS
| are for the 'stupid' developers" drilled into them, and
| thinking that they can intuit it.
| yau8edq12i wrote:
| And yet, somehow, I browse websites using CSS successfully
| every day. Reality disagrees with your narrative, which is
| nothing more than a pandering "CSS bad" with little
| substance. "Not fit for any domain", "incomprehensible",
| these insults are based on what, exactly?
| greasyphalanges wrote:
| I will concede to an argument that CSS exemplifies "design
| by committee" pejorative and is blighted by backward
| compatibility woes, but rest assured, it does its job as
| best as it can. Web development has patchworked its way out
| of most problems it has created, making it somewhat
| burdensome to learn. I'd say that is its Achilles's heel.
| camillomiller wrote:
| It's always funny to read people that just never understood
| CSS trying to convince everyone that CSS is impossible to
| understand!
| bryanrasmussen wrote:
| it's better on HN because you can get it combined with
| snide insinuations that they could have created a better
| layout system that would do all the things that CSS does,
| but also fix the various problems that CSS has.
|
| However the glory days are evidently behind us, because
| these insinuations never end with "in a weekend" anymore.
| jampekka wrote:
| I'd be surprised to hear anybody with intimate knowledge
| of CSS claiming to understand CSS.
| crispyambulance wrote:
| Yes, that's fair.
|
| Sure, today we have grid and vanilla CSS is sane and
| useable by anyone who takes the time to learn the modern
| way of doing things.
|
| But let's not forget what a long and tortured road CSS
| has taken to become what it is today. CSS was a total
| dumpster fire up until around when flexbox came out. It
| was SO HARD to make it do what you want for SO LONG.
|
| The MOST BASIC NOTION of layout, putting things in a
| freaking grid, was missing from CSS for almost two
| decades. Yet, the grid concept has been around in
| application layout since the 1980's. I can't explain why
| it took CSS such a long time, and the explanations I've
| heard don't seem plausible to me.
|
| It's understandable that folks who were around in the bad
| days of CSS are still kind of bitter. I was, and if I
| didn't take the time to see the new ways of using it, I
| would still be incredulous about CSS.
| afavour wrote:
| > I can't explain why it took CSS such a long time
|
| It is weird to look back on but the web platform
| essentially went through a dark ages for a while. You
| could say the same about why it took us so long to get to
| ES6 JS, too. The standards bodies were frozen in ice (and
| I don't quite know why either), everyone was debating
| HTML5 vs XHTML and somehow the rest of the platform
| floundered for years.
| marksbrown wrote:
| Microsoft failed to capture the internet. IE6 can still
| cause sane minds to crack.
| bazoom42 wrote:
| > The MOST BASIC NOTION of layout, putting things in a
| freaking grid, was missing from CSS for almost two
| decades
|
| This is not true. CSS have had 'display:table' for 25
| years, which is a simple grid layout model equivalent to
| html tables. Content can be aligned in rows and columns.
|
| 'Display:grid' is much more powerful of course.
| crispyambulance wrote:
| Yeah, I remember those. It was intended as a way to make
| "tables" using divs.
|
| That way, we could pretend to do page layout with CSS,
| while still feeling shitty about repurposing something
| meant for tables.
|
| There's just no justifiable reason for putting whole-page
| lay-out on the back-burner for so long. So many other far
| less important things came out before grid, it feels
| almost like it was deliberately spiteful to delay it so
| long.
| bazoom42 wrote:
| Why would you feel shitty about using 'display:table'?
|
| It puts things into a freaking grid as you asked for.
| jampekka wrote:
| There was a huge cargo cult adamantly against using
| tables back in the day, even though the "true way" of
| hacking divs with float and clearfixes and invisible
| images was totally broken. Somehow having bunch of
| wrapper and empty divs was "more semantic" or something.
|
| I was in the cult. It was totally inane, but seems to
| carry some effects to this day.
| crispyambulance wrote:
| For a long time, css was a huge step backwards from what
| we were accustomed to with desktop application layout
| mechanisms.
|
| Web-apps were "a thing" starting in the very early
| naughts, yet just getting stuff to stick where you wanted
| it on web page required a bunch of stupid hacks and
| accommodations. Of course people resorted to using tables
| for page layout. The display:table thing was just a
| continuation of that.
|
| Whole-page layout should have been an absolute top
| priority for the folks that controlled css, yet it seems
| they just didn't care until grid finally came out in
| 2017-ish? I just don't understand why that is.
| dada78641 wrote:
| While I agree that CSS is sometimes difficult and obtuse,
| and getting things working in it is more of an art than a
| science, it's actually _shockingly_ easy to get basic
| layouts working in it these days even as a total beginner.
| CSS is very powerful and you can learn the basics very
| quickly.
|
| It's also worth keeping in mind that CSS is sometimes more
| complicated than it seems like it should be due to
| accessibility concerns and flexibility. That's why you can
| take some HTML produced by some part of your system and use
| it in completely different contexts with totally different
| designs, entirely as is, just by adding a few different
| rules.
|
| I've been doing HTML dev since the late 90s and things were
| infinitely more difficult back in the old days. CSS might
| have been simpler, but doing complex things required tons
| of bizarre hacks that also made your design more frail and
| less accessible. These days CSS has improved to the point
| where you can do just about anything, and even very
| complicated effects can fairly easily be deconstructed just
| by looking at the devtools and poking around until you get
| it.
|
| CSS isn't perfect, but all things considered I'm not
| complaining.
| snapcaster wrote:
| Not fit for any domain? It's one of the most widely used
| "programming languages" in the world. It's clearly fit for
| many domains I don't know why people have to be so dramatic
| with their tech opinions
| bodantogat wrote:
| I don't get the drama either. The issue I have with CSS
| is less about the spec itself, and more about browser
| compatibility. I'd be dead with caniuse.com and MDN.
| Having said that, when I build a new page, I rarely need
| to spend more time laying out the html & css than it
| takes to type it out and test. Creating cross platform,
| responsive web pages is a solved problem now.
| gherkinnn wrote:
| Nonsense. CSS works. It has its quirks, but what doesn't?
|
| What I do see here, is one of many cases of "I don't
| understand it therefore it is dumb because it can't be my
| fault".
| bmacho wrote:
| But your favorite 20% of CSS (just like in the old days +
| some of the new features) fits nicely for web design.
| whywhywhywhy wrote:
| It's honestly not that difficult at all, saying that as a
| designer.
| JamesSwift wrote:
| HTML and CSS were created in a time where the entire point
| was to provide marked-up documents to be read. Now the
| browser is mainly a generic application runtime.
|
| Its like if the terminal was actually now mostly a video
| player and people complaining about how awk and sed are
| tough to use against video frames.
| alpaca128 wrote:
| Did the designers of Unix also have to ensure compatibility
| with billions of devices connected worldwide running different
| software stacks?
|
| Also as mentioned in the linked article the masonry layout is
| already possible with JS, no decades-long committee process
| needed. It's just about standardizing something frequently
| used.
| kevincox wrote:
| It's fine, just run ./configure before compiling.
| btbuildem wrote:
| The point GP is making is that they didn't have to, because
| the architecture made it infinitely configurable while
| remaining coherent.
|
| Billions of connected devices worldwide do indeed run on *nix
| with a mad variety stacked on top.
| klabb3 wrote:
| CSS may be complex, but you get a huge bang for the buck in
| terms of UX, rendering performance, flexibility, accessibility,
| compared to most drawing and layout systems. You could argue
| against border-radius and flex as well, but Im glad we're past
| clearfix and gifs for corners. Does masonry layout qualify for
| becoming standard? I don't know.
| blackbear_ wrote:
| > compared to most drawing and layout systems
|
| This is just an accident of history and not because CSS has
| anything that makes it intrinsically better than the
| alternatives.
| jampekka wrote:
| Anything other than existing.
|
| CSS is quite a mess, and I would welcome a backwards-
| incompatible new layouting system, but all the alternatives
| out there are a lot worse.
| klabb3 wrote:
| Accumulated garbage for backwards compatibility? Let him
| who is without sin cast the first stone.
|
| I'm not saying css is intrinsically better (what does
| intrinsic even mean in this case?). It's pragmatically
| better than anything else I've seen. It's dead simple to
| learn and use, and (almost) fully declarative, and degrades
| gracefully. Just show me a better alternative and I'll
| change my mind.
| doctor_eval wrote:
| I want to say something about monolithic kernels but I'm too
| scared.
| jampekka wrote:
| Trusting us plebs with universal turing machines is
| unacceptable. There's a config/app/saas/appliance for
| everything you need to need.
| mejutoco wrote:
| What is the composable unix approach for layout/graphical
| interfaces?
| mrighele wrote:
| Tcl/Tk ?
|
| When you had enough of using text as the single data
| structure in a shell, you can start doing the same with a GUI
| toolkit.
| wizzwizz4 wrote:
| Tk has basically the same model as CSS, except that it's
| not strictly hierarchical. (Though CSS has that now, too:
| https://developer.mozilla.org/en-US/docs/Web/CSS/@scope)
| wodenokoto wrote:
| What dynamic layout system is it that ships in posix again?
| cjk2 wrote:
| Um, err, POSIX.
| jojobas wrote:
| Was rather hard to tell if you're joking or not, seeing how
| every trivial program today wants to have Electron with it.
| lumb63 wrote:
| I didn't realize this was satire until the second paragraph.
| Well done.
|
| As a firmware engineer who is trying to build a website in his
| spare time, I find CSS absurd. I've found SCSS and Sass make it
| much more bearable. The ability to represent a hierarchy
| concisely is awesome.
| meowface wrote:
| CSS is adding native nesting:
| https://developer.mozilla.org/en-
| US/docs/Web/CSS/CSS_nesting...
| micromacrofoot wrote:
| the committee process is probably down to about 5ish years now?
| I feel like people who complain about this weren't around when
| the process was "20 years from now when we can drop IE support"
| -- velocity has improved significantly
| pquki4 wrote:
| I thought this kind of waterfall layout was cool and trendy a few
| years ago, but these days very few websites are doing it?
| rezonant wrote:
| A big reason is because it's not possible on the web, and it's
| worth noting that the kind of visual you see in masonry demos
| is the most extreme example of what you could do with it. Most
| of the time it's: I want to fill a page with modules of
| differing heights where positionality is based on importance
| not coordinate, without weird gaps where items fall into the
| same row and constrain each other.
| nkozyra wrote:
| For awhile it was just described as "Pinterest style."
|
| It has some use cases but for the most part it's literally a
| wall of unstructed information. Difficult to parse and build
| any mental hierarchy.
|
| It's also ... incredibly easy to do with existing css.
| thousand_nights wrote:
| > incredibly easy to do with existing css
|
| care to demonstrate? given a dynamic collection of images
| where you don't know the aspect ratios beforehand
| crote wrote:
| Does it actually solve that problem, though?
|
| In the photo demo all content is either 1-column or
| 2-column wide - and that already results in some very
| noticeable gaps. I don't get the impression that it can
| properly handle arbitrary aspect ratios. You're pretty much
| forced to stick to a single column width and fit all images
| to match, so not exactly an improvement over what we
| already have right now.
| echoangle wrote:
| It does handle arbitrary aspect ratios by scaling the
| image to fit the width of the column. What else should it
| do? It also allows you to define different widths for
| each column. Isn't that exactly what you want for a
| masonry layout?
| nkozyra wrote:
| If, for example, it rendered the child elements such that
| they automatically gained/lost overflow in relation to
| other columns, it might have some practical application
| that straight CSS cannot do. This would allow children to
| be sized vertically (effectively cropped) to produce an
| even square.
| nkozyra wrote:
| All of the images have only a constraint on the width, the
| aspect ratio is irrelevant. You can still do it with a
| grid, you just let the browser render the images within as
| it would normally.
|
| Where it gets more complicated is getting them all to align
| horizontally at the bottom, which even this proposal
| doesn't do. Pinterest, of course, solved this by not having
| a "bottom."
| SassyBird wrote:
| Not the GP, but here is my website with photos with
| different aspect ratios. I used display:inline-block to
| achieve this result, effectively treating photos as text
| that needs to reflow.
|
| https://yakubin.com/photography/albumless/
|
| https://yakubin.com/photography/album/kenya-2023/
|
| Proper masonry layouts which fill all available space in
| practice actually crop some images. Leaving space around
| photos is required when you don't want cropping and want to
| preserve aspect ratio. That's why I prefer my solution over
| what JS libraries for masonry layouts do.
| crote wrote:
| Yeah, it's quite weird to see such an obscure feature being
| proposed as a CSS standard. The demos just aren't convincing?
| Sure, I get the Pinterest application, but the other ones
| seem like a solution in search of a problem.
|
| In the megamenu demo the multicolumn layout is pretty much
| indistinguishable from masonry. The only thing wrong with it
| is that it allows column breaks in the middle of content.
| That doesn't need masonry to fix it.
|
| In the newspaper demo the multicolumn layout is actually
| better, because _that 's how newspapers work_. The masonry
| demo becomes an unreadable mess.
|
| The museum demo almost feels intentionally mis-designed. The
| CSS Grid 1 layout obviously has issues, but it could've
| easily been solved by pulling the nav bar out of the gallery,
| and using a multicolumn layout for the gallery instead.
|
| So that leaves the Pinterest-style photo gallery. Sure, it's
| objectively better if you want to achieve this kind of style,
| but it's an outdated design with horrible UX. Why is it
| special enough that we need explicit support for it in the
| standard?
| whywhywhywhy wrote:
| It's been called masonry before Pintrest was even founded.
| nkozyra wrote:
| I don't doubt it, but it certainly wasn't common web design
| terminology. Waterfall was one I encountered frequently.
| lovegrenoble wrote:
| I always preferred to use Flexbox on almost everything; it's
| suitable for most situations. Also, for anyone struggling
|
| with flexbox - I use this tool to streamline the process:
| https://flexboxcss.com
| ThatMedicIsASpy wrote:
| I already use this. On Firefox I just enable it in the options
| and make use of it for my bookmarks. On Mobile this isn't an
| issue since it's just stacked on top of each other (no
| about:config on mobile).
|
| The last image has it turned off.
|
| https://imgur.com/a/o7OyZEW
| jamincan wrote:
| From what I can tell, the rules of masonry layout result in
| irregular sorting since, from what I can understand, it fills
| by row the highest available slot first, but the result
| visually appears as though it's sorted in columns. So if you
| resize your window, the order of your bookmarks would change.
| somishere wrote:
| Try Firefox beta on mobile :)
| codingclaws wrote:
| I built a masonry layout with only CSS and HTML 10 years ago. The
| site is actually still live. A scripting language is used to
| generate the HTML and CSS based on the dimensions of the images.
| But the masonry runs left to right not top to bottom.
| thejohnconway wrote:
| How does that differ from just setting the images to be inline-
| blocks? Was it justified?
| codingclaws wrote:
| It's centered basically. All rows span the same width, but
| the heights of the rows can differ.
| The_Colonel wrote:
| That's not going to be responsive which is today a must have.
| codingclaws wrote:
| It is actually responsive, I think because I used percentages
| in the CSS.
| The_Colonel wrote:
| So it makes pictures larger / smaller based on the screen
| width?
|
| Usually what is expected is that with narrower screen, you
| get fewer columns, pictures are still same-ish size. You
| also need to keep the order of the items (e.g. on a wider
| screen 1, 2, 3, 4 are all on one row, with a smaller screen
| 1 and 2 are on a row, then 3 and 4 on another row).
| CodeWriter23 wrote:
| So no different than current design paradigms (which I
| loathe btw) which give you the exact same content
| regardless of viewport size.
| The_Colonel wrote:
| Sure, but different from what the masonry design is meant
| to facilitate (check the linked demos). It's very useful
| esp. for a photo gallery kind of sites.
| KwanEsq wrote:
| Nice to see this getting some push and attention. I still
| remember seeing Mats Palmgren (seemingly?) single-handedly
| proposing/speccing and implementing this in Firefox a few years
| ago. Glad it hasn't just died because it was a Mozilla
| proposal/experiment (with proper experimental stage), instead of
| something Google just dumps on the web fait accompli.
| slimebot80 wrote:
| Is there any examples of server-side rendering that pre-
| determines a masonary layout for the content?
|
| Like: Given these images, and this window size, here's a
| calculated layout to make them all look nice...
|
| I figure this would be more performant than any type of JS
| polyfill
| echoangle wrote:
| How would this work when loading the page the first time? Would
| you check the window size and reload once just to get the first
| layout? And would you reload the page every time the window is
| resized?
| phkahler wrote:
| Umm. Can't you just make each column a subgrid within a larger
| grid that has one row?
|
| It seems like either these constructs are poorly designed, or
| people don't see how to use them to get what they want.
| PullJosh wrote:
| As I understand it, the hard part of a masonry layout is
| ensuring that items are laid out with the first items near the
| top of the screen and the last items near the bottom of the
| screen.
|
| If you just plop your items into columns, the first items will
| all appear in the first column and the last items will all
| appear in the last column (left to right), which is not the
| behavior you want.
|
| To my knowledge, the correct behavior cannot currently be
| created in CSS alone. (Or if it can, it must be a wild hack.)
| phkahler wrote:
| If people want to choose where things land they can do that.
| Therefore I assume we're talking about a scenario where the
| items are not known in advance - i.e. they come from a
| database query or similar. Is there no way to SELECT every
| Nth item when doing a query? Return a count and select where
| count MOD N = k? Dump those in a column.
|
| This feels like "I want my layout algorithm to be part of the
| standard." and if you don't think so, see the part where they
| also want the equivalent of "colspan = 2" for some itmes -
| possibly with another pattern to define which ones.
| micromacrofoot wrote:
| > "I want my layout algorithm to be part of the standard."
|
| I mean, yes... it's a very common layout algorithm so it
| gets standardized
| threeseed wrote:
| But what if you resize the browser or turn the screen on
| your iPad.
|
| Would you really want that to trigger an entirely new set
| of SQL statements ?
| achairapart wrote:
| So, the background story is that CSSWG DevRels from browser
| vendors are debating how to formally include the Masonry layout
| into CSS, at least since 2020, when Firefox first proposed it.
|
| The news here is that people at WebKit decided to push the debate
| to the public, inviting designers and developers to take some
| action ("post to social media, write blog posts"), in order to
| get past this.
|
| While it may look just like a formality, I think this will make
| an important precedent. The real underling debate here is either
| to treat every layout option as a part of the CSS Grid, or
| keeping adding new CSS Display proprieties as necessary.
|
| The first option will make even more complex the (already
| convulsed, IMHO) CSS Grid specs, the latter will bloat the CSS
| specs with a load of new proprieties (and related sub-
| proprieties).
|
| Either way, it's not as easy as it looks.
| mvonballmo wrote:
| A "row-less" grid fits very well in the current CSS Grid
| specification, in that it can reuse the very powerful column-
| definition property as well as sub-grids. Their examples very
| convincingly show how orthogonal these features are.
|
| Mostly, you just write grid-row-template: masonry and
| everything else just works with it. This is nice. It doesn't
| become harder to use the grid layout than it already is IMHO.
|
| The drawback is mostly for browser-engine authors, for whom the
| bar for "fully supports CSS Grid" will be set even higher. They
| also mention that it might avoid "performance traps" where an
| implementation that needs to support all features of grid might
| be slower at some parts of grid layout than it would be if the
| specification were simpler.
|
| If there were a separate display mode, then you'd have to
| repeat the grid-column specification for the masonry layout,
| which seems a shame.
| nightpool wrote:
| > If there were a separate display mode, then you'd have to
| repeat the grid-column specification for the masonry layout,
| which seems a shame.
|
| Why? What's the downside to reusing grid-column-template or
| whatever for the CSS Masonry spec?
| krsdcbl wrote:
| my thoughts exactly - i think this points to a possible
| naming issue, since "masonry" is a relatively vague alias
| that does not really describe the underlying layouting
| logic, it just became ubiquitous enough for people building
| webstuff to understand because of that one jQuery plugin
| back in the days.
|
| A better approach might be to lean on the "grid" naming,
| but still silo it off via an own display directive (a bit
| like "block" and "inline-block" have shared properties, but
| also mutually exclusive behaviours)
|
| So maybe an own `display: flex-grid;` could be an
| interesting solution?
|
| This separate layout mode would avoid "result-specific"
| nomenclature like "masonry", and could lean on both flexbox
| & grid to achieve that look: - using `grid-auto-flow` to
| set a "masonry axis" & distribution logic - using _either_
| `grid-template-columns` or `grid-template-rows` to specify
| the "lanes" - and to make my frankensteinian display-mashup
| even worse (or genius! for you to decide), the grid items
| could in turn abuse `flex-grow, flex-shrink, flex-basis` to
| control their height/width within the main "masonry" axis
| beardedetim wrote:
| I really like this concept of `flex-grid` because that's
| exactly what this display would be.
| eyelidlessness wrote:
| > Either way, it's not as easy as it looks.
|
| And exploring the tradeoffs might lead those exploring to
| reconsider their preferences going in.
|
| Not directly related to the topic, but I recently did some
| prototyping on a second iteration of an interface with a
| similar tension--proliferation of similar but distinct types in
| a data model, or expanding the set of nuances within each
| existing type to support refinement within it. Going into that
| prototyping session, I had a very strong bias in favor of the
| latter. But after exploring the options, I found it vastly
| simpler to consume the "bloated" interface, and to reason about
| the resulting application code consuming it.
|
| I don't have strong feelings on the topic as it applies to CSS
| masonry, but I suspect there could be similar surprises in how
| people think about this tension intuitively versus in practice.
|
| And while I think CSS in particular will have a hard time
| justifying "bloat" (proliferation of use case specific
| semantics), I think it's possible that users do tend to find
| more difficulty using CSS's denser APIs (like grid).
| qingcharles wrote:
| It's great they're doing this. I've been nudging everyone
| involved with this since last year. The Chrome guys are the
| furthest behind (no support). FF has flag support.
|
| I've been testing it since last year on FF and Safari and have
| no complaints about their implementations. I know some people
| are sniffling about the placement and naming of the properties.
| You have to be pragmatic about it, though, and realize there
| probably isn't a perfect solution and just implement it.
|
| I refuse to use JavaScript for the fallback, so the fallback is
| a lot of ugly CSS that doesn't order things in the right way,
| but it doesn't make a big deal of trouble for the project I'm
| working on. Most people will fallback to JavaScript right now,
| though, and when JavaScript is your solution to layout then
| you're already on a loser.
| doctorpangloss wrote:
| Is there a JavaScript polyfill today that can read the CSS
| properties in any of the proposed / implemented specifications
| that Just Works in Chrome?
| aidog wrote:
| look at the examples they made why it should be in CSS grid. I
| totally agree it should be in that. It's a form of grid. It
| should be part of CSS grid.
|
| This is one of the layouts that were just impossible in CSS and
| we really need it soon. I also needed the feature they talk
| about with the background colors for css grid tracks in 2012. I
| solved that with DIVs, but it was hard to make it responsive.
| reactordev wrote:
| CSS Grid is a mistake. Baking in a design philosophy when we
| had really creative pages without it.
|
| I like grids for pages with content and documentation and such.
| I don't like grids for pages of media or other creative
| content. Cards, flex box, grids, these are all design framework
| choices and shouldn't be in CSS spec. We were totally fine with
| position relative and media-query centric widths and heights. I
| get that it's easier to standardize if grids are part of the
| standard but I miss the days of pages having some creativity in
| their design. Every site looks the same nowadays.
|
| And before I get downvoted. I have a degree in graphic design.
| I love CSS and I love the web. Bring back the fun.
| rhdunn wrote:
| CSS grid makes it possible to implement wrapped content that
| is uniformally aligned with the last row keeping the same
| number of columns as the others, and have that scale
| correctly to different page widths. This is useful in things
| like book layouts. You can get close with flex, but the last
| row doesn't fully work.
| reactordev wrote:
| Does it require a ::last-child hack to get working? I'm a
| fan of grids when it comes to heavy writing content like I
| mentioned but I still don't think it should all be packed
| in the spec.
| fatbuoy1 wrote:
| Sure what was wrong with table layouts and spacer gifs anyway
| amirite?
|
| I'm a designer who codes, and CSS Grid has completely
| transformed (and simplified) my approach to responsive web
| design, and enabled much more complex layouts as a result.
| Just because a layout was possible before doesn't mean it was
| easy.
|
| By all means do things the old way if you want, but to
| suggest that it would be better if it didn't exist is insane.
| reactordev wrote:
| Not that it wouldn't exist. It just wouldn't be part of the
| spec. You are free to declare your own grid.
|
| I'm also not advocating to bring back tables and invisible
| spacer gifs. We have margins and padding for that. Even
| borders...
| krsdcbl wrote:
| It was "fun" when tinkering with some really creative special
| concern, it was an insufferable pain when your job was
| finding ways to layout all the "fun" designers envisioned who
| weren't highly familiar with CSS.
|
| Before position and float madness and all, we used to abuse
| tables -- because layouts for complex information do work
| best in grid systems. Now CSS finally has a module that
| serves this purpose, and brings a huge amount of flexibility
| to make formerly painful stuff easy.
|
| I'm not even talking about "page layouts" as a whole, just
| simple particle patterns like "a big icon with a title +
| description to it's right" is so so much cleaner and easier
| to do in markup AND css with grid.
|
| Embrace the tools, and if you dislike them - you may as well
| just not use them. But thinks like grid make simple, stupid,
| deadlined webdesign _work_ so so much less of a grind.
|
| (speaking as a General Graphic Designer who's also been deep,
| deep in CSS since before 2.1)
| bfgeek wrote:
| Part of the tension with building masonry on top of grid is
| that they work in fundamentally different ways.
|
| Grid you place everything in the grid first (e.g. an item goes
| in col:2,row:3), then size the grid. Masonry ideally you want
| to size the tracks first, then place items in those tracks.
|
| The first Firefox implementation (and the spec at that stage)
| basically said you don't consider any masonry items for sizing
| tracks (except for the first row, and some other rules - its
| complex). This meant that it is trivial to create items that
| overflow their tracks.
|
| The specification at the moment asks to place every item in
| every possible track. This has quadratic performance O(N_tracks
| * N_items) in the worst (and somewhat common case). Quadratic
| performance is bad[1] and we don't really have this in other
| layout algorithms.
|
| With nesting introduced the performance goes (sub-)exponential,
| which is really poor, even if you have a fast CPU.
|
| One may argue that these cases aren't common, but folks always
| test the boundaries with layout modes in CSS - so things need
| to be fast by default.
|
| Note: In grid items size themselves differently depending on
| what tracks you place them in, which is why you need to place
| in every possible position.
|
| Masonry potentially needs a different algorithm for sizing
| tracks to mitigate these problems, (the blog post doesn't go
| into these issues in sufficient detail). There may have been a
| version of grid sizing which didn't have item positional
| dependence but that ship has sailed.
|
| [1] https://randomascii.wordpress.com/2019/12/08/on2-again-
| now-i...
| fantasai wrote:
| Quadratic performance is a bit of an exaggeration. It's not
| O(N_items^2). It's N_tracks x N_items, and basically nobody
| has N_tracks [?] N_items. Practically speaking, the upper
| limit is closer to (N_items^1.5) because N_tracks is unlikely
| to go over sqrt(N_items) in cases where N is large. And
| almost all of those layouts will have repetitive track sizing
| patterns, so they can be optimized to a much smaller N_tracks
| that approaches O(N_items).
| JoshTriplett wrote:
| Why does this require checking every item in every column? It
| looks like the layout algorithm greedily picks the column
| with the least total height so far, every time it adds an
| item.
| bfgeek wrote:
| The requires it for sizing the columns (the step before
| placing the items into the columns).
| JoshTriplett wrote:
| The examples in the article seem to have CSS that
| directly sizes the columns, albeit with some flexibility
| such as being able to change the number of columns to
| better fit the width. It seems like the item widths
| depend on the column widths, rather than the other way
| around (which seems like it'd be circular). What's an
| example where the column widths depend on the items?
| bfgeek wrote:
| If you have something like: columns: 1fr
| auto max-content <!-- items -->
| <div>1</div> <div>somethingsuperlong</div>
| <div style="span: 2;">something else</div>
|
| You first need to decide how big each of the three
| columns are going to be, then you want to place the items
| in each of the columns.
|
| Depending on the non-fixed column type (there are
| different rules for each type) you want to ensure their
| constraints are satified (typeically they are big enough
| to encompass the items).
| matsemann wrote:
| I think one additional point to consider when adding it as a
| new display mode vs re-using grid, is that currently these
| demo's fallback quite nicely now when it's re-using grid.
| Instead of showing it as masonry (since my browser doesn't
| support it), it at least behaves as a grid. If it's a new
| display: X property, it will fallback to div behavior with the
| content all over the place in unsupported browsers.
| laszlokorte wrote:
| you could simply do: "display: grid; display: masonry;" and
| all not-supporting browsers would skip the second
| declaration.
| yurishimo wrote:
| This is assuming there isn't any cross pollution of shared
| properties either.
| jjcm wrote:
| > I think this will make an important precedent
|
| It's worth noting this is not the first time things like this
| have gone to the community for feedback. They did the same for
| nested CSS selectors, which ended up working quite well
| feedback-wise: https://webkit.org/blog/13607/help-choose-from-
| options-for-c...
| Izkata wrote:
| > new proprieties
|
| I'm guessing this was going to be "properties"? It kinda looks
| like "proprietary" instead, so let's double down on that - I
| propose "display: tetris;"
| falcor84 wrote:
| I would suggest that `display: tetris;` is implemented such
| that each row SHOULD have whitespace, and if at any point a
| row becomes fully occupied, a conforming rendering agent MUST
| remove the entire row.
| flakiness wrote:
| If there is a debate, who is pushing back? Or is it more about
| details while every vendor is supportive at high-level?
| madeofpalk wrote:
| It seems like the precursor to this was the whole "Help choose
| the syntax for CSS Nesting" thing that happened a while back.
| Browser vendors couldn't figure out the syntax, so they asked
| the 'wider public' which they preferred
| https://webkit.org/blog/13607/help-choose-from-options-for-c...
| tomp wrote:
| This is readily achievable today with `columns`:
| https://primozic.org/aesthetics-art
| sn0wleppard wrote:
| That example doesn't achieve the second objective of the
| proposal, "It distributes content across the page (instead of
| flowing down each column, one by one)."
| emadda wrote:
| Related: I created an interactive demo of grid principles here:
|
| https://cssprinciples.com/3/grid/
| victor106 wrote:
| this is very educational and useful
| emadda wrote:
| Thanks Victor, it means a lot :)
| 6510 wrote:
| My proposal would be to put the image dimensions in the name of
| the image file. example-400x200.jpg
|
| Without that I cant think of an "easy" to implement formula to
| keep each column the same length.
|
| If given a group of numbers, how would one divide them into 8
| groups the same size?
|
| Extra fun: You may increase each number by n in order to make
| each group exactly the same size. n must be as small as possible.
| paulhilbert wrote:
| "Others are questioning whether or not this kind of layout is
| needed on the web at all -- they aren't sure that well-known
| websites will use it."
|
| Would it instead be possible to exclude anyone with that attitude
| from a discussion about an open standard? I know this sounds
| toxic, but I would argue that approaching public design this way
| is ultimately more toxic wrt the outcome and those affected by
| it.
|
| Or maybe I misunderstood that part since everyone seems to not be
| bothered by it at all here...
| rolha-capoeira wrote:
| And honestly, that's a ridiculous claim. Two very popular
| websites I can think of right away are Pinterest and VSCO.
| (Perhaps VSCO on the web isn't as popular as the mobile app,
| but the company continues to use masonry as the design
| evolves.)
| grub5000 wrote:
| Lots of sites that return a ton of images, like an of the
| image search sites (Google, Bing, DuckDuckGO, loads of porn
| sites etc.)
| gwbas1c wrote:
| > Would it instead be possible to exclude anyone with that
| attitude from a discussion about an open standard?
|
| That attitude is rather critical and important to the
| discussion.
|
| I don't think it's the browser, or the standards bodies,
| responsibility to have built-in support for every possible
| feature we can imagine. Instead, the standards need to be
| simple and extensible so that that libraries (Javascript or
| WASM) can do creative layouts. (IE, instead of waiting for
| Masonry layout in CSS, you should be able to grab a Masonry
| layout library and include it with your web site.)
|
| Otherwise, we're building a system where the standards (CSS in
| this case) are so complicated that it's getting harder and
| harder to implement the standards; and are too inflexible to
| support what tomorrows' developers can imagine.
| bezbac wrote:
| I can totally understand the quoted comment. I mean, we are
| talking about CSS as a language here. Anything that is
| formalized is expected to be implemented and supported by
| browser engines and vendors. Browser engines are already
| extremely complex, so it's fair to think closely about
| formalizing new things when it's not apparent that there is a
| big enough need.
|
| I'm not claiming this is the case with the Mansory layout; I
| just understand that adding unnecessary complexity for a small
| target user base is a valid concern.
| paulhilbert wrote:
| I totally get that. But for me there is a fundamental
| difference between "big enough need" and "well known websites
| need this".
|
| How are potentially thousands of niche websites less of an
| argument than "instagram and co don't need it"?
| The_Colonel wrote:
| Well-known == highly visited == native implementation will
| have large accumulated impact on end users (their
| performance, energy consumption, improved usability ...).
| peebeebee wrote:
| Why? When developing standards it's very good to have good
| gatekeepers. Not everything should be built _inside_ the
| browser if you can achieve the same with existing technologies
| like JS.
|
| Otherwise your browser(standards) might become too complex.
| paulhilbert wrote:
| That is an orthogonal discussion.
|
| I need masonry layouts a lot and tend to be on the "we don't
| need another display class" side in this debate. But that's
| unrelated to my "rant".
| layer8 wrote:
| For what it's worth, I found masonry layout always
| detrimental to my use of a site. I would prefer CSS not to
| encourage it by providing built-in support.
| cornstalks wrote:
| Questioning whether something new is actually needed is
| absolutely worth doing, so long as it's done respectfully.
|
| This is a standard that affects billions of people and many
| implementations. It's great to ask if something is really
| needed or if it's just adding bloat.
|
| We shouldn't just grow the standard without first asking if the
| growth and added complexity carry their own weight. If someone
| proposing something can show that, then wonderful.
|
| But yeah, just straight up trying to block these people from
| being able to ask these questions totally is toxic. As long as
| they're asking and participating respectfully there's no need
| to be a jerk toward them.
| paulhilbert wrote:
| Again: when did "well-known websites use this" become the
| motivating factor behind standard design?
|
| The blink tag was used by well-known website and it's
| universally recognized as a bad decision.
| cornstalks wrote:
| It's fine if you disagree with the premise of the question.
| But it's also fine to ask the question, since presumably
| the asker wants to know the feature would get enough usage
| to justify its addition to the specification, and an easy
| way to show it gets usage is by showing some well-known
| sites would use it.
|
| But what is not fine is trying to exclude people from the
| conversation and silence them just because you have a
| disagreement.
| PurpleRamen wrote:
| Why? Any feature is a liability, so it's good to question
| whether a feature has to be implemented, and whether it should
| be in this way and position, or maybe somewhere else.
| paulhilbert wrote:
| Where is the connection to "well-known websites"?
| PurpleRamen wrote:
| I assume, with "well-known", they mean popular. Which means
| they (also) measure the worth of this feature by the number
| of users which might benefit from it. This is a very legit
| metric for this kind of situation.
| paulddraper wrote:
| Surely questioning the real world usefulness is not "toxic"?
|
| CSS is already very complicated. Adding more options needs
| proportionally strong justification.
| Turing_Machine wrote:
| No, but basing capabilities solely on what they _imagine_
| "well-known websites" might want _is_.
| paulddraper wrote:
| And how would you do it sans imagination?
| paulhilbert wrote:
| I mean the actual point of the article is to ask
| everyone, not just "well-known" examples.
|
| So it seems there were some reasonably forces in the
| discussion that align with my stance without the
| unnecessarily antagonistic (and rhetoric) primer I
| should've probably left out.
|
| Seems like a good approach to widen the discussion and
| improve the design.
| krsdcbl wrote:
| I heavily agree!
|
| This take is imho dangerously conflates personal taste and
| motivation with "should a heavily generalized and clearly
| purposed layout system be complicated with some magic keyuword
| options to serve your specific intents?", and misappropriates
| the assumption that people like and use this form layout as a
| reason to approve the latter.
| t_mann wrote:
| I really like the general look and feel of masonry/waterfall
| layout, maybe it's because I grew up reading physical newspapers
| (and still do), but to me a columnar layout is just an intuitive
| way to divide up a page.
|
| I just wish there was an alternative to the default masonry
| ordering, which afaik is a simple rule that goes sth like 'place
| the next item in whichever column it can go up highest'. This
| means that the left-to-right order is really juggled from the
| second row onwards. What I imagine would be really nice is if
| there was a layout that preserves more of the left-to-right (or
| right-to-left, if that's your preferred direction) reading flow.
| Something like 'put the next item one column to the right of the
| previous item (or in the leftmost, if you were at the rightmost),
| unless you can put a second item in the same column without the
| new bottom going too far below the bottom border of the column to
| its left'. This would be more flexible than strictly going left-
| to-right (which would also mess up alignment) and would reatin
| _some_ meaning of the left-to-right reading direction.
|
| I know it won't be possible to accommodate every possible formula
| one could prefer for masonry, but if you have content where the
| ordering matters at least a bit (maybe not for Pinterest, but for
| a journal eg it would), then I really think sth like this would
| be a more sensible default than the classic masonry rule.
| tetris11 wrote:
| something like: { /* Move element
| a maximum of 2 columns left or right on update */
| grid-template-max-horizontal-shift: 2 col; }
| mvkel wrote:
| You could run into issues where you don't have enough content
| to plug the holes this way though, right?
|
| For example if there's a gap that needs filling that Is 3
| spaces away
| amadeuspagel wrote:
| I'd only use a masonry layout for something where there's no
| "clear" order anyway. I wouldn't use it for chronologically
| sorted images.
| fmy105 wrote:
| The CSS Grid Level 3 proposal for masonry layouts looks very
| promising. The ability to specify a desired row height and have
| content flow into columns of equal width would make implementing
| common design patterns much easier. I especially like how this
| approach maintains the grid structure and allows for features
| like gap to work as expected.
|
| One potential concern with the masonry layout is how it will
| handle responsiveness and different screen sizes. Will there be a
| way to specify breakpoints or change the row height and column
| count at different viewport widths? Ensuring masonry layouts are
| flexible and adaptive will be key for real-world usage.
|
| The masonry-auto-flow: next property seems like it could lead to
| some interesting creative uses beyond the standard masonry look.
| Being able to control the placement of items and have them span
| multiple rows opens up a lot of layout possibilities. Would be
| great to see more examples exploring this.
|
| It's good to see the CSS working group thinking ahead to Level 3
| and 4 of Grid and gathering feedback from developers. Masonry has
| been a major pain point and commonly requested feature for years,
| so addressing it thoughtfully in the spec makes sense. Hopefully
| this is the first of many enhancements to come in future Grid
| iterations.
|
| The comparisons to a potential alternative masonry implementation
| using display: masonry were helpful for understanding the trade-
| offs. While a separate masonry layout mode could offer some
| benefits, the simplicity and consistency of extending Grid is
| compelling. It will be interesting to follow the discussion and
| see which path is ultimately chosen.
| presentation wrote:
| Why would breakpoints be an issue? They'd just work the same as
| any other CSS feature wrapped in a media query.
| Unai wrote:
| I really don't like how disingenuous, propagandistic and
| patronising Simmons is being in this article. Ending each section
| saying "all this will be impossible if not done the way I like",
| which is absolutely not true. There's not one reason why anything
| that can be done in "display: grid" couldn't be done with
| "display: masonry".
|
| But I think, and I hope, that people aren't the fools she's
| taking us for, and can see how absurd her proposition is.
|
| You could basically clone the grid specification, if you want all
| those features, and that way both can be developed with what
| works for each. She says doing that means new grid features might
| take more time to come to masonry. Really? More time than having
| to deal with new grid features that won't work at all with your
| version of masonry integrated in grid? You're still having to
| deal with two layout systems, even if you want to disguise one of
| them. Except doing it your way you can't select which system gets
| the features that work with it.
|
| At the end, instead of two layout systems with two complete sets
| of features, we'll have one single layout system with a bunch of
| features that sometimes work and sometimes doesn't, depending on
| a particular value of a particular declaration that you'll have
| to know about. And that's why people hate CSS.
|
| Seems lazy and an absolute mess to maintain. And it doesn't make
| sense at an intuitive level, since masonry works similarly to
| flexbox, not grid; and it doesn't make sense at a logical level
| either, since a masonry layout is _not_ a grid.
|
| But I guess this is what we'll end up getting, since apparently
| anything Jen says goes. Like the ridiculous idea of doing "CSS4",
| which means nothing, does nothing and is nothing, but we're going
| with it for some reason anyway.
| SigmundurM wrote:
| I wonder, what theoretical features could we have for a modular
| grid that'd be fundamentally incompatible with a columnar grid,
| and vice versa?
|
| If adding columnar grids to CSS Grids doesn't make any features
| impossible, then I don't see why we shouldn't just have one CSS
| Grid standard, and thus always ensure feature parity between
| modular and columnar grids.
|
| The argument being portrayed by Simmons, as I understand it, is
| that every feature that currently works for CSS Grid's modular
| grids, would also work for a columnar grid.
| troupo wrote:
| > I really don't like how disingenuous, propagandistic and
| patronising Simmons is being in this article. Ending each
| section saying "all this will be impossible if not done the way
| I like"
|
| This is a very uncharitable way of reading this, and that's a
| polite way of describing this view.
|
| She shows what _is_ possible, and how existing grid mechanisms
| can be leveraged for masonry layout. It 's implicit that coming
| up with a proposal outside the grid would need to accommodate
| the same capabilities somehow.
|
| How is it patronising or disingenuous? They (and Firefox)
| literally implemented this and are showing what is possible.
| And are asking you for input. If you think you're incorrect,
| you can join and show them the error of their ways:
|
| --- start quote ---
|
| Our hope is that web designers and developers chime in (post to
| social media, write blog posts) with your thoughts about which
| direction CSS should take.
|
| Some people, including those of us at Apple, like having
| "Masonry" be part of CSS Grid. We believe this functionality is
| a mechanism to expand CSS Grid -- allowing it to finally create
| columnar grids as well as modular grids. And we want this
| functionality to be mixed with all the other features of Grid,
| including the powerful options for defining a columns, track
| spanning, explicit placement, and subgrid.
|
| Other people instead believe Masonry should be its own separate
| display type. At first glance, defining Masonry with a new
| display type might make a lot of sense. You do get a tidy
| separation between layout types.
|
| --- end quote ---
| egypturnash wrote:
| I feel like I spent this whole proposal waiting for "grid-
| template-columns:masonry" to be discussed.
| nofunsir wrote:
| No thank you. I just want all the whitespace to take a hike. I
| certainly don't need this layout if webdevs are just going to put
| all the content on the center 1/3 to 1/4 of my screen.
| hwbunny wrote:
| Webkit team snorting cocaine?
|
| look at this, how intuitive, how readable:
|
| grid-template-columns: 14ch repeat(auto-fill, minmax(28ch, 1fr))
| 14ch;
|
| just throw the whole grid thing out of the window and get on
| board someone who can create syntax that wouldn't send you to
| jump off a cliff and feels like it was made by a fellow human
| being, not an AI controlled robot.
| hombre_fatal wrote:
| Well, at least show us your ideal replacement for that logic
| that's more intuitive.
|
| Until then, these complaints usually cash out into
| unfamiliarity + assuming it's very hard to understand if you
| were you trying to understand it.
|
| Declarative UI is a very hard problem, so it's not always going
| to be `text-decoration: underline`.
| risenshinetech wrote:
| Many things are hard problems, but you don't need to be an
| expert to recognize an obviously bad solution.
|
| If you had showed someone the first bicycle, and it came with
| 3 differently sized wheels and a spike for a seat, you
| wouldn't have to provide an "ideal replacement" to know that
| it was a bad design.
| JamesSwift wrote:
| Which part of this is the spike for a seat?
|
| > grid-template-columns: 14ch repeat(auto-fill,
| minmax(28ch, 1fr)) 14ch;
| Onavo wrote:
| Can you add drag and drop to this? Currently you need libraries
| like https://gridstackjs.com/, especially for nested cases.
| turboat wrote:
| Suppose we could create a backwards-incompatible system to
| replace CSS. How would we do it?
|
| Are there any books or papers on how to create a coherent layout
| system?
|
| What about alternatives like Qt, Tk, SwiftUI, etc.? I've never
| used anything besides CSS. Are any of the actually-implemented
| systems in the wild better? If so, what makes them better?
|
| I want a system that provides a better interface for developers,
| but how? If we could start over, what are the design principles?
| eyelidlessness wrote:
| One thing to be cautious about when selecting prior art for
| reference is that CSS sets a high bar for declarative control.
| I can't speak to any you mention in detail, but my sense is
| that more comparable prior art would likely be found in print
| use cases.
| pphysch wrote:
| CSS is overall pretty great and I've seen at least a couple
| non-web GUIs rip out their bespoke GUI systems and replace them
| with CSS or something very much like it.
|
| I think the big change will be better support for hierarchical
| definitions, including but not limited to nesting. TFA
| discussion would be pretty moot if there were namespaced
| properties that could somehow fit under display: masonry;
| rather than polluting the global namespace.
| turboat wrote:
| I have to assume that's partly because of the availability of
| implementations, tooling, and developer familiarity. Many
| platforms will let you toss in a web view, and if you want to
| set up e.g. a configuration screen with text and toggles,
| HTML/CSS will get the job done, more easily than maintaining
| a custom system that's peripheral to the core purpose of your
| app.
|
| I don't want to be overly negative, but I just can't view CSS
| as "pretty great."
|
| I appreciate the inherent difficulty of using 1-dimensional
| static text to specify a 2-dimensional dynamic layout. Still,
| basically every programming problem involves defining
| abstractions over some domain concept and expressing that in
| the syntax of your programming language. Somehow that's
| harder in CSS than any other language I've used.
|
| Within web dev I find both HTML and JS much easier to work
| with, despite their imperfections.
| mch82 wrote:
| Constraint-based layout using the Cassowary algorithm seemed
| like a popular alternative for a while (see
| https://github.com/slightlyoff/cassowary.js/?tab=readme-
| ov-f...). It's designed to solve for variance in screen size
| and shape. Apple switched to Swift UI and may have moved on
| from this approach.
| legulere wrote:
| I think one classic book about it is "Rastersysteme fur die
| visuelle Gestaltung - Grid systems in Graphic Design". Never
| read it though.
| turboat wrote:
| Thanks for the reference.
|
| As I've been thinking about this, I do wonder if starting
| with grids as the foundation would have been a better
| approach. As I understand it, early CSS focused on stuff like
| color and font style, with primitive layout tools. Over time
| better tools have been bolted on, but it's messy.
|
| Say we merged flexbox and grid into a unified system, and
| threw away the other layout algorithms. At the same time,
| made some tweaks to clarify margin, border, padding, and
| overflow. Maybe that's a good foundation.
| cdrini wrote:
| Ah available for borrow at Internet Archive: https://openlibr
| ary.org/works/OL3106695W/Grid_systems_in_gra...
| cdrini wrote:
| This would be such an interesting write up comparing many
| styling/layout systems! Unfortunately I reckon not many people
| have experience with multiple styling languages, so not many
| people can create such a write-up.
|
| I think flutter and XAML might be other interesting ones to
| look at
| madeofpalk wrote:
| XAML poorly reimplements half of CSS layout, and then gives
| up and tells you to write your own manually positioned layout
| with terrible performance.
|
| Things which are 3 lines in CSS are hundreds of lines of a
| combination XAML/.NET only to get janky window resizing
| behaviour.
| SassyBird wrote:
| Reposting as a top comment for more visibility:
|
| I have a website with my photos, which doesn't use any JS for
| layout. When I was making it, I considered using JS masonry
| libraries, but I wasn't satisfied with the results. Proper
| masonry layouts which fill all available space in practice
| actually crop some images. Leaving space around photos is
| required when you don't want cropping and want to preserve aspect
| ratio. The only way not to do that is to have infinite scroll,
| which I guess is what corporate addiction machines want, but
| that's not what I want on my own website. Here is what I did:
|
| https://yakubin.com/photography/albumless/
|
| https://yakubin.com/photography/album/kenya-2023/
|
| I used display:inline-block to achieve this result, effectively
| treating photos as text that needs to reflow into new lines. I'm
| very satisfied with the result and prefer it over what the
| masonry libraries do.
| datagram wrote:
| Flexbox was designed for these kinds of layouts, so that would
| also be an option here.
| qingcharles wrote:
| I don't use JS for masonry layout. I have a fallback from the
| current masonry CSS solution to a supported CSS solution.
|
| The problem is ordering. The current CSS-only solutions work
| fine as long as the order is not important. (though you will
| still end up with weirdness at the bottoms of the columns IIRC)
| FireInsight wrote:
| You could probably have done this layout in a couple lines of
| CSS with a row-oriented flexbox that wraps and is center-
| aligned. That would be the more standard way to do it too.
| specialist wrote:
| Neat. I like it.
|
| Out of curiousity, why don't browsers have pluggable layout
| managers? Like Java's AWT/Swing LayoutManager. [1]
|
| Fussing with CSS and Java's stock layout managers (gridbag,
| table) always fills me with frustration and anxiety. In my
| experience, for the fussy work, it's easier to explicitly code
| what I want.
|
| Ages ago, inspired by Designing Visual Interfaces [2], I made a
| layout manager [3] for canonical design grids [4].
|
| It was pretty neat. Fluent API. Always visually correct. All the
| baselines aligned _just so_. Predictable results. Perfect for
| banging out CRUD forms. [5]
|
| 1/
| https://docs.oracle.com/en/java/javase/21/docs/api/java.desk...
|
| 2/ https://www.amazon.com/Designing-Visual-Interfaces-
| Communica...
|
| 3/
| https://web.archive.org/web/20110302212909/http://java.net/p...
|
| 4/
| https://web.archive.org/web/20110308034949/http://designgrid...
|
| 5/
| https://web.archive.org/web/20110515182322/http://wiki.java....
| aidog wrote:
| I absolutely want this. I have wanted this for years. This is a
| form of grid so it should be in CSS grid. Especially since it has
| tracks. Browser makers, please just ship this.
| account42 wrote:
| I absolutely hate this kind of layout, especially when combined
| with infinite scrolling. Makes it impossible to systematically go
| over all items.
| amadeuspagel wrote:
| It's not meant for things that you want to systematically go
| over, it's meant for things that you want to explore.
| layer8 wrote:
| Some people want to go systematically over the items when
| exploring. I certainly tend to operate that way, and it's
| infuriating when the UI is making it difficult for no good
| reason.
| yau8edq12i wrote:
| I guess in that case you can just browse other websites. No
| website can pander to everyone.
| thebeardisred wrote:
| If this leads to more "forever" scrolling pages where I can never
| get to the footer I'll lose my goddamn mind.
| spintin wrote:
| You can very simply do this with javascript.
|
| Browser developers are now reaching for straws to remain
| employable.
|
| That said the biggest tasks remains:
|
| - Go back to HTTP/1.1 with "One time password" auth.:
| https://datatracker.ietf.org/doc/html/rfc2289
|
| - Simplify the browser so that it can be compiled in less than
| many hours on the latest CPU.
|
| - Completely remove the tie-ins to any commercial/governmental
| entities.
|
| Basically go back to Netscape with some improvements to
| javascript performance and hardware accelerated rendering of
| HTML.
|
| Everything else invented in the last 20 years is meaningless.
| This is valid in most domains: Raspberry Pi is the only real
| exception.
| paradox460 wrote:
| It feels good to see the webkit team actually doing good,
| publicly visible work again
|
| When I was cutting my teeth in web design, the early webkit blog
| and safari releases were always inspirational. The rate at which
| they pushed out new features in the mid 00s was astonishing
| qingcharles wrote:
| They've definitely brought in some new people. AFAICT the
| reason Safari even has Masonry support is because they brought
| in the (very talented) guy that wrote the CSS spec for it.
| cnotv wrote:
| I evaluate the CSS updates based on the gap in masonry layout
| achievement. It's one of the most important layouts that have
| existed for more than a decade and should have been the only
| achievement after flexbox and grid. If you have a bunch of media,
| unless you have a narrow container like FB/IG, that's the only
| way to go. The alternative is fixed ratios. Anyone who has been
| working in FE knows it.
| roblh wrote:
| I found a really cool way to do this with svelte and css grid a
| few months ago, based on a blog post I can't seem to find now. A
| full masonry layout too, not just columns, but each element can
| have dynamic height and width. The thing that made it click for
| me was that you don't have to make the grid rows and grid columns
| 1:1 with the full width/height of each element. Making 10px or
| 20px rows and columns and then using a svelte component for each
| image that chose a number of columns and rows based on the image
| aspect ratio. I'll see if I can make the repo public today.
|
| Edit: reading further, I think my approach was basically the same
| as theirs near the end of the post!
| fzeindl wrote:
| I never understood why CSS would not just adopt Apple's
| Autolayout and be done with it: I want to specify that this space
| should be equal to that space, these borders to grow, and those
| borders to shrink and this point always aligned to that point.
|
| It is simple, intuitive, it works for all cases. Instead we are
| inventing, what, the fifth generation of CSS-layouting now? Does
| nobody think this is odd?
| layer8 wrote:
| It's difficult to unambiguously _and usefully_ specify what
| should happen when not all constraint can be fulfilled. And you
| can likely also DOS browsers by exponentially exploding
| constraint calculations. CSS is bad as a layout system, but I
| also don't like constrained-based layout systems unless they
| enforce that the constraints can always be fulfilled and be
| calculated in reasonable time. Which implies that you wouldn't
| be able to change the layout willy-nilly client-side with
| JavaScript.
| fzeindl wrote:
| Checking that the layout isn't exponentially complex and
| DOSing the browser could be a simple task for the web
| developer. If you want your website to perform bad you can
| always find a way.
| branmcconnell wrote:
| I'll admit that I was skeptical at first about including masonry
| in the CSS Grid spec.
|
| After reading through the article, I'm convinced it is the right
| path forward, allowing masonry layouts to utilize the same APIs
| and properties (columns/rows, gap, etc.) as CSS Grid.
|
| This would lower the bar of entry by using familiar APIs and
| allow simpler switching between masonry and other column/row
| setups responsively.
|
| ```css .example { display: grid; grid-template-columns:
| repeat(auto-fit, minmax(250px, 1fr)); grid-template-rows: auto;
| @media (width > 500px) { grid-template-rows: masonry; } } ```
| jmull wrote:
| Feels like a special-purpose layout that more properly belongs in
| a framework than CSS.
| danjl wrote:
| The vertical layout is simple to implement. Horizontal is much
| harder, and more useful for media like images and videos, see
| Flickr. None need CSS. And, if you are going to do it in CSS, you
| better handle both, not just the easy less useful variant.
| bschmidt1 wrote:
| I do it on my portfolio site (https://www.bennyschmidt.com) in
| JavaScript by maintaining a `colCount` with each column just
| being `flex-direction: column`.
|
| But after seeing this I should switch to using CSS. Didn't put
| too much thought into it, but when I realized it wasn't
| immediately simple in CSS grid just did it in JS.
| pricecomstock wrote:
| I have it on my website (https://packagepicker.co) in only CSS
| by using `flex-direction: column` and setting a best-guess max
| height with several breakpoints. Unfortunately it does break
| down in some situations because some pages have many fewer
| selections.
|
| My order doesn't super matter but I do like to maintain it. I
| tried for a long time using CSS columns but I didn't have good
| luck with that either, though I can't remember exactly why
| luc_ wrote:
| Looks convenient, but another step towards a monoculture
| internet. :(
| thih9 wrote:
| How can there be an "inventing masonry" section without a
| reference to the masonry js library[1] - I suppose this is where
| the name comes from?
|
| [1]: https://masonry.desandro.com/
| hgyjnbdet wrote:
| Caveat: I know nothing about this, but have some experience with
| grid and flexbox.
|
| To my mind flexbox could be a basis for masonry way better than
| grid with less overhead.
|
| I also think mosaic would be a better name.
| nsonha wrote:
| CSS is such a failure. Grid is the 3rd or 4th iteration of layout
| methods and still you need to think this much about how to code a
| layout? This is the most basic thing in UI and we've been doing
| it for 3 decades.
___________________________________________________________________
(page generated 2024-04-23 23:00 UTC)