> and dont do stuff like hijacking the scroll, zoom or other common behaviours.

The hijacking of scrolling pisses me off so god damn much that I've considered building Firefox from source and modifying the code to completely eliminate a website's ability to set the scroll position.[0]

Front end devs, I implore you. Stop acting like you think you know what the user wants in regards to scrolling behavior. Smooth scrolling already exists natively in every browser. There's no need to try to re-implement it in JavaScript. Your implementation will not work in every browser, and will only cause strange stuttering, bouncing, or even end up somehow completely disabling scrolling altogether. Do not try to get fancy and implement "momentum" into scrolling. You're changing a well-understood behavior into something that is unexpected and jarring, and likely it won't work anyways.

Do not change the scrolling amount. My wheel sensitivity and browser setting are configured so that 1-click ~= 2.5 lines of scrolling. Do not impose your preference of 1 click ~= 1 line on me. You do not know better than me.

And disabling zooming? WHO EVEN DECIDED THAT WEBSITES SHOULD BE ALLOWED TO DO THIS?! It destroys accessibility! Sometimes there's text or an image that's just a little too small to recognize. I'd pinch to zoom in...but some moron front-end dev has adopted the beyond-bone-headed mentality of "removing features is a feature!" and makes their site tell the browser to not allow zooming because...why? Someone please, tell me why.

[0] I'm sure it's possible to write an extension that could do this, but any time you're manually setting the scroll position in code, you're bound to fuck it up. Rather just completely eliminate the ability to set the scroll position entirely.

> I don't know how useful this is.

I think very. I've never designed anything based on arbitrary breakpoints (md, lg, xl and whatever numbers they might translate to) because that forces me to make design choices around those constraints.

The only way to sanely add breakpoints in my opinion is to gradually reduce the width of your page and search for things that start looking off. Are your paragraphs starting to look a little cramped? Add a breakpoint at that width, maybe remove the sidebar, maybe lower paddings and margins to allow it to stay a little longer, maybe manually reduce font size or switch your column layout to rows if applicable. Keep doing that until you get to ~350px width and everything looks fine. You decide what needs to change when it makes sense rather than being told that something needs to change at some specific breakpoint.

> I don't know how useful this is.

The website that is the subject of this discussion comes from Andy Bell.

I would encourage you to see his other work, e.g. Every Layout[1], and the website[2] linked to a recent talk he gave[3].

In particular the answer to your question can be found at 14:38[4] in the talk, perhaps more precisely the slide he shows at 14:59.

[1]https://every-layout.dev [2]https://buildexcellentwebsit.es [3]https://www.youtube.com/watch?v=5uhIiI9Ld5M [4]https://youtu.be/5uhIiI9Ld5M?t=878

>I don't know how useful this is.

>setting breakpoints allows some sanity in the build and testing process

clamp allows for sane responsiveness

https://developer.mozilla.org/en-US/docs/Web/CSS/clamp

and if needed you can add some minimal breakpoints.

The fact is that most front end devs don't know about it, and there is no framework that I know of which is based around its use (and everything nowadays seems to be about the frameworks), thus you end up with inefficient multiple breakpoints which may seem sane until you get too close to one of the breakpoints and your design looks like crap until that point is hit and you can switch to the new values set for the breakpoint.

breakpoints are a great solution if you happen to be living and working in the web of 3 years ago. But the clamp, min, and max functions have been available in every major browser since 2020 - even Opera.

People keep telling me 3 years is an eternity in internet time, so why are there still all these damn breakpoints?

For me it really just involves squishing the browser window in all sorts of ways and see what happens, and if I get any ideas on what I would want to change. I don't see what the big deal is.

> crap (stuff that can go wrong) like animations, weird font sizes and font faces, javascript

None of these per se are the issue, and you can still have the issue with zero animations, fonts or JavaScript.

Using the data provided, I calculated the minimum window size in order to have full viewability among a percentile subset of the audience. Here are the answers:

  Mobile: 
  50% of viewports: Width 375, Height 635 
  80%: Width 375, Height 635 
  90%: Width 360, Height 560 
  95%: Width 360, Height 550 
  99%: Width 320, Height 500
  
  Desktop:
  50% of viewports: Width 1440, Height 900
  80%: Width 1024, Height 600
  90%: Width 1024, Height 600
  95%: Width 1024, Height 600
  99%: Width 800, Height 300

