Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The ideal viewport doesn't exist

viewports.fyi

Post reply on HN
Print view View original

181–190 of 202 posts

Re: The ideal viewport doesn't exist

#181

Post by bryanrasmussen »

5350-uiop-1130 wrote: post #180
bryanrasmussen wrote: post #94

Earlier quoted context omitted.

>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 i…

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

Re: The ideal viewport doesn't exist

#182

Post by [deleted] »

bryanrasmussen wrote: post #181
5350-uiop-1130 wrote: post #180

Earlier quoted context omitted.

> 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 i…

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

[deleted]

Re: The ideal viewport doesn't exist

#183

Post by madeofpalk »

adventured wrote: post #105
temac wrote: post #97

Earlier quoted context omitted.

I'm not even sure what mobile means in this context. What happens when you plug your phone on a screen? What happens when you use a tablet?

That's very straightforward. Obviously the user agent is reported by the browser/device as mobile or not (it either includes that keyword or not). In nearly all cases mobile means smartphone or tablet, whether Android or iOS, Chrome or Safari. iPad commonly includes the mobile keyword in its user agent string, unless desktop is enabled by default and then they'll just get the desktop version (you could trivially dete…

"works so well" is debatable. Is iPad "mobile" (honestly, I'm not sure). What if I'm on desktop and I make my screen just a bit smaller? Can I now not use the website because it doesn't bother adapting to the changing width.

If this is how you want to build websites, discarding users, go ahead. But it's irresponsible to recommend this as advice to others.

Re: The ideal viewport doesn't exist

#184

Post by WhrRTheBaboons »

coldpie wrote: post #121
karmakaze wrote: post #36

Landscape on mobile is the least well supported configuration I know. Static headers/footers commonly take 50% or more vertical space with no way to dismiss or shrink them.

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.

cheers!

Re: The ideal viewport doesn't exist

#185

Post by debugnik »

paulddraper wrote: post #167
debugnik wrote: post #126

Earlier quoted context omitted.

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.

Re: The ideal viewport doesn't exist

#186

Post by PMunch »

crazygringo wrote: post #48
PMunch wrote: post #5

I wish more pages took the pointer and resolution media queries into account. So many times I open windows side-by-side on my desktop and end up with the menu collapsing into a hamburger menu which fills the entire screen when clicked. Many phones today have very high DPI and very low precision in touch, so it makes sense to have massive visual elements and buttons, but my desktop with the same size in pixels as my p…

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 main…

Sorry if I was unclear. I didn't mean that the resolution changed, but rather that pages should take into account how big elements will actually appear in the real world. Typically if I open a website and half-and-half my browser with a terminal the website goes into mobile-mode. The page however is about three times wider than my phone screen, and the hamburger menu is more than twice the size of my mouse cursor. Just because I don't have the page open full-screen any longer doesn't mean that I suddenly can't click the same size buttons or read the same size font, so there's no point in making everything big and clunky.

Re: The ideal viewport doesn't exist

#187

Post by MrJohz »

crazygringo wrote: post #162
smarkov wrote: post #34

Earlier quoted context omitted.

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

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

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

Re: The ideal viewport doesn't exist

#188

Post by Izkata »

Sohcahtoa82 wrote: post #93
5350-uiop-1130 wrote: post #15

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

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

Re: The ideal viewport doesn't exist

#189

Post by ghusto »

PMunch wrote: post #8
ghusto wrote: post #2

> It’s safest to presume that users on desktop or laptop devices are not filling their entire screen with a browser. Not on literally any laptop I've ever seen. I've never seen a screen where the browser _isn't_ filling all space available to them, sometimes even the entire screen (in fullscreen mode on MacOS).

You never side by side your browser and another application like a terminal or text editor? And even barring that the taskbar of your OS along with window decorations means that your browser is seldom 100% of the screen. This is also talking about the viewport, so even though they clumsily refer to it as the "browser" the website won't be given 100% of your resolution even if your browser did have 100% simply because…

> You never side by side your browser and another application like a terminal or text editor?

Never. I cmd+tab between windows. What I _have_ seen is developers have those on different monitors, but even there the browser is always fullscreen.

> And even barring that the taskbar of your OS along with window decorations means that your browser is seldom 100% of the screen

I did mention this ;)

Re: The ideal viewport doesn't exist

#190

Post by ghusto »

kube-system wrote: post #84
ghusto wrote: post #2

> It’s safest to presume that users on desktop or laptop devices are not filling their entire screen with a browser. Not on literally any laptop I've ever seen. I've never seen a screen where the browser _isn't_ filling all space available to them, sometimes even the entire screen (in fullscreen mode on MacOS).

I presume you're talking about maximized windows, but that still does not equal "filling the entire screen", because browsers have their own user interface around the viewport. Go maximize your browser and enter this into your dev tools: console.log(`${window.innerWidth}x${window.innerHeight}`) Does that equal your screen resolution?

I did differentiate here ;) and even mentioned that I "sometimes even [see] the entire screen (in fullscreen mode on MacOS) [being used]"
Post reply on HN