Hacker News Reader

Comment by FrontAid | Hacker News Reader

I agree with the general sentiment.

> What can the web designer do?

Completely disagree with this section.

Each of the suggested device categories (Desktop/laptop, Tablet, Phone) has many different screen sizes/resolutions. And all of them might have screens in landscape or portrait mode. All of these devices might support multi-tasking with varying split screen sizes. All of those devices support custom accessibility configurations for font-sizes, zooming or both. By detecting the UA and trying to shoehorn it into a certain category, you only increase the number of issues for the users.

One part of a solution to this problem is to use relative CSS units. Avoid hard breakpoints whenever possible. Only break columns into rows when there is no more space left.

View on HN

> One part of a solution to this problem is to use relative CSS units. Avoid hard breakpoints whenever possible.

This is what "responsive design" used to mean. I remember being quite confused when people started using it to refer to distinct, non-responsive mobile-vs-desktop views.

Yeah, the advent of CSS frameworks introduced the concept of a relatively small number of global breakpoints. The consequence of this was that at certain widths, typically some figure meant to represent a change on form factor (mobile, tablet, laptop, desktop), there'd be dramatic layout shifts.

For a long time I resisted this, opting instead for more surgical introduction of a breakpoint, literally at the _point_ where some part of a page's design _breaks_ (not really the etymology of the word, but it's fun to think of it this way). But it's felt like a decade-long battle against the momentum of the industry, and sometimes I just want to build things rather than fight.

I agree with you in principle. But having many different breakpoints that are accurately defined at exact widths leads to one huge practical downside: the number of possible combinations of website element versions skyrockets. I have found this to quickly lead to a situation where it is no longer practical to test all combinations.

A small number of global breakpoints can be a better trade-off when it means the website works better (for most people).

I think you're definitely right. It's possible that container queries may open up new possibilities that resolve the tension between the two approaches.

Or, you know, use CSS Grid.

This feels a little snarky, and somewhat tangential.

I've been using CSS Grid for years as my default layout method, but it doesn't magically solve all issues.

It pretty much does, though. It’s just the syntax is horrible.

Looks that approach it would be a hell to maintain. In special if it's a big web app.

I prefer having a few fixed well defined breakpoints that having a combination explosion of places to fix and widths that I have to control when I do a changed on a component.

Yeah, that was confusing to me, too. I saw the article's first example and thought, "Well, that's not really responsive design, that's switching between two entirely different views!"

On my personal site I do indeed have a media query to make some tweaks when the viewport is phone-in-portrait-orientation narrow, but I try to keep them pretty minimal. I find sites that reorganize themselves at different widths ("if your browser window is 2000px across, this is a three-column display instead of two!") to be…not necessarily bad, but at best, unnecessarily clever.

I guess that's bootstrap's legacy: they implemented a grid in precisely that annoying way. Not that you have to use it like that, but the temptation seems to be considerable.

> This is what "responsive design" used to mean. I remember being quite confused when people started using it to refer to distinct, non-responsive mobile-vs-desktop views.

I agree this is confusing, but I think we still need a term for distinct types of views. The point of the article is that, once a user has started using one particular view, it shouldn't suddenly change to a completely different view with a different layout just because the user's browser window got resized by a few pixels.

I don't think it's possible for an app to auto-detect which view the user wants to use, particularly not if the auto-detection logic allows changing views on the fly in the middle of a user session based on resizing the browser window. I think the only real solution is to have different views that each have their own distinct URL, so the user can choose which view to use. Each view can then be "responsive" within the general constraints of the layout it adopts.

I have heard that called adaptive design.

It's not strictly defined but usually I've heard serving distinct mobile web pages (or layouts) as adaptive design

> One part of a solution to this problem is to use relative CSS units. Avoid hard breakpoints whenever possible. Only break columns into rows when there is no more space left.

While the web still lacks in certain areas to accomplish this with CSS, there are many new techniques with grid and flex that allow very little use of media queries to reflow the content.

When using break points, or media queries, I don't think you should abide to a constant set. While relative units might solve certain situations, it's not a complete solution.

Using constant set of breakpoint sizes is what causes these bizarre jumps from a "wow this is a very stretched out mobile site." By using grid and flex and things like auto-fit, minmax(), etc will get you part of the way today. After you still need to use breakpoints to handle edge cases. These should always be set only at the point they are actually needed, not a fixed "this how wide phones kind of are." This way when the page is resized you have a fluid adjustment of content that only reflows automatically (with grid and flex) and at strategic breakpoints for edge cases. So regardless of the device it will flow more smoothly according to your site's content, rather than just 5 different screens (breakpoints).

> One part of a solution to this problem is to use relative CSS units. Avoid hard breakpoints whenever possible. Only break columns into rows when there is no more space left.

Not sure what you mean. What does "no more space left" mean in practice, and how do you detect it with CSS?

Assume you have a number of cards organized in rows and columns. You could define how many columns to show between each breakpoint using several media queries. However, a better approach would be to use a flex container with `flex-wrap:wrap`. Specify `flex-basis` for its children and the browser will automatically wrap them accordingly. No break points needed.

That makes sense, thanks; although I am still not sure it's applicable to the case described in the article, where the author was complaining of the layout grid that changed a three-column layout to a single-column layout. Assuming that we use CSS grids for layouts, and grid's cells don't wrap, I can't imagine how one can manage without a media query that will change the number of the grid's columns. Which will cause an abrupt change in the layout, which is, if I understand the author correctly, something he doesn't like.

Use a float grid which may flow ugly, or native CSS Grid which allows child elements to dictate their own min- and max-sizes.

I agree with your sentiment.

But instead of just using CSS units, you can use hard breakpoints, but not for the whole site. Each UI elements needs to be tailored based on width and height of a browser, you cannot bucket everything.

The best way to accomplish this is container queries, which are just starting to show up in browsers. Essentially, you define breakouts based on the dimensions of individual elements, not the full browser window. https://css-tricks.com/say-hello-to-css-container-queries/

Sounds like they just dropped in Chrome Canary, so this is very, very early. That typically means it'll take years for it to be supported in all browsers or 99% of browser versions in use. Is there a polyfill solution for this in the meantime?

Container queries have been suggested for a while now, it is not a new idea. But it has gained a lot of momentum recently, for example [1]. So maybe it will not be years until all modern browsers might support it. Until then, you might want to try [2] (not a polyfill, but a workaround with JavaScript).

[1] https://github.com/w3c/csswg-drafts/issues/5796

[2] https://philipwalton.com/articles/responsive-components-a-so...

Not to mention watches and TVs

Reply on news.ycombinator.com