> setting breakpoints allows some sanity in the build and testing process otherwise you have an infinite scope for issues which of course would be pretty lucrative for a boutique agency.

Honestly, now that container queries are available, I see very little use for breakpoints. Container queries allow for easy reuse of components, and a truly fluid and responsive design.

The problem is that at a real company, this is very difficult because you have to argue with your product/design team and explain why you don't want to implement [x] feature because it's "too complex". Inevitably they'll point to some competitor website that has the same feature, which makes you look like you're just lazy. It's possible to succeed in those arguments, but it's hard.

It's one thing to convince them not to do some weird scrolljacking, but even something like a dropdown or a popover adds a ton of complexity for responsive sites.

There's one thing I absolutely will disable and that is the MFing pull to refresh. I hate that feature more than pretty much anything else about the Internet.

Users can't, for some hideous reasons that should be illegal due to accessibility concerns, disable it, and it is an excellent way to accidentally throw away your work several times a month if you don't have very steady hands, depending on if the back button decides to not restore.

Fundamental dilemma:

* The web is a great way to publish information and access a few services.

* The web is the cross-platform operating system for applications.

Everything stems from the difference in those two approaches. Both are correct.

I wouldn't say it's a hostile platform, I'd say that it's a volatile design medium. Regarding breakpoints, I've always agreed with Jeremy Keith's opinion on the subject, which in some sense is to design for the content and fix it when it breaks, but to assume that it will and test it as best as you can. Breakpoints are just a way of demarcating broken/not-broken layout. I also use them for generalizing design if I'm doing it before writing the layout in code, which you can do if you start with no assumptions as to how it will be viewed, and just choose some arbitrary constraints to move things around within, then refine when you actually have something in the browser.

I agreed with you until you went overboard with your last sentence. A "hostile" platform? What in the world? You literally just mentioned how easy it can be to avoid all this crap. There is nothing "hostile" about the web. I really don't like these overly strong statements.

If you need to get weird now, webgpu has arrived, what we really require is a dedicated demoscene on the live web ;)

