4 ms·

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 conte

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 2y ago
I would expect most browsers that aren't running JS do not properly handle state of the art CSS extensions.
- rezonant 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
        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 2y ago
  Or is your average email client? Many of these support modern HTML with scripting and remote content disabled.

sebzim4500 2y ago

I would expect most browsers that aren't running JS do not properly handle state of the art CSS extensions.

rezonant 2y ago
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 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
Or is your average email client? Many of these support modern HTML with scripting and remote content disabled.