[HN Gopher] Full-Bleed Layout Using CSS Grid
___________________________________________________________________
Full-Bleed Layout Using CSS Grid
Author : feross
Score : 424 points
Date : 2020-10-05 15:42 UTC (7 hours ago)
(HTM) web link (www.joshwcomeau.com)
(TXT) w3m dump (www.joshwcomeau.com)
| agumonkey wrote:
| 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.
| darepublic wrote:
| 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
| ihuman wrote:
| How do you write your full bleed containers, and why do you
| prefer them?
| neon_electro wrote:
| 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.
| LocalPCGuy wrote:
| 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.
| uallo wrote:
| > 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 .wrapper h1, .wrapper
| p {}
|
| or soon .wrapper :is(h1,p) {}
|
| Alternatively, you can also use .wrapper >
| :not(.full-bleed) {}
|
| And in SCSS (or similar) you can write .wrapper
| { h1,p {} }
|
| (edit: Earlier versions of this comment mentioned :has instead of
| :is)
| pupppet wrote:
| 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]
| joshwcomeau wrote:
| 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.
| krsdcbl wrote:
| 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!
| JoshTriplett wrote:
| :has is not supported in any browser, and that seems unlikely
| to change, for performance reasons. https://caniuse.com/css-has
| uallo wrote:
| Sorry, I meant :is (which is already supported in some
| browsers).
| err4nt wrote:
| You can support :has(), and things like it yourself via
| client-side JavaScript styling runtimes well enough.
| MVorlm wrote:
| 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.
| Atomskun wrote:
| 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.
| Rusky wrote:
| 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.
| dmlittle wrote:
| 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?
| uallo wrote:
| Don't apply the max-width on the container but on selected
| children only.
| enkrs wrote:
| I guess it's time for bettermotherfuckingwebsite.com gridless
| version to hit HN :)
|
| This is not really CSS magic: main>*{max-
| width:65ch;margin: 1em auto} .full-
| bleed{width:100%;max-width:none}
| chrismorgan wrote:
| 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).
| rattray wrote:
| Not only is this a nice technique, it's also a nice introduction
| to several key CSS Grid concepts.
| mfincham wrote:
| 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]
| aembleton wrote:
| What do you display on the rest of your screen? Doesn't it
| distract you from what you are reading in your browser?
| mfincham wrote:
| Just whatever other software I'm using. Usually terminal
| windows, sometimes text or graphics editor, e-mail client.
| That kind of thing.
| baxtr wrote:
| 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
| akersten wrote:
| 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.
| commandlinefan wrote:
| > 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.
| daveilers wrote:
| 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)
| akersten wrote:
| 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
| bobthepanda wrote:
| 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/
| stjohnswarts wrote:
| 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.
| [deleted]
| qvq wrote:
| 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
| leksak wrote:
| You could probably write an article that'd be very often read
| if you teach CSS from this perspective.
| akersten wrote:
| 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.
| hombre_fatal wrote:
| > 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.
| rimliu wrote:
| 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.
| aarpmcgee wrote:
| 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.
| bobthepanda wrote:
| 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.
| stjohnswarts wrote:
| 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 :)
| akincisor wrote:
| 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.
| giantrobot wrote:
| The differences in how different engines/platforms behave
| definitely does not help when doing any non-trivial layout.
| wilsonrocks wrote:
| I think a _lot_ of this is standardised now in the vast
| majority of browsers people use.
| bobthepanda wrote:
| 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.
| wilsonrocks wrote:
| 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.
| bobthepanda wrote:
| Even just IE11 is pretty bad given the state of grid and
| flexbox on IE11.
| wilsonrocks wrote:
| Yeah, grid is pretty much not worth it imo, as you have
| to do so much differently. You can make flexbox work
| though.
| giantrobot wrote:
| 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.
| wilsonrocks wrote:
| 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.
| stormbrew wrote:
| 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.
| shaftway wrote:
| 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.
| animationwill wrote:
| > 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
| doinathing wrote:
| 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?
| preommr wrote:
| I hate that people use CSS Grid like this. For some reason, I see
| so many people reach for CSS Grid like it's the de facto solution
| for responsive design.
|
| This is a bad design because you're tying the child elements to
| the grid layout of the parent. If you added an extra column in
| the grid, you'd have to go and adjust it for the full bleed
| elements.
|
| IMO a better solution would've been to just use a column layout
| with 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.
| exogen wrote:
| 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.
| highwind wrote:
| This reminded me of days where we used <table> to do layout.
| tekkk wrote:
| 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.
| ss3000 wrote:
| 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.
| =_=
| asddubs wrote:
| 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
| bigbubba wrote:
| 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.
| sergeykish wrote:
| 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.
| aembleton wrote:
| Easier to just use Reader View
| MrBuddyCasino wrote:
| I stopped reading the article because of this. Highly
| offensive.
| remram wrote:
| 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?
| aembleton wrote:
| Because I have many tabs open that I am switching between. Some
| of them work better in full screen and others need less space.
| roelschroeven wrote:
| 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.
| ryandrake wrote:
| > 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
| remram wrote:
| 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.
| throw_m239339 wrote:
| 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.
| pkulak wrote:
| 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.
| hardwaregeek wrote:
| I find it really frustrating when project runners refuse to
| acknowledge shortcomings. I'm not always expecting them to
| solve it, but I'd at least like an acknowledgement that the
| issue I'm facing is valid. Pretending it's just me or that the
| obviously worse alternative is okay gets annoying.
|
| One example is ReasonML's async story: Q:
| What's BuckleScript's async story? A: If you're
| not interfacing with any library that 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.
|
| IMO that's a less than ideal response. I'd prefer a more honest
| response like:
|
| 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".
| ducaale wrote:
| 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...
| andrewingram wrote:
| 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.
| dsego wrote:
| 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
| mattigames wrote:
| 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.
| andykx wrote:
| Funny, I was just struggling with this yesterday in an
| assessment I was given for a new job.
| hombre_fatal wrote:
| 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.
| krsdcbl wrote:
| 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.
| bigbubba wrote:
| 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._
| svnpenn wrote:
| 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.
| aembleton wrote:
| Interesting. I don't see the screen turning white on Firefox 81
| svnpenn wrote:
| Its been implemented since Firefox 69 (I am using older
| version). But regardless, its part of a draft spec, shouldnt
| be used on a public website IMO.
| andy_ppp wrote:
| 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.
| awake wrote:
| 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
| bhl wrote:
| 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.
| svnpenn wrote:
| > https://www.gwern.net/About
|
| what the hell, its like someone vomited CSS on that page
| nessunodoro wrote:
| If you subscribe to the newsletter, I highly recommend the non-
| stop confetti party.
| ddevault wrote:
| I have a much simpler approach which works on browsers going back
| 10+ years:
|
| https://mirror.drewdevault.com/margins.html
| reidjs wrote:
| 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.
| indentit wrote:
| 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`...
| 1-more wrote:
| If you're printing a resume 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 resume unless you
| (re)enter academia, and the learning curve is a bear. But
| your resume 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/
| diroussel wrote:
| 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: 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; }
|
| It's ok. But the infobox isn't right. It takes up too much space
| from the main column.
|
| Anybody got a better layout?
| mattacular wrote:
| 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.
| spurgu wrote:
| From what I've understood it's already rolling out in small
| steps.
| aembleton wrote:
| I like using Wikiwand. For example:
| https://www.wikiwand.com/en/Hacker_News
| notatoad wrote:
| is there a reason this is better than just putting a max-width on
| your paragraphs, and margin:auto?
| laksdjfkasljdf wrote:
| lol. that problem is solved decades ago. the problem have always,
| since the table layouts, been a decent VERTICAL bleed _on top_ of
| this.
| neogodless wrote:
| 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?
| aembleton wrote:
| 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.
| neogodless wrote:
| Ah gotcha, missed that line!
| sp332 wrote:
| Flexible content is deemed a problem under the heading "The
| Problem".
| enkrs wrote:
| 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?
| krsdcbl wrote:
| 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.
| justusthane wrote:
| I think part of it is that there are probably lots of
| additional items that you want to constrain to the main column,
| so your CSS would end up looking more like:
| #content p, h1, h2, h3, nav { .. }
|
| Kind of a pain to manually specify each element that you want
| to constrain, when it's most of them. This approach allows you
| to instead target the items that you _don 't_ want to
| constrain.
|
| Additionally, as a more specific 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.
| uallo wrote:
| Then use something like `#content > :not(.full-bleed) { .. }`
| akersten wrote:
| Still not sure I get it. CSS makes it very easy to carve-out
| elements because of selector specificity.
| .content * { max-width: 65ch; margin: 0 auto; }
| .content img { max-width: 100%; width: 100%; }
|
| It's a neat demo of CSS Grid, for sure, but the above would
| be my much preferred way of doing this kind of layout. Maybe
| if there were a need for elements (quotes, callouts, etc.) in
| the side columns alongside the content, then it makes more
| sense to use Grid.
| vbernat wrote:
| You would get a ragged left margin if you have elements
| less than 65ch wide.
| krsdcbl wrote:
| you actually wouldn't, as these smaller elements still
| get centered by the auto margin
| akersten wrote:
| 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.
| iamben wrote:
| 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; }
| typon wrote:
| Can this be done using flex-grow?
| dunnevens wrote:
| 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.
| glitcher wrote:
| 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.
| jayparth wrote:
| Agreed! It's very well written -- I noticed that immediately
| too
| zamalek wrote:
| > 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.
| jarek83 wrote:
| Whoa - your website eats 40% of quite recent Macbook Pro' CPU. It
| looks cool at the same time! Great content!
| acomjean wrote:
| 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..
| pier25 wrote:
| Why even use grid when you can solve this much easier without it?
| onion2k wrote:
| 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.
| grumple wrote:
| 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
| pier25 wrote:
| I don't disagree but it seems like you're avoiding my
| question.
| sntran wrote:
| How would you do this otherwise?
| e1g wrote:
| A simple implementation that works on IE8
| https://twitter.com/e1g/status/1313178559234609153
| pier25 wrote:
| That's exactly what I was thinking about
| sntran wrote:
| What about inline or inline-block children, such as an
| aside, a TOC. You are assuming every children is a block.
| That is not always the case.
| sntran wrote:
| Nevermind, it's the same with Grid.
| pier25 wrote:
| Couldn't you just group all inline-block elements inside
| a block element?
| k33n wrote:
| That layout was never terribly hard to implement.
| ryandrake wrote:
| > 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.
| LocalPCGuy wrote:
| 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.
| roelschroeven wrote:
| 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.
| Jach wrote:
| 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
| LocalPCGuy wrote:
| 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.w
| ikia.nocookie.net/__cb20060729105544/psychol...
| ryandrake wrote:
| 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.
| benfrain wrote:
| 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
| Perizors wrote:
| I don't know why but this page is using 100% CPU and making my
| fans go through the roof in Safari.
| skyo wrote:
| 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.
| spurgu wrote:
| Same, around 40-50% CPU in Brave (MacOS), and the article is
| more or less useless with JS disabled.. tth_tth
| Perizors wrote:
| Yeah, disabling JS fixed it but then you can't see any of the
| code snippets.
| spurgu wrote:
| This seems to work nicely: https://archive.is/YjDHQ
| frosted-flakes wrote:
| 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.
| tylershuster wrote:
| Yes, I always have to play around with some variant of
| margin: 0 calc(50vw - 50% - 1rem);
|
| or something, which feels really hacky.
| jszymborski wrote:
| 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.
| LeoPanthera wrote:
| I closed the page as soon as I saw that because I assumed it
| was an ad that had escaped the blocker.
| SketchySeaBeast wrote:
| 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.
| lukeramsden wrote:
| And the little heart on the right smiles more the further you
| scroll.
| typon wrote:
| I just loved that so much
| remram wrote:
| Agreed. On the other hand, it probably could have done without
| the sound.
| jszymborski wrote:
| ah, my sound was off. That is unnecessarily intrusive.
| amanzi wrote:
| Agreed. I subscribed to the newsletter too - I would normally
| never do that.
| davidandgoliath wrote:
| Same, well, that and the content is wonderful.
| sntran wrote:
| 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
| dylan604 wrote:
| 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
| nimih wrote:
| I got the same flickering in FF 81, OS X 10.15. It only
| happened when the stars were on-screen.
___________________________________________________________________
(page generated 2020-10-05 23:00 UTC)