Full-Bleed Layout Using CSS Grid
joshwcomeau.com
joshwcomeau.com
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.
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.
And what a surprise, it's just Safari holding us back again. =_=
edit: oh and i guess now that i upvoted it it's not grey anymore xD
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.
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.
Pick some other phrase for "most popular"
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.
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.
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.
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.
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.
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.
(I agree with you on this simple layout)
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..
> 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.
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.
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 :)
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 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 ;)
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 don't understand this.
You can appreciate something while still acknowledging its obvious flaws, nothing is perfect.
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.
> > 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.
>> 21st century capitalism a wealth concentration problem
> No you're wrong because communism is terrible.
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".
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.
[1] http://jobjo.github.io/2019/04/24/ocaml-has-some-new-shiny-s...
https://github.com/rescript-lang/ocaml "This branch is 387 commits ahead, 5444 commits behind ocaml:trunk"
If they are semi-serious, then "cromulent" would be a better synonym for "(marginally) acceptable."
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.
Yes it does. You can use
.wrapper h1, .wrapper p {}
.wrapper :is(h1,p) {}
.wrapper > :not(.full-bleed) {}
.wrapper { h1,p {} }
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.
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!
p { max-width: 65ch; }
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.
#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.
.content * { max-width: 65ch; margin: 0 auto; }
.content img { max-width: 100%; width: 100%; }
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 :/
.content { width: 65ch; margin: 0 auto }
.content .full-bleed {
width: 100vw;
margin-left: calc((65ch - 100vw) / 2);
} .content {
max-width: 85ch;
width: 100%;
margin: 0 auto;
}
.content img,
.content .full-bleed {
width: 100vw;
height: auto;
padding-left: 50%;
margin-left: -50vw;
}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.
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
Also the "cascading" nature of CSS makes it hard to reason about.
Safari and IE are the big bugbears in my experience.
I stand by my comment if you don't have to do IE < 11 though.
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.
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.
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.
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.
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
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 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".
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?
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.
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.
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.
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)
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
I want to implore everyone on HN to not be one of those people
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
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 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.
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.
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.
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.
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.
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 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.
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.
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.
https://medium.com/@panuviljamaa/why-css-is-difficult-a2cdf0...
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/
margin: 0 calc(50vw - 50% - 1rem);
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`...
Protips: \usepackage[garamond]{mathdesign} sudo getnonfreefonts --sys -a
https://ctan.org/pkg/mathdesign https://tug.org/fonts/getnonfreefonts/
[1]: https://meyerweb.com/eric/thoughts/2020/07/01/accordion-rows...
what the hell, its like someone vomited CSS on that page
Hmmm. That had really not occurred to me. A great post for this little gem alone.
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?
Edit: he is using ResizeObserver:
https://developer.mozilla.org/Web/API/ResizeObserver
which hasnt made it past draft JavaScript specification.
I'm now off to learn more about this magical "ch" unit.
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.
Delete StandardLayout__GradientWrapper, it served no useful purpose, it only pisses people off.
"ReferenceError: Can't find variable: ResizeObserver"
Works fine in firefox. Diabling javascript in safari works, excepting some images don't load..
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?
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.
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).
That is the way your preferences affect me.
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.
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, (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.
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...
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.
As a matter of fact, that would require even less attributes to work compared to the method presented in the article.
This is not really CSS magic:
main>*{max-width:65ch;margin: 1em auto}
.full-bleed{width:100%;max-width:none}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).
</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.
[1] some segment of the SF Bay Area photography community circa 2010
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.
Is there any actual research on this number?
FF 80.0.1 MacOS 10.14 (yeah it's old)
https://ethanmarcotte.com/wrote/css-grid-without-max-width/
Used that one myself here: https://rwd.education
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?
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.
So, if it’s a bad design, and still makes it a pleasant readability approach, then I’m all for it.
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.
Also this is more complex than using negative margins ever was.
nav
content
2. Alternately:
nav content
Unsurprisingly enough, HN uses #1.
This is great design that I’m sure converts as well without cheapening your brand and accosting your users.