Live data from Hacker News

Full-Bleed Layout Using CSS Grid

joshwcomeau.com

211–220 of 277 posts

Re: Full-Bleed Layout Using CSS Grid

#211
post #154

Earlier quoted context omitted.

This alternative falls apart as soon as you want to put a border or box-shadow around the content column while still having full-bleed elements. Now you're limited to having it individually around each group of elements before/after any full-bleed content, instead of the entire set of content.

Not necessarily. I'm on mobile, so can't link to code right now, but here's how it would happen: You can have another .background element which spans all the rows (using grid-row-start and grid-row-end) and positioned in the centre column. Apply the shadows on it, and keep it before the content div in DOM order. That should do it.

[deleted]

Re: Full-Bleed Layout Using CSS Grid

#212
post #209

Isn’t this a non-problem easily solved at the user’s preferences? Simple size your browser to the desired width!

A lot of people use browser tabs, which allow you to use the same window to view different websites. And a lot of websites use highly different font sizes, and layouts without sidebars or with sidebars of varying widths. Combine those facts, and you'll see that if people tried to size their browser window to the desired width, they would have to resize it every time they switched tabs to a different website. Not ideal: it's better if sites include styles to default to a readable column width given their own specific layout.

Re: Full-Bleed Layout Using CSS Grid

#213
post #159
post #145

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.

Firefox and Chrome still don't agree on how tables should work.

Re: Full-Bleed Layout Using CSS Grid

#214
post #167

Earlier quoted context omitted.

I think CSS is "difficult to understand" because most people who do front-end don't want to spend a day learning it. Ask some people who make the claim it's difficult: what is the box model, and what is selector specificity. I can almost guarantee they won't be able to answer those questions, because they haven't bothered to actually try to learn CSS. Their knowledge of CSS is built from a set of "how do I do X in CS…

Pardon me, but I've read tens of technical references, rationales and getting started's in my life, but not a single one was so ritualistic and/or useless for practicing as everything about css. The reason is... Their knowledge of CSS is built from a set of "how do I do X in CSS" searches Because "box model and selector specificity" is light years away from how to do X. If you want an analogy, you are suggesting to w…

CSS is a top-down language, not a constraint language. It is not surprising that you cannot construct things in the same way as you would in a constraint-based layout system.

I am sure I could discover an equal "simple" example that is easy in CSS but difficult/impossible in GTK.

That you cannot use a hammer in the same way as a crowbar, even though they are both blunt instruments, is not a condemnation of the hammer. So yes, you do need to evaluate what the right tool for the job is - like JS to do a quick width-match on the labels' natural widths - after the CSS did most of the rest. That is not "bla-bla-blah," that's just knowing the limits of your tools.

The frustration seems to be the impression that CSS should be able to solve any conceivable layout desire on the web, which isn't its charge: CSS is first and foremost made to style web documents, which by-and-large don't fit as easily into the constraint-based-layout box as a traditional desktop app would. Since this kind of desire often crops up in desktop-like SPAs, where JS use is endemic already, it's not wrong to use a little bit more JS to nudge the visual experience a little closer to what you'd see on a desktop app.

I guess my takeaway is, CSS doesn't promise the world, so if you come in expecting that, you'll walk away disappointed. Luckily there are many tools in the web dev toolkit to achieve your engineering desires, and it's not verboten to use them (aside from a philosophical desire to avoid JS, but if the biggest problem for your page when JS is disabled is that the labels are slightly different sizes, I think you're doing a great job already).

Re: Full-Bleed Layout Using CSS Grid

#215
post #159

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.

IE actually created many of the standards we take for granted like XMLHttpRequest. [1] It was the innovator for a long time until priorities changed and the IE team was disbanded leading to the stagnation.

Microsoft definitely takes the blame in keeping it poor for so long but this situation is nothing like Safari which has refused to implement standards that already exist, as well as messing with others in unintuitive ways.

1. https://schepp.dev/posts/today-the-trident-era-ends/

Re: Full-Bleed Layout Using CSS Grid

#217
post #13

It’s beyond me why CSS has to be so hard to understand. I have made several attempts and got it right, but it feels like I have to start at zero every time. I believe, it’s because CSS is not a programming language, but we are trying to do programming with it. Like: if screen is mobile then render divs stacked. I don’t know

I think CSS is "difficult to understand" because most people who do front-end don't want to spend a day learning it. Ask some people who make the claim it's difficult: what is the box model, and what is selector specificity. I can almost guarantee they won't be able to answer those questions, because they haven't bothered to actually try to learn CSS. Their knowledge of CSS is built from a set of "how do I do X in CS…

> I think CSS is "difficult to understand" because most people who do front-end don't want to spend a day learning it.

I couldn't disagree more. There are a ton of reasons CSS really is hard, even when one understands the box model etc.

E.g.:

1. Hugely non-modular. An element's behavior always depends, to some extent, on styles applied to other elements. Systems full of entangled global state are inherently complex, separate from any other concern.

2. Highly magical. E.g. if you want to control how elements stack with z-index, you need to also know that z-index is ignored for elements that aren't positioned, which in turn means you need to set up your margins differently because positions disable margin collapsing. There's no one "model" to learn; it's a big morass of interconnected rules and edge cases.

3. Extremely fragile. Layout changes that a human user might consider minor often can't be done without significantly redesigning the page.

Of course, problems like these can all be mitigated to various extents. But that takes care and experience; it's not just a matter of reading some articles like you imply.

Re: Full-Bleed Layout Using CSS Grid

#218

Earlier quoted context omitted.

Wouldn’t that be Chrome? The ubiquity leads to lazy developers testing only on it. Maybe some fancy SVGs saying “Best viewed on Chrome!” To really rub it in :)

No, the definition of "the new IE" is to not support the latest features. Pick some other phrase for "most popular"

[deleted]

Re: Full-Bleed Layout Using CSS Grid

#219

Earlier quoted context omitted.

Wouldn’t that be Chrome? The ubiquity leads to lazy developers testing only on it. Maybe some fancy SVGs saying “Best viewed on Chrome!” To really rub it in :)

No, the definition of "the new IE" is to not support the latest features. Pick some other phrase for "most popular"

he is 100% right that IE's ubiquity is what caused the problem to begin with. well, that and microsoft getting arrogant because of it.

Re: Full-Bleed Layout Using CSS Grid

#220
post #185

Earlier quoted context omitted.

slow to follow the standards 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 keepi…

Apple is only able to do this because of the monopoly of browser engines for 1.5 billion iOS devices. If they allowed (or were forced to allow) other browser engines then likely a large number of users would switch to another browser, forcing Apple to compete for features.

What's that say about the quality of Safari then?
Post reply on HN