Hacker News Reader

Comment by 5350-uiop-1130 | Hacker News Reader

> "The main point we’re trying to get across is that you simply do not know how users are going to visit your website or web app. Instead of making design decisions on strict, limited breakpoints, keep in mind the sheer amount of fragmentation there is in viewports."

I don't know how useful this is.

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.

> "This goes all the way back to planning your projects too. When mapping out page content, ask yourself how it will be for the weird viewport sizes that don’t fit the typical mould? Always try to simplify and condense content to make it useful for everyone."

it's really not that complicated. keep the amount of crap (stuff that can go wrong) like animations, weird font sizes and font faces, javascript to a minimum. and dont do stuff like hijacking the scroll, zoom or other common behaviours. just dont do anything unless you absolutely have to.

but thats why the web is such a hostile platform. difficult to manage high user/client expectations with pragmatism.

View on HN

> 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.

> And disabling zooming?

I had a weird experience with Google Groups recently - I zoomed in because the text was too small and ... the page resized the viewport to its original pixel size even though the font was scaling. Ended up with about 10 characters in an unscrollable viewport. HILARIOUS.

I had the opposite problem with a web page the other day. When I zoomed in, the text resized itself to still fit the same amount of text in the viewport, but since other elements would zoom correctly, the more I zoomed in, the smaller the text got.

Yes, I see this paradoxical zoom behavior all the time.

Alternate horror scenarios that are all too common:

Zoom only to have one picture take over the whole page, pushing text off the side (not even down, off screen to the side).

Zoom only to have the text immediately become wider than the screen, forcing you to scroll sideways for every single line.

> And disabling zooming? WHO EVEN DECIDED THAT WEBSITES SHOULD BE ALLOWED TO DO THIS?!

Applications such as maps, image editors, presentations, and flowcharts benefit from having control over zoom. (And you'll notice that almost every one of them does.)

This of course is only one difference of many between "documents" and "applications" and the web is being used for both.

Maps drive me fucking nuts, taking over zoom. As do nearly every other app that does it. They think they know what's good for me, and they don't, and it leads to me using them less. Yes, paper maps just work better for me a lot of the time.

The only thing maps.app or Google maps are good for are finding places to spend money or driving to places to spend money. If you have any other spatial interests, they're almost pointless.

I would happily run a build that removes this capability.

I would love to see your maps app that doesn't touch zoom.

No offense, I had to try that..

https://upload.wikimedia.org/wikipedia/commons/3/3d/LARGE_el...

Look how fast and responsive it is!

With progressive decoding and spatial range requests this could actually be a reasonable replacement for a slippy map.

I'll use it on my drive home.

That supports touch zoom just fine, it just has a low limit to how far in it goes.

Obtaining the zoom level is an adventure worse than implementing multi-touch-twist-and-shout-zoom from scratch.

No, they benefit from overriding the pinch gesture or the scroll wheel. Browser zoom shouldn't need to be a casualty for those features to work, it ought to stay available in some form.

Yes, that's what people mean.

Browser zoom cannot be overridden.

Yes it can be, with the viewport meta tag. I've also seen some web apps, mostly maps, whose CSS or JS tries to resist browser zoom in ways that break the layout or make them unusable.

Plus, overriding the zoom gestures makes it really hard in mobile browsers to access the actual browser zoom, although I blame that on browsers.

yes you're right. we have a map with a toolbar at the top of the screen. when zoom was enabled people were constantly zooming in preventing them from being able to see some or all of the buttons hindering their ability to use the app. and causing confusion because they didn't realize they were zoomed in. as soon as we disabled zoom the complaints and questions stopped.

setting just the toolbar to not zoomable should have been the obvious solution.

(In stead I have to disable zooming in on images to preserve the next/previous/close buttons and implement zoom from scratch. wtf?)

> 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]

That'll break just about every cloud logging UI I'm aware of, but what you do to your own UA is your business.

You're mad at the wrong people here. I've never met a frontend dev who doesn't hate moving stuff vertically or scrolljacking. It's the marketing people that want it.

The one that hurt me the most was making a page that started at the bottom and scrolled up. I left a comment somewhere in the JavaScript apologizing for it.

I really want to know what was the reasoning they gave you to do that

