6 ms·

> "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 decis

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

johnnyworker 3y ago
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.
smarkov 3y ago
> 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.
- crazygringo 3y ago
  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.
  - MrJohz 3y ago
    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).
danielvaughn 3y ago
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.
- withinboredom 3y ago
  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.
  - hagg3n 3y ago
    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.
    - esdott 3y ago
      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.
      - withinboredom 3y ago
        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.
traceroute66 3y ago
> 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 https://every-layout.dev [2]https://buildexcellentwebsit.es https://buildexcellentwebsit.es [3]https://www.youtube.com/watch?v=5uhIiI9Ld5M https://www.youtube.com/watch?v=5uhIiI9Ld5M [4]https://youtu.be/5uhIiI9Ld5M?t=878 https://youtu.be/5uhIiI9Ld5M?t=878
dsr_ 3y ago
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.
- CRConrad 3y ago
  No, only the first is correct. The second is, still, an ugly kludge.
depressedpanda 3y ago
> 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.
- tshaddox 3y ago
  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-shells/multi-column#component-aa0e4b496e24d741e984c820f5e938ba https://tailwindui.com/components/application-ui/application...
  - depressedpanda 3y ago
    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.
ArtWomb 3y ago
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 https://codelabs.developers.google.com/your-first-webgpu-app
Sohcahtoa82 3y ago
> 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.
- fsckboy 3y ago
  > Do not impose your preference of 1 click ~= 1 line excuse me, but no designer ever gave audience to such a sensible suggestion
- zimpenfish 3y ago
  > 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.
bryanrasmussen 3y ago
>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 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?
- throwaway14356 3y ago
  it seems much cleaner to give each size its own css?
- 5350-uiop-1130 3y ago
  > 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.
  - bryanrasmussen 3y ago
    >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) OR 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.
eternityforest 3y ago
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.
- depressedpanda 3y ago
  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.
  - eternityforest 3y ago
    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...
deleted 3y ago
[deleted]
brailsafe 3y ago
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.
deleted 3y ago
[deleted]
hammock 3y ago
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
- qingcharles 3y ago
  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.
deleted 3y ago
[deleted]
mmcnl 3y ago
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.

johnnyworker 3y ago

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.

smarkov 3y ago

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

crazygringo 3y ago
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.
- MrJohz 3y ago
  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).

danielvaughn 3y ago

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.

withinboredom 3y ago
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.
- hagg3n 3y ago
  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.
  - esdott 3y ago
    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.
    - withinboredom 3y ago
      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.

traceroute66 3y ago

> 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 https://every-layout.dev [2]https://buildexcellentwebsit.es https://buildexcellentwebsit.es [3]https://www.youtube.com/watch?v=5uhIiI9Ld5M https://www.youtube.com/watch?v=5uhIiI9Ld5M [4]https://youtu.be/5uhIiI9Ld5M?t=878 https://youtu.be/5uhIiI9Ld5M?t=878

dsr_ 3y ago

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.

CRConrad 3y ago
No, only the first is correct. The second is, still, an ugly kludge.

depressedpanda 3y ago

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

tshaddox 3y ago
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-shells/multi-column#component-aa0e4b496e24d741e984c820f5e938ba https://tailwindui.com/components/application-ui/application...
- depressedpanda 3y ago
  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.

ArtWomb 3y ago

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 https://codelabs.developers.google.com/your-first-webgpu-app

Sohcahtoa82 3y ago

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

fsckboy 3y ago
> Do not impose your preference of 1 click ~= 1 line excuse me, but no designer ever gave audience to such a sensible suggestion
zimpenfish 3y ago
> 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.

bryanrasmussen 3y ago

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

throwaway14356 3y ago
it seems much cleaner to give each size its own css?
5350-uiop-1130 3y ago
> 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.
- bryanrasmussen 3y ago
  >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) OR 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.

eternityforest 3y ago

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.

depressedpanda 3y ago
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.
- eternityforest 3y ago
  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...

deleted 3y ago

[deleted]

brailsafe 3y ago

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.

deleted 3y ago

[deleted]

hammock 3y ago

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

qingcharles 3y ago
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.

deleted 3y ago

[deleted]

mmcnl 3y ago

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.