CSS Container Queries in Web Components

I remember the dumpster-fire days too.

The thing that I can't understand is, why did it take SO LONG to get useable, proper, and intuitive CSS-based layout on web-pages?

I mean, we've had all kinds of rock-solid mechanisms for layout in desktop applications since the dawn of GUI's in the NINETEEN EIGHTIES. Meanwhile, in CSS, people had resort to HTML tables up until sometime in the early naughts, when AWFUL, counterintuitive float-based hacks were part of the "Web 2.0" buzz.

For Christ's sake, just getting fixed side-bars and a width-adaptive central area was called "The Holy Grail" by CSS experts. Isn't that the one of the most fundamental layouts GUI's-- AKA "The Docpanel"? It wasn't possible to get really nice layout without crazy hacks until flexbox in 2010-ish?

Finally, a few years after flexbox, CSS grid comes out, and oopsie, we weren't supposed to use flexbox for overall layout anyway. Now it's CSS-grid for 2D (page layout), Flexbox for 1D (component layout), and floats for what they were originally intended for (putting pictures into a block of text and have the text flow around the pictures).

To be fair, I actually like CSS now. It seems like it's really reached a point where you don't have to cling tightly to somebody's zany overcomplicated framework and can pretty much execute your will without frenetic trial and error.

So NOW it's a success, but it's distressing that I feel CSS deserves nothing more than a sarcastic SLOW CLAP?

Why would you want React interop for the styling? What would that even mean? Struggling to understand the use case here.

I had been trying to get into Tailwind CSS in recent projects but noticed some of the Bootstrap functionality I tend to like was missing out of the box so with Bootstrap 5 coming out last week I switched gears to start using that for a new project.

The project itself is an update to an older one that was originally built with Bootstrap 2.

For the old one, when I go to print the somewhat detailed tables I'm using show up fine, but in the new Bootstrap 5 version, one of the tables sticks outside of it's container when going to print and for the life of me I've been struggling to figure out a solution that works consistently for the print side of things (which I feel tends to be overlooked quite a bit in regards to CSS). What's even odder, is that when I implement a change that helps with the second table (making it appear contained within the page dimensions) the first table above starts exhibiting the issue of it being outside of the container. Also, in this case, if I were to leave the default styling of the "table-responsive" div containing the table, you wouldn't be able to see the rest of the columns at all when printing (since the scrollbar would show up) so everything I'm describing above is with an override to have "overflow-x: visible" when printing. Some other suggestions online included adding some overrides that use "page-break-inside: avoid;" for tables/tr/td/div elements and "display:block !important;" for the body and div elements but I'm not completely happy with those results, but yup that's been a bit frustrating trying to sort out since I'm not even sure why it's behaving the way it is at the moment.

I haven't kept up fully with all of the Sass/SCSS advancements in recent years but have a semi-decent CSS foundation to build off of (from my understanding those advancements primarily help with some additional programmatic elements that then get pre-processed back into CSS? Along with some syntactic sugar to simplify some of the repetitiveness that CSS can require).

The other big annoyance I was dealing with was related to what appears to be a long-standing WebKit issue related to scrollbars on mobile devices? (for the theme I'm using, I'd scroll down on an iOS device and wouldn't be able to see the very last item in the mobile menu). I found a reference somewhere (probably Stack Overflow of course) that mentioned using "@supports (-webkit-touch-callout: none)" to try and target the mobile browsers specifically and I reduced the height by an extra 65px or so which seemed to be enough to help with that particular issue (the theme utilizes "perfect scrollbar" it seems, but not entirely sure about all of the styles involved). (Before settling on this solution I had already tried out the solution described over here: https://allthingssmitty.com/2020/05/11/css-fix-for-100vh-in-...).

One last item I was dealing with this week seems to have to do with SVG rendering on the desktop vs. on mobile (for a logo). We sort of have a designer on staff but he deals more with print than with web stuff so I asked for a variation of our logo with the name of the application integrated into it and provided back to me as an SVG (since the PNG I had created myself looked slightly fuzzy when it was downscaled to fit the space I was using it in on the page, so I felt an SVG version would look crisper). After swapping things to the SVG version provided to me, it looks pretty good on mobile, but on the desktop (both in Chrome and Firefox), things just don't look as good. Some resources online mention it could be related to the lower DPI of a desktop monitor vs. the retina type DPI of a mobile device, but I don't know...I also saw some mention of a "pixel hinting" approach that might be able to be utilized by the designer in Adobe Illustrator perhaps that might help as well so that's something I've asked him to give a try for me so we can see the results, but I was kind of disappointed about the way the SVG looked as well (and now that'll require a bit of extra time to research/learn/experiment about, rather than focusing more on the application I'm trying to actually build...but at the same time it's semi worth it at the moment since I'm hoping the foundation I'm building with this new web app will be utilized in a couple of other updates that I'd like to make over the coming year, but we'll see how it goes ;-).

I'll postscript this message that I'm not a frontend dev, but since I'm basically a team of one with an eye for certain details/issues, I try and get these sorts of problems sorted out at the beginning of a project so they don't cause issues, but also as a team of one, I really wish that in addition to the backend frameworks that are available (Laravel in my case is the one I'm currently ramping up on, as it's the more or less leader on the PHP side), it would be nice to have a nice frontend option with "batteries included" for a developer to really utilize and not have to worry too much about (Bootstrap has probably been the closest in that regard...I do like a lot of what Tailwind CSS is doing though, and of course it's heavily promoted in the Laravel community, but I just found that it would require too much work for me and too much time...and my workplace isn't exactly software development focused so I have to pick my battles in that regard vs. spending a lot of time getting something basic going vs. getting something shipped for users to start using).

Hopefully one day we'll be completely away from needing to do any sort of CSS hacks (and things have come an extremely long way in the past few years), but at the moment I wouldn't say things are completely hack free yet (at least for us non-100% frontend folks...you all might have some extra magic you can cook up on the fly to solve any problems encountered maybe using what's already available :-).

> The thing that I can't understand is, why did it take SO LONG to get useable, proper, and intuitive CSS-based layout on web-pages?

Many reasons:

- HTML and CSS are not designed for anything complex.

HTML and CSS at their core are only meant to display a static page of text and some images in a single rendering pass on a computer from 1990s.

- Many decisions in CSS (especially early CSS) are one-off solutions that might not even have correct specifications compared to how people usually use it

Float is really a one-off solution for a very specific subset of layout. The standard box model famously has a default that no one in real world uses, and that IE actually got right. There are more: https://pavpanchekha.com/blog/css-problems.html and https://www.impressivewebs.com/css-the-bad-parts/

- Any solution has to be aware of any previous solution and mistake

Let's say, you introduce flex. How will it work with floats? What about display:inline or display:inline-block? Tables? Inside tables?

Let's say you introduce grid. All the question above plus all the questions on how it will behave with flex.

Let's say you introduce...

- Standards are mostly driven by browser implementors, who are not known for any/much of web work. Additionally, solutions have to be "fully complete including edge cases that maybe one person in the world cares about".

Cant' find the link for that, sorry, you'd have to take me at my word :)

- All that still has to work reasonably fast for some definition of fast, including all the weird interactions between mistakes and other workarounds of past, present, and future

For example, Cassowary constraint solving algorithm for layouts was proposed in 1999, but was rejected because it was deemed too costly to process.

I found these an easier read https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Contain...

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Contain...