Full-Bleed Layout Using CSS Grid(joshwcomeau.com)
joshwcomeau.com
Full-Bleed Layout Using CSS Grid
https://www.joshwcomeau.com/css/full-bleed/
276 comments
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. =_=
And what a surprise, it's just Safari holding us back again. =_=
In fairness, this feature was only released in Chrome a couple of months ago, and has in the past week been merged into WebKit: https://trac.webkit.org/changeset/267829/webkit
Fair enough, I guess both Chrome and Safari were holding us back until a few months ago haha.
Really ecstatic to see that it's going to be in Safari soon though! Thank you so much for sharing! Really made my day.
This is why I love Hacker News.
Really ecstatic to see that it's going to be in Safari soon though! Thank you so much for sharing! Really made my day.
This is why I love Hacker News.
The new IE.
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 :)
> SVGs saying “Best viewed on Chrome!”
HA! Chrome absolutely SUCKS at displaying SVGs. I rarely use them and I've already found two stupid bugs.
One super weird one (probably too much caching) where an animated element in a <use> clone didn't inherit colours while its non-animated siblings do. This one is fixed now.
What isn't fixed yet is that `filter: hue-rotate(90deg)` applied to an SVG child element doesn't do anything (in firefox it does), is a pain in the ass because SVG filters, while more powerful, are much harder to set up.
HA! Chrome absolutely SUCKS at displaying SVGs. I rarely use them and I've already found two stupid bugs.
One super weird one (probably too much caching) where an animated element in a <use> clone didn't inherit colours while its non-animated siblings do. This one is fixed now.
What isn't fixed yet is that `filter: hue-rotate(90deg)` applied to an SVG child element doesn't do anything (in firefox it does), is a pain in the ass because SVG filters, while more powerful, are much harder to set up.
Safari also has its share of SVG bugs, like this one: https://stackoverflow.com/questions/31150919/svg-background-...
SVG filter support in Chromium is actively being worked on, primarily led by an incredible engineer at Opera ([email protected]). This work has been ongoing for almost a year and should complete in Q4. Please star https://crbug.com/109224 for updates (stars also help prioritization).
Going to codepen this later and see what’s up. I haven’t used them beyond toy setups since it’s usually a hassle, I always get inspired by the Stripe site.
No, the definition of "the new IE" is to not support the latest features.
Pick some other phrase for "most popular"
Pick some other phrase for "most popular"
[deleted]
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.
Yeah "web standards" my ass - with WHATWG 100% just being Chrome devs, and W3C a pay-as-you-go wannabe "standardization body" financed by Google (and long out of the game of doing anything meaningful except CSS) so-called web standards are more of a monopolization and extortion instrument than anything else. Web heads seriously need to wake up rather than making it ever more complicated.
The definition of "the new IE" is not not supporting the latest features (IE had plenty of "new" features—see e.g. filters, VML, XMLHttpRequest). The issue with IE was that it supported it's own proprietary features without consultation nor coordination with competitors. Something it was only able to do due to its market monopoly.
Yes, Chrome does this too.
It's slightly better in that it tends to submit them to standards bodies after implementing them, but most of the time that's WHATWG which is a much less democratic body than others, and mostly Google-led. Either way Chrome's market monopoly leave competitors with little choice in the standards process.
Yes, Chrome does this too.
It's slightly better in that it tends to submit them to standards bodies after implementing them, but most of the time that's WHATWG which is a much less democratic body than others, and mostly Google-led. Either way Chrome's market monopoly leave competitors with little choice in the standards process.
You mean the common JS environment that doesn’t support fetch, Node?
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 has absolutely ignored standards when it suits apple. That's why, for example, you can't rely on PWAs on Apple products.
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/
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/
A browser engine that's primarily used on platforms where it's mandatory, and cannot be uninstalled or replaced, is "very essential for keeping the web open"?
ie was also a trashfire because of the release/update model, holding the entire web back because it was so far behind standards (ie6 was actually ahead of its time on release, but then didn't get updated for ages). safari, especially on ios where you can't even get any other browser engines, and the safari version is tied to the operating system version, follows that same model with the same consequences. not as painful these days, since the web has come a long way already, but you can definitely see the parallels
unsure what part of this is cause for downvoting-- it is absolutely correct. it's not even invalidating other peoples' observations. people are weird (or ignorant (or both))...
edit: oh and i guess now that i upvoted it it's not grey anymore xD
edit: oh and i guess now that i upvoted it it's not grey anymore xD
Safari has a lot of issues outside of just being behind the standards. I've encountered background and z-index jank, form issues, SVG issues and even mouse event issues. If you are a web developer, there's a good chance your codebase has Safari bugfixes.
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 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.
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.
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?
How quickly people forget who brought canvas, CSS animations, etc.
Firefox and Chrome still don't agree on how tables should work.
Chrome got in in May finally...Firefox has had it for years. One thing I really missed in Chrome and Safari.
Awesome - didn't know this was a thing.
there's virtue to having smaller isolated components when possible. kind of a weird example, but the other day I tried to make a huge table responsive (that needed to be paginated badly, but that was an issue out of my reach) - I found out that chrome actually maxes out at 1000 rows for display:grid, and then your layout just breaks. I converted it to flexbox and getting it to look the way I wanted was way easier than I expected, plus I could support ie11 without having to do the weird ms grid syntax. I imagine it's also faster for the browser
It's surprising how rarely I even consider using CSS grid and every time I do, I still figure out a way to do it with flexbox. Now this depends of course on what you are doing, but for simple things, and you should keep things simple more often than complicated, flexbox is still as valid as it was before.
Maybe my layouts aren't as fancy as those who know how to neatly proportion their boxes with CSS grid using golden ratios, but I'm quite satisfied that they work and are easy to understand for anyone who knows a thing or two about flexboxes. Sometimes I might have to add an unnecessary wrapper, I admit that. But oh well.
Maybe my layouts aren't as fancy as those who know how to neatly proportion their boxes with CSS grid using golden ratios, but I'm quite satisfied that they work and are easy to understand for anyone who knows a thing or two about flexboxes. Sometimes I might have to add an unnecessary wrapper, I admit that. But oh well.
I agree. Grid seemed great in theory, but in practice I almost never find myself using it. The number of use cases that flexbox doesn't satisfy is quite small, and the Grid syntax is a bit more tedious. It's just not worth the trouble most of the time.
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.
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.
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]
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.
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.
The tables haven’t died for email layouts. Email presentation is horrific. Outlook with its special IE is oh so much fun.
Outlook doesn't even have IE btw... It has a custom MS Word compliant HTML parser/renderer (Facepalm emoji)
You’re correct. They switched from IE to Word https://www.litmus.com/blog/a-guide-to-rendering-differences...
The parent-child problem you mention can be addressed with names. Children can say "grid-name: footer". This is just a hint for the parent to decide where to place it in the grid. Then the parent can use grid-template-areas to arrange its children. You no longer need to change the children if you're adding columns to the layout.
(I agree with you on this simple layout)
(I agree with you on this simple layout)
I like CSS grids for global layout stuff because of the layout flexibility it gives you when it comes to different screen sizes and orientations, without having to use js when you need to swap the order of things around (and at some point you will have to eventually unless it is a very simple page). This helps separating the markup from the styling even further so it is rather a good thing.
I would — however — never had the idea to abuse it like that. Why not just limiting using max-width on your text-related tags?
The only problem I ever had with that is that markdown generated HTML will wrap <img> into <p> if it follows the standard and as of now there is no CSS way of selecting p without child of type IMG or p only with child of type img..
I would — however — never had the idea to abuse it like that. Why not just limiting using max-width on your text-related tags?
The only problem I ever had with that is that markdown generated HTML will wrap <img> into <p> if it follows the standard and as of now there is no CSS way of selecting p without child of type IMG or p only with child of type img..
max-width on text do have a problem: you cannot set margin on the them. Say, blockquote, unordered list, etc.
Could you show some example CSS for your alternative suggestion by any chance? I'm not quite sure what you mean about using flexbox this way.
Seems like you are the style police ;)
According to the creators of the Grid you can use it for whatever you want however you want. So there is no right or wrong.
The last yeas I often hear to voices saying "this is wrong do it so" or something until I realized, that a elegant way in CSS is mostly not adaptable from one html layout to another (across CMS ). So everyone has to find his own way to write clear code which is manageable. There is no gold path.
This displays a very mediocre grasp on, at the very least, web semantics and CSS Grid. (Also, an emotional disposition against a simple piece of web technology. Wild.)
> This is a bad design because you're tying the child elements to the grid layout of the parent
Apart from that sentence carrying very little internal logic and abusing the word "because", there is a simple fix to what, I think, is your point: Name your grid areas.
There is absolutely nothing in CSS Grid specifications that urges you to fill in all the possible areas, or, in fact, any of the areas. Or make it 2D. If you can use it to solve your layout problem in an elegant way, that's a good thing. The solution in the linked article is semantically sound and elegant -- obviously far more elegant than the proposed alternative of adding control markup to every single child.
> This is a bad design because you're tying the child elements to the grid layout of the parent
Apart from that sentence carrying very little internal logic and abusing the word "because", there is a simple fix to what, I think, is your point: Name your grid areas.
There is absolutely nothing in CSS Grid specifications that urges you to fill in all the possible areas, or, in fact, any of the areas. Or make it 2D. If you can use it to solve your layout problem in an elegant way, that's a good thing. The solution in the linked article is semantically sound and elegant -- obviously far more elegant than the proposed alternative of adding control markup to every single child.
You can use the same trick in a flexbox container?
Set every * to max-width: 65ch and then have the same full-bleed class to go to width: 100%.
I agree with OP that using grid for this is a bit misplaced. But realistically, it probably won’t be a problem.
Set every * to max-width: 65ch and then have the same full-bleed class to go to width: 100%.
I agree with OP that using grid for this is a bit misplaced. But realistically, it probably won’t be a problem.
This doesn't work because `65ch` means very different things depending on the font-size. You need to apply it to a parent class, so that it picks the base font size (I'm not actually sure how this works but in practice it seems to base it on the child <p> tag).
I also don't like the idea of "reaching in" and setting widths on all children. Feels like this could cause problems, especially on replaced elements like images/videos. Not to mention that it just feels wrong when combined with a component architecture, where I might expect a <Heading> component to control its own destiny. In fairness, my solution also reaches in to apply a grid-column, but grid-column is a property that only makes sense when combined with a parent's `display: grid`. So it bothers me less.
Enough people have brought this up that I wonder if I should have addressed it in the article... but then I realize, it's not my job to argue against or "disprove" all alternative ideas. I'm not claiming that my way is the best way, I'm just sharing a cool trick I found :)
I also don't like the idea of "reaching in" and setting widths on all children. Feels like this could cause problems, especially on replaced elements like images/videos. Not to mention that it just feels wrong when combined with a component architecture, where I might expect a <Heading> component to control its own destiny. In fairness, my solution also reaches in to apply a grid-column, but grid-column is a property that only makes sense when combined with a parent's `display: grid`. So it bothers me less.
Enough people have brought this up that I wonder if I should have addressed it in the article... but then I realize, it's not my job to argue against or "disprove" all alternative ideas. I'm not claiming that my way is the best way, I'm just sharing a cool trick I found :)
There really aren't any scenarios I can think of that an element would need to have `grid-column` set without being wrapped in another grid, so for that reason it is generally safer to set `grid-column` on all children than it is to set `max-width`. I would be surprised if I added an element only to discover that its width was being modified by a wildcard rule, less so with `grid-column` because grid placement is arguably the concern of the grid.
As a side note, I like this technique and have already had a good opportunity to apply it instead of the old padding & negative margins method or even flexbox + stretch (and I like flexbox), neither of which actually worked for this very specific case.
As a side note, I like this technique and have already had a good opportunity to apply it instead of the old padding & negative margins method or even flexbox + stretch (and I like flexbox), neither of which actually worked for this very specific case.
> I'm not claiming that my way is the best way, I'm just sharing a cool trick I found :)
I agree. It’s not that I really think one way is better or worse.
I like flexbox more, but since you’re not working in my codebase, you can do whatever you want ;)
I agree. It’s not that I really think one way is better or worse.
I like flexbox more, but since you’re not working in my codebase, you can do whatever you want ;)
Doesn't that run in the "ch depends on font and font-size" problem e.g. with headings vs paragraphs again if you don't use wrappers?
Hmm, that’s definitely possible, but then I think we probably shouln’t be using that magic unit to begin with.
Why? It specifically exists to make things dependent on the font, and sizing text columns based on the size of the body text, and have other elements follow that, also makes sense.
Yes, but with it being dependent on the current font size, its a tad hard to use effectively.
You can make the container have a sensible weight to keep all elements within it, but you cannot have the children contain their own destiny in a consistent manner.
You can make the container have a sensible weight to keep all elements within it, but you cannot have the children contain their own destiny in a consistent manner.
I fail to see anything in your reply that disputes anything OP said
My use case would be to style markdown exports and it's really a pain to add divs everywhere and it screws with the timelessness of your document. A few years ago I used js to achieve full bleed.
I can tell you why I, a sys admin interested in dabbling in html/css for my own personal website, looked into CSS Grid.. Firefox Developer Start Page. Right there in the middle.
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 with many developers about this or that language. Obviously, there were some problems or we wouldn't be needing CSS grids or flexbox today.
I don't understand this.
You can appreciate something while still acknowledging its obvious flaws, nothing is perfect.
I don't understand this.
You can appreciate something while still acknowledging its obvious flaws, nothing is perfect.
Seems like a bit of a strawman, people who couldn't think of a single issue with CSS. You are generally talking to beginners when you encounter anyone like that on any subject. Kind of like trying to draw too many conclusions from a Twitter argument you had with someone who is actually a 14yo (probably happens a lot more than we like to think).
Instead I think I could agree with people who could point out that it's all trade-offs, and there are some upsides to having fewer autolayout options in UI programming. For example, flexbox and cssgrids enables things you simply wouldn't have attempted before in CSS (you'd have gone with something less expressive, like media-query hard-coding). And any time you nest grids and/or flexboxes you get to rediscover the horrors of autolayout flexibility.
UI is hard and there is no "best". Though it's the emergence of mobile devices that forced the hand to more complex autolayout tools.
Instead I think I could agree with people who could point out that it's all trade-offs, and there are some upsides to having fewer autolayout options in UI programming. For example, flexbox and cssgrids enables things you simply wouldn't have attempted before in CSS (you'd have gone with something less expressive, like media-query hard-coding). And any time you nest grids and/or flexboxes you get to rediscover the horrors of autolayout flexibility.
UI is hard and there is no "best". Though it's the emergence of mobile devices that forced the hand to more complex autolayout tools.
I've noticed that some people mistake 'the best extant X' with 'X has no problems.' For instance, 'Y is a problem with X' will often receive the response 'Nuh-uh, because extant Z also has problem Y but is worse than X in other respects.' Look for this particularly in conversations about smartphones.
> > iphones have poor battery life, I'd like a phone that keeps a charge for a full week at least.
> No you're wrong because android phones also have bad battery life.
> > iphones have poor battery life, I'd like a phone that keeps a charge for a full week at least.
> No you're wrong because android phones also have bad battery life.
I've also noticed this. It seema to be especially common amongst proponents of capitalism:
>> 21st century capitalism a wealth concentration problem
> No you're wrong because communism is terrible.
>> 21st century capitalism a wealth concentration problem
> No you're wrong because communism is terrible.
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:
A: Unfortunately, we do not offer an async/await equivalent currently. BuckleScript has a Js.Promise type for using Promises. We understand that this is not ideal, and are working on other options.
Look—it's okay that they don't have the feature. Nobody's perfect. But they shouldn't pretend that callbacks are an acceptable replacement because they're "performant".
One example is ReasonML's async story:
Q: What's BuckleScript's async story?
A: If you're not interfacing with any library that uses promises, you can simply use callbacks. Everyone gets them and they're performant. If you need to bind to a JS library that uses promises, or communicate with such library, you can use BS's Js.Promise.
A: Unfortunately, we do not offer an async/await equivalent currently. BuckleScript has a Js.Promise type for using Promises. We understand that this is not ideal, and are working on other options.
Look—it's okay that they don't have the feature. Nobody's perfect. But they shouldn't pretend that callbacks are an acceptable replacement because they're "performant".
This is my biggest bugbear (the general behaviour, not the specific example). I want to make good technical decisions, your library has made choices based on its principles and design goals, don't obscure the trade-offs you've been made -- this is just a (poor) growth hack in disguise.
I've seen so many people use technologies then regret it a year later because they realised what they actually wanted to achieve was at odds with the design goals of the technology.
I've seen so many people use technologies then regret it a year later because they realised what they actually wanted to achieve was at odds with the design goals of the technology.
OCaml has monadic let syntax[1] which is similar to F#'s computation expressions. I am not sure why it is not yet supported in Reasonml/Bucklescript.
[1] http://jobjo.github.io/2019/04/24/ocaml-has-some-new-shiny-s...
[1] http://jobjo.github.io/2019/04/24/ocaml-has-some-new-shiny-s...
Because Bucklescript/ReScript is based on a modified fork of OCaml 4.06, before monadic let was added.
https://github.com/rescript-lang/ocaml "This branch is 387 commits ahead, 5444 commits behind ocaml:trunk"
https://github.com/rescript-lang/ocaml "This branch is 387 commits ahead, 5444 commits behind ocaml:trunk"
Perfect use of "performant" as a nonsense pseudo-adjective, to signal sarcasm and condescension.
If they are semi-serious, then "cromulent" would be a better synonym for "(marginally) acceptable."
If they are semi-serious, then "cromulent" would be a better synonym for "(marginally) acceptable."
Yeah, it might have embiggened their presentation
In my experience, no matter how many improvements there have been, there are always things that you are trying to do that css doesn't support or make easy to do. Recently I've tried making tabs the same width but not justified horizontally, meaning all tabs should have the same width as the widest one. Something like this (1) but without hard coding the children count. In my mind, you would be able to set the widths to max-width of siblings. In general, I would love to have more signifiers that describe relations between elements.
(1)https://codepen.io/brettdonald/pen/oRpORG
(1)https://codepen.io/brettdonald/pen/oRpORG
Then what direction of relationship would have precedence, left to right? Right to left? If neither how precedence would be defined? Overall I don't want css to become any more complex, if you need an edge case such as that one JavaScript is a great tool for the job.
Funny, I was just struggling with this yesterday in an assessment I was given for a new job.
Yeah I have the same feeling. I was struggling for hours the other week to make two columns the same height, but the need for an overflow on one kept on killing everything.
Coming from a mechanical engineering background, I'm very used to being able to define spatial properties with respect to other elements in CAD, and it just seems lacking in CSS.
Coming from a mechanical engineering background, I'm very used to being able to define spatial properties with respect to other elements in CAD, and it just seems lacking in CSS.
It's tough to know that something is bad when you don't know about anything better. I remember when I started doing Android development was when I really realized how terrible CSS was. And this was long before all the new constraint stuff in iOS and Android that still makes CSS look bad.
i suspect you might be mixing up people who talked about the spec and actual end users - at least can't seem to recall anyone ever saying css is good as it is, back in the days. The shortcomings where well known and anmoying to anyone having to work with them. But that might be true to my bubble only.
[deleted]
Just wanted to say that's an excellent tutorial. I almost never touch anything on the front end. My web dev skills are, at best, thoroughly out of date. But I could still follow and understand everything presented. If you're reading, thanks Josh. Great job.
I especially appreciate how the end solution was presented fairly early in the tutorial after the stage had been set. I find it helpful to see the code representing "where we're going" instead of holding out until the very end to arrive there.
Agreed! It's very well written -- I noticed that immediately too
> It's relatively easy to constrain all children, but CSS doesn't really have a mechanism to selectively constrain some children.
Yes it does. You can use
Yes it does. You can use
.wrapper h1, .wrapper p {}
.wrapper :is(h1,p) {}
.wrapper > :not(.full-bleed) {}
.wrapper { h1,p {} }
I think the point being made was it's not easy to selectively have some children break out of a parent container with a max-width.
[deleted]
:has is not supported in any browser, and that seems unlikely to change, for performance reasons. https://caniuse.com/css-has
Sorry, I meant :is (which is already supported in some browsers).
Sometimes it'd be great to have full XPath available for CSS selectors. But I can see how that's a performance nightmare.
You can support :has(), and things like it yourself via client-side JavaScript styling runtimes well enough.
Hi there! Author here.
What I meant is that there is no way to tell certain children to disregard the constraints of a container; if a parent is 800px wide, there isn't a way to say "keep this child in-flow, but fill the viewport".
The alternative you propose is problematic for a couple reasons:
- I don't like "reaching in" to child elements. Especially in a component-focused architecture, it's a quick way to make a mess. My solution DOES reach in to apply a grid column, but that property only makes sense within the context of a grid, so it doesn't seem as problematic to me.
- the `ch` unit doesn't work properly when applied individually to different elements; an `h1` with 65ch width is going to be much wider than a `p` with 65ch width. You need the width to be applied to the parent, so that it remains consistent
- It's likely that you already have a constrained container, if you're adapting this solution to a page that already exists. If so, your approach isn't really workable without a major overhaul.
I'd also just add, the nice thing about using Grid is that it's super extensible. If you want to add a sidebar, it's quick and straightforward.
What I meant is that there is no way to tell certain children to disregard the constraints of a container; if a parent is 800px wide, there isn't a way to say "keep this child in-flow, but fill the viewport".
The alternative you propose is problematic for a couple reasons:
- I don't like "reaching in" to child elements. Especially in a component-focused architecture, it's a quick way to make a mess. My solution DOES reach in to apply a grid column, but that property only makes sense within the context of a grid, so it doesn't seem as problematic to me.
- the `ch` unit doesn't work properly when applied individually to different elements; an `h1` with 65ch width is going to be much wider than a `p` with 65ch width. You need the width to be applied to the parent, so that it remains consistent
- It's likely that you already have a constrained container, if you're adapting this solution to a page that already exists. If so, your approach isn't really workable without a major overhaul.
I'd also just add, the nice thing about using Grid is that it's super extensible. If you want to add a sidebar, it's quick and straightforward.
I do see how op misread your intention, but would like to add that you did a very good job on addressing all these shortcomings and provide a neat solution with this tutorial - very good work!
> Research has shown that the ideal line length is about 65 characters. Anywhere between 45 and 85 is generally seen as acceptable, in the context of a roman alphabet.
This should be literally nailed into everyones head. It's really tiring to hack and patch website styles to make them readable; Desktop HN is guilty of this too. Sometimes I feel I'm reading an ancient papyrus scroll around here.
Brilliant blog and I'm excited to implement full-bleed in my blog. I feel that code snippets, data tables and even some screenshots can really take advantage of this!
This should be literally nailed into everyones head. It's really tiring to hack and patch website styles to make them readable; Desktop HN is guilty of this too. Sometimes I feel I'm reading an ancient papyrus scroll around here.
Brilliant blog and I'm excited to implement full-bleed in my blog. I feel that code snippets, data tables and even some screenshots can really take advantage of this!
A custom CSS could fix that for you.
p { max-width: 65ch; }
For me it's teh other way around.
I hate these narrow designs where two third of the site is blank. Mostly gleaming white.
Additionally I have to scroll even though the text would have fit on one page.
The value for the optimal column width does not seem to be saved either:
http://blog.fawny.org/2005/09/21/measures/
This should be literally nailed into everyones head
No, it should be treated as a matter of subjective opinion, because that's what it is. They can take their "research" and shove it where the sun doesn't shine. It simply does not apply to everyone, no matter how much the "researchers" wish it did.
Never mind that I actively prefer wide columns, there's also the fact that I didn't spend $2000 for a monitor so I could look at 80% empty space.
No, it should be treated as a matter of subjective opinion, because that's what it is. They can take their "research" and shove it where the sun doesn't shine. It simply does not apply to everyone, no matter how much the "researchers" wish it did.
Never mind that I actively prefer wide columns, there's also the fact that I didn't spend $2000 for a monitor so I could look at 80% empty space.
Great article. While CSS grid is very powerful, maybe I'm not seeing the full picture in the examples: aren't the examples possible with just p { margin: 0 auto; max-width: 65ch } ? What does grid bring here?
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:
Additionally, as a more specific issue, the static-site generator that I use renders markdown such that images are inside a paragraph, so your approach wouldn't work at all for me.
Edit: As an aside, that's a super fun site! Lots of neat little UI easter eggs.
#content p, h1, h2, h3, nav { .. }
Additionally, as a more specific issue, the static-site generator that I use renders markdown such that images are inside a paragraph, so your approach wouldn't work at all for me.
Edit: As an aside, that's a super fun site! Lots of neat little UI easter eggs.
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%; }
You would get a ragged left margin if you have elements less than 65ch wide.
I left out some assumptions for brevity, but my presumption was that everything inside of the container (like p tags) would be display: block, so it would try to fill the max-width of 65ch with blank space anyway.
you actually wouldn't, as these smaller elements still get centered by the auto margin
i think your version will break a bunch of common uses of `margin-{left,right}`; e.g. indenting like
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 :/
blockquote {
margin-left: 15px;
/* ... */
}
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 :/
This might be solved by putting the margin on .content and using negative space for full-bleed elements, as in:
.content { width: 65ch; margin: 0 auto }
.content .full-bleed {
width: 100vw;
margin-left: calc((65ch - 100vw) / 2);
}yeah, that's the most common way of doing it afaik
Indeed the grid based solution in the article depends on selector specificity in exactly the same way as this.
Use a negative margin on the full bleed item? Bit hacky, but works fine:
.content {
max-width: 85ch;
width: 100%;
margin: 0 auto;
}
.content img,
.content .full-bleed {
width: 100vw;
height: auto;
padding-left: 50%;
margin-left: -50vw;
}Then use something like `#content > :not(.full-bleed) { .. }`
only theoretically, for the p element itself.
ch is a fontsize relative unit and this solution wouldn't provide the same results for any element that has another text sizing and is not wrapped within a p tag.
and if you apply these rules to the whole content wrapper, you loose the ability to have some children selectively fill the viewport.
ch is a fontsize relative unit and this solution wouldn't provide the same results for any element that has another text sizing and is not wrapped within a p tag.
and if you apply these rules to the whole content wrapper, you loose the ability to have some children selectively fill the viewport.
[deleted]
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 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
CSS is declarative and not imperative. A lot of people have issues with a different kind of programming.
Also the "cascading" nature of CSS makes it hard to reason about.
Also the "cascading" nature of CSS makes it hard to reason about.
The differences in how different engines/platforms behave definitely does not help when doing any non-trivial layout.
I think a _lot_ of this is standardised now in the vast majority of browsers people use.
Depending on what space you work in and what consumers you have “majority” is not acceptable.
Safari and IE are the big bugbears in my experience.
Safari and IE are the big bugbears in my experience.
True - I'm lucky not to have to consider versions of IE prior to 11 on most projects I work on, and I can usually get things working there, although there's a flexbox thing that I always forget with IE11 that catches me out.
I stand by my comment if you don't have to do IE < 11 though.
I stand by my comment if you don't have to do IE < 11 though.
Even just IE11 is pretty bad given the state of grid and flexbox on IE11.
Yeah, grid is pretty much not worth it imo, as you have to do so much differently. You can make flexbox work though.
The environment for CSS isn't nearly as "standard" as you might think. Even though WebKit and Blink are the majority engines on mobile there's tons of combinations of versions, screen sizes, and aspect ratios. Trivial layouts are easy but more complicated layouts can be very difficult to get working right, let alone looking right, across browsers/platforms.
The problems are often solvable but not necessarily easy. The difficulty is compounded by the heterogeneity of the Android space.
It's great the majority browser engines follow the CSS standards but a lot of problems aren't bounded by the accuracy of the implementation.
The problems are often solvable but not necessarily easy. The difficulty is compounded by the heterogeneity of the Android space.
It's great the majority browser engines follow the CSS standards but a lot of problems aren't bounded by the accuracy of the implementation.
Without wanting to diminish what you're saying, which makes a lot of sense - I feel like we should be trying to avoid complex layouts on mobile - at least in the browser.
And you're right that screen sizes can mess stuff up, Firefox/chrome mobile view on devtools doesn't always tell the full story... Got something working there and it was broken on my actual phone.
And you're right that screen sizes can mess stuff up, Firefox/chrome mobile view on devtools doesn't always tell the full story... Got something working there and it was broken on my actual phone.
I think it really has more to do with the fact that it was originally only designed with print flow in mind. Like laying out a magazine with columnar text.
When it was initially designed there was an expectation that structural layout would happen outside of it and then you'd flow your text and other inline/block objects within that.
Most everything since then has just been about trying to get css back to the structural flexibility people had in 1996 with tables, while still trying to keep the flow flexibility css brought (and then, as you say, adding on media-type flexibility). It's not a surprise this turned out ugly.
When it was initially designed there was an expectation that structural layout would happen outside of it and then you'd flow your text and other inline/block objects within that.
Most everything since then has just been about trying to get css back to the structural flexibility people had in 1996 with tables, while still trying to keep the flow flexibility css brought (and then, as you say, adding on media-type flexibility). It's not a surprise this turned out ugly.
I think it's because of the combinatorics of it and it's compounded by the specificity system, the size of the vocabulary, and no built-in compiler.
The combinatorics are tough for our lizard brains to reason out. If you don't have a strict set of rules for your CSS then you end up with a mixture of element rules, class rules, and id rules, and the combinations of these can get hard to hold in your head. Having compound styles doesn't help at all because it's easy to not realize you're setting a style accidentally.
Then what happens when there's a collision? The specificity system is supposed to sort that out, but without learning the rules there's just no way to intuit them. When I'm struggling with getting something just right and some library CSS is overriding my local CSS it's always the specificity rules that are at fault.
The vocabulary size is enormous. It's unclear exactly how many properties there actually are, but the most authoritative answer I could find was 522. That's a crazy number. And yes, that treats `margin` and `margin-left` as two separate properties, but they're still in there. By comparison there are 53 reserved words in Java and only 33 in Javascript. It's possible for a mere mortal to memorize these.
And finally there's no built-in compiler. Yes, I know about Sass, but that's not much more than a macro system; a useful macro system, but still just a macro system. A lot of us use compilers as our grammar and vocabulary checkers. If I do mis-spell a word in Java the compiler usually errors out and I'm forced to fix it. But if you mis-spell a property in CSS it's happy to just ignore it and you spend several minutes trying to figure out why your change did nothing.
The combinatorics are tough for our lizard brains to reason out. If you don't have a strict set of rules for your CSS then you end up with a mixture of element rules, class rules, and id rules, and the combinations of these can get hard to hold in your head. Having compound styles doesn't help at all because it's easy to not realize you're setting a style accidentally.
Then what happens when there's a collision? The specificity system is supposed to sort that out, but without learning the rules there's just no way to intuit them. When I'm struggling with getting something just right and some library CSS is overriding my local CSS it's always the specificity rules that are at fault.
The vocabulary size is enormous. It's unclear exactly how many properties there actually are, but the most authoritative answer I could find was 522. That's a crazy number. And yes, that treats `margin` and `margin-left` as two separate properties, but they're still in there. By comparison there are 53 reserved words in Java and only 33 in Javascript. It's possible for a mere mortal to memorize these.
And finally there's no built-in compiler. Yes, I know about Sass, but that's not much more than a macro system; a useful macro system, but still just a macro system. A lot of us use compilers as our grammar and vocabulary checkers. If I do mis-spell a word in Java the compiler usually errors out and I'm forced to fix it. But if you mis-spell a property in CSS it's happy to just ignore it and you spend several minutes trying to figure out why your change did nothing.
> By comparison there are 53 reserved words in Java and only 33 in Javascript.
Where did you find these numbers? I'm trying to find them but I can only find the Ecmascript and the number appears way higher
Where did you find these numbers? I'm trying to find them but I can only find the Ecmascript and the number appears way higher
For Java I used https://www.thoughtco.com/reserved-words-in-java-2034200 but Wikipedia lists 51. I'm too lazy to actually diff it.
For Javascript I used https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... and fudged the numbers a bit. There are future reserved words, but I didn't iinclude them because there's no point in memorizing them. Now that I look in detail that list also doesn't include "true", "false", and "null".
For Javascript I used https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... and fudged the numbers a bit. There are future reserved words, but I didn't iinclude them because there's no point in memorizing them. Now that I look in detail that list also doesn't include "true", "false", and "null".
39 listed here https://tc39.es/ecma262/2020/#sec-keywords-and-reserved-word...
51 listed here https://docs.oracle.com/javase/specs/jls/se15/html/jls-3.htm... with a bunch of non keywords listed below, of which true false and null are also reserved
51 listed here https://docs.oracle.com/javase/specs/jls/se15/html/jls-3.htm... with a bunch of non keywords listed below, of which true false and null are also reserved
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 don't need all that power most of the time, but it's there. To understand CSS you have to understand a lot of underlying concepts about layout and web page structure. People feel like "Why do I have to remember all these arbitrary rules?!". I sympathize - and sure a fair few things are arbitrary and never changed due to not breaking existing code - but most of the rules are not arbitrary, they just serve a bigger world than what we might be dealing with as web devs.
In the end I prefer to think of CSS as a powerful programming language that gives me lots of _primitives_, not a framework with a bunch of out of the box behavior that matches my narrow needs. If you want those, they are out there of course.
But yeah. CSS is hard and it takes study, practice, and time to be good at it. I think half of the time we struggle with CSS it's because we expect that it is "easy" and that it should cooperate without us investing time in learning it. It's written in short lines that look like plain English. It should do what we expect all the time, right?
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 don't need all that power most of the time, but it's there. To understand CSS you have to understand a lot of underlying concepts about layout and web page structure. People feel like "Why do I have to remember all these arbitrary rules?!". I sympathize - and sure a fair few things are arbitrary and never changed due to not breaking existing code - but most of the rules are not arbitrary, they just serve a bigger world than what we might be dealing with as web devs.
In the end I prefer to think of CSS as a powerful programming language that gives me lots of _primitives_, not a framework with a bunch of out of the box behavior that matches my narrow needs. If you want those, they are out there of course.
But yeah. CSS is hard and it takes study, practice, and time to be good at it. I think half of the time we struggle with CSS it's because we expect that it is "easy" and that it should cooperate without us investing time in learning it. It's written in short lines that look like plain English. It should do what we expect all the time, right?
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.
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.
CSS is able to target print: https://www.princexml.com/
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 CSS" searches and the resulting stylesheets are hobbled together messes.
If you learn the box model, if you learn the reasons behind selector specificity, and how cascading works, you'll really earn a true appreciation for CSS. It does not take long to learn, you just have to spend a day reading through the "boring" stuff.
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 CSS" searches and the resulting stylesheets are hobbled together messes.
If you learn the box model, if you learn the reasons behind selector specificity, and how cascading works, you'll really earn a true appreciation for CSS. It does not take long to learn, you just have to spend a day reading through the "boring" stuff.
> I think CSS is "difficult to understand" because most people who do front-end don't want to spend a day learning it.
Yeah, "html/css" is the object of our derision on HN as some sort of thing that's beneath us. As if someone who is an "html/css" designer isn't a real developer. Yet at the same time we complain that we have to learn it. That after pretending it was trivial all this time, we're annoyed that we can't just fake our way through it when the going gets tough.
But the other reason it's hard is that UI and clientdev is hard. There's this weird meme that UI is just bells and whistles and stakeholder pleasers instead of a human interface that demands a lot of forethought and expertise, and something that has to be functional and possibly even a joy for the user to use. You can see this when people here brag about being backend developers that never touch the client as if that's something to brag about.
Yeah, "html/css" is the object of our derision on HN as some sort of thing that's beneath us. As if someone who is an "html/css" designer isn't a real developer. Yet at the same time we complain that we have to learn it. That after pretending it was trivial all this time, we're annoyed that we can't just fake our way through it when the going gets tough.
But the other reason it's hard is that UI and clientdev is hard. There's this weird meme that UI is just bells and whistles and stakeholder pleasers instead of a human interface that demands a lot of forethought and expertise, and something that has to be functional and possibly even a joy for the user to use. You can see this when people here brag about being backend developers that never touch the client as if that's something to brag about.
> 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.
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.
I've been writing CSS for about 10 years at nearly every professional job I've had. I don't get 'stuck' often and generally feel competent, but I am far from an expert or a master. I think CSS is difficult to understand because there are so many ways to accomplish a task, and so many of those ways lead to (sometimes) unforeseeable consequences, and nearly all of the APIs (possibly with the exception of css grid) don't feel very coherent... in my experience. I think it is difficult to learn because there's no real apparent holistic design to really grok.
I tried mdgriffith's elm-ui on a personal project and it was a breath of fresh air. It felt like an utterly excellent abstraction and I hope someone ports it to Typescript/React/JSX some day.
I tried mdgriffith's elm-ui on a personal project and it was a breath of fresh air. It felt like an utterly excellent abstraction and I hope someone ports it to Typescript/React/JSX some day.
Yeah I think working with CSS is like working with Databases. There are a lot of ways in databases to get the job done. At first glance it seems to work the way you want and even survives early testing or even deployment. It doesnt fall apart until much later when you are trying to build upon it, scale it, etc.. This causes many people to learn the wrong way to do something because they might not stick around until it falls apart. The next time they have to do something they remember the way they got it to work last time and do it again, never realizing they are leaving a trail of tears for future developers to clean up the mess with.
CSS is very much the same way. I can't tell you how many times I have seen CSS files that are a house of cards. One wrong element gets added into a markup and the whole thing crumbles. Unnecessary use of !important, wildcards, overly specific, not specific enough, inconsistent media queries, desktop-first layouts (as opposed to mobile-first, or often times a mixture of the two depending on the element), and so on. At first glance, the stakes for bad CSS also seem pretty low (which is not the case with databases or backend code). This further causes developers to just hack at it until it works or is "close enough". It instills bad habits that last years or even entire careers.
CSS is very much the same way. I can't tell you how many times I have seen CSS files that are a house of cards. One wrong element gets added into a markup and the whole thing crumbles. Unnecessary use of !important, wildcards, overly specific, not specific enough, inconsistent media queries, desktop-first layouts (as opposed to mobile-first, or often times a mixture of the two depending on the element), and so on. At first glance, the stakes for bad CSS also seem pretty low (which is not the case with databases or backend code). This further causes developers to just hack at it until it works or is "close enough". It instills bad habits that last years or even entire careers.
The comparison with databases is an interesting one. I have observed in both that really diving into exploiting the domain in a language-native way (e.g. CSS or SQL) can lead to extremely powerful solutions, but ones which don't integrate very neatly into a broader system. So you usually find people inventing patterns, or restricting themselves to subset -- choosing to skip some of the power in favour of maintainability. You can build an entire system in just SQL and little-to-no other programming languages, but should you?
it also doesn't help that sometimes you have to whack-a-mole different browser implementations of the spec, and particularly if you're working on a bit of a website somebody else owns you have to be very careful about specificity, what styles other teams may be using, etc.
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 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?
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.
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
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.
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).
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).
You just switched from blaming me for not knowing css to blaming me for not using the right tool, as if I had a clear way to do that. It is nothing new and was propheted in bla-blah paragraph. But if you ever tried to size-match in JS, you know that it is not a trivial task. First, an element must be temporarily placed into document.body for all styles to apply correctly. Second, it must repeat all of the hierarchy it was in, which requires to break/duplicate a component encapsulation in your code. Third, in a narrow-width situation you simply cannot guess what surrounding containers would do to the effective width/height based on an intrinsic geometry. Not even speaking of cpu/battery issues, these three alone make it possible only in theory. And no, there is no library for that to "just work" in your project.
I am sure I could discover an equal "simple" example that is easy in CSS but difficult/impossible in GTK.
I doubt it, really. I mean, you could find something for base gtk (which is already out of reach compared to css in ui geometry, because it was done for it), or for the fact that gtk is not a networking engine, but it is just a bunch of predefined containers, calculation phases and signals in C. It is easily extensible in a native way and hides no knowledge about how everything looks or works. Gtk is an example of how you expose distinct particles, pre-implement few useful combinations, and then users build a universe with them. Css is an example of ritualistic black box that hides almost everything about its geometry and requires a non-trivial effort for really basic things. E.g. in css, you have to struggle with dumbest things like a one-pixel vertical scroll in a single-line input. My complaint is not "css is not gtk-like", it is "css is incomplete and unreasoned AF in its own model".
I am sure I could discover an equal "simple" example that is easy in CSS but difficult/impossible in GTK.
I doubt it, really. I mean, you could find something for base gtk (which is already out of reach compared to css in ui geometry, because it was done for it), or for the fact that gtk is not a networking engine, but it is just a bunch of predefined containers, calculation phases and signals in C. It is easily extensible in a native way and hides no knowledge about how everything looks or works. Gtk is an example of how you expose distinct particles, pre-implement few useful combinations, and then users build a universe with them. Css is an example of ritualistic black box that hides almost everything about its geometry and requires a non-trivial effort for really basic things. E.g. in css, you have to struggle with dumbest things like a one-pixel vertical scroll in a single-line input. My complaint is not "css is not gtk-like", it is "css is incomplete and unreasoned AF in its own model".
> It is nothing new and was propheted in bla-blah paragraph.
I don't think we can have a reasoned discussion about this if you're going to write off any contention as "bla-blah," so I'm disengaging.
I don't think we can have a reasoned discussion about this if you're going to write off any contention as "bla-blah," so I'm disengaging.
It was my bla-blah, so please read it as etc-etc, and if you feel offended by that and by my tone, I apologize. But it would be fair if you also excused my huge disappointment after following these exact ideas, spending days and finding out that they do not work or are completely non-viable in vivo. If any css loving guy implemented the puzzle above (and a half of other common issues) as a library that could be simply added to a job-grade project, they are welcome to share it (or sell, such an easy $$$). I've been in these discussions and done what was suggested, that's why I listed all these reasons word by word, before anyone had a chance to repeat them, and that's where my criticism comes from. I just cannot sit here and silently watch how they praise a thing that is not remotely as good as is claimed. How many man-centuries have to be spent until we all admit the undeniable?
> 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.
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.
Which editions did you read?
Many of the css options that make complex layouts more palatable have only been commonly supported more recently. (flex-box:2015 , grid:2017, newer units:2010)
Many of the css options that make complex layouts more palatable have only been commonly supported more recently. (flex-box:2015 , grid:2017, newer units:2010)
I don't remember the specific editions, but it was a long time ago - long before flex-box and grid were around. Still, back then, people could work magic with CSS using floats and positioning and such, and I couldn't make any sense of it. Maybe it's time to pick up a more up-to-date book on CSS and try again with the modern timesavers.
[deleted]
I don't know if there is a single perfect resource out there, but the thing that helped me the most was understanding CSS as a shift from programming with an imperative mindset to a declarative mindset. Treat CSS as a medium for expressing 'what you want' instead of 'what to do.' My guiding principle is that "less is more" and if you find yourself writing a ton of super-specific and messy CSS, it's one of two scenarios: there's an easier way to do it, or you have a very picky project manager who wants things to be pixel-perfect to the mock-up. If it's the latter, you have my sympathies.
Focusing on the box model is important because it sets the right overall mindset for working with CSS layout. At the risk of being too patronizing, I would highly encourage everyone to at least read the MDN article on CSS basics[0] just to set a baseline for CSS terminology, the idea of the box model, and a few other things.
You should then read more detailed documentation [1] on the box model and start to get a feel for how it works in depth. Most pedestrian "spacing issues" should be solved at the level of adjusting margins and padding.
The other arm I mentioned was specificity, and this tends to be where a lot of folks get caught asking why their rules aren't applying and those sorts of issues. The documentation is fairly 'academic' but worth a read-through[2].
MDN overall is a great resource for a motivated learner, but unfortunately I don't have any 'CSS the right way' sorts of articles in my hat at the moment. Maybe others will post some.
[0]: https://developer.mozilla.org/en-US/docs/Learn/Getting_start...
[1]: https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_...
[2]: https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity
Focusing on the box model is important because it sets the right overall mindset for working with CSS layout. At the risk of being too patronizing, I would highly encourage everyone to at least read the MDN article on CSS basics[0] just to set a baseline for CSS terminology, the idea of the box model, and a few other things.
You should then read more detailed documentation [1] on the box model and start to get a feel for how it works in depth. Most pedestrian "spacing issues" should be solved at the level of adjusting margins and padding.
The other arm I mentioned was specificity, and this tends to be where a lot of folks get caught asking why their rules aren't applying and those sorts of issues. The documentation is fairly 'academic' but worth a read-through[2].
MDN overall is a great resource for a motivated learner, but unfortunately I don't have any 'CSS the right way' sorts of articles in my hat at the moment. Maybe others will post some.
[0]: https://developer.mozilla.org/en-US/docs/Learn/Getting_start...
[1]: https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_...
[2]: https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity
css tricks has nice flexbox and grid guides that also have helpful pictures to show what the end result of CSS is:
https://css-tricks.com/snippets/css/a-guide-to-flexbox/
https://css-tricks.com/snippets/css/complete-guide-grid/
https://css-tricks.com/snippets/css/a-guide-to-flexbox/
https://css-tricks.com/snippets/css/complete-guide-grid/
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.
Using tables for things that aren't tables is terrible for accessibility.
Why is it so bad for accessibility? I don't know much about web design.
Browsers, and therefore things like screen readers, see table elements as collections of tabular data. Using these elements for layout or design will cause a confusing and useless interpretation for people using a screen reader or analogous tool.
This really deserves to be echoed. Accessibility just isn’t taken seriously by web developers in general and it makes me so sad. If it’s mentioned at all most of the time it’s an afterthought and they try to shoehorn it in on existing code as an afterthought which just makes things worse.
I want to implore everyone on HN to not be one of those people
I want to implore everyone on HN to not be one of those people
I like doing short challenges to learn and solutions to peak at in case I get stuck.
Andy Bell posted front-end challenges for a while, here's the archive: https://piccalil.li/category/front-end%20challenges%20club/
Codepen hosts challenges every week. They aren't always CSS focused but many of them are. https://codepen.io/challenges
Andy Bell posted front-end challenges for a while, here's the archive: https://piccalil.li/category/front-end%20challenges%20club/
Codepen hosts challenges every week. They aren't always CSS focused but many of them are. https://codepen.io/challenges
While I think this is definitely a useful foundation, things get a lot more complicated quickly once you jump into a large site's stylesheet(s).
Why isn't this element the size I specified? Or why is there a tiny amount of scroll overflow here when I specify overflow-x hidden? What does vertical-align do and how does it work when inline and inline-block boxes are in an inline flow? etc. etc.
So I would add that the next frontier after learning the proposed foundations is learning how the browser actually determines box sizes and layout, and I think this is difficult to understand, mainly because it jumps straight into the spec, or worse, your browser's layout engine specifics.
https://www.w3.org/TR/css-sizing-3/#auto-box-sizes for instance is a nontrivial subsystem that a CSS dev will easily run into when nesting flex containers, and I think the standard box model of yore wasn't really written to help grok these concepts.
Edit: one particularly hairy explanation from the spec I recently ran into while trying to deepen my understanding of the box model:
"Except for table boxes, which are described in a later chapter, and replaced elements, a block-level box is also a block container box. A block container box either contains only block-level boxes or establishes an inline formatting context and thus contains only inline-level boxes. Not all block container boxes are block-level boxes: non-replaced inline blocks and non-replaced table cells are block containers but not block-level boxes. Block-level boxes that are also block containers are called block boxes."
Not saying this is relevant for the average use case, but I believe even something like the box model is a day-to-learn-lifetime-to-master kind of thing.
Why isn't this element the size I specified? Or why is there a tiny amount of scroll overflow here when I specify overflow-x hidden? What does vertical-align do and how does it work when inline and inline-block boxes are in an inline flow? etc. etc.
So I would add that the next frontier after learning the proposed foundations is learning how the browser actually determines box sizes and layout, and I think this is difficult to understand, mainly because it jumps straight into the spec, or worse, your browser's layout engine specifics.
https://www.w3.org/TR/css-sizing-3/#auto-box-sizes for instance is a nontrivial subsystem that a CSS dev will easily run into when nesting flex containers, and I think the standard box model of yore wasn't really written to help grok these concepts.
Edit: one particularly hairy explanation from the spec I recently ran into while trying to deepen my understanding of the box model:
"Except for table boxes, which are described in a later chapter, and replaced elements, a block-level box is also a block container box. A block container box either contains only block-level boxes or establishes an inline formatting context and thus contains only inline-level boxes. Not all block container boxes are block-level boxes: non-replaced inline blocks and non-replaced table cells are block containers but not block-level boxes. Block-level boxes that are also block containers are called block boxes."
Not saying this is relevant for the average use case, but I believe even something like the box model is a day-to-learn-lifetime-to-master kind of thing.
You could probably write an article that'd be very often read if you teach CSS from this perspective.
I've wanted to actually! It's become almost a meme that CSS is hard and a badge of honor to be ignorant of it, but it's not that bad. I will concede that there are some annoying design decisions (like margin collapsing) but overall, I think it's a well-designed and evolving solution that has stood the test of time. That we've been able to so easily add things like flexbox and Grid to it in response to the changing needs of the web is kind of a testament of how well CSS modelled the problem of layout. Learning box-model and cascading will let one solve 90% of common CSS problems people encounter just from first principles.
While I agree with the main thrust of this comment; I don't think I'll ever "earn a true appreciation for CSS". Even the most careful application of class naming guidelines eventually creeps into specificity battles, and you cannot predict exactly what a line of CSS will do until it's actually applied to an element.
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.
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.
Where is the best place to learn CSS from a more foundational/complete perspective? I took freeCodeCamp's responsive web dev course but still find myself googling a lot of "how to do x in CSS"
Yes, this exactly. Spend no time trying to understand something and then claim that something is hard to understand. No, sir, throwing stuff at the wall and hoping some will stick is not a good way to learn.
Alas, this approach is becoming more and more prevalent with everything, not just CSS.
This is me. My brain chucks it in the bitbucket as soon as the project over. 95% of my time is in firmware with the occasional web page/javascript to update and I google and It All Starts Making Sense, and then the project is over and I don't touch it again for 2 years :)
One reason it is hard is that the effect of CSS rules depends on their order. Imagine if in your JavaScript you write 5 functions, and depending on the order you write them in causes them to have a different effect.
https://medium.com/@panuviljamaa/why-css-is-difficult-a2cdf0...
https://medium.com/@panuviljamaa/why-css-is-difficult-a2cdf0...
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; you want some content closer than others.
For asides, it means I have to write smaller footnotes that vertically match the height of paragraphs - exactly the kind of lack of content/style separation I want to avoid.
This guy's site is fantastic and the article is well written tho, and it probably works for some people.
[1] example article that uses full-bleed sections: https://nickpunt.com/blog/category-defining-products/
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; you want some content closer than others.
For asides, it means I have to write smaller footnotes that vertically match the height of paragraphs - exactly the kind of lack of content/style separation I want to avoid.
This guy's site is fantastic and the article is well written tho, and it probably works for some people.
[1] example article that uses full-bleed sections: https://nickpunt.com/blog/category-defining-products/
I recommended dropping vertical margin and instead using exclusively margin-bottom (or padding-bottom) as much as possible. The behavior is generally more intuitive, and you'll get the control you're looking for.
In my case each subsequent paragraph, heading, or object is it's own grid row, which act like table rows where margins cannot collapse. Thus things like headings having a certain whitespace above them aren't possible without margin-top, among other small annoyances. Hence the reason I want to switch :)
A quick note is that by using CSS grid, margins are not collapsed. For the example in the article, the heading and the paragraph are rows, so if they have top and bottom margins, they will be further apart than normally. This can break design sometimes
This is actually a really neat technique. I've done full-bleed layouts before grid was around, but it required messing around with negative margins, which is fragile and hard to get right.
Yes, I always have to play around with some variant of
margin: 0 calc(50vw - 50% - 1rem);
If there's any chance the content on your page will need to be printable or turned into a PDF, do not use CSS Grid. It will get obliterated no matter which browser you use. I made a mobile responsive resume using CSS Grid which I eventually had to completely redo the styling because Grid broke everything.
This is good advice. I recently tried to rewrite my resume in HTML and CSS because I was annoyed with LibreOffice's (though Word would be no different) table handling/UX - wherein my table ended right before the bottom page margin so I ended up with an unnecessary trailing blank page.
After switching to CSS grids, I had problems with alternating row background colors (I achieved it, but relied on knowing the contents when what I really wanted was a generic solution). Apart from that (and me wanting to group some elements together to make the markup a bit more semantic and `display: contents` having some weird interactions), it was quite a breeze. But, then I tried to print it to PDF, and discovered that browsers won't split a grid row over two pages even if I tell it to, so ended up with more whitespace in other places... Am now trying to decide whether to just use table markup as one cannot specify colspans etc in CSS with `display: table-cell`...
After switching to CSS grids, I had problems with alternating row background colors (I achieved it, but relied on knowing the contents when what I really wanted was a generic solution). Apart from that (and me wanting to group some elements together to make the markup a bit more semantic and `display: contents` having some weird interactions), it was quite a breeze. But, then I tried to print it to PDF, and discovered that browsers won't split a grid row over two pages even if I tell it to, so ended up with more whitespace in other places... Am now trying to decide whether to just use table markup as one cannot specify colspans etc in CSS with `display: table-cell`...
If you're printing a résumé I cannot recommend LaTeX highly enough. It's a hassle to set up, it's niche so you'll probably only ever use it for your résumé unless you (re)enter academia, and the learning curve is a bear. But your résumé will sing and if you like to look at beautiful type while you work this will feel good. You may find yourself writing up set theory problems just for fun.
Protips: \usepackage[garamond]{mathdesign} sudo getnonfreefonts --sys -a
https://ctan.org/pkg/mathdesign https://tug.org/fonts/getnonfreefonts/
Protips: \usepackage[garamond]{mathdesign} sudo getnonfreefonts --sys -a
https://ctan.org/pkg/mathdesign https://tug.org/fonts/getnonfreefonts/
I like this idea, but how do you deal with pseudo bleed elements overlapping with sidebar content? For example many websites put navigation elements on the sidebar [1], or margin notes [2], [3]. I personally would love to see a css only solution for pseudo bleed with margin notes. The only solutions I've found so far use resize observer to absolutely position the margin notes using js or have hand coded positions and offsets.
[1]: https://meyerweb.com/eric/thoughts/2020/07/01/accordion-rows...
[2]: https://www.gwern.net/About
[3]: https://www.inkandswitch.com/local-first.html
[1]: https://meyerweb.com/eric/thoughts/2020/07/01/accordion-rows...
[2]: https://www.gwern.net/About
[3]: https://www.inkandswitch.com/local-first.html
> https://www.gwern.net/About
what the hell, its like someone vomited CSS on that page
what the hell, its like someone vomited CSS on that page
A compromise might be to hide navigation elements or margin notes until you hover / click on an element, sort of like how Wikipedia enables page previews on internal links.
I don't know why but this page is using 100% CPU and making my fans go through the roof in Safari.
Same. I stopped reading halfway through because I'm on battery and don't want to run it down just reading a blog post. Also I got tired of the fan noise.
Same, around 40-50% CPU in Brave (MacOS), and the article is more or less useless with JS disabled.. ಠ_ಠ
Yeah, disabling JS fixed it but then you can't see any of the code snippets.
This seems to work nicely: https://archive.is/YjDHQ
Probably some janky bit of JS watching the scroll too frequently so that the little clippy guy can pop up and ask if you want to see his latest project
> There's a complicating factor, however—not all content should be constrained.
Hmmm. That had really not occurred to me. A great post for this little gem alone.
Hmmm. That had really not occurred to me. A great post for this little gem alone.
I have a much simpler approach which works on browsers going back 10+ years:
https://mirror.drewdevault.com/margins.html
https://mirror.drewdevault.com/margins.html
The article starts out with the problem of wikipedia pages. Does anyone have a solution to wikipedia pages?
I tried to adapt the articles approach to wikipedia. Create an account on wikipedia, or login.
Then go to https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsec...
I chose MinervaNeue with Custom CSS. Here is what I set the CSS to:
Anybody got a better layout?
I tried to adapt the articles approach to wikipedia. Create an account on wikipedia, or login.
Then go to https://en.wikipedia.org/wiki/Special:Preferences#mw-prefsec...
I chose MinervaNeue with Custom CSS. Here is what I set the CSS to:
main {
display: grid;
grid-template-columns:
1fr
min(65ch, 100%)
1fr;
}
main p {
font-family: "Hoefler Text", Garamond, "Times New Roman", Cambria, Cochin, Georgia, Times, 'Times New Roman', serif ;
}
main > * {
grid-column: 2;
}
.infobox {
width: 100%;
grid-column: 1 / 4;
}
Anybody got a better layout?
Not sure the answer to your question but worth mentioning that Wikipedia is working on a major redesign that will hopefully address some of these things.
From what I've understood it's already rolling out in small steps.
I like using Wikiwand. For example: https://www.wikiwand.com/en/Hacker_News
Not only is this a nice technique, it's also a nice introduction to several key CSS Grid concepts.
this guy has some voodoo going on this site. I see the page, then the whole screen turns white. Even in safe mode.
Edit: he is using ResizeObserver:
https://developer.mozilla.org/Web/API/ResizeObserver
which hasnt made it past draft JavaScript specification.
Edit: he is using ResizeObserver:
https://developer.mozilla.org/Web/API/ResizeObserver
which hasnt made it past draft JavaScript specification.
Whoa - your website eats 40% of quite recent Macbook Pro' CPU. It looks cool at the same time! Great content!
min(ch, ...) is the most interesting and potentially useful thing I've learned!
I'm now off to learn more about this magical "ch" unit.
I'm now off to learn more about this magical "ch" unit.
If a site like Wikipedia is too wide, wouldn't you just make your browser window thinner? Mine has never been wider than half the display since I got a widescreen LCD ~ 15 years ago.
[deleted]
What do you display on the rest of your screen? Doesn't it distract you from what you are reading in your browser?
Interestingly, before they added the iOS-style fullscreen mode, the "maximise" button on Mac OS X would actually just fit the window to the content, rather than the screen.
A common frustration to those used to Windows or Linux, while the Mac folks were equally confused about why people wanted full-width windows with miles of empty space on either side.
A common frustration to those used to Windows or Linux, while the Mac folks were equally confused about why people wanted full-width windows with miles of empty space on either side.
Just whatever other software I'm using. Usually terminal windows, sometimes text or graphics editor, e-mail client. That kind of thing.
The translucent gradient overlay this site has is truly obnoxious. What possesses people to do things like this? Headers that follow you when you scroll down the page are bad enough, but this is truly abominable. Don't fade out text I'm trying to read dammit!
Delete StandardLayout__GradientWrapper, it served no useful purpose, it only pisses people off.
Delete StandardLayout__GradientWrapper, it served no useful purpose, it only pisses people off.
I stopped reading the article because of this. Highly offensive.
I've thought blocking sticky header would remove it but no —
flying gradient. Besides how to support names like StandardLayout__GradientWrapper-sc-1x2euwc-2 doIIpB in annoyance list? They would change in a moment.
Easier to just use Reader View
I get that one of my browsers isn't the newest safari (last update 2019), but the page shows the content, then blanks out the screen... Can't we fail gracefully..
"ReferenceError: Can't find variable: ResizeObserver"
Works fine in firefox. Diabling javascript in safari works, excepting some images don't load..
"ReferenceError: Can't find variable: ResizeObserver"
Works fine in firefox. Diabling javascript in safari works, excepting some images don't load..
If your screen is too wide to read websites comfortably, why don't you resize your browser?
What is the point of buying a bigger monitor if you're still going to full-screen your browser to the point you can't read anymore? Isn't the point of bigger monitors to show more things at once?
What is the point of buying a bigger monitor if you're still going to full-screen your browser to the point you can't read anymore? Isn't the point of bigger monitors to show more things at once?
I don't understand either.
These days we have many websites with giant empty spaces on the left and/or right, all in the name of making the text lines short enough (much shorter than I like them, but that's another rant). Making the browser window smaller often makes the text even smaller, instead of the useless empty spaces. Make some room for my other windows, please! We're not in the 90's anymore where monitors were only large enough for one window.
There's this trend of very wide and ultra wide monitors. I sincerely hope people don't use their browsers full-screen on 3440x1440 monitors.
Unless those empty spaces are supposed to be filled with ads that my ad blocker blocks for me. But that too is another rant.
These days we have many websites with giant empty spaces on the left and/or right, all in the name of making the text lines short enough (much shorter than I like them, but that's another rant). Making the browser window smaller often makes the text even smaller, instead of the useless empty spaces. Make some room for my other windows, please! We're not in the 90's anymore where monitors were only large enough for one window.
There's this trend of very wide and ultra wide monitors. I sincerely hope people don't use their browsers full-screen on 3440x1440 monitors.
Unless those empty spaces are supposed to be filled with ads that my ad blocker blocks for me. But that too is another rant.
> These days we have many websites with giant empty spaces on the left and/or right, all in the name of making the text lines short enough (much shorter than I like them, but that's another rant).
The other rant is here: [1].
Curious why do you hope people don't use their browsers full-screen? How does someone else's browsing preference affect you? Am I a lesser person if I want to use my browser full-screen on a 5120x2880 retina display?
It seems more and more every year, the user's preference gets sidelined in favor of the web site designer's preference. I never thought it would get to this, but as web sites get more and more opinionated about enforcing their particular stylistic choices, I'm more often than not feeling the need to disable CSS or go into Reader mode. I wish browser developers would provide better tools to override questionable site designs, rather than taking them away. At least I can still change the font size with the browsers (shhhh--don't give them any ideas).
1: https://news.ycombinator.com/item?id=24690133
The other rant is here: [1].
Curious why do you hope people don't use their browsers full-screen? How does someone else's browsing preference affect you? Am I a lesser person if I want to use my browser full-screen on a 5120x2880 retina display?
It seems more and more every year, the user's preference gets sidelined in favor of the web site designer's preference. I never thought it would get to this, but as web sites get more and more opinionated about enforcing their particular stylistic choices, I'm more often than not feeling the need to disable CSS or go into Reader mode. I wish browser developers would provide better tools to override questionable site designs, rather than taking them away. At least I can still change the font size with the browsers (shhhh--don't give them any ideas).
1: https://news.ycombinator.com/item?id=24690133
I'm not trying to tell you what to do. But if YOU make your browser wider than YOU can comfortably read, why do you expect ME the developer to do something with CSS to deal with it?
That is the way your preferences affect me.
That is the way your preferences affect me.
If I choose to fullscreen my browser window, I'm not expecting the developer to do anything about it. In fact, I'm hoping he will not choose to go out of his way to try to do something about it (e.g. deliberately adding whitespace). Honoring the user's preference often means less code/CSS.
Oh I see. Then we are agreeing :)
Because I have many tabs open that I am switching between. Some of them work better in full screen and others need less space.
Another solution which I haven't seen anyone here mention yet is having multiple text columns, essentially splitting up your content into paragraphs that are laid out side-by-side, like you often see in newspapers and research papers.
This has its drawbacks and some people don't like it, but surely it's better than only using 20% of the width of a wide display.
I would like to see more websites at least include it as an option.
This has its drawbacks and some people don't like it, but surely it's better than only using 20% of the width of a wide display.
I would like to see more websites at least include it as an option.
> Have you ever tried to read Wikipedia on a very large screen? It looks like this: [image] Those paragraphs are so wide! Wikipedia doesn't constrain the container width at all. This leads to lines that are hundreds of characters in length.
NOOOOO! Please, please, please, please stop second-guessing my choice of browser window width! I bought a nice 27" monitor, and maybe I just want to use the whole thing. Why is your opinion about the amount of space I should be able to use for text more important than mine? I honestly don't care what your research says about optimal character lengths. I deliberately stretched my browser window to be this wide. Please don't override me.
NOOOOO! Please, please, please, please stop second-guessing my choice of browser window width! I bought a nice 27" monitor, and maybe I just want to use the whole thing. Why is your opinion about the amount of space I should be able to use for text more important than mine? I honestly don't care what your research says about optimal character lengths. I deliberately stretched my browser window to be this wide. Please don't override me.
Two reasons. One, the designer of the site has a specific UX and UI in mind, and that is their decision. If you don't like it, you can hack it with local CSS or just use a different site.
Two, (I know you don't care, but for others reading) there are studies that show that for the vast majority of people, width constraints make it easier to read. So there is good reason to enforce those constraints in the design from a usability perspective, not just a design perspective.
Sorry you don't care about the research. When I'm building a site I absolutely DO care about the research, and what will make it work the best for the largest number of people.
Two, (I know you don't care, but for others reading) there are studies that show that for the vast majority of people, width constraints make it easier to read. So there is good reason to enforce those constraints in the design from a usability perspective, not just a design perspective.
Sorry you don't care about the research. When I'm building a site I absolutely DO care about the research, and what will make it work the best for the largest number of people.
The people of number two can resize their browser window.
If I prefer full width lines I'm forced to the designers specific UX. That's quite ironic because the U in UX stands for user and my eXperience with such sites is horrible.
Worst of all are those that have code examples that go beyond the column width but don't wrap, so I have to scroll horizontally even though two thirds of the page are empty.
Have you read the research? It doesn't really support the claims people make about it. A good starter thread (albeit it's hard to follow all the replies in the nested conversations): https://twitter.com/danluu/status/1115707741102727168
I've read quite a bit of it. It really depends on the claim. Speed is generally faster with longer lines, although it does seem like there is an upper limit. But comprehension and subjective judgement (yes, that last is hard to quantify) seem to be best between 40-60 characters (actually less than the commonly recommended 65 as seen in the original post here). Also, it's generally not line-length, but characters per line, that matters, and keeping the visual angle from changing as the user reads.
So it depends on what exactly is being measured, which is why I said the overall UX and not something more specific.
This is a bit older, well prior to the days of 4K displays, but lots of interesting stuff nonetheless: http://images3.wikia.nocookie.net/__cb20060729105544/psychol...
So it depends on what exactly is being measured, which is why I said the overall UX and not something more specific.
This is a bit older, well prior to the days of 4K displays, but lots of interesting stuff nonetheless: http://images3.wikia.nocookie.net/__cb20060729105544/psychol...
Optimal line length for the web is not as short as it is commonly believed: https://www.viget.com/articles/the-line-length-misconception...
Even apart from that, I just see no point in constraining the widths forcefully. Just let the width adapt to the browser width, then each user can size it to his/her preferences and needs of the moment. Win-win for everyone.
Even apart from that, I just see no point in constraining the widths forcefully. Just let the width adapt to the browser width, then each user can size it to his/her preferences and needs of the moment. Win-win for everyone.
I guess my rant should be more directed towards browsers. I remember Netscape allowing me to specify all sorts of stylistic preferences. Hell, I could easily make your web site's background be a brick wall if I wanted to. Most those things have kind of disappeared by now, and we're left with CSS hacks, "Disable CSS" and "Reader Mode". Oh and I guess we can set default fonts and colors too, but those just get over-ridden by 99% of sites. Would be nice if User-agents would return some more control back to the actual user.
Yah, I definitely miss the days of providing your own user style sheet without plugins or other addons. These days I don't hardly bother, although I will pop open the dev tools to "fix" something once in a while if it's really bad.
Wait until Web developers find about setting a width and horizontal margins: auto on a block container again.
As a matter of fact, that would require even less attributes to work compared to the method presented in the article.
As a matter of fact, that would require even less attributes to work compared to the method presented in the article.
Since the element you're trying to apply the full-bleed to lives in a container that has a max-width, wouldn't you need to play with negative margins or absolute positioning to accomplish this with only margins?
I guess it's time for bettermotherfuckingwebsite.com gridless version to hit HN :)
This is not really CSS magic:
This is not really CSS magic:
main>*{max-width:65ch;margin: 1em auto}
.full-bleed{width:100%;max-width:none}Here’s an example on my site: https://chrismorgan.info/blog/rust-fizzbuzz/
That’s left-aligned (margin-left: 0; margin-right: 0) rather than centre-aligned (margin-left: auto; margin-right: auto), but it gets the point across. Headings, paragraphs, list items, &c. all get their widths constrained (deliberately to different points, in my case, which wouldn’t work if you were going centre-aligned), but figures can be full-bleed simply by not having that max-width (though in my case they still need negative side margins, but of known values).
That’s left-aligned (margin-left: 0; margin-right: 0) rather than centre-aligned (margin-left: auto; margin-right: auto), but it gets the point across. Headings, paragraphs, list items, &c. all get their widths constrained (deliberately to different points, in my case, which wouldn’t work if you were going centre-aligned), but figures can be full-bleed simply by not having that max-width (though in my case they still need negative side margins, but of known values).
Don't apply the max-width on the container but on selected children only.
Doesn't that just make it tricky to put stuff in the sidebars again? The article doesn't really talk about that but it is implied.
For a sidebar alone, you don't need CSS grid (probably obvious). The point of this article, i.e. having something full-bleed, is implemented by adding a specific class to the element. Which means you would always have a DOM similar to
The exception would be if you would want the full bleed element directly under the sidebar (in terms of z-index). Here CSS grid is useful, but this is probably a special case anyway.
</something that gets closed>
<full bleed>
...
</full bleed>
<next>
...
The exception would be if you would want the full bleed element directly under the sidebar (in terms of z-index). Here CSS grid is useful, but this is probably a special case anyway.
Nit: that's not full-bleed, which extends to all edges, including top and bottom. Bleeding to two edges we[1] called half-bleed.
[1] some segment of the SF Bay Area photography community circa 2010
[1] some segment of the SF Bay Area photography community circa 2010
is there a reason this is better than just putting a max-width on your paragraphs, and margin:auto?
I found css grid to be both practical, efficient and fun. I don't know what flaws it has but it's one of the lowest friction css layout bit I've ever toyed with.
Yeah, I don't get why it bugs some people so much but I find it to be really intuitive.
The spec is large and the syntax is a but surprising at times but it really gets you going.. I still can't figure out how to float divs properly you know :)
Why even use grid when you can solve this much easier without it?
Grid enables you to do this (and a lot more) in a way that works across all modern browsers without much code in a robust and consistent manner. If you still need to support IE or older Android it's useful to understand other approaches but if you want to deploy something today that works grid is an excellent approach.
I've been building front end stuff for about 25 years and grid is much more straightforward than any approach that's come before it. Tables were a hassle to change, floats were fragile across browsers, flex was (and still is) good, but grid is a step up from all of those.
I've been building front end stuff for about 25 years and grid is much more straightforward than any approach that's come before it. Tables were a hassle to change, floats were fragile across browsers, flex was (and still is) good, but grid is a step up from all of those.
Just as an FYI, I've run into browser compatibility issues when using grid. It's been a while since I worked on that project, so hopefully mobile / edge / safari / chrome / firefox are all on the same page now, but it wasn't great a year or two ago. Go here [1] and keep hitting more, there are unfortunately lots of things not working in Safari and partly in Firefox.
1. https://caniuse.com/?search=grid
1. https://caniuse.com/?search=grid
I don't disagree but it seems like you're avoiding my question.
How would you do this otherwise?
A simple implementation that works on IE8 https://twitter.com/e1g/status/1313178559234609153
That's exactly what I was thinking about
The article states, "Research has shown that the ideal line length is about 65 characters." but it links to a pdf. I skimmed several pages and found one statement that said what the average length was but I found mention of research on the ideal line length. The Smashing Magazine article linked says 65 is just a general rule derived from 2.5 times the Roman Alphabet.
Is there any actual research on this number?
Is there any actual research on this number?
From what i recall, the 65-75 char count for web comes from
The Elements of Typographic Style by Robert Bringhurst
Did anyone else get weird screen flickering[0] from the animated stars used in a few places on this site? The dev-tools show the stars are <span> elements being added/removed dynamically. The animation is cutesy, but the flickering is annoying.
FF 80.0.1 MacOS 10.14 (yeah it's old)
[0]https://vimeo.com/465078029
FF 80.0.1 MacOS 10.14 (yeah it's old)
[0]https://vimeo.com/465078029
I got the same flickering in FF 81, OS X 10.15. It only happened when the stars were on-screen.
Is this any different to Ethan Marcotte’s technique written from back in April?
https://ethanmarcotte.com/wrote/css-grid-without-max-width/
Used that one myself here: https://rwd.education
https://ethanmarcotte.com/wrote/css-grid-without-max-width/
Used that one myself here: https://rwd.education
The page presenting the article (and used as an example) doesn't use the same technique as mentioned in the article!
[deleted]
> 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?
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.
An em is historically based off the width of the letter M in a typeface. https://iamvdo.me/en/blog/css-font-metrics-line-height-and-v... is a fun deep dive into font sizing, which is pretty hairy.
That was my understanding as well. em was used for width and ex used for height.
Is it just me and/or Desktop Firefox? The first example shows fixed navigation/ads and flexible content, but then the article goes on to demonstrate fixed content with flexible side bars.
Which of these options does the author consider the real Holy Grail?
Which of these options does the author consider the real Holy Grail?
Flexible content is deemed a problem under the heading "The Problem".
Which of these options does the author consider the real Holy Grail?
> Once flexbox achieved mainstream browser support, this layout went from "holy grail" to "fountain drink"; it was everywhere, because it offered a great user experience, and was within reach for all developers.
> As the web has evolved, I've discovered a new aspirational layout.
> Once flexbox achieved mainstream browser support, this layout went from "holy grail" to "fountain drink"; it was everywhere, because it offered a great user experience, and was within reach for all developers.
> As the web has evolved, I've discovered a new aspirational layout.
Ah gotcha, missed that line!
How is this not solved by giving the fixed width elements margin-left & -right auto?
This layout by CSS is awesome. It makes it possible to accomodate different screen dimensions (iPad, iPhone, landscaped iPhone, widedesktop).
So, if it’s a bad design, and still makes it a pleasant readability approach, then I’m all for it.
So, if it’s a bad design, and still makes it a pleasant readability approach, then I’m all for it.
I don't like selectively making some children full bleed within an otherwise constrained container. Use full bleed containers instead imo and don't mix the two
How do you write your full bleed containers, and why do you prefer them?
Not the original commenter, but you would just write the container as full bleed and constrain the elements with-in it. That way any elements not so constrained are by default full-bleed. I'm of mixed minds which I like better, generally I prefer less elements and less nesting when possible, but there are almost always going to be wrapping elements in any mildly complex site.
I’m using Bootstrap’s approach of a `.container-fluid` class for a full-bleed container, and a `.container` class for the standard centered and fixed width container.
I’m interested in applying CSS Grid as a progressive enhancement specifically targeting browsers supporting it, and keeping what I do today for browsers that don’t.
I’m interested in applying CSS Grid as a progressive enhancement specifically targeting browsers supporting it, and keeping what I do today for browsers that don’t.
I really appreciate the clear explanation of the problem at the beginning. This halfway inspires me to go rewrite my personal website in order to accommodate full bleed.
I much preffer fluid layout so anyone can adapt the screen to their need. I'm tired of layouts who are based on the author criteria. Let me handle that.
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.
CSS Grid is horrendous to debug once it gets complex and you can’t rely on document flow any more, things can be placed anywhere which might seem big and clever but a few nested grids + the cascade and you’re quite frankly screwed. If you really must use CSS grid I say use it for the main layout and nothing else, then at least future you has a chance.
Also this is more complex than using negative margins ever was.
Also this is more complex than using negative margins ever was.
Can this be done using flex-grow?
If you subscribe to the newsletter, I highly recommend the non-stop confetti party.
1. Improved version of the "holy grail" layout:
nav
content
2. Alternately:
nav content
Unsurprisingly enough, HN uses #1.
nav
content
2. Alternately:
nav content
Unsurprisingly enough, HN uses #1.
I want wide columns.
Slightly OT, but this page has the BEST alternative for a modal newsletter pop-up I’ve ever seen. I have a personal rule that I close the tab as soon as a modal asking for my email pops up. When the cute little figure on the left _asked_ for my consent to pop-up a modal, I had to click on it because it was so cute and respectful.
This is great design that I’m sure converts as well without cheapening your brand and accosting your users.
This is great design that I’m sure converts as well without cheapening your brand and accosting your users.
And the little heart on the right smiles more the further you scroll.
I just loved that so much
Agreed. On the other hand, it probably could have done without the sound.
ah, my sound was off. That is unnecessarily intrusive.
Agreed. I subscribed to the newsletter too - I would normally never do that.
Same, well, that and the content is wonderful.
I closed the page as soon as I saw that because I assumed it was an ad that had escaped the blocker.
What information are you concerned about them harvesting that they won't have gotten just from the ad loading? I suppose time on site and stuff, but I'm not sure what bits of info you're trying to hide. Feels like a situation where you might as well enjoy the content.
I'm not "concerned" at all. It's just a personal philosophy. Especially as the pop-up was a waving cartoon character. Bad memories of Bonzi Buddy.
lol. that problem is solved decades ago. the problem have always, since the table layouts, been a decent VERTICAL bleed on top of this.
That layout was never terribly hard to implement.
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 flex box, where the children are containers at standard sizes (e.g. full-bleed, 80-characters, etc.).
Yes it adds like another tag or two, but it's semantically more sound. And from that extra markup we get a lot more flexibility, e.g. going from column layout to a slide show or something if someone wanted.
CSS Grids are good for grids i.e. layouts where you want control over flow in both axes. This is not a grid. You have one column of data where you are controlling whitespace.
This has become a real pet peeve of mine because it seems like so many people love css grid when it's actual use case is fairly rare.
Edit: I also want to add that this creates an uglier layout if you have variable width children. Because you'd essentially create a full-bleed container element just to add a non-full bleed child to it.
And I am sorry that this came across as kind of aggressive, this is something that's really been irking me with recent web dev trends. And I feel like a crazy person confused over why the world suddenly decided on Css Grid all day every day.