I refuse to read anything even remotely related to accessibility written by someone dumb enough to put white text on a yellow background.
Screenshot?
The ideal viewport doesn't exist
171–180 of 202 posts
Re: The ideal viewport doesn't exist
#172> If you’re on a desktop device reading this, how many windows are filling the entire screen? How much screen space does the browser you’re reading from take up? > It’s safest to presume that users on desktop or laptop devices are not filling their entire screen with a browser. Is this true? If you're reading this casually (and you are reading this casually) is your browser not at full size? I almost exclusively use…
Not an outlier, I almost exclusively use full-screen browser windows. Even if I need to see content in close proximity, I usually just switch between two workspaces (vim on one, browser on another) and flip back and forth pretty easily to see the output.
Re: The ideal viewport doesn't exist
#173I know that this article is probably 'objectively good design' in some way, seeing as its written by front-end experts of some sort, but I found the content much tougher to read and digest than a much plainer format. All the different bold colors, graphics, and large/varied font sizes were tougher for me to absorb than something more straightforward (eg https://www.arslonga.email/how-to-connect-zotero-with-obsidi... - just the most recent example I could think of). Anyone else feel the same?
Re: The ideal viewport doesn't exist
#174> "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…
> 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 scrol…
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.
Re: The ideal viewport doesn't exist
#175LOL. Line 1268 of that CSV file [0] has a negative height. And it actually is in the visualization [1]. Wonder what kind of device reports a -2000 height :D [0]: https://viewports.fyi/data.csv [1]: https://viewports.fyi/all/
Maybe someone holding their phone upside down?
Re: The ideal viewport doesn't exist
#176Earlier quoted context omitted.
The button is 44x44. The SVG is 30x18
If that's the clickable area, is someone complaining that's too large? You've been able to select radio buttons by clicking on their text for decades now. On desktop. Often literally hundred of pixels wide. Generous margins for clickable elements seems like a feature, not a problem. As long as they don't interfere with anything else (which they don't, here).
I happen to agree, just trying to point out the miscommunication
Re: The ideal viewport doesn't exist
#177Earlier quoted context omitted.
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!
That supports touch zoom just fine, it just has a low limit to how far in it goes.
Re: The ideal viewport doesn't exist
#178> "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…
> 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 scrol…
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.
Re: The ideal viewport doesn't exist
#179Earlier quoted context omitted.
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 de…
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...
Re: The ideal viewport doesn't exist
#180> "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…
>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 abo…
> 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.