181–190 of 277 posts
Earlier quoted context omitted.
Widespread flex gap support will probably eliminate 95% of grid usage in my apps today: https://caniuse.com/flexbox-gap And what a surprise, it's just Safari holding us back again. =_=
The new IE.
Earlier quoted context omitted.
For me I think CSS is hard to understand mostly because the underlying concepts are low level and designed to accommodate ALL POSSIBLE rendering scenarios, not just "I'm putting a website on this laptop or phone screen". CSS is able to target print and all manner of other different scenarios and needs. It's inherently complicated because it's very flexible and accounts for all kinds of use cases. The problem is you d…
CSS is able to target print Only an old textual part of it, e.g. grids cannot page-breaks. It is far from "flexible" and just "out there if you want". May I ask, do you even media print? Because every time I have to do unusual un-mainstream thing in css, I can bet that it will not work and make a net profit.
Earlier quoted context omitted.
Widespread flex gap support will probably eliminate 95% of grid usage in my apps today: https://caniuse.com/flexbox-gap And what a surprise, it's just Safari holding us back again. =_=
The new IE.
I hate that people use CSS Grid like this. For some reason, I see so many people reach for CSS Grid like it's the de facto solution for responsive design. This is a bad design because you're tying the child elements to the grid layout of the parent. If you added an extra column in the grid, you'd have to go and adjust it for the full bleed elements. IMO a better solution would've been to just use a column layout with…
You're not alone! I strongly prefer flexbox too. Besides the points you mention, excessive use of grids leads to "designing to the grid" instead of letting the content and context dictate flow. Tangent: I also remember doing ridiculous things with nested tables during the original browser wars (circa 2001?) and consider it a "first-world problem" to be choosing among standards-based styling mechanisms.
Earlier quoted context omitted.
The new IE.
Very disingenuous of you. IE was a trashfire because it refused to do anything in a standard way, meaning it had to be specially catered for. Safari is slow to follow the standards but at least its compliant. A engine that isn't Chrome is very essential for keeping the web open, especially since Firefox user share keeps going down.
Safari is not only slow to follow the standards, it is slow to advance the standards. I'd be more likely to believe the spin that Apple just wants to make sure things are done well on the web if it appeared that they were trying as hard to add good, new capabilities to the web platform as they are to add good, new capabilities to iOS.
A engine that isn't Chrome is very essential for keeping the web open
Also essential is for the open web to be competitive with closed alternatives, or the fact that it's open will matter less and less. Apple is quite willing to provide competition for Chrome. It does it with iOS.
I really hated this era before flexbox and co. CSS used to be the least intuitive thing on the planet yet a lot of people claimed otherwise. We had to resort to silly tricks (remember overflow hidden?) in order to make up for the mess that CSS used to be. Again what really pissed me off isn't CSS inherent issues but the fact that many people claimed there was absolutely nothing wrong with it, a pattern I often see wi…
I find it really frustrating when project runners refuse to acknowledge shortcomings. I'm not always expecting them to solve it, but I'd at least like an acknowledgement that the issue I'm facing is valid. Pretending it's just me or that the obviously worse alternative is okay gets annoying. One example is ReasonML's async story: Q: What's BuckleScript's async story? A: If you're not interfacing with any library that…
If they are semi-serious, then "cromulent" would be a better synonym for "(marginally) acceptable."
I hate that people use CSS Grid like this. For some reason, I see so many people reach for CSS Grid like it's the de facto solution for responsive design. This is a bad design because you're tying the child elements to the grid layout of the parent. If you added an extra column in the grid, you'd have to go and adjust it for the full bleed elements. IMO a better solution would've been to just use a column layout with…
Widespread flex gap support will probably eliminate 95% of grid usage in my apps today: https://caniuse.com/flexbox-gap And what a surprise, it's just Safari holding us back again. =_=
> but CSS has an obscure unit that makes our life a little bit easier I've been out of the HTML game for a while, is ch the new em ? em has been around for a while. I understand that they are slightly different, but is there a strong reason to use one over the other?
ch is based on the width of a "0" character, em is based on the font size, which is the height of the character. for setting widths of things that contain text ch makes more sense. For padding, spacing, font sizes, inline symbols, and that kind of thing, em makes more sense.
I hate that people use CSS Grid like this. For some reason, I see so many people reach for CSS Grid like it's the de facto solution for responsive design. This is a bad design because you're tying the child elements to the grid layout of the parent. If you added an extra column in the grid, you'd have to go and adjust it for the full bleed elements. IMO a better solution would've been to just use a column layout with…
Widespread flex gap support will probably eliminate 95% of grid usage in my apps today: https://caniuse.com/flexbox-gap And what a surprise, it's just Safari holding us back again. =_=
nav
content
2. Alternately:
nav content
Unsurprisingly enough, HN uses #1.