I implemented something like this on my website [1] and I'm not really sold on it and I'm considering changing back. The two things that I've lost are collapsing margins between paragraphs/headers and the ability for any asides (like a floating image or a footnote) to vertically span multiple paragraphs. For margins between paragraphs I replaced them with grid-gap, but always having the same grid-gap is not great; yo…
Full-Bleed Layout Using CSS Grid
161–170 of 277 posts
Re: Full-Bleed Layout Using CSS Grid
#162Earlier quoted context omitted.
I think part of it is that there are probably lots of additional items that you want to constrain to the main column, so your CSS would end up looking more like: #content p, h1, h2, h3, nav { .. } Kind of a pain to manually specify each element that you want to constrain, when it's most of them. This approach allows you to instead target the items that you don't want to constrain. Additionally, as a more specific iss…
Still not sure I get it. CSS makes it very easy to carve-out elements because of selector specificity. .content * { max-width: 65ch; margin: 0 auto; } .content img { max-width: 100%; width: 100%; } It's a neat demo of CSS Grid, for sure, but the above would be my much preferred way of doing this kind of layout. Maybe if there were a need for elements (quotes, callouts, etc.) in the side columns alongside the content,…
blockquote {
margin-left: 15px;
/* ... */
}
won't work properly (it'll go all the way to the left). i haven't checked, but i think that in the grid version, you'd get an indent as expected.and i think that's the grid version's main advantage – it doesn't "use up" `margin` and `max-width`, so you're free to use them to style stuff that appears in the body. feels a bit more composable, though at the cost of also feeling massively overcomplicated :/
Re: Full-Bleed Layout Using CSS Grid
#163Re: Full-Bleed Layout Using CSS Grid
#164I'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?
Re: Full-Bleed Layout Using CSS Grid
#165Earlier quoted context omitted.
> most people who do front-end don't want to spend a day learning it. Can you link to some good resources? I've read "CSS The Definitive Guide" by Eric Meyer, "Eric Meyer on CSS" (also by Eric Meyer) and "CSS Zen Garden" and I still can't get CSS to do anything useful and always resort to table-based layouts because they work.
You sound a lot like me. I'll use CSS for colors/fonts/theming/separation and then do layout with tables :) . None of the stuff I work on is really all that complicated, so "tables are slow" just doesn't come up because the pages aren't large at all so 5ms vs 50ms doesn't matter.
Re: Full-Bleed Layout Using CSS Grid
#166It’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…
However: it's unclear to me what a better solution would look like; and it's clear to me that nothing better would ever be so much better as to "beat" CSS.
Re: Full-Bleed Layout Using CSS Grid
#167It’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…
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 win a chess tournament by thoroughly learning chess rules and figures. But you can not. It is okay for chess, where you build up your expertise for years and decades, but not for a rapid application development. Css is a bike with no front wheel, one pedal and it only turns left, unless you know that sit-backwards hack. There are better (more reason-enabling at least) layout systems out there, but cool web guys are digging in their heels on that "css" thing. And that would be okay, iff they made that damn bike at least complete, at least once in its lifetime.
Want a simple, trivial puzzle?
(component1)
.form
label.a input
label.b input
.some-content
(component2)
.form
label.c input
Make all labels of the same, non-fixed width, for these forms to look more aligned under different label localisations. Without recomposing layout elements. In constraint-based layout, it is a.w = b.w = c.w (priority:low). In gtk, you add (a,b,c) into the same SizeGroup. In css I'm doing it the wrong way, these requirements are strange, I should rethink my model, take a different/better approach, maybe it is okay for them to not be aligned, because awesome css at least solves a huge load of problems and the internet rests on it, bla-bla-blah.That even may have an almost-css-only solution, but whatever it is, it will be yet another "recipe" with a pile of crutches as ingredients. Which is likely not compatible with rendering loops or a structure of a half of popular js/css frameworks.
Re: Full-Bleed Layout Using CSS Grid
#168I 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…
(I agree with you on this simple layout)
Re: Full-Bleed Layout Using CSS Grid
#169> 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?
Re: Full-Bleed Layout Using CSS Grid
#170Earlier 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.