Your first WebGPU app (Conway's Game of Life)

https://codelabs.developers.google.com/your-first-webgpu-app

This. Unfortunately today, the desktop is an afterthought and everything is designed for “mobile first”. I even see this in SaaS apps that should actually never be used on a phone. Or desktop OSes like windows and mac are increasingly using mobile paradigms on the desktop.

There is so much whitespace, huge fonts, huge buttons, hamburger popup menu everywhere (aaaargh!!)

Basically it boils down to the “information density” which is dumbed down to the lowest possible denominator.

There should be a measure for this and websites/apps should be rates based on that.

I'm actually not entirely sure what you're talking about.

I'm very familiar with websites switching to mobile layout with hamburger menu instead of a navigation bar, when you reduce the width of the browser window on your desktop. BUT I don't think I've ever come across a resolution change where the website elements (either hamburger menu or content) get massively larger.

Can you provide an example of one or two mainstream sites that change resolution like that?

The reason I'm confused is because in CSS everything is based on logical pixels, not actual device pixels. E.g. a "1 px" width will be 2 or 3 hardware pixels wide on an iPhone. Similarly "1 em" will be 16 hardware pixels on a standard resolution display, but 32 or 48 hardware pixels on a 2x or 3x display. So web designers don't have to do anything special to accomodate hi-DPI screens in the first place.

I know the official line is that "media types have proven insufficient as a way of discriminating between devices with different styling needs." But as far as I can tell most people really do just want to know if the visitor is viewing on a monitor or a phone. Trying to back that out through media features like viewport resolution and pointer types has been a big mess. I don't think the plan to replace media types with media features is wrong, but so far we haven't been given the right features to do what we want.

When I visit my bank, with my browser taking up half my 1080p desktop display, it tells me to use the app instead.

This is an interesting observation. Do you have some examples of this?

It doesn't work like that. Web browsers do not count actual pixels when rendering. They adjust high density pixels to the equivalent real life size of low density pixels.

I have this shaky hypothesis where the majority of UX devs today (not just web devs) grew up consuming content on smart phones, ipads, and small laptop screens. Their default way of interacting with technology is one app or web page at a time, all in maximized windows taking up the whole screen, and switching between between full-screen apps to multi-task. Perhaps this pattern carries over into their adult work, where they design sites and apps that look great when taking up the whole screen of a typical PC or tablet, but outright fail when exposed to a typical "windowed" browser width.

My normal browser width is about 1300 pixels and I see so many web sites and apps these days that can't tolerate what I consider a very reasonable browser width that this is the only explanation I can come up with.

If you’ve worked in front-end dev for a while you can be aware of all the issues.

The problem, generally, is that frontend dev is taught poorly if it’s taught at all, and the barrier to entry is so low that there’s an Eternal September problem.

Here you go:

https://i.imgur.com/9cJ13ue.png (alternative link: https://imgur.com/a/uBG5KUD)

(The area of each circle is proportional to the count, clamped to a minimum value. Axes a are linear.)

Uses the data from https://viewports.fyi/data.csv.

Code:

    import csv
    from math import sqrt
    import sys

    csv_reader = csv.reader(sys.stdin)
    headings = next(csv_reader)
    data = [tuple(map(int, row[:3])) for row in csv_reader]
    max_w = 7100 # max(row[0] for row in data) + fudge
    max_h = 7100 # max(row[1] for row in data) + fudge
    max_count = max(row[2] for row in data)

    margin = 200
    svg_width = max_w + 2*margin
    svg_height = max_h + 2*margin
    max_r = 90
    min_r = 4

    print('<?xml version="1.0"?>')
    print(f'<svg xmlns="http://www.w3.org/2000/svg" width="{svg_width}" height="{svg_height}" viewBox="{-margin} {-margin} {svg_width} {svg_height}">')
    print('<desc>Visualization of viewport sizes from https://viewports.fyi/</desc>')
    print(f'<rect x="{-margin}" y="{-margin}" width="{svg_width}" height="{svg_height}" fill="white"/>')

    print(f'<line x1="0" y1="0" x2="{max_w}" y2="0" stroke="black"/>')
    print(f'<line x1="0" y1="0" x2="0" y2="{max_h}" stroke="black"/>')
    for i in range(0, max_w, 200):
        print(f'<text font-size="64" font-family="sans-serif" x="{i}" y="-30" text-anchor="middle">{i}</text>')
        print(f'<line x1="{i}" y1="0" x2="{i}" y2="-20" stroke="black"/>')
    for i in range(0, max_h, 200):
        print(f'<text font-size="64" font-family="sans-serif" x="-30" y="{i + 20}" text-anchor="end">{i}</text>')
        print(f'<line x1="0" y1="{i}" x2="-20" y2="{i}" stroke="black"/>')

    print('<g fill="blue" stroke="darkblue">')
    for w, h, count in data:
        r = max(min_r, sqrt(count) / sqrt(max_count) * max_r)
        print(f'<circle cx="{w}" cy="{h}" r="{r}"/>')
    print('</g>')
    print('</svg>')

> and slightly fewer people are designing entire websites in Photoshop & Illustrator alone

Across the wide industry, sure, but I haven't worked with a designer who uses Photoshop in 10 years...

Granted, I'm in my own bubble, but over a varity of gigs it's been Sketch, and now universally figma.

I've started doing frontend work back in 2008, and I immediately noticed the friction with designers coming from Adobe tools and their equivalents. It's disheartening to see that 15 years later the problem is still there

I'm going to change your life: https://github.com/t-mart/kill-sticky

It's a bookmarklet that gets rid of sticky elements. It nukes those stupid fucking headers and footers and kills most cookie banners and "give me your email" type pop-ups. Works in every browser (I use it in Safari on iOS and Firefox on desktop). I almost reflexively go hit this bookmarklet on every website now. It makes the web so much better.

> no way to dismiss or shrink them

You can shrink them by rotating your phone back to the correct, portrait orientation.

Such meaningless comparisons also often have the opposite of the desired effect. I read it and went "there are >8 billion people all over the planet, and you can fit all the possible viewports into a single football stadium. Neat!"

> I think people know how big 120.000 is, but if you must, just say its more than wembley

Agreed. And if you must compare to a stadium, why not just pick a bigger stadium? You can pack at least 115,000 into Michigan Stadium, which would get you a lot closer than Wembley.

(What's that you say? You've never been to Michigan Stadium? That's probably another reason not to rely on this kind of comparison! I, for example have never been to Wembley and have no idea how big it is.)

Also, working in an industry with a lot of data, 120k isn't a lot