> 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.

For sites that have no business disabling zoom: no idea, and it annoys me too. I just chalk it up to dev, designer and/or managment incompetence, close the tab and never return again.

/Moron frontend dev

As the poor sap who’s had to build lots of these types of sites, I’ll tell you that it’s not the devs that want this. It’s the damn client that keeps complaining about the “gravity” or the “momentum” or the “scroll speed” of the site. Locomotive.JS being the main thing clients want us to use… no amount of explanation of all your valid points will persuade them if “this one cool site we like had it”.

I will say this… the scroll speed being different between Chrome, Safari and Firefox doesn’t help our cause… wish these were normalized at the very least so we can avoid “it feels better in X, but we use Y browser” notes.

Allowing an easing function API for scroll would be a middle ground I could live with. It’s better than what we have now (a bunch of award winning sites emulating scroll with translates).

Do you feel the same way about scroll-enabled menus? I had to implement a menu recently (similar to the one on https://getbootstrap.com/docs/5.3/getting-started/introducti...) and my first draft used traditional anchor-to-id links.

It was very jarring and also felt weird being flush with the top - we added a jQuery smooth scroll to go to just a little above the item in a few hundred ms and it felt much better. I say this as someone who generally hates scrolljacking and custom scrollbar rendering on sites.

In pay experience, scrolljacking happens after front end devs are told to implement it by the designers and the designers are told they must do it by the marketing people who in turn have been begged by both the front end devs and the UX team and. The design team to please record wider this insane decision - but insisted on it anyway.

I have a collection of articles and studies and discussions on scrolljacking that I show to the business stakeholders when it comes up.

I make sure thy hear from multiple parties independently when such an idea starts making its way toward implementation.

But it is exhausting because trendy flashy websites still use the technique and do catch the eye and I have to explain why we can’t and should not have the shiny toy - despite big brand x y or x having it.

In which process I am saying no to the very people deciding on my bonus.

Just a bit of perspective.

> 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.

Smooth scrolling can cause motion sickness because it doesn't perfectly match up with the action. Javascript versions make it even worse because the ratio is pretty much guaranteed to be off from the user's normal scroll amount, particularly with a mouse or touchpad.

It's not that bad for me, but I do disable it wherever possible because I find it disorienting. Can't do that with javascript implementations.

> Do not impose your preference of 1 click ~= 1 line

excuse me, but no designer ever gave audience to such a sensible suggestion

> 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.

That's a fine (and arguably superior) philosophy for a simple personal site.

But it just isn't practical for a commercial product that needs manual testing. If you have a single breakpoint, you only have 2 versions to test. If you ultimately have 30 different breakpoint values, that's 31 versions to test. And that's a lot of opportunity for CSS rules designed in isolation to wind up colliding with undesired results.

Not to mention a nightmare for any designer to attempt to document expected behavior.

But your site can be broken at different sizes even without breakpoints. From a QA perspective with manual testing, there's no difference whether or not developers have used breakpoints, the question is whether the application is working for the users' screen sizes. And, as the article points out, they are myriad.

To test that the responsiveness works everywhere, the easiest thing is to probably go to the "responsive" tool in the browser's devtools, which opens the page in a little subwindow inside the main browser window, and then you can resize the subwindow freely to check a range of different sizes (rather than just an explicit set of them).

> 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?

it seems much cleaner to give each size its own css?

> why are there still all these damn breakpoints

they're simple, easy to understand and well tested.

looking at clamp it smells of over engineered complexity. 3 arguments. difficult to visualise.

margin, padding, box sizing, line-breaks, non-breaking spaces that can all impact how text flows and wraps - clamp is stacking on top.

most css is written, forgotten and ime never refactored. so what's fast and dirty often is good enough, within reason.

>looking at clamp it smells of over engineered complexity. 3 arguments. difficult to visualise.

although you can use clamp to do complicated things that are difficult to understand, as is the case with all technology the simplest way to use it is quite clear.

(static minimum size you want for something, percentage of something, static maximum size you want for something)

thus width: clamp(100px, 80vw, 750px)

and now someone says well why wouldn't you just do min width max width etc. with that - no reason it's just nicer to have it one line to see IMO. But of course you can put clamp anywhere you can calculate anything so.

margin-left: clamp(20px, 5vw, 50px)

margin-right: clamp(var(--minmarg),var(--margpercent), var(--maxmarg))

then you change your minmarg, margpercent, maxmarg as needed by normal css variable rules.

This should be an easy to understand system for a developer. It is easy enough for me to understand and visualize, and I suck at visualization.

This allows one to finally get rid of most breakpoints and say not just what the min and max heights and widths are of things but what the min and max and preferred margins, paddings, font-sizes etc. are of things - which without that IMO the max height and max width is just sort of stupid. But with that you can make designs flow and look good in a manner that can actually be described as 'responsive'

Now as I said - one can do all sorts of complicated and clever stuff on top of this sure. And if people do that they might end up with something that is difficult to reason about.

But if people can't reason about the margin example above then I think they should probably switch from Frontend development.

on edit: grammar change.

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

I've been using a min width of 320px lately due to some unusual displays, mainly on vertical flip phones with super-tall screens. That justifies my insanity. Thank you.

> 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.

IMO the promise of container queries isn't that breakpoints will go away, but rather that breakpoints can emerge from the bottom-up composition of components rather than top-down from your CSS framework or Tailwind config or whatever.

You're still probably going to want the left sidebar of your multi-column layout to collapse behind a menu on narrow viewports and abruptly appear when the viewport width gets to >= n [0]. But it's conceivable that the value of n emerges from some constraints you specify (such as the minimum desired width of the sidebar and the main content column), instead of being chosen upfront from a small list of predertmined breakpoints.

[0] E.g. https://tailwindui.com/components/application-ui/application...

While I suppose breakpoints might still have some use cases, I believe an overwhelming amount of the stuff we currently use them for can be better and more fluidly accomplished with container queries.

The example you give of a sidebar collapse with a menu button replacement can easily be accomplished with a container query on the wrapping box, no?

I'm honestly curious about a use case that a media query breakpoint can handle, but which a container query can't.

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.

If your company cares one iota about accessibility, you can usually get those features off the table instantly just by arguing that point. "Yeah, well it's pretty clear that competitor doesn't care about blind people" is a pretty easy argument.

I invite you to learn to use a screen reader and try using your app (whatever it happens to be). It's seriously pretty terrible for some of these websites with all the fancy crap.

I envy you cause the teams and companies that I've worked with basically say fuck em to that argument.

I have lost jobs and annoyed people trying to argue for greater care with accessibility. It's somewhat depressing.

This is exactly what happens. Especially if your voice is in the minority Or you’re the only one. You’re seen as a trouble maker. We all know what happens to trouble makers when margins are on the line.

I just stab them in the eyes and then say "now you'll care about blind people," then calmly walk away. Works every time. /s

In all seriousness, I ask something similar to the above: "Would you feel the same way if you got in an accident that left you blind for the rest of your life?" Sometimes this moves a few people to your side. I don't want to be the only one, but I do care about accessibility. I care a lot, for personal reasons. But like you said, you don't want to be the minority trying to support minorities.

I think there are some laws which require a certain degree of accessibility for at least government websites. And if your big company deals with government, they'd better think about that.

Another comment suggested you try to appeal to empathy. It might work, it might not.

If it doesn't you can instead appeal to the bottom line. Tell 'em that they might get targeted by an accessibility troll: https://www.wrightlawgroup.com/blog/attack-of-the-ada-trolls

As far as trolls go, I consider these fairly benign, as their behavior actually promotes something good; we got hit with such a lawsuit, and all of a sudden a11y became a big thing as our CEO didn't want to give a dime to those 'greedy assholes'.

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.

If a website allows you to throw away a lot of work by accidentally refreshing the page, it's poorly written. There are multiple ways to deal with this: a warning, a confirmation prompt, storing data in sessionStorage, etc.

None of which HN appears to do... ideally you're right, it shouldn't be possible, but disabling pull to refresh helps a lot on a crappy legacy site.

Plus it's also just plain annoying. If a site has no well defined concept of pages, you'll probably be in a whole different dynamically generated page. Not that I think sites like that are all that great to begin with...

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.

No, only the first is correct. The second is, still, an ugly kludge.

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

Reply on news.ycombinator.com