[HN Gopher] Just because I have a vertical screen doesn't mean I...
___________________________________________________________________
Just because I have a vertical screen doesn't mean I'm on a phone
Author : edent
Score : 407 points
Date : 2021-02-02 12:53 UTC (10 hours ago)
(HTM) web link (shkspr.mobi)
(TXT) w3m dump (shkspr.mobi)
| thinkloop wrote:
| Mobile has some unique characteristics that don't fully allow
| agnostic design, namely:
|
| - viewport changes size due to soft keyboard - address bar
| hides/unhides during scroll down/up
|
| For certain types of apps, like games, it's important to know
| whether a device is actually "mobile" regardless of
| size/resolution. Sniffing user-agents might have to come back
| into vogue. Who knows where "mobile browsers" will end up - maybe
| some giant 60" kiosk app, or other places.
|
| Barring that though the article brings up good points and
| searching the web for how to detect mobile usually brings up the
| error-prone portrait/landscape resolution detection that the
| article discusses.
|
| The full solution requires the knowing the resolution and the dpi
| to get an estimate size of screen in inches. At least with that
| we can be safe until next article "Just because I'm a 100" kiosk
| app, doesn't mean I'm on a phone".
|
| Is there a good npm lib that does the above?
| SeeManDo wrote:
| You know you do it just to look L337...
| jordache wrote:
| the author must be aware that his use case (vertically oriented
| monitor) is such an obscure demographic, that almost no company
| will invest in time to optimize this experience. His complaining
| about this situation is pure self-centered arrogance.
|
| There is effectively zero benefit of optimizing for this use
| case.
| [deleted]
| qwerty456127 wrote:
| How do they know it's your screen which is vertical, not just a
| window?
| Stevvo wrote:
| The proposed solution for developers doesn't work any better; DPI
| is correctly calculated on desktop, but nearly always wrong on
| phones. So fixing sites for vertical desktop monitors will break
| them in most phones.
| chrismorgan wrote:
| I'd express it much more strongly than you have: doing what
| this article suggests is catastrophically wrong. For layout
| purposes you _must not_ look at physical resolution. Physical
| resolution should only be used so that you can render on scaled
| displays at higher quality, e.g. by choosing a higher-
| resolution image, or by scaling your canvas by devicePixelRatio
| so you can draw more precise lines.
|
| The proposed solution is not just no better, but far, far
| worse.
| peanut_worm wrote:
| Aren't CSS breakpoints usually based on width and not
| orientation? I have always done it based on width.
|
| The width of the window is probably dropping below a breakpoint
| when he reorients the screen.
| jiofih wrote:
| > that can leave some sites too small to read properly. I need to
| zoom out the page
|
| Well, then all I can say is that the CSS breakpoint is doing its
| job perfectly. It switches to layout you can read at this
| (emulated) screen size. There is nothing to fix.
| kuon wrote:
| I think the most important factor is not really screen resolution
| or size, but "cursor precision".
|
| I'm fine with HN on mobile, but it is really hard to press the
| buttons with my large fingers on a mobile screen. But much easier
| on a 800x600 monitor using a ball mouse. For HN I don't really
| mind, as a pinch to zoom.
|
| To check for touch, there is `Navigator.maxTouchPoints` but this
| might backfire on some laptop which have touch screen (which you
| usually use for drawing rather than UI, but your mileage may
| vary).
|
| But I think the core issue is much earlier in design. Many
| websites and app have complicated design/UI while it could be
| simpler, and they split their UI into mobile and desktop very
| early in the design process, which leads to two very different
| version. And while I agree that mobile and desktop are different
| experience, I think you can keep them close in term of UI and UX.
|
| For example, let's say you want tooltip, on desktop this is a
| normal UI control which is natural, but on mobile it is not, so
| instead of using tooltip on desktop and "think of something" when
| doing the mobile version, we need to design early for both.
| Today, many website and apps are designed with a "mobile first"
| mindset, and this cause problem when used on desktop. The
| solution is not better detection of either platform, but better
| design to keep them as close as possible.
|
| Of course, there is also the issue of scaling text vs scaling the
| whole site, and this is not very well handled by many website,
| even with the "let's use em/rem units".
| ping_pong wrote:
| I have 3 monitors. Once of them is portrait mode because it's
| easier to read longer posts and articles this way.
|
| I've never had such a problem as described by the blog post, but
| my resolution doesn't drop to 720px like the author.
|
| Scaling the size of fonts has always been discouraged, even by
| Windows. I used to use larger fonts on Windows way back and it
| would mess up the spacing of many apps, because it's just so
| uncommon. I fought against the wind for years and gave up.
| lmilcin wrote:
| Welcome to globalization.
|
| Some people try to implement fancy heuristics that fails for some
| users but not enough to care to fix.
| aasasd wrote:
| Browsers should provide to websites the user's (typical) distance
| to the eye, and preferred zoom level. Maybe also the preferred
| type of input, to tell mouse users from finger users.
|
| Obviously pixel count and screen ratio is complete nonsense, in
| this almost-glorious day of sweet variety of gadgetry. It will
| only become more of a nonsense, until we all switch to neural
| interfaces.
|
| But since designers only have what CSS&JS provide, they cling to
| the pixel count and DPI, choose a font size according to
| someone's eyesight, and stick to that. This is bogus, and leads
| to fonts from something like two mm in height (ahem HN cough) to
| almost a centimeter, so I either have to stick my nose to the
| phone screen, or hold the phone at a full arm length and scroll
| like mad. And browser zoom is no help in this model.
|
| Meanwhile, in the real world, all that matters is the visual
| angle of the font or image, and the user's eyesight. The first is
| dictated by the distance from the screen, and the second
| determines how much the content must be zoomed in from the
| perfect-vision scenario. In fact, since I wouldn't want the
| content to grow and shrink when I move my arm somewhat or lay
| back in the chair, perhaps devices could use some default visual-
| angle values according to their form-factor and typical usage,
| then adjust for the user's chosen zoom level, and report only one
| value to websites: either preferred visual angle, or zoom level
| from some global anchor value--whichever of the two is better to
| use for calculations.
|
| With this info, the screen's pixel resolution affects only one
| consideration: whether a given line of text or other content
| would fit in the screen horizontally at the preferred visual
| ratio--or it must be broken or scrolled.
| matheusmoreira wrote:
| People also assume phone users only hold it vertically. Most
| popular apps don't even allow landscape orientation. They can't
| even cope with varied screen sizes and orientations. I've
| actually found bugs when I forced them to try via split screen
| view.
| rho4 wrote:
| I've been using 3 vertical screens side-by-side for years. Like
| web pages, source code is also long and (usually) not too wide.
| Being able to see that complete method / function without
| scrolling is invaluable to me. Square screens would also suit me
| well, but they don't exist, sadly (apart from very expensive
| Eizo).My current resolution is 3x 1440 x 2560, so luckily I don't
| get mobile versions of web pages.
| viseztrance wrote:
| I can relate. Sometimes I'm browsing a page, and zoom in
| (control+) to make the text larger. But then the webpage switches
| to its mobile view.
|
| So it seems like we've broken desktop accessibility in favour to
| the mobile one.
| ohazi wrote:
| Forget the arguments about counting pixels for a moment... Mobile
| browsers have a "request desktop site" switch that _seems_ to
| work pretty reliably, even though the viewport is still tall.
|
| Yet when I tile my browser to the left or right of my giant 4k
| display, I _frequently_ get a mobile site with text that you can
| read from across the street. Is there a way to jusr get a
| "request desktop site" switch that performs the same magic on my
| desktop browser?
| idonotknowwhy wrote:
| Similar issues here since working from home on my 19 inch CRT.
| Easy solution, hold ctrl and scroll down with the scroll wheel.
| That zooms out a bit and the websites pop back to normal again.
| Had similar issues with the crosshair in halo reach on PC, it was
| an oval instead of a circle. Luckily they fixed it a few months
| ago.
| ThePadawan wrote:
| Just because my horizontal resolution is around 1200, I am not on
| a tablet.
|
| It's amazing how many websites are incredibly unusable when
| displayed 2-up on my 27" monitor.
|
| There's so much screen estate, but I often literally have to
| resize the window to fullscreen to find a search or login field.
| MivLives wrote:
| This is the worst when you're displaying two sites side by side
| on a 1080p screen.
| robertoandred wrote:
| At what horizontal resolution?
| t-writescode wrote:
| 960x980.
|
| 1920x1080 in half.
|
| It's a regular problem I run in to.
| Kuraj wrote:
| This drives me up the wall. You would think it's such a
| common scenario!
| mrweasel wrote:
| We use a web-based time tracking system that appears to
| assume that you're either on a device with a touch screen,
| or have an ultra wide display. You can't easily scroll side
| to side without touch, so the second best option is full
| screen on a ultra wide screen, so you don't need to scroll.
|
| I long advocated that website started to use the more of
| the width of the screen on desktops, to avoid unnecessary
| scrolling. However, I just a frequently have two windows
| next to each other.
|
| There's no real good way of satisfying all use cases, but
| it generally seems like desktops are being neglected when
| company design websites. Previously mobile seemed to be
| hacked on to an existing site, now everyone seems to go the
| route of: If it's good enough for mobile, it's good enough
| for desktop users.
| MivLives wrote:
| It's one of the reasons I have a vertical monitor. 1080
| horizontal doesn't seem to trip it.
| iamben wrote:
| It's a difficult one though - say I have left menu, and a
| sidebar on the right, and a central column with my copy. Very
| roughly, at about ~1350px (so neatly displayed on a generic
| 1440 laptop) I have about 250*2 (500px) for my sidebars, about
| 800px for my central column, which at a decent font size will
| give me a 'right-ish' about of words per line, and a few more
| pixels for gutters.
|
| As you start to make that smaller - 1200, 1100, something has
| to change. We can maybe adjust the font size in the main
| column, maybe there's some flexibility to shrink the sidebars
| (but maybe there isn't, because we need an ad in there, and
| that can't be resized). So we have to adjust - lose a sidebar
| to a hamburger menu, or change our horizontal menu at the top
| to include the most clicked links (and not the ten links we
| have before). Maybe the search bar becomes an icon, because
| it's more important we push the "Buy Now" button than give
| people an option to search, etc etc.
|
| It's an art - what do people need the most? What will make them
| convert? What can we remove first? What resolutions are most
| used, and how do we optimise for that?
| ThePadawan wrote:
| I see your point, and I'm not complaining about that.
|
| As you point out:
|
| > Maybe the search bar becomes an icon (...)
|
| I'd already be _ecstatic_ about that.
|
| I'm talking about features which are essential to a website
| that just disappear _completely_ because the owner thinks
| "no one on a tablet will ever want to use this".
| iamben wrote:
| Haha, yes, it's definitely a balancing act! Thankfully
| analytics and heatmaps are a good start to figuring this
| out (even without applying common sense fundamentals)!
| ericol wrote:
| Wholeheartedly agree. And this apply not only to vertical.
|
| I have a Samsung Tab A Tablet (Model SM-T510) that has better
| resolution than my notebook (A Lenovo T430). A page that displays
| very well in the Lenovo (1366x768) displays like crap in the
| tablet (1920x1200) even when using it in the landspace position.
| StillBored wrote:
| I think he is totally doing this wrong, firefox has a zoom text
| option (that was the default years ago).
|
| https://support.mozilla.org/en-US/kb/font-size-and-zoom-incr...
|
| That keeps the layout/images/etc the same, while bumping the font
| px/em.
| adenozine wrote:
| What's a nice way to say "Who cares? Nobody does this" ?
| whalesalad wrote:
| I don't think this has much to do with your vertical screen as
| much as it's the narrow viewport.
| chrismorgan wrote:
| Absolutely. When I read the _headline_ , I frowned, because I'd
| call it quite rare for sites to mishandle my 1080x1920
| displays, though not unknown.
|
| But then I read to "720x1280", and... well of course, what did
| you expect?
| eznzt wrote:
| Exactly. CSS does not check that your screen is taller than it
| is wide. What it sees is a narrow viewport.
| jkochis wrote:
| Is that what this is for? https://developer.mozilla.org/en-
| US/docs/Web/CSS/@media/aspe...
| jefftk wrote:
| You can query for aspect ratio in CSS, yes. This can be
| useful for figuring out whether it's better to place
| something as, say, a sidebar vs a footer. The sites they
| are complaining about, however, are only looking at the
| horizontal dimension.
| Nathanael_M wrote:
| I think primarily that's for constraining a div's aspect-
| ratio. Like making sure you have a div that's always 16:9
| to hold a video player. I'd be interested in hearing other
| use cases, though.
| madeofpalk wrote:
| No, it's not.
| dairylee wrote:
| The CSS could very well be checking that
|
| // The viewport is in a landscape orientation, i.e., the
| width is greater than the height.
|
| @media (orientation: landscape)
|
| // The viewport is in a portrait orientation, i.e., the
| height is greater than or equal to the width.
|
| @media (orientation: portrait)
| ChrisRR wrote:
| As with every engineering project, there's always a point where
| you have to look at how few people are within a certain use case
| and decide it's not worth the effort to cater for them
|
| As a vertical PC user, you're in the vast minority, and you can't
| really be surprised that people don't want to spend the extra
| time (and money) developing to support your edge case
| _trampeltier wrote:
| On work, I know a couple of people who use vertical screens
| (including me). At home I have a large 43" 4K monitor (no
| scaling). A lot of websites think it would be something like a
| 23" 4K monitor and everything on the website is super large. As
| rule of thumb, as more fancz the website is, the more is the
| website broken if you don't use just a 08/15 monitor.
| jiofih wrote:
| His problem is not really the vertical screen, but that he is
| virtually scaling the monitor down to 720px wide.
| jefftk wrote:
| Sites are not detecting a portrait screen and deciding that
| they're displaying on a phone. Someone who switches their monitor
| to portrait, or resizes a window to be taller than it is wide, is
| still going to get the desktop view.
|
| In this case the author is scaling their resolution, and so their
| browser is presenting itself to sites as 720px wide. Sites see
| that and show a layout optimized for a screen of that width.
| Those sites are acting _correctly_.
|
| The author's proposed solution is for sites to use DPI instead,
| but this would thwart the preferences of users who use scaling
| because they want the whole site to look bigger.
| ortusdux wrote:
| The A.V. Club took flak for turning all their lists into slide-
| shows on desktop. Their response was to tell people to adjust
| their browser width to force the mobile view. When you load a
| page, it preloads the assets for both views and switches based
| solely on window width. If you play an embedded youtube video
| and try and toggle full screen mode, the site reverts back to
| slide-show and breaks the video.
|
| example: https://tv.avclub.com/the-hunt-is-on-with-clarice-the-
| equali...
| hellotomyrars wrote:
| That's horrific. And the content is off center at full res so
| they can load their sidebar that well, isn't so much as off
| to the side as halfway into the center of the screen.
| marssaxman wrote:
| I prefer to browse with portrait-mode windows, and often find
| that sites give me the mobile layout unless I stretch the
| browser out wider than I'd prefer. It is annoying.
| tyingq wrote:
| The example of https://www.just-eat.co.uk/ bailing out to a
| hamburger menu at 768px, just to deal with 5 navigation options
| is a bit much.
| Wowfunhappy wrote:
| As it happens though, with the navigation design they chose,
| the entries wouldn't fit at that width.
|
| They certainly could have added an extra breakpoint where the
| navigation becomes smaller before bailing to a hamburger, but
| of course that does add complexity.
| smichel17 wrote:
| Two rows?
| tyingq wrote:
| I suppose, but "Deliver with Just Eat" is a pretty long,
| and an overall odd choice for a top menu item. Wasn't clear
| to me that it meant "drive for us". And that's what's
| eating the width.
| tomjen3 wrote:
| @media and (pointer: fine) { your computer specific
| CSS rules goes here }
|
| No reason to tell a tall window it is on a phone.
| sillysaurusx wrote:
| This doesn't address the author's central argument, which is
| that websites need an effortless way of letting fonts become
| bigger without affecting the entire layout. I've wanted it too.
| I don't really care if some text gets cut off on headers and
| looks weird, I just want to read stuff from the comfort of my
| bed with my laptop a few feet away.
| jakub_g wrote:
| FYI desktop Firefox has "Zoom Text Only" feature.
| View > Zoom > Zoom Text Only
|
| On mobile: all browsers have "force enable zoom" + test
| scaling in accessibility settings; Additionally Opera
| supports reflow on zoom (Settings > Text options > "Text
| wrap").
| Izkata wrote:
| I like how it's now a "feature". This is what zoom
| originally did, and "full zoom" was the feature.
| altcognito wrote:
| This was tried in the mid-late oughts was it not? It is
| nearly impossible to logically derive what should increase in
| sized and what should not.
|
| Should the space given to sidebars increase? Should those
| sidebars disappear? What about headers and footers? How will
| the overfloat be treated? A single line, double lines? What
| about captions underneath images? How do you handle text that
| happens to be embedded within images themselves, or even on
| top of images?
|
| "I don't care if headers look weird"
|
| It goes beyond things looking weird, it really does break
| websites.
| nofunsir wrote:
| God forbid we use the scroll bar.
| richardwhiuk wrote:
| Horizontal scrolling perform disastrously badly in UX
| testing.
| pc86 wrote:
| Nobody's suggesting we not use it, and honestly I don't
| even know what this needlessly rude comment means in the
| context of the larger discussion.
|
| Given that we're increasing the text 2x or 3x, it's an
| important question whether or not we're also increasing
| the width of the scrollbar 2x or 3x.
| stronglikedan wrote:
| I love that Chrome on Android lets me zoom into any content
| on any site, regardless of how bad the devs borked the UX.
| (Yes, devs, if you don't allow me to zoom using the browser's
| built-in capabilities, you have borked the UX, and should be
| ashamed of yourselves.)
| ficklepickle wrote:
| Unless its, say, a mapping web app. In which case, pinch-
| zoom adjusts the canvas map zoom, allowing regular zoom
| would actually break the UX.
|
| I agree though, let me zoom on a blog post. The diagrams
| are often unreadable on mobile.
| KLexpat wrote:
| If you have a windows 10 laptop, pinching on the touchpad
| seems to give you the same zoom functionality now. vastly
| superior than the one built into the browser
| Aerroon wrote:
| This is one of the main reasons I prefer using a website on
| my phone as opposed to an app. Some apps allow me to zoom
| others don't. The browsers lets me do that regardless.
| Robotbeat wrote:
| I didn't know this! And inability to do this is a huge pet
| peeve (as well as not being able to zoom OUT and get a
| desktop-like view on my phone). Does this work on any
| browser for iPhone?
| falcolas wrote:
| Just confirmed it works on Firefox and Safari. Though I
| seem to recall seeing some sites which break that
| functionality with CSS.
| matsemann wrote:
| That's how zooming (ctrl+scroll) in the browser used to work:
| It increased font sizes. It has been abandoned because it
| just wreaks havoc on the layout and is impossible to handle
| properly.
| oneeyedpigeon wrote:
| It was so standard, it wasn't even called "zooming",
| because it wasn't. It was called "increase text size". It
| worked well for most reasonable sites, certainly a lot
| better than an actual zoom typically does.
| falcolas wrote:
| It's still an option in Firefox. In the general
| preferences, a checkbox titled "Zoom text only".
| cratermoon wrote:
| I just have bad eyes. I complained once about text size here
| and a lot of people just said, "use your browser zoom",
| completely ignoring how layouts not scale or reflow.
| pc86 wrote:
| > _I just want to read stuff from the comfort of my bed with
| my laptop a few feet away._
|
| That's not what laptops are for.
|
| I think that's a typical snide HN/Stack Overflow-type answer,
| and I don't mean it rudely, but it _does_ have some bearing
| on this conversation. What 's the intended form factor of a
| laptop? What are the top 10 intended form factors? I'm not
| sure "reading from 'a few' [several] feet away, while I'm
| laying down in bed" is in that top 10 list.
|
| Are there devices better suited to that form factor? I don't
| know.
| HPsquared wrote:
| Until 2020, it was probably uncommon. Not so sure now.
| reaperducer wrote:
| _I don 't really care if some text gets cut off on headers
| and looks weird, I just want to read stuff from the comfort
| of my bed with my laptop a few feet away._
|
| How is a web site supposed to know if you're someone sitting
| in bed with the screen a few feet away, or someone sitting at
| a desk with a screen a few inches away?
|
| That's on the user. Learn how to use your browser, device,
| and operating system's zoom features.
| bcrosby95 wrote:
| You're missing the forest for the trees here. Sites are using
| pixels as a proxy for physical device size. Which obviously
| breaks. I doubt people actually _intend_ to display mobile view
| on a 720px, 12 " wide device.
|
| They're only working correctly if you ignore the intent and
| only look at the technical implementation. The technical
| implementation is flawed and doesn't accomplish the intent.
| contravariant wrote:
| But the OP is using pixels as a proxy for screen size as
| well, they're deliberately presenting their screen as
| 720x1080 _to make the fonts bigger_ because they are too far
| from the screen.
|
| The stupidest thing to do at that stage would be to say "ah I
| see you're running a low resolution on a huge screen, let me
| make all the text tiny".
| cratermoon wrote:
| > they're deliberately presenting their screen as 720x1080
| to make the fonts bigger because they are too far from the
| screen.
|
| As I read this I:
|
| 1. am wearing my computer reading glasses +1.5
|
| 2. have my browser set to zoom HN by 125%
|
| 3. am reading distance from the screen
|
| I know programming and tech in general is a young man's
| game, but let's at least try not to be ignorantly ageist &
| ableist.
| contravariant wrote:
| I have no such intention, I was merely rephrasing what
| they said:
|
| > But I find the fonts slightly too small at that
| resolution - given how far I sit from the screen.
| Brian_K_White wrote:
| I think their point was that if you want fonts to be
| bigger, there are settings to do that. (or should be even
| if the world isn't perfect yet) Same to a lesser extent
| for other ui features.
|
| In reality, as of today, so far, neither desktops nor
| apps are that good where you can have the display set at
| it's correct native resolution, while having buttons,
| menus, icons, text, window controls etc all scale to
| preference.
|
| But saying that that's what should happen rather than lie
| to the software about the hardware, is not agist or
| ableist.
|
| I think the point was simply that fundamentally, lying to
| the software about the hardware is always inherently
| doomed to produce some form of incorrect result, and when
| it does, it's not the tech's fault for failing to second-
| guess, work-around, and essentially thwart your actively
| dishonest misconfiguration.
| Retric wrote:
| More to the point he is using multiple edge cases at the
| same time and dislikes the result he's getting. He then
| suggests other people accommodate him.
|
| Sorry, as long as the site still works it's simply not
| worth it.
| quicklime wrote:
| > The author's proposed solution is for sites to use DPI
| instead, but this would thwart the preferences of users who use
| scaling because they want the whole site to look bigger.
|
| Agree. I sometimes browse the web on my TV - and I sit about 2
| metres (or 6 feet) away from it. So the TV screen occupies a
| similar portion of my field of view that a phone would, and I
| usually browse at 150-200% zoom.
|
| DPI might help you figure out the size of the screen, but it
| doesn't tell you how much of a person's field of view that
| screen occupies, which is what really matters.
| hunter2_ wrote:
| Yes, field of view is what really matters, but scaling at the
| OS level (like TFA's author is doing) is a good way to
| correct for unusual fields of view. Got a higher-than-typical
| DPI and/or ridiculously far away screen and/or vision
| impairments? Scale the OS up. Got a screen with lower-than-
| typical DPI and/or touching your nose and/or amazing vision?
| Scale the OS down. You need the entire OS scaled, not just
| web pages.
|
| "CSS pixels" are kind of a roundabout way to conceptualize
| it, but they solve the problem of proper readability once the
| OS scale is correct for the user. The combination acts as a
| proxy for field of view.
|
| Then there's detection of course/fine pointing devices, as
| already discussed, to further augment the layout for proper
| target area.
|
| I don't believe anything else will matter if the above is
| accounted for.
| ur-whale wrote:
| >Someone who switches their monitor to portrait, or resizes a
| window to be taller than it is wide, is still going to get the
| desktop view.
|
| My experience has been the _exact opposite_ of what you 're
| saying.
|
| And the result is, 90% of the time, a site that goes from
| usable to unusable.
| jefftk wrote:
| What viewport width are you providing in that case?
| ur-whale wrote:
| I typically go from width=1920 x height=1080 (or larger but
| with similar aspect ratio) to width=949 x height=1028
|
| On many sites, this trigger the appearance of the dreaded
| hamburger menu.
| jefftk wrote:
| When people lay out desktop sites, 960px is the smallest
| common minimum design width. Many of these sites are
| statically laid out, and if rendered with the width of
| 949px would require horizontal scrolling.
| nobleach wrote:
| Yes, and webdevs have been trying for over 10 years now to
| figure out how to get this right. Has no one just stopped to
| consider having a browser send a `prefersMobileView` or
| `viewport:phone` or anything like that? I can remember back a
| few years ago, an iPhone 6+, turned sideways could get a
| desktop view on some sites... simply because it met the
| requirements set by the author. Now, the author's assumptions
| were wrong of course, but all we have to go on, is literally
| guesswork. We're told constantly NOT to use user-agent strings,
| but honestly, it's like we really need something to key off of.
| I know the A List Apart folks would have us create content that
| can be viewed on ANY viewport, but I consider that a tad bit
| unrealistic. I've been out of Front-end dev for a few years
| though, so perhaps things have changed.
| asddubs wrote:
| IMO the best solution is to just have natural breakpoints
| (i.e. when a part of the design of the given page would cease
| to work, add a breakpoint to change the format of that
| component, rather than at predefined points) and then for
| logged in users have an option to request the desktop design,
| which you can do by simply setting a viewport to 1000px width
| and leaving everything else unchanged
|
| what would be really nice would be element-size-based media
| queries. you can use javascript to do it but that sucks
| ryandrake wrote:
| I think we really need to be able to more cleanly separate
| content from the design, and let the browsers, a.k.a. user-
| agents, decide/override more. Browsers have ceded too much
| control over layout and visual structure to web designers,
| who go on to make (often incorrect) assumptions about how
| the user wants to interact with their content.
| asddubs wrote:
| the problem is that there is no distinction between a
| webapp and a document, the line is thoroughly blurred.
| For documents, you can probably just override a fair bit
| of schenanigans and things will still work, if look
| somewhat ugly, but for a spreadsheet app that's a rube
| goldberg machine of javascript and continuously
| regenerated html and css, it'll just turn it into a
| broken mess. the browser has become the de facto cross
| compatible application platform, which requires handing a
| lot of control to websites.
| jiofih wrote:
| One of the original selling points of the iPod touch/iPhone
| was that it could display full desktop websites...
| klodolph wrote:
| Fair, although back at the time they came out it meant
| something different. Mobile-optimized websites in 2008 were
| horrible, stripped-down things.
| chungy wrote:
| Isn't that still true in 2021? I haven't been
| particularly fond of the mobile view of most sites I come
| across. I force desktop-view on my phone fairly
| frequently just to get at features/pages I want.
| jefftk wrote:
| It is still maybe a little bit true, where some sites
| will make some things only possible to do on desktop, but
| when the iPhone came out mobile sites were generally
| incredibly minimal. They needed to be, to handle existing
| devices and browsers, which were much less powerful than
| the iPhone.
| iamben wrote:
| It can. As can Chrome on Android. Just request the "Desktop
| site" version. It's pretty unusable though, which is why we
| have responsive websites :-)
| jefftk wrote:
| Mobile vs Desktop is not a clean division: screens run the
| full range of widths. Instead, developers should:
|
| * Lay out content based on the viewport width, in CSS pixels.
|
| * Use larger tap targets for coarse pointers
| (https://developer.mozilla.org/en-
| US/docs/Web/CSS/@media/poin...).
| badsectoracula wrote:
| > Lay out content based on the viewport width, in CSS
| pixels.
|
| This is wrong because the viewport width is not the same as
| the monitor width or the DPI: especially on big monitors
| running the browser fullscreen is very hard to use (my
| browser rarely exceeds more than ~50% width on a 2560x1440
| monitor and even when i use a 1366x768 monitor - which btw
| is at 22", not some tiny laptop one - i very rarely use it
| maximized).
| jefftk wrote:
| The viewport width is the browser width, not the screen
| width. What are you saying is wrong with using the
| viewport width?
| badsectoracula wrote:
| Uh, i wrote "viewport width is not the same as the
| monitor width", this is the same as what you wrote.
|
| As for why it is wrong, it is because you can't rely on
| it to make a Mobile vs Desktop distinction - i already
| provided an example why.
| jefftk wrote:
| "Mobile vs desktop" is not a distinction websites should
| be making. Sites should make the best use they can of the
| available horizontal space.
|
| It's still not clear to me where you think this approach
| gives bad results?
| karpierz wrote:
| Ergonomics of using touch screen vs. mouse.
|
| Usage while walking/moving vs. sitting/standing at a
| desk.
| jefftk wrote:
| For touch screen vs mouse, use "pointer:coarse":
| https://developer.mozilla.org/en-
| US/docs/Web/CSS/@media/poin...
|
| Most "mobile" usage is actually stationary, typically
| seated. If you really need to change layout based on
| motion you can use the accelerometer, but I can't see why
| you would?
| jon-wood wrote:
| I had no idea that detecting coarse pointers was a thing,
| thanks for calling that out!
| asiando wrote:
| Agreed completely. One mistake that designers/developers do
| though is to completely give up under 1000px so we get this
| swaths of whitespace and a hamburger. That's a waste of estate
| and a waste of my time.
| rdsubhas wrote:
| I've found sites using Material UI guidelines (heavy use of
| cards and navbar hamburger) especially culpable to this. Huge
| gap of greyish whitespace with a hamburger in the left.
|
| Someone else mentioned bootstrap in the other thread too.
|
| Maybe because these Frameworks are hugely popular, their
| defaults amplify the impact. Definitely these values are
| tweakable.
| iamben wrote:
| Yeah, I still very often get "here is the desktop design,
| here is the mobile design". Depending on who is developing
| the designs depends how that's going to translate.
|
| I have all the time in the world for developers that reflow
| the page and remove/adjust elements at different breakpoints
| (based on the design) between 'desktop' and 'mobile' so the
| experience is good for everyone. Sadly, most people don't
| bother.
| tehbeard wrote:
| Convincing a client to pay for time to spend checking the
| design and tweaking it in the space between the breakpoints
| can be more hassle than it's worth.
|
| That said, sane breakpoints can usually avoid unexpected
| hamburgers on the desktop.
| dstick wrote:
| Agreed, Tablet is the only intermediate I consider. The
| rest is just not worth the time investment.
| iamben wrote:
| What tablet? Aren't we talking pretty much anything
| between about ~500px and ~1200px here? That's pretty much
| tablet zone...
| DangerousPie wrote:
| If desktop + mobile make up >95% of your audience it's hard
| to justify the cost of creating a third set of rules for
| the rest.
| reaperducer wrote:
| That makes sense on the surface, but you should design
| for all possibilities, current and future.
|
| I learned this lesson the hard way. The client was on
| desktop. The users were 40% phones. Everything was great
| for months and months.
|
| Then one day the owner of the company that owned the
| company tried to look at the web site on her grandkid's
| iPad. Fan met shit that day.
| owlmirror wrote:
| that's something I don't understand. the Dev tools in
| Chrome and Firefox make it really easy to test through
| every resolution without problems. every UI change I make
| I view in all possible resolutions and its quite obvious
| of something breaks and I adjust accordingly.
| DangerousPie wrote:
| The tooling isn't the problem, time is. Every device and
| resolution you support takes time and at some point you
| hit a point of diminishing returns.
| jspash wrote:
| For my day job working on a UK e-commerce site that gets
| roughly 100,000 uniques a day, our split is 70/30 for
| mobile/desktop. Unfortunately within the company it's
| closer to 1/99. So no matter how many times I repeat the
| phrase "mobile first", the higher-ups just don't get it.
| Luckily I can make rational decisions for them!
| iamben wrote:
| I like to start on the desktop but build in a way I know
| the objects will flow. Then I set up a tester with a
| bunch of breakpoints and check as I go and make micro
| adjustments to each element that is "off". Then you can
| set the element inspector to the side and just keep
| shrinking the screen to make sure nothing is awry as the
| width gets less and less. I don't really have X sets of
| 'rules', just elements adjusting at the point it feels
| right to adjust them.
| prox wrote:
| I believe true webdesigners are in decline. You have lots
| of people who do this as a side gig after reading a few
| tutorials. In a way that's a nice compliment for the
| accessibility of the tech, but not accessibility for the
| end user.
|
| Same with "We only tested this on Chrome." of sites/apps,
| of which are there are many, as I can attest, as I never
| use Chrome.
| mywittyname wrote:
| It's just plain hard to keep up with front-end tech. Most
| people use front-end dev work as an entry point. They
| quickly realize there are more sane jobs available on the
| backend and migrate there.
| jefftk wrote:
| _> I believe true webdesigners are in decline. You have
| lots of people who do this as a side gig after reading a
| few tutorials._
|
| In decline from when? Picking it up after reading a few
| tutorials has always been a common way to get into web
| work, and if anything I feel like it's been getting more
| professionalized over the last twenty years.
| prox wrote:
| Just the general gist over the last few years. I am not
| saying there are no really skilled professionals, I am
| just seeing a lot of lower par work from jobs I take
| over. Plus just by surfing the web and noting the
| quality.
| silon42 wrote:
| IMNSHO, more or less the case since they stopped using
| tables for layout.
| devmunchies wrote:
| > sites/apps
|
| I don't think apps are as relevant to current discussion.
| For apps (not public websites), there are different
| requirements depending on the target audience.
|
| I wouldn't be mad at a B2B web app being desktop only, no
| mobile CSS.
|
| But I agree that web apps should still be compliant with
| safari + FF + Chrome.
| AlchemistCamp wrote:
| I've emailed one of YC's huge successes multiple times over
| years about how it's frustrating to have horizontal scrolling
| on a browser that's half of a 1080p display wide (i.e.,
| nearly 1000px).
|
| Unfortunately, the horizontal scrolling UX with substantial
| wasted whitespace on the sides remains.
| andylynch wrote:
| It could be worse. One particular web app I use daily has
| horizontal scroll bars even when full screen (and has some
| off the main info at far right).
| ansible wrote:
| Name and shame. That's the only way it gets better.
| pmalynin wrote:
| Sounds like the Azure Dashboard, but I haven't used it in
| years
| jiofih wrote:
| For some reason people adopted 1040px-1080px as a default - I
| think it's twitter Bootstrap's fault. 980 or even less is
| much more reasonable.
| sn_master wrote:
| I can't use HackerNews on my monitor without scaling. If I
| press Ctrl+0 on Chrome, the site becomes unusable.
| jefftk wrote:
| HN has chosen to use very small fonts; I also leave it a bit
| zoomed in.
|
| Specifically, they have: .comment {
| font-size: 9pt; } .commhead { font-
| size: 8pt; }
|
| If I turn off all the site's font-size overrides, I no longer
| need to zoom in.
| ryandrake wrote:
| Personally, I'm not a fan of having a web site designer
| thousands of miles away from me just _decide_ what font and
| text size I should be using to read their web site. Why not
| let the browser more easily control /override this? We
| already have PDF if your content truly needs pixel-perfect
| layout. Browsers have kind of dropped the ball. They're
| limiting user choice and slowly turning into desktop
| publishing platforms rather than being agents of the user.
| int_19h wrote:
| Most browsers have a "minimum font size" setting, which
| would be applicable here.
|
| In general, CSS already provides a bunch of generic font
| families and sizes. So a page _could_ style something as
| e.g. "sans-serif" and "large" - and then the browser
| should figure out what this actually means according to
| user settings. The problem is that very few sites
| actually use these. But for those that do, the browsers
| do the right thing - and, again, most of them let you
| configure what the generic font families map to.
| [deleted]
| peheje wrote:
| Both Chrome and Safari has accessibility features to set
| a minimum font size in their settings page. I can't see
| how it could be easier.
| joveian wrote:
| It could be easier in Firefox where it applies per
| language, with no "just set everything" option (at least
| Latin and Other are needed for english). I highly
| recommend using it, although it does break sites
| occasionally (seems like less often these days).
| sgerenser wrote:
| So it's not just me. I think HN is the only site I use that
| I've bothered to configure custom zoom factor for.
| cratermoon wrote:
| It's definitely not just you. And I really get sick of the
| people saying things like "just zoom" or "set a custom
| minimum font size".
|
| When I read that, I read, "we're ableist and here's a few
| crumbs so we can feel better about ourselves".
| freebreakfast wrote:
| > The author's proposed solution is for sites to use DPI
| instead
|
| This is untenable as well. You'll end up with microscopic
| websites on high DPI phone screens.
| ss64 wrote:
| What I use is @media (pointer: coarse) and (hover: none) { If
| you have a mouse plugged in, you get the desktop design.
| mywittyname wrote:
| This should result in the website knowing that the screen is
| 7" inches (dots-per-inch / dots = inches) across and setting
| the style for small devices.
| freebreakfast wrote:
| This requires the use of JavaScript to style a website.
| mywittyname wrote:
| Is that really an issue? Javascript is basically
| universally supported on the web.
|
| Users with NoScript will just have to live without some
| functionality. I'm sure they are used to that already,
| since a large fraction of websites use JS for styling. (I
| use NoScript)
| freebreakfast wrote:
| > Is that really an issue?
|
| Setting aside the debate about separation of concerns.
| Yes, it has notable performance and UX implications.
|
| > Users with NoScript will just have to live without some
| functionality.
|
| Why should we prioritize OP's use case over that of
| NoScript users?
| brundolf wrote:
| I would add to this that the specific sites in question have
| fairly unreasonable media-queries: The Guardian breaks to
| mobile at 980px, and Just Eat at _1024px_. On my MacBook Pro
| with default scaling, these are both more than 50% the width of
| the monitor; i.e. if I size the window to half-screen, I 'm in
| mobile mode on these sites. For reference, in sites I make I
| usually set the mobile breakpoint closer to 768px (note that
| this isn't a question of increasing pixel-density on phones;
| "CSS pixels" are virtualized to approximate the same physical
| size across devices, though they get affected by display-
| scaling too).
|
| So IMO it just comes down to some sites doing a bad job of
| picking responsive breakpoints.
|
| Edit: Out of curiosity I checked MDN, and their media query
| tutorial has you set the mobile breakpoint at 40em. Default
| font size at least on desktop is 16px (again, virtual pixels
| which scale with display-scaling and device size), which comes
| out to a breakpoint width of 640px:
| https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...
| esrauch wrote:
| iphoneX looks like it has a css px width of 812px. They may
| also be trying to capture tablets, which are pushing above
| 1024 css px.
| brundolf wrote:
| I just checked and the iPhone X has a _height_ of 812px. It
| has a width of 375px. The regular iPad has a width of
| 768px, and the iPad Pro has a width of 1024px. So you could
| be right about them trying to capture all tablets, though a
| hamburger menu on the enormous iPad Pro sounds just as
| ridiculous as it does on a vertical monitor
| yurishimo wrote:
| The hamburger is more for "better" touch navigation
| though. I know these devices work fairly good with
| standard hover type states now, but the UX could be
| argued to be better when optimized for touch inputs.
|
| Sizing is another matter entirely, in which I would
| agree, yea a tiny hamburger menu on an iPad Pro is likely
| bad. We all have engineering budgets though and in the
| grand scheme of things, iPads are likely a small fraction
| of the visitor base for these sites, so I get it.
|
| -\\_(tsu)_/-
| [deleted]
| AzzieElbab wrote:
| Carl- is my friend
| superkuh wrote:
| In the past I'd respond: just because I have javascript disabled
| doesn't mean I'm on a phone. But unfortunately developers have
| dropped supporting HTML completely for even older cell phones.
| There's no more mobile.twitter.com that serves HTML for example.
| nyuszika7h wrote:
| If you set your user agent to Googlebot, you can still access
| the legacy desktop site, but only when logged out.
| KarlTheCool wrote:
| I think the bigger problem is the design pattern of "mobile-mode
| vs desktop-mode". The document isn't meant to escape hatch on
| size, individual elements are.
| parski wrote:
| The first DPI detector site detects my 55" 4K monitor as 442 DPI
| (5120x2880 at 13.3") when entering my resolution and diagonal
| size in inches gives me 80 DPI. The other one detects it as
| 192x192 DPI which is a much larger number. Maybe the first number
| means it should be 80x80 DPI but either way 192x192 is much
| larger. Maybe I'm missing something.
| edent wrote:
| https://dpi.lv/ is _not_ detecting your screen size. It shows
| 13.3 as a default. Type in your real size and it will calculate
| your actual DPI.
| dmitrybrant wrote:
| Just a quick note about a very prominent user of vertical
| screens: Professor Martyn Poliakoff, known for the Periodic
| Videos channel (which I highly recommend).
| https://www.youtube.com/watch?v=Oy8ZMFXS_5E
| swiley wrote:
| At least these sites have a desktop oriented UI. Modern Gnome
| just assumes you're always on a phone (even though the phones
| capable of running Gnome are still extremely niche.)
| ficklepickle wrote:
| Some of that has spilled into Cinnamon DE also. Gedit and
| vlc(?) both have egregious hamburger menus on my Linux desktop.
| Sad.
| awillen wrote:
| As a product manager, my immediate response is... not worth the
| time.
|
| You've chosen to have a unique setup, which is fine, but your use
| case represents some absolutely miniscule fraction of users. On
| top of that, it's not even that websites are unusable, just that
| they're not ideal.
|
| When you decide to do weird/special/unique stuff, don't expect
| the world to adapt to you. You can rotate your monitor back or
| live with it. The idea that companies should spend
| engineering/QA/PM resources to deal with this is... vain.
| TomSwirly wrote:
| > You've chosen to have a unique setup,
|
| But is this unique? Lots of people prefer to have windows that
| are significantly taller than wide - just like books are. I'd
| love to see some hard data on this.
|
| > The idea that companies should spend engineering/QA/PM
| resources to deal with this is... vain.
|
| /eyeroll
| awillen wrote:
| Hah, look at this guy - "lots of people prefer", he says,
| before saying he'd love to see hard data. Feel free to go
| find some hard data, then. I've dealt with a lot of people
| with computers in my personal life and my career, and well
| under 1% of them have had this setup. I'm not going to go
| find data to prove something obvious to a guy on the
| internet. It's like a Trump support insisting there's fraud
| and then telling everyone else to prove there isn't.
|
| Eye roll all you want, but I have dealt with so many
| customers like this as an enterprise software PM. Usually it
| was with Salesforce configurations... my favorite was the guy
| who had a truly bizarre custom Salesforce setup that had two
| copies of every user. I was managing a product that synced
| their data from Salesforce to our product. It was a problem
| for his users of our product that there were duplicate copies
| of every user, and he wanted us to fix that. No sir - when we
| were selling this to you we explained that we sync all
| users... just because you assumed we'd somehow magically
| dedupe yours in your insane setup doesn't make that reality.
|
| You're free to configure the products you use in unique and
| interesting ways. Just don't expect other people who develop
| tools for those products to make them work for your
| configuration.
| speedgoose wrote:
| The author gets a mobile layout not because of the portrait
| mode but because of zooming on the websites. Most responsive
| websites do not care about whether the screen is in portrait
| or landscape.
| marssaxman wrote:
| You don't need to rotate your screen; just shrink your browser.
| I know that lots of people like to use fullscreen windows, but
| that makes me feel claustrophobic; text ought to be formatted
| in narrower columns for comfortable reading, so I like narrower
| browsers. This often fools websites into sending me the phone
| layout, which is unhelpful and annoying.
| NeutronStar wrote:
| So what's your solution? How do we differentiate between a
| tablet user and someone who decided to shrink their windows?
| ironmagma wrote:
| Copying from elsewhere in this thread: `@media (pointer:
| coarse)`
| capableweb wrote:
| Don't think that's quite right either. Pointer coarse
| would just refer to the device used for pointing. Using a
| tablet with a mouse would be "pointer: fine" but it's
| still a tablet.
|
| As always, the issue isn't black and white. There is no
| solution that always works, because it depends on what
| you're targeting. If you want to scale elements to be
| easier clickable for people who might devices where it's
| harder to click/tap accurately, then "pointer: coarse"
| makes sense. If you're thinking about scaling elements on
| the website, some other solution fits better. Which one?
| Again depends on what you're aiming for.
| bmitc wrote:
| > As a product manager, my immediate response is... not worth
| the time.
|
| > When you decide to do weird/special/unique stuff, don't
| expect the world to adapt to you.
|
| > The idea that companies should spend engineering/QA/PM
| resources to deal with this is... vain.
|
| Your response is extremely aggressive.
|
| A vertical monitor or browser windows snapped to half the
| screen of a horizontal monitor are not unique setups.
|
| I'm pretty sick of seeing mobile (read: phone) websites at all
| on anything other than a mobile device. I rarely if ever even
| want to see a mobile website on a tablet.
| SirSavary wrote:
| Seems to me that proper DPI detection might lead to a better
| experience across all "unique" monitor setups, not just this
| one.
|
| Is it extra work? Sure. I thought we referred to that as
| polish.
| ss64 wrote:
| People with disabilities or visual impairments often have
| unusual setups that enable them to read. They didn't CHOOSE to
| be disabled.
| georgyo wrote:
| I just tested all the demo sites on my vertical monitor, and all
| of them look as the "correct" rendering he wants.
|
| Shrinking the viewport so it is toothpick shows me the phone
| screen view. I don't think they are selecting on aspect ratio
| alone.
| rhacker wrote:
| Takeaway: I need to start using units like Inch, Pt, mm instead
| of pixels.
| chrismorgan wrote:
| No. All of those units are defined in terms of CSS pixels.
|
| 1in = 25.4mm = 72pt = 96px
| rhacker wrote:
| Well that's just useless then.
| vehemenz wrote:
| I think many developers/designers ignore device and dpi detection
| now. It has become too complicated, and the benefits are too few.
|
| @media rules with min-width or max-width is really all you need;
| just make sure the breakpoints aren't so ridiculous that you
| serve the "mobile" version of your site to desktop users.
| sime2009 wrote:
| That still doesn't work very well. I have Firefox on one half
| of my 1440p monitor and vertical tabs down the left side. Web
| pages I see are tall and narrow, and many fall back to mobile
| style controls.
| myfonj wrote:
| His proposed solution -- measuring screen size in _physical_
| display points -- is futile.
|
| He writes it directly in his article:
|
| > My monitor's native resolution is [w x h device pixels]. But I
| find the fonts slightly too small at that resolution - _given how
| far I sit from the screen_. [So I use DPI scale factor R, what]
| translates to an effective screen resolution of [w /R x h/R
| virtual (CSS) pixels].
|
| (In his case it is 1080 x 1920 / 1.5 = 720 x 1280). Measuring
| screen dimensions in physical display points, like
| var dppx = window.devicePixelRatio; var screenWidth =
| screen.width * dppx; var screenHeight = screen.height *
| dppx;
|
| reveals nothing about your preferences and conditions.
|
| The moment he decides to get another second vertical monitor and
| put both _just a bit farther_ he will be back on the square one.
|
| You may have super tiny device with super high density display
| close to your nose, look at a screen on opposite side of your
| room that can have same density (what would be a bit wasting
| resources, but anyway) or look at super large billboard screen
| across the road.
|
| Until the page will know exactly: - how far is the screen from
| eye of its observer, - observer's eyesight conditions, - and
| observer's perceived visual size preferences, there will be no
| way to solve virtual pixel problem the way that will make
| everyone happy.
|
| (And that's quite OK, I think.)
| madeofpalk wrote:
| I'm kind of confused about this - I'm sure the author experiences
| real problems, but I wonder if there's something else at play
| here?
|
| I've never actually seen screen aspect ratio media queries used
| in practice, nor have I really seen them advocated for. When I
| load www.theguardian.com on my portrait monitor (1441 x 2561) I
| get the desktop layout https://imgur.com/a/ZpUI95Z
|
| Absolutely yes design your breakpoints around screen width. Using
| aspect ratio seems like a poor choice.
| asiando wrote:
| The author is actually complaining about narrow viewports and
| not about portrait orientations, without even realizing it.
| madeofpalk wrote:
| Even then - when I set my resolution to the same 1080 x 1920
| the author states, The Guardian still renders the "desktop"
| layout. The more compact layout from the doesn't kick in
| until 739px.
|
| Maybe it's their font-scaling settings are getting in the way
| and changing the viewport resolution?
| patriarchybad wrote:
| most websites dont work well on small screens because of the
|
| modern ui with all of the extra spacing
|
| this issue affects women particularly because we have
|
| smaller hands and so use smaller screens
|
| its yet anther example of how tech designed for men keeps
|
| women out of tech, a vicious cycle
|
| material design is perpetuating internalized misogyny
|
| edit: and of course my comment is dead thats the kind of
|
| behavior tolerated on the angry orange site
|
| edit 2: i am formatting this comment to a narrow width
|
| to be more friendly to smaller screens especially those
|
| used by women
|
| edit 3: i now realize that my comments exclude trans women
|
| who may have larger hands
|
| there was no transphobic intent in my remark simply that
|
| since trans women are a smaller segment of women women
|
| on average have smaller hands
| TeMPOraL wrote:
| Wait, so sniffing on screen resolution is _the_ way web
| developers distinguish desktops from mobile? _That 's just
| crazy_.
|
| There should IMO be a preference sent, "I'm on a portable, touch-
| enabled device". I'm guessing it doesn't exist because it would
| add a bit to the fingerprint.
| jefftk wrote:
| In this case, "portable, touch enabled device" wouldn't match
| what we're talking about. Someone with a large tablet should
| receive the version optimized for larger screens.
|
| The website is saying "if your screen is at least this big, I'm
| going to show you the version for big screens". The OP has an
| unusual setup where their big screen is reporting as a smaller
| screen.
| masklinn wrote:
| > Someone with a large tablet should receive the version
| optimized for larger screens.
|
| Not necessarily, because the "smaller screen" layout tends to
| be linked to the touch one e.g. larger active targets, while
| the "large screen" layout is optimised for precise pointing
| devices (mice) and may be nigh impossible to interact with
| using fingers.
| madeofpalk wrote:
| Well, if you want to change for interactions, we have
| @media (pointer: coarse) and @media (pointer: fine) for
| that.
| bryanrasmussen wrote:
| the way that web developers generally do responsive design is
| to use media queries checking the width of the screen they are
| on, as opposed to the device width.
|
| This is the suggested way because if you check the device width
| you know that they are on a small device and thus probably
| mobile but your styling changes for small windows (less wide
| windows) do not get applied, so 'best practice' is to check the
| actual screen width. Hardly anyone checks the height because
| for web development height is generally not that important.
|
| But this is often not useful because a lot of web solutions
| style things based on JavaScript and CSS and while the CSS will
| rerender automatically based on changing the screen size the
| JavaScript needs to detect you've changed the screen size and
| then rerender. So then there is a discussion as to how many
| people really resize the windows and do we need to catch this
| resize to do a rerender even though doing so is irritating and
| can be a resource hog (fixable by extra code but maybe better
| not to code at all!)
|
| But there are lots of other ways to detect if you are on a
| mobile device, you can detect if touch screen events are
| enabled etc. but then what if you have one of those weird
| desktops that became possible a few years ago (I nearly wrote
| popular instead of possible) where your laptop's monitor also
| has touch screen events.
|
| As a general rule it is best to do things based on the capacity
| of the system, and not by what type of system it is, but as the
| capabilities of our systems exist in infinite combinations it
| follows some things will just fall through no matter how
| exacting you try to be - maybe especially if you try to be too
| exacting.
| masklinn wrote:
| > Wait, so sniffing on screen resolution is the way web
| developers distinguish desktops from mobile?
|
| There's really no other information since "physical" dimensions
| are completely fake: a CSS inch is 96 CSS pixels which are "one
| pixel at 96 dpi at an arm's length".
| madeofpalk wrote:
| Screen resolution is, more or less the best approach.
|
| Layouts need to fit a _size_ , not a device, so that's why
| media queries based on the screen size are usually the best
| approach. If I resize my browser to make it smaller, I should
| get a layout to match that. If I'm using Safari on iPad, docked
| to the side of the screen, I should get a layout to match that.
| These are all about screen sizes, not "mobile vs desktop".
|
| For testing interaction cabailities, there are the @media
| (pointer: coarse) and @media (hover: hover) media queries for
| testing touch vs mouse, and hover capabilities, but it's
| important to not rely on these for mobile vs desktop layouts
| otherwise tomorrow a MS Surface user will post "Just because I
| have a touch screen, doesn't mean I'm on a phone".
| tuckerconnelly wrote:
| Best practice dictates "mobile-first responsive design" with
| "progressive enhancements." So designing first for mobile and
| touchscreens seems ideal, and then adding special features
| for larger resolutions, and, in a separate media query, for
| devices with (hover: hover).
| donatj wrote:
| The general idea with well built responsive design is to build
| a site that works at any width, reflowing as things would
| break. You can try it by just resizing the window of most
| popular sites to be progressively smaller.
|
| It's honestly been a significant improvement over dedicated
| mobile layouts and for the most part works pretty well.
| forgotpwd16 wrote:
| >"I'm on a portable, touch-enabled device".
|
| That's what the user-agent is[0]. And all major browser engines
| have/had a Mobile token on relevant devices.
|
| [0]: https://developer.mozilla.org/en-
| US/docs/Web/HTTP/Browser_de...
| freebreakfast wrote:
| Google is moving toward that not being the case[0].
|
| [0] https://www.zdnet.com/article/google-to-phase-out-user-
| agent...
| forgotpwd16 wrote:
| Client hints (proposed successor) are the same thing but
| more selective. That is a site has to request extra
| information rather being given right away. Among them are
| platform and mobileness.
| wruza wrote:
| Yes, they define a bunch of @media filters in css for different
| _known_ screen widths. You usually get a surprising look when
| pointing out that it is crazy. "How else would you know that?"
|
| Something as simple as "use-case: handheld | bellyheld |
| desktop" property? Css designers missed this opportunity
| completely.
| robertoandred wrote:
| "use-case: handheld | bellyheld | desktop" would give zero
| useful information. How would you detect a desktop with a
| small window?
| tootie wrote:
| It's a bad habit, but it's pretty common. Really, there's two
| distinct things to consider when building responsive design.
| One is viewport size (and really just width in most cases) and
| the other is touch vs mouse. Vertical monitors is one case, but
| so is touch-enabled monitors or mouse-enabled handhelds. Most
| of those are considered small enough edge cases, that it's not
| worth investing. Most websites look kinda crummy if you use a
| phone in landscape too.
|
| I used to insist that designers never say "phone, tablet,
| desktop" and instead say "small, medium and large" but it never
| stuck.
| matsemann wrote:
| > _Wait, so sniffing on screen resolution is the way web
| developers distinguish desktops from mobile? That 's just
| crazy._
|
| No, it's not how it's done. And there is generally no logic
| trying to see if it's a mobile or not. One just have various
| designs for various sizes. When he has a 700px wide display,
| what else can the website do than collapse the content when
| it's not enough space for it?
| fouuler wrote:
| Syntax error.
| nacho2sweet wrote:
| I read this and go "these fools are like ~1% of my visitors?? I
| don't care lmao".
| timw4mail wrote:
| The real problem is that designing for different screen sizes,
| especially with responsive design, is very difficult.
|
| For my personal projects, screen size is the factor used to
| determine layout. Mobile/tablet/laptop/desktop is irrelevant. My
| goal with smaller viewports is to make the layout as similar as
| possible, without the user having to scroll horizontally. Because
| I don't want to change the layout too much, I do not use hidden
| navigation menus.
|
| Hamburger menus are terrible - I see them as a design copout.
| [deleted]
| Nathanael_M wrote:
| I'm curious what your menu solution is. I agree hamburger menus
| besmirch the good name of the hamburger, but for longer menus
| they feel like at least an acceptable solution.
| InfiniteRand wrote:
| I like gear icons, sometimes they don't map to exactly the
| semantics of what is in a menu, but if there are no other
| possible menu elements than I know to go to the gear icon.
|
| I've become used to the hamburger menu, but it still doesn't
| catch my eye (Chrome's now three dot option is even worse at
| this), gear looks noticeably different than the rest of the
| UI and so I can easily spot it for options.
| Hendrikto wrote:
| > Hamburger menus are terrible - I see them as a design copout.
|
| I am genuinely interested in why. The only reason I can think
| of, is that they may me unintuitive, but I think this is
| becoming less and less of a problem.
|
| Hamburger menus are an accepted and pervasive design element.
| That does not means it's good design, but it means that users
| are familiar with the concept. Familiarity goes a long way to
| ensuring good UX.
| zdragnar wrote:
| Just use the word "menu". The hamburger menu (and its cousin,
| the three vertical dots) have no analogy to the real world.
|
| Sure, it has become more common, but for anyone not already
| familiar with it, it is utterly useless. You have to be
| willing to click random things to discover what it does.
|
| From personal experience, I had to train both my wife and
| mother to look for them, neither of whom had the patience
| otherwise to figure out these cute designs. They may be
| common at the sites you look at, but that doesnt help people
| who have only used sites without them, or only used portions
| of sites accessible without clicking on them.
|
| I consider that to be an utter failure.
| madeofpalk wrote:
| There's a lot of "literature" about the shortcomings of
| hamburger menus and "junk drawer navigation" that come up
| when i google the topic.
| dahfizz wrote:
| The real real problem is that so many sites overcomplicate
| their design.
|
| HN works beautifully on any window / screen size.
| matsemann wrote:
| Lolno. I have to make Firefox take only half the screen,
| otherwise HN will render wiiide lines with text. I cannot
| read lines with >200 characters, then I miss the mark when
| jumping to the next line when it's multiple lines in a
| paragraph. HN is also the only site I have zoomed in on
| desktop, as the font is unreadably small on high dpi devices.
|
| And on mobile I find it impossible to hit the upvote arrow.
| t-writescode wrote:
| I prefer that way, way more than going to, for example,
| Github and doing a code review and the website refusing to
| give me more columns to look at in side-by-side view,
| because they think that the number of lines they've enabled
| is perfect and want to have the sides of the screen be full
| of whitespace that you have to modify the layout of the
| website to get rid of.
|
| Or random blog sites that become a narrow column of text
| and a *huge* amount of whitespace on either side.
| ryandrake wrote:
| Browsers should have more say. In a perfect world, the
| web developer should not even need to know the browser's
| width or height, whether it's a phone or computer, or
| what kind of input devices are available. The developer
| should simply provide some kind of semantically tagged
| content (text and images), a list of _suggested_ colors
| and fonts, and let the browser make the final call, based
| on what 's best for the particular platform and screen
| size.
|
| Somehow we've gotten to this world where the web designer
| expects almost-pixel-perfect control over the layout of
| every little thing on the page, user's preference be
| damned. You're not laying out a magazine page in a
| desktop publishing application!
| dahfizz wrote:
| I can read long lines just fine, and I like that the full
| width of the viewport is used.
|
| Because HN is designed so simply, you can trivially get the
| layout you want (half width lines) and I can also get the
| layout I want.
|
| If HN instead tried to artificially limit the viewport in
| code (which is something lots of web developers do), they
| would break all sorts of other use cases for no reason.
| That's what I mean when I say websites tend to
| overcomplicate their design.
| matsemann wrote:
| > _Because HN is designed so simply, you can trivially
| get the layout you want (half width lines) and I can also
| get the layout I want._
|
| Except you're ignoring mobile devices.
| Tagbert wrote:
| No, the say that HN does it works regardless of screen
| width. If the site were to assign a fixed width, it would
| conflict with mobile devices.
| jefftk wrote:
| This is why CSS has "max-width".
| badsectoracula wrote:
| I read HN on mobile all the time, what is the problem
| with it? The only issue i've noticed is being a bit
| harder to tap the show/hide branch icon but it is a minor
| issue.
| pantalaimon wrote:
| That's why i like to keep an 19" TFT screen as a third
| display on my desk, most websites render perfectly on it
| and i can always have a browser in the foreground.
| planb wrote:
| What? I can't count how often I accidentally downvoted a post
| because I can't hit the correct arrow on mobile!
| [deleted]
| DangerousPie wrote:
| HN is almost useless on mobile. Tiny UI elements that are
| hard to hit, people using code blocks for quotes that cut off
| after the first few characters, etc
| falcolas wrote:
| At least it allows for pinch zooming, which is (IMO, of
| course) an acceptable compromise. Maintain readability for
| the text while still making it possible to hit the UI
| elements.
| cptskippy wrote:
| Any site allows pinch zooming if you use Firefox and
| toggle a setting.
|
| That isn't an acceptable compromise, you end up doing a
| lot of horizontal scaling to read block quotes and
| zooming to touch UI elements.
|
| It's not the worst, but it is trivial to do better.
| StillBored wrote:
| It does clamp text at some max width. If you have a couple
| 1440p monitors try stretching the browser window across
| screens.
|
| Its actually one of those cases where the old news print
| model of multiple columns would work well, but that is much
| harder than it should be with CSS, so pretty much no one does
| newsprint style scrolling where you read all the columns and
| then scroll to the next set.
| nobleach wrote:
| Sure. Now let's say you're shopping for a brand new rug for
| your living room. Are you going to buy it from a site the
| looks like HackerNews? If so, I'd venture to say you're in
| the minority. A used rug from Craigslist, perhaps, but a
| brand new rug costing hundreds, you're going to want a site
| that looks VERY professional.
| anon321321323 wrote:
| Actually I've bought rugs and computers from websites not
| much more complex than HN. Both sets of transactions went
| smoothly and quickly with no issues. I wish I could say the
| same for some very flashy websites I've used. On some I
| can't even get a delivery estimate until I've submitted
| credit card etc.
| Robotbeat wrote:
| So you're saying "professional == follows modern design
| fads" as a proxy for how legitimate a site is. And maybe
| you're right that is a somewhat useful (if unreliable)
| proxy for legitimateness, but it's not an argument that
| it's good design.
| ncallaway wrote:
| For a site that sells rugs, good design is design that
| accommodates all users and sells as many rugs as
| possible.
|
| So an accessible site that follows modern design fads is
| probably the best thing to have (if that sells rugs).
| dranka wrote:
| I would definetly pick the store with the hacker newsish
| website!
| jrockway wrote:
| Amazon is a design garbage bin, but it doesn't seem to be
| reducing their sales.
| asiando wrote:
| It's not that hard to display a few paragraphs. It's hard to
| display complex pieces of information while also making them
| look good to the client (which, we should remember, pays our
| bills)
| Spooks wrote:
| HN is a pretty minimal site though - it is just a message
| board.
| alpaca128 wrote:
| Almost all websites are pretty minimal in terms of their
| features, but they're built as if they were an in-browser
| image editor.
|
| Reddit is barely more than HN with pictures and a LOT of
| bloat inbetween. It could be as minimal as 4chan-style
| imageboards if you add voting and a slightly different
| comment view.
|
| Youtube is just a tiled list of thumbnails or an embedded
| video player followed by a list of thumbnails. It could
| work 100% without JS outside of the video controls. Instead
| it's a huge, slow mess. It's also inconsistent; in my case
| it scales the list of videos from subscriptions to about
| 50% of the browser window's width, leaving a chunk of empty
| space on the sides. The startpage with basically the same
| layout always uses the full width.
| dahfizz wrote:
| 100% agree. The kneejerk reaction of "well HN is so
| simple, of course it has a simple design" has the
| causation backwards. You only realize how simple HN is
| _because_ they stick to a simple design!
|
| 99% of websites are (could be) just static text and
| images. Facebook, Reddit, CNN etc could look like HN.
| Amazon could look like craigs list. The amount of sites
| that actually need and are enhanced by JS bloat is very
| low.
| majewsky wrote:
| A message board like HN is more difficult than you think to
| get right across a wide range of screen sizes, just because
| comments can nest many levels deep. HN arguably has
| problems of its own in that regard.
| petters wrote:
| It works beautifully for it's indented audience.
|
| I think many people, my parents included, would have trouble
| navigating HN on a phone. Especially upvote/downvote.
| dec0dedab0de wrote:
| I generally agree. But thumbs up/down is difficult on mobile
| with my fat fingers, even worse since I've had nervr damage.
| falcolas wrote:
| Pinch zooming works on HN, which helps me hit the buttons.
| I might prefer slide-to-action like narwhal's Reddit
| interface, but I'm OK with HN not being quite that fancy.
| oblio wrote:
| And yet quotes don't wrap to any specific size, so you end up
| with an awful horizontal scroll bar.
|
| There is no way to format your text, even stuff that's
| available since MS Word 1.0, such as bold or italic. Even
| science papers have formatting so I don't buy the "overuse of
| styles" BS.
|
| There is no way to have avatars or some other ways to
| distinguish users (or mods!) to make this place feel more
| like a community in real life. I've gotten used to it but it
| still sucks.
|
| The contrast is super low.
|
| HN is an MVP for a super minimalist forum that wouldn't fly
| for any other kind of community except for the intersection
| between hackers and wannabe entrepreneurs.
| thepratt wrote:
| If you weren't aware https://news.ycombinator.com/formatdoc
| may be helpful. There are some basic options for text
| formatting on HN, including italics and bold.
| oblio wrote:
| There is no bold.
| teddyh wrote:
| Are you sure?
| pitaj wrote:
| Stop tricking people. Yes you can use unicode for all
| kinds of fun stuff, but that's not formatting, it's a
| hack.
| teddyh wrote:
| I'm sorry, it was not my intention to mislead anyone.
| Yes, it's all trickery with copy-and-pasted Unicode bold
| characters.
| 0xffff2 wrote:
| >And yet quotes don't wrap to any specific size, so you end
| up with an awful horizontal scroll bar.
|
| HN doesn't have a "quotes" feature. Some users here have
| the unfortunate habit of abusing the code formatting
| feature for quotes.
|
| >There is no way to have avatars or some other ways to
| distinguish users
|
| Thank god. There's a lot I miss about forums, but avatars
| and huge signature blocks are better left in the trashbin
| of history.
| oblio wrote:
| Yes, because avatars and signature blocks (which are
| useless, I agree), couldn't possibly be designed to be
| tasteful and fast to load. Especially avatars. A 30x30
| image of any kind would be enough to convey more info
| about the speaker.
| jfk13 wrote:
| > There is no way to format your text, even stuff that's
| available since MS Word 1.0, such as bold or italic
|
| Are you _entirely_ sure about that?
| oblio wrote:
| Ok, now do bold ;-)
| teddyh wrote:
| You mean like this?
| kps wrote:
| Now try a screen reader (on a mac, _Edit > Speech > Start
| Speaking_ will do nicely).
|
| Spoiler: You mean mathematical sans-serif bold small l,
| mathematical sans-serif bold small i, mathematical sans-
| serif bold small k, mathematical sans-serif bold small e,
| mathematical sans-serif bold small t, mathematical sans-
| serif bold small h, mathematical sans-serif bold small i,
| mathematical sans-serif bold small s?
| oblio wrote:
| There is no formatting support for it, it seems you can
| use Unicode bold formats or something. Doesn't seem
| approachable or trivial...
| jfk13 wrote:
| Yes, I know people do things like that (mostly on
| Twitter, it seems), but I wouldn't recommend it; it'll
| interfere with searchability, copy/paste, etc., and
| generally make the text less interoperable. The
| mathematical alphabets in Unicode are intended for
| specific technical uses where the typeface is an inherent
| part of the symbol's identity, not for styling normal
| text.
| lorenzhs wrote:
| tx@t uwop @psdn stroddns u@^@ NH 'ua@W I
| macintux wrote:
| I'm much happier that it isn't a "proper" community with
| avatars & such, fwiw. Much like I'm not fond of small talk,
| I'm also not fond of the obligations that come with social
| media.
| fasdf1122 wrote:
| For my own ventures, I always use a fixed width layout. Saves
| an almost infinite amount of time, tricky bugs, and therefore a
| lot of $. Designers produce designs and you just take the pixel
| dimensions it always looks good. Done.
|
| OTOH, when clients tell me they want responsive design - no
| problem! It's job security, and I bill by the hour ;)
| grincho wrote:
| Width-based media queries are simply a corrupt idea altogether.
| In addition to the problem complained noted in the post, they
| give rise to other pathological behaviors I encounter daily. I
| increase the zoom of a page to better see an image, only to have
| the image shrink due to a layout change. I shrink a window to
| remove a huge empty margin, only to have the text recede even
| further.
|
| They way they're implemented in browsers, width media queries are
| a UI antipattern. They violate the principle of least
| astonishment because their boundaries are invisible, causing the
| user to be surprised every time.
| newsbinator wrote:
| Author's proposed solution: var dppx =
| window.devicePixelRatio; var screenWidth = screen.width
| * dppx; var screenHeight = screen.height * dppx;
| thinkloop wrote:
| dppx always gives me 1
| rob74 wrote:
| Ironically, the author of dpi.lv (https://lea.verou.me/) doesn't
| even bother to have a "desktop-friendly" site. On desktop
| everything (font, header, images, buttons) is _huge_ and ~50% of
| the vertical space is wasted. Not the best calling card for
| someone living "at the bleeding edge of web standards". Or maybe
| it looks Ok if you view it on a Mac?
| ourcat wrote:
| That's the latest WordPress 'twentytwenty' theme I think.
| rob74 wrote:
| Cool, that's the theme WordPress recommended to use as
| default in 2020? Maybe I should ask them to buy me a Hi-DPI
| monitor... that would display a bit more content, but
| actually I'm afraid the lonely column of text in the middle
| of the screen would look even worse.
| Xevi wrote:
| Holy cr*p, that website consumes 30% CPU in Chrome for me.
| Scrolling lags like hell. Please revoke their web dev license.
| polytely wrote:
| It looks fine on mobile to me, scrolling is free, and filling
| 100% of the screen with information has nothing to do with if a
| person is "at the bleeding edge of web standards".
| rob74 wrote:
| That's my point, it looks (probably?) great on mobile, but on
| desktop it's a mess. Maybe that's what they mean by "bleeding
| edge" - only that it's the eyes of some of the users doing
| the bleeding...
| jeroenhd wrote:
| > I have tried "Fractional Scaling" - it works OK on Wayland, but
| leaves all the fonts looking soft and fuzzy.
|
| Ah, there we go. The real, underlying problem is that the scaling
| that would make this problem go away doesn't work for you.
|
| Scaling the fonts instead of fixing the underlying issue and then
| deciding that all of web development is wrong for optimising for
| CSS pixel count (like one should) instead of manually doing DPI
| calculations (which everyone gets wrong, very often, and probably
| Javascript just to do a basic layout) is a silly solution.
|
| Look for a blurry-font-rendering solution instead of a change-
| the-way-everyone-develops-websites solution, it's a lot easier to
| convince people that it's a real problem.
| marvindanig wrote:
| This is an excellent post. I wrote about the new landscape of the
| web [1] a few weeks ago and how responsive web design is a
| complete failure in addressing that.
|
| There are so many fallacies!
|
| 1. Tablet != mobile. 2. Mobile != Watch. 3. Desktops can be in
| portrait mode. 4. EV Cars like Tesla Model 3/S are closer to
| tablet than desktop.
|
| [1] https://bubblin.io/blog/the-new-landscape-of-the-web
| therealmarv wrote:
| Hm, designed a bunch of websites and never tested for vertical
| desktop screens.
|
| Seems there is failproof solution missing there for recognizing
| tablet, desktop and mobile.
|
| Btw. many websites break also on quadratic screens ;)
| joshxyz wrote:
| I did that vertical monitor orientation before, it's honestly odd
| and a little hilarious trying to read long threads starting from
| top of screen and reaching the bottom screen.
| mixmastamyk wrote:
| I've had a second portrait monitor for about 15 years now, and
| highly recommend it. I don't have many issues possibly due to my
| screens being 4k.
|
| However, the responsive decision point is regarding the width of
| the viewport or window. To my knowledge sites don't care about
| the height at all. So the fact it is in portrait orientation
| (vertical) is not pertinent.
|
| Once in a while I do have to zoom or resize the window if its
| size is not large, but it is not a burden that I really notice.
| tartrate wrote:
| Mobile browsers usually have a "request desktop version"
| checkbox. How does that work then?
| [deleted]
| asiando wrote:
| On iOS it just changes the UA. This means that regular CSS-only
| responsive sites don't change at all, unlike what the other 2
| comments are suggesting. Maybe on Android it's different.
| masklinn wrote:
| The mobile browser uses different viewport information (and
| likely sends a desktop UA string).
| edent wrote:
| In my experience, they change the detected width of the
| viewport. Some also change the User Agent header.
| MisterBastahrd wrote:
| If a client asks for it, I'll do it. Otherwise the use case for
| people with vertically oriented non-phone screens is so tiny that
| it isn't worth the effort. What are we realistically talking
| about here? One in twenty thousand, if that?
| Wistar wrote:
| It is common for serious users of time-line-based animation and
| compositing software as well as layer-based software such as
| Photoshop and Illustrator to use one display in portrait for the
| timelines and layers. I know I do.
|
| I have tried using it for web-viewing, especially to find media
| assets such as stock footage and typefaces but usually have to
| move the browser to portrait because the sites usually don't
| display correctly on portrait.
| g3e0 wrote:
| I feel like I must be missing something, because I don't
| understand this author's point at all.
|
| "Lots of websites think "Vertical Screen == Mobile User"!" No,
| they don't - They think a 720px wide screen is a tablet user,
| which is probably a fair assumption.
|
| I could equally write "Just because I browse zoomed in 500%
| doesn't mean I'm on a mobile"
|
| When you zoom in, things get bigger, so fewer of them will fit on
| the screen... You have a choice between horizontal scrolling, or
| the website showing you the version of itself designed for
| smaller viewports.
|
| Looking at the "How it should render" screens - I just checked
| the Guardian site, and that is exactly how the website looks at
| 1080px wide. The author admits that because of their zoom
| solution they are running at an effective width of 720px, so
| maybe just.. don't do that??
|
| The proposed solution doesn't seem to solve anything, because
| physical size of the screen isn't the full story, it also depends
| on how far away from the screen the user is - which the browser
| can never know.
| jessriedel wrote:
| Why don't browsers tell the server whether the user has a touch
| screen? This seems like a perfectly reasonable thing that the
| website should know before delivering the page, and users who
| are hyper privacy focused could toggle a setting to not send
| this info.
| aembleton wrote:
| A touch screen has @media (pointer: coarse)
|
| CSS can be used to style elements accordingly:
| https://developer.mozilla.org/en-
| US/docs/Web/CSS/@media/poin...
|
| No need to get the server involved.
| TazeTSchnitzel wrote:
| Hell, the sites may just think it means the user has a narrow
| window. And that's reasonable. A nice thing about the
| responsive web is you can have a small browser window and it
| should work.
| t-writescode wrote:
| They don't even think that.
|
| I have one 1920x1080 monitor and one 1440p monitor. On both
| monitors, I regularly make it so that each screen is used by 2
| applications.
|
| A lot of websites think 960x980 is mobile. *half* of a 1080p
| screen.
|
| It's bad and a huge assumption on their part that their website
| should only be seen in full-screen mode, or half of some 4k
| screen when the most popular resolution is ignored in a
| productivity usage.
| hinkley wrote:
| To expand on this, my work responsibilities often but don't
| exclusively involve monitoring logs or graphs, and usually I
| have one monitor dedicated to this. My goal is to encourage
| myself to look at it every time I remember to do so, and
| greasing the wheels means tiling windows so I don't have to
| touch anything. I'm peeking at them like my rear view
| mirrors.
|
| If I haven't set up a vertical monitor, that's two browsers
| with half the screen (or 55% with some clever overlapping to
| clip margins). If I got around to rotating my display, that's
| could be a portrait window or still only 1100 pixels wide.
| vagrantJin wrote:
| Portrait viewing for screens bigger than tablets are edge cases
| of edge cases.
|
| The rabbit hole is websites are supposed to cater for every
| screen size by pixel is ridiculous. At some point the user should
| respectfully use normal orientated/ sized device.
| [deleted]
| donatj wrote:
| I feel like this is a more complex problem to solve than it seems
| at face value or the author implies, especially considering
| tablets of varying dpi.
|
| CSS dpi media queries are unsupported in Safari mobile and
| desktop, so that increases the complexity significantly.
|
| Beyond that, the fact is most web layout is still done in px or
| other non-fraction-of-the-width units, so it's often a matter of
| the wider layout simply being broken at smaller widths, rather
| than just refusing the display.
| simion314 wrote:
| Yeah, I was trying to find a way to create a toolbar with
| buttons and make sure the buttons are not too small or not too
| big. DPI info is not present and different tricks to work
| around this will fail on different phone models.
|
| I wish I could ask the browser "what are the dimensions you the
| browser use for your buttons" so I can use same dimensions too
| and the user could configure this in his browsers and
| everything would follow it.
| jameshart wrote:
| In _theory_ this is what css { font: caption } should do.
| There are other font shorthand's for menu text, icon labels,
| dialog box text, etc. that should clue you in to how a
| particular system UI is scaled, if browsers are doing it
| right. (Of course they also might not because of
| fingerprinting risk)
|
| Note that this is different from { font-family : system-ui }
| which doesn't include size information.
|
| Caniuse sadly doesn't have much info on font: caption
| support.
| asiando wrote:
| There's a good reason why there are no real DPI media queries:
| You should not decide how big things appear on the screen,
| that's up to the user. The user has the ability to change
| resolution or to change the website's zoom level, you should
| never access the real size and decide that a button must be
| exactly 1cm wide in real life on every screen for everyone.
|
| Just design for the default and then people will zoom or change
| resolution if the default isn't enough.
| VPenkov wrote:
| What about the min-resolution media query?
| @media only screen and (-webkit-min-device-pixel-ratio: 1.3),
| only screen and (min-resolution: 120dpi) { /* High
| DPI code */ }
| aimor wrote:
| I remember learning how to get my site to display decently on
| different screen sizes. I got an abridged history of past
| attempts: "handheld" CSS media type, then media features "device-
| height/width, resolution, pointer, orientation, aspect ratio",
| some people try to use the User Agent, others target a huge list
| of specific device resolutions, webkit has a device pixel ratio?,
| it all seemed like a huge mess.
|
| Then it turns out the solution isn't CSS it's the HTML "meta"
| tag: <meta name="viewport"
| content="width=device-width, initial-scale=1.0">
|
| On top of that I use media queries to respond to the font size.
| @media (max-width: 35rem)
|
| I'd love to know if there's a better way, but this has been
| pretty good for me.
| ficklepickle wrote:
| Nope, you pretty much nailed it. That meta tag is crucial.
|
| If you were mobile-first, you'd use min-width media queries
| rather than max-width.
| Robotbeat wrote:
| I wish for once that requesting "Desktop version" on my phone
| would actually give me a desktop view, not the same exact mobile
| view. Sizing based on viewport (a "responsive design" principle
| that I hate) gives me hamburgerized unusable mess.
|
| I want to be able to zoom out to see the same page features as I
| would see on desktop. A lot of websites USED to work this way on
| ios Safari before "responsive design" became a thing. Now,
| there's no way to get a typical website to give you a desktop-
| like layout when you "zoom out" because it automatically detects
| your viewport and forces you to hamburger no matter that you
| selected "Desktop version."
|
| I understand why mobile view exists. It's more comfortable to
| read for probably most people. But by ignoring "request desktop
| site" because of the hubris of "responsive design," it means that
| there's no way for you to get desktop-like functionality &
| experience on your phone browser. That is a reduction in
| functionality from the smartphone experience of 5-10 years ago on
| many site that'd give you a desktop-like layout if you zoomed
| out.
|
| An example of this frustration is that on a forum I frequent, if
| the viewport is below a certain size, user avatar thumbnails are
| hidden and text tables of values are all reflowed to an unusable
| mess where before I could zoom out and get a desktop-like view
| where the tables (which are just fixed-width straight text,
| entered by forum users) could be seen clearly.
|
| The refusal to allow some way to get a real desktop-like view in
| "responsive design" is user-hostile.
| jorams wrote:
| One of the things "Request desktop site" is supposed to do is
| report a larger effective viewport. For a responsive site, that
| should switch it to a desktop view. Does iOS Safari not do
| that?
| Robotbeat wrote:
| Good question. Now that you mention it, I do not know if the
| problem is on iOS Safari or the website. EDIT: I just tried
| it on HN (which is usable enough for me as-is, I'm just using
| it as a test), and it seems my effective viewport remained
| unchanged.
| invalidtaxonomy wrote:
| Some sites go as far as to assume that I'm on mobile because my
| user agent says ARM. I'm getting a mostly blank page on amazon
| unless I'm changing arm to x86_64 in my user agent string, then
| it magically becomes usable.
| ryandrake wrote:
| That's both sad and hilarious! It reminds me of the rumor[1]
| that Microsoft had to go from Windows 8 to Windows 10, skipping
| 9, because too many clueless developers were grepping the
| version string for "Windows 9" in a flawed attempt to detect
| the Windows 95 and Windows 98 operating systems.
|
| 1: https://www.pcworld.com/article/2690724/why-
| windows-10-isnt-...
| aruncis wrote:
| And no one is talking about neck problems.
| cosmodisk wrote:
| Many years ago, when I was a little kid in dark 90s,my dad was
| picking up some cargo from the country's largest dairy company at
| the time. So we end up walking through the narrow passages of the
| production line and eventually end up at the account sitting in
| front of her very modern PC with a vertical screen!It wasn't even
| tilted,it was made that way! I looked at it and it looked so
| impressive. It took many years for me to see again someone using
| a monitor like that.
| egypturnash wrote:
| The "solution" he gives for website devs is to "stop naively
| using screen resolution". But the thing is, an iPhone 12's
| resolution is 2532-by-1170-pixel at 460 ppi - _bigger_ than his
| 1080x1920.
| edent wrote:
| Sure, but the viewport resolution is only 390px wide.
| https://useyourloaf.com/blog/iphone-12-screen-sizes/
| jaywalk wrote:
| The iPhone doesn't report it's "real" resolution, though.
| egypturnash wrote:
| His method of taking reported resolution and multiplying by
| window.devicePixelRatio is designed to work around exactly
| that.
| egypturnash wrote:
| And of course realistically he is probably seeing sites with
| breakpoints built _entirely_ on min-width /max-width, which
| gives the size of the browser canvas.
|
| The Guardian, for instance, has a lot of "@media (max-width:
| 71.24em)" in its CSS. Screen height? Zero fucks given. I turned
| my desktop monitor to portrait and I can change between desktop
| and phone versions by shrinking my desktop window and/or
| changing the font size. Which feels like a perfectly sensible
| way to tackle the problem if you are coming from a place where
| you are thinking in typography.
|
| eat.co.uk? Tons of "@media print, screen and (max-width:
| 768px)". Screen height? What's that?
|
| popsci.com? A lot of "@media screen and (max-width: XXXpx)",
| where XXX varies a lot - every number is different, the lowest
| is 325px and the highest is 1720, someone's been thinking about
| a _lot_ of edge cases in that layout.
|
| ----
|
| The fundamental problem of "I am getting the mobile site on my
| desktop" still applies, but his theories as to why are wrong.
|
| Really I feel like he is sitting in the middle of a very small
| edge case. Not many people use portrait screens on their
| desktop. And of those people, how many are bumping the
| effective resolution by changing the scaling? Finding a
| solution that can work properly for him, and not fuck things up
| for people with failing vision (and maybe even run afoul of
| accessibility laws by doing that) is gonna be a lot of work for
| very little return, and he should just bump his font size down
| a little and live with that, or do some CSS injection on every
| single offending site if he has a _lot_ of time to blow on
| this.
| munk-a wrote:
| It would be really nice if there was something in the browser
| header to indicate whether 1) The user had a touch interface and
| 2) The user had a persistent on-screen cursor (both may be true)
| but, leaking that information also opens the door for more
| accurate browser fingerprinting so I guess, once again, we can't
| have nice things because of advertising.
| darkerside wrote:
| To quote the great Dave Chappelle,
|
| "Just because I am dressed this way... does NOT make me a WHORE"
| naringas wrote:
| "falsehoods developers believe about screens" ?
| mhh__ wrote:
| A collection of deep-deep dives on various topics would be a
| fun thing for someone who can build a nice website to do (You
| don't want to see my attempts at being a designer).
|
| For example, "What every programmer should know about memory"
| covers memory but what about (as you say) screens.
| edent wrote:
| You might enjoy https://github.com/kdeldycke/awesome-
| falsehood
| hombre_fatal wrote:
| No. Just simple heuristics that work for most users at the
| expense of people who admit, like OP's opening statement, "I'm
| a weirdo".
|
| Building responsive client UI is hard. In my experience here,
| the falsehoods HNers believe about clients is that it's somehow
| not hard. Or just a silver bullet away from being easy (like
| replacing JS with $faveLang). Or that resources are infinite
| such that every defect is explained by incompetence (except
| for, presumably, that HNer who is intimately familiar with
| resource finitude in their own life).
| jariel wrote:
| It's 'hard' largely because the standards bodies and browser
| makers fail to provide simple and expedient means to do the
| most basic of operations, making every little thing a
| designer wants to do a giant hack.
|
| For something so universal ... there should be a very clear
| and unambiguous function call and at least a rational way to
| move through the fragmentation molasses.
| patrickaljord wrote:
| More like testing for an infinite number of resolutions is
| expensive so developers only test on the main ones and the ones
| used by hackers on Pop_OS Linux that rotate their screen 90
| degrees are out of luck and default to one of the tested
| resolutions :)
| andreynering wrote:
| On tablets you face this problem all the time, too. Both on
| websites and apps.
| izacus wrote:
| One of the best features of my Lenovo Chromebook Duet (a 10"
| ChromeOS tablet) is that it reports itself as a laptop with
| 1920x1200 screen so you get actually usable webpages and not
| the mobile crap.
| avipars wrote:
| why not use the user-agent?
| jefftk wrote:
| The UA doesn't tell you anything about the screen the person is
| viewing on or the size of their window. If I resize a window on
| my desktop to 450x1000, showing me the layout for narrow
| screens is likely the best option.
| thesuitonym wrote:
| Perhaps the answer is not to change elements on the website,
| but to design the site in such a way that it looks good at
| any resolution.
|
| We used to do this before responsive design took over.
| jefftk wrote:
| Responsive design _is_ about making the site look good at
| any size. Can you give an example of the "old way" vs the
| "responsive design" way?
| bryanrasmussen wrote:
| I was going to say because it's been deprecated but then I saw
| this https://deviceatlas.com/blog/postponed-googles-attempt-
| depre...
| madeofpalk wrote:
| Because a single user agent and present websites at multiple
| sizes.
|
| Consider an iPad which can display a website at three vastly
| different sizes. Full-width, half-width, and roughly 1/5th
| width docked to the site. They should have at least two
| different layouts.
| Nightshaxx wrote:
| What if the person is using an Android phone connected to a
| monitor? As someone said in another thread: you design a view
| for a screen size not a device.
| [deleted]
| sleepybrett wrote:
| user agent?
___________________________________________________________________
(page generated 2021-02-02 23:00 UTC)