[HN Gopher] Just normal web things
___________________________________________________________________
Just normal web things
Author : vitplister
Score : 327 points
Date : 2023-08-05 16:07 UTC (6 hours ago)
(HTM) web link (heather-buchel.com)
(TXT) w3m dump (heather-buchel.com)
| veave wrote:
| >Stop hijacking my typical browser shortcuts for use in your own
| app I've seen this happen with ctrl + f for opening a custom in-
| app search bar. I don't want that. It doesn't always search the
| page as usual.
|
| You can bypass this by selecting the url bar before using ctrl-f.
| rjh29 wrote:
| Ctrl-f is often overriden for a reason, though. On modern
| shitty React sites content outside the viewport may not be
| loaded into the DOM, so the browser find won't even work. It is
| quite frustrating the scroll past some text, ctrl-f for it and
| get "no results".
| shadowgovt wrote:
| Correct. The most common perpetrator of "stealing" ctrl-f I
| use is the Google drive suite (Sheets, Docs, &c) and it's
| basically necessary. That operation is executed server-side.
| The client doesn't _have_ the data to do the search.
|
| But that should be an exception, not the rule.
| eddd-ddde wrote:
| Google at least gets it right, I almost never used a
| generic site's search function cause they never help me
| find what I want
| gxs wrote:
| I hope everyone reads this and listens.
|
| I'll always long for the days of simple websites but I know they
| are gone and that's fine.
|
| The least we could do, however, is preserve some modicum of
| standards and usability.
|
| I'll throw in ability to open images/media as standalone files to
| this list.
| Given_47 wrote:
| > Stop hijacking my typical browser shortcuts for use in your own
| app I've seen this happen with ctrl + f for opening a custom in-
| app search bar.
|
| Ah the Discourse classic. But did you know if you hit ctrl+F
| twice sequentially you can override that annoying behavior!
| ajimix wrote:
| Why bank websites remove the ability to paste? You have already
| copied the text when you realize you cannot paste. So what is the
| point? Writing things by hand are prone to errors and if your
| clipboard is poisoned you have already copied the stuff by the
| time you realize you cannot paste...
| capableweb wrote:
| Usually it starts with a company having issues with robot
| traffic. So they try a bunch of things to hinder the robot(s).
| They do something, the robot stops working, but after a while
| it comes back, it's a cat and mouse game essentially.
|
| One day, they (developers pushed by middle managers) disable
| copy-paste on the login page, and the robot temporary stops
| working, until a couple of days later, when the robot found a
| way around it.
|
| On to the next thing to do to stop the robot, but that previous
| "fix" is still there, with the thinking that "maybe that stops
| some of the robots", but it probably doesn't.
|
| But there it sits, some ~10-ish lines of JS that will hang
| around until rewrite v6 when they'll begin from the beginning,
| and some months/years later come around to disabling it once
| again.
|
| No, I'm absolutely not speaking from experience.
| extraduder_ire wrote:
| IME, middle-clicking on a linuxy computer still works as
| expected most places. I use that far more often than real
| copy/paste.
| epivosism wrote:
| I always imagine there is an "intro to forms programming" which
| includes code to disable copy and paste, and its concepts now
| have thousands of descendants across the web, to the point that
| people start imagining it's a security measure and proactively
| copy it. I agree w/you and don't see the point in stopping
| users from pasting in the first place.
| mgkimsal wrote:
| I don't think it specifically violates any accessibility
| regulations, but preventing pasting has always come across to
| me as an accessibility violation.
| samwillis wrote:
| I hate this so much, was registering for a new ISP the other
| day, they blocked paste in the password inputs and broke my
| password manger. Such an incredible bad decision from a
| security perspective.
| Devasta wrote:
| Not saying this is the case, but there was malware that would
| check to see if you had copied what looked to be a bitcoin
| account and replaced it with its own.
|
| https://techcrunch.com/2018/07/03/new-malware-highjacks-your...
|
| Something like that maybe?
| klabb3 wrote:
| Yeah I also hate this but they have a point. Desktop
| clipboard is a shitshow. Any app can read it willy nilly,
| certainly if focused but I wouldn't be surprised if it works
| in the background on some platforms.
|
| It is one of the prime candidates for a global redesign from
| scratch, including even physical keys (since copy-paste is so
| common, certainly more than say caps lock). All the APIs are
| riddled with decades of tech debt and are entirely platform-
| specific.
| bryanrasmussen wrote:
| maybe they think criminals are too stupid to put a varying
| timer to make keypress times seem natural.
| bobbylarrybobby wrote:
| This is why I have an automation on my computer to type out the
| clipboard character by character.
| bakugo wrote:
| Not only does my bank's website not allow me to paste my
| "password", it doesn't allow me to type it at all. It's insane.
| Said "password" is just a 6 digit number (we're not allowed to
| set our own passwords, because 6 digits is definitely way more
| secure than the 16 character random strings my password manager
| generates) and it forces me to enter it using buttons on the
| page itself with randomized positions. No idea how any of this
| is supposed to help with security, if my device is already
| compromised to the point that all my keypresses and clicks are
| being logged, the attacker can probably also just read the
| password from the browser's memory...
| duderific wrote:
| That's maniacal.
| earthling8118 wrote:
| It's time to find a real bank.
| brigadier132 wrote:
| > nevermind the basic accessibility requirements that are often
| missing like alt text on images
|
| It's easier than ever to make websites accessible and a lot of
| these new tools enable this. Like throwing linter errors when alt
| text is not set on images.
|
| A lot of the things described in this article are issues with a
| lack of skill or maliciousness from the developer or whoever
| hired them. That copy paste thing? I almost always notice it on
| the websites of legacy book publishers. I think you can pretty
| easily guess their motivations.
|
| I dislike react for other reasons but the majority of developers
| having shallow knowledge of how the web works is not one of them.
| That's just nature, the most common thing always ends up going to
| the lowest common denominator. Chocolate: hersheys or nestle,
| coffee: nespresso pods, food: mcdonalds, programming:
| javascript...
| nosefurhairdo wrote:
| Can confirm the pain of working on a react application where
| 90% of the code was written by folks with shallow web
| knowledge. Not the fault of React.
| blorenz wrote:
| I'd wager with the rise of LLMs then we'll get an immense rise
| of accessibility as the LLM can interpret a page in context of
| what the user requires.
| flagsarecolored wrote:
| I agree with the sentiment, but why is this still attributed to
| JavaScript. This applies to essentially everything exposed to UX,
| well beyond JS and web. We didn't JavaScript it away, we bad-
| developered ourselves through a narrowing hallway until a point
| where we ended up with a black sheep. JavaScript didn't enable
| this, there's as many issues in this space in environments where
| JavaScript is not even a player, it may have been a carrier but
| not the root cause.
| austin-cheney wrote:
| I don't blame the developers for this at all. I consider myself
| strong with accessibility and yet at the last job I was
| intimidated to bring it up. There accessibility was an anti-
| pattern. At many places they are just struggling to put text to
| screen. At these places you need a billion lines of code in
| multiple frameworks to display "hello world". How can you blame
| the JavaScript developer when nobody knows what they are doing
| and everybody points fingers at each other?
|
| This doesn't just apply to accessibility. It also applies to
| security, performance, and a variety of other things that never
| happen unless a law suit is coming or a major client stops
| paying.
| yuumei wrote:
| "Stop hijacking my typical browser shortcuts for use in your own
| app" GitHub does this now, it's infuriating
| rado wrote:
| The crazy thing about the rampant inaccessibility is that it's
| clearly illegal and discriminatory and nobody cares. Any success
| stories about convincing product managers to stop it?
| Kiro wrote:
| > Let me copy text so I can paste it.
|
| I'm guilty of doing this because in my game people kept
| accidentally double clicking and selecting all the text in the
| UI. What are the best practices around this?
| noduerme wrote:
| There's nothing wrong with that. A game UI is where you
| _should_ block text selection. Web-based games that let you
| accidentally select UI text look unprofessional. I think the
| author is talking about informational or business apps.
| yonatan8070 wrote:
| I was reading some article a while back, and as I read I like
| to highlight what I'm reading with my mouse, but that
| particular website decided that when I try to highlight text,
| the appropriate reaction from the site would be a tooltip
| saying that highlighting is not allowed... So I opened the
| devtools and copied the whole thing out of spite
| ricardo81 wrote:
| I'd guess it'd be to limit your custom behaviour to the element
| it applies to, rather than potentially the whole doc, or
| multiple pages etc.
| nicbou wrote:
| CSS lets you set that behaviour per element
| shadowgovt wrote:
| In an ideal world, we really should have had another button or
| key combo for "I want to select the text" that isn't overloaded
| on "I want to select in general."
|
| The old way was fine when word processors and other apps were
| completely separate beasts, but the web has blurred all of that
| and we are unfortunately albatross'd to decisions made in the
| past.
|
| I want a fifth mouse button where 5-drag always means "select
| text" independent of all other UI content and as a result all
| text is selectable because text selection and other
| manipulations are totally different operations (at the event
| layer; "mouse down" and "mouse textselect" would be two
| different events).
|
| Wishful thinking; we're stuck with the UI we have.
| creata wrote:
| Imo that's fine. In fact, it's annoying when people (e.g., the
| "5 seconds" rewind in the YouTube player) don't do this.
|
| Even if it's often abused, user-select exists for a reason.
|
| [But if there _is_ some text in your game that you think users
| might ever want to copy, please make it selectable!]
| p1mrx wrote:
| I'm aware of 5 operations that a standard link should support:
|
| - Left-click (obvious)
|
| - Right-click (context menu)
|
| - Middle-click (open in new tab)
|
| - Ctrl-click (open in new tab)
|
| - Shift-click (open in new window)
|
| Most sites support at least one of right/middle/ctrl-click,
| though sometimes you have to Duplicate the tab and then left-
| click. If none work, and duplicating the tab loses context, it's
| probably time to abandon hope and find another website.
| eyelidlessness wrote:
| Note: if at all possible, _don't implement these yourself_!
| You'll very probably do it wrong for at least some users. For
| example, ctrl-click for new tab is platform specific: on macOS
| it should be cmd-click, and ctrl-click should open a context
| menu. Most if not all are or can be user-configurable, which
| might not be detected by JS. But the default behaviors _will do
| the right thing unless you override them_.
| p1mrx wrote:
| I'm the parent commenter and I approve this message.
| samwillis wrote:
| I think of this as the "appification of _websites_ ", we need to
| stop doing it. We need to move back to SSR and sprinkles of JS on
| _websites_.
|
| On the other hand _web apps_ absolutely can play a little more
| with the UX if it provides value to the user. But if it 's in the
| browser, some of this really do still apply. I'm all in on web
| apps, its a universally accessible platform for development
| outside the walled gardens of app stores.
|
| What we need to stop doing is treating _every single website as
| an app_!
|
| If you want your page to appear in search results on a search
| engine, it's not a _web app_ it 's a _website_.
| holoduke wrote:
| On the other hand a good webapp can also be a website. Just
| matter of spending enough time on it.
| satvikpendem wrote:
| > _We need to move back to SSR and sprinkles of JS on
| websites._
|
| Fortunately with stuff like React Server Components, looks like
| we are moving back to sprinkling JS for websites, which I'm a
| big fan of.
| bo1024 wrote:
| You might like this commentary: https://notan.app/
| bunga-bunga wrote:
| I really wish we could have browser "Accept: text/markdown" for
| raw documents, but that boat sailed the moment we got CSS.
| aerzen wrote:
| Why though? We could have the browser apply the styles. And
| even allow user preferences to affect the presentation! kinda
| like firefox "article mode".
|
| But that text/markdown would have to be restricted not to
| include any html tags, which are allowed in the "common" md
| spec.
| bob1029 wrote:
| > Let me zoom in on my browser without the website getting all
| out of whack. I just want to be able to read.
|
| This is my new OCD obsession when doing layout. I will keep my
| browser at 250% zoom for the first 3-4 hours of development.
| Periodically, I will spot test things like tables up to 500%.
|
| I had no respect for the humble non-breaking space or automatic
| table layouts until I started doing this.
| agumonkey wrote:
| It's hard to focus on this, even though I agree 100% with the
| whole list, when you're developing on react.
| shadowgovt wrote:
| I'd be interested in more information on the difficulties
| you've encountered. I do most of my web dev in React and I
| don't remember encountering difficulties with these items.
| muhehe wrote:
| One of many things I hate on crappy modern web is messing with
| history (API). You click a interesting-looking link somewhere
| (like HN), go to page. You scroll down, either reading or just
| skimming, and every funcking header (or even something less
| important) add entry to you history. To get back to original site
| you have to click back like a million times.
|
| Fuck everyone who does that.
| firefoxd wrote:
| One thing that happens when you learn to build web things using
| React before learning html, is that you don't care about links.
|
| When I joined my team, all links were buttons, random elements,
| or <a> with onClick. Nobody complained, but that meant ctrl click
| was useless, right click did not give you the options you wanted.
|
| This is the only thing I'm a dictator about. There is zero room
| for negotiation when it comes to links.
| noman-land wrote:
| I'm the same way. If someone is committing code that violates
| web standards it is not going in unless there's a thorough
| discussion and an excellent reason for doing so. Lean on the
| web.
| sonofhans wrote:
| Oh, you and the OP are both making me happy. Plenty of people
| seem to use nothing but DIV, SPAN, and maybe A or BUTTON. You
| don't have to use all the semantic richness of HTML, but
| damn, at least treat links right. The <a onclick> pattern is
| awful.
| trealira wrote:
| Since we're on the topic of how people should learn to build
| web things: what do you think are the most important things to
| learn first to make web stuff? The "right" way? Just raw HTML,
| CSS, and some JavaScript (Typescript?)? It seems common among
| programmers to criticize the overuse of web frameworks. Are
| there a lot of people who learn only web frameworks?
| satvikpendem wrote:
| > _Are there a lot of people who learn only web frameworks?_
|
| Yes, because many people learn web development through
| bootcamps or other such courses (modern web dev is not
| usually taught in college, in my experience) which rush you
| to "job readiness" thus incentivizing using React over
| vanilla JS since most web dev jobs use React nowadays.
| blq10 wrote:
| What would a college that aimed to teach Web Development as
| a specialty actually look like?
|
| People look down on bootcampers, but it always feels to me
| that 99% of what is taught in university programs is
| similarly only useful in specialized situations. The actual
| good thing is having had to sit down and write a _lot_ of
| code before anyone lets you touch anything.
|
| What does such a program look like for Web?
| josephg wrote:
| > what do you think are the most important things to learn
| first to make web stuff? The "right" way? Just raw HTML, CSS,
| and some JavaScript (Typescript?)?
|
| Yes. I think all web programmers need to know HTML and CSS.
| CSS is still just as relevant no matter how you build
| websites. People should also spend time learning HTML. Like,
| learn how to make content using raw HTML. Read the HTML of
| some of your favorite sites. This will improve everything you
| do with react and friends.
|
| > Are there a lot of people who learn only web frameworks?
|
| Yes.
|
| Web programming probably has more programming beginners than
| any other area of software development. Its easy to learn -
| there are no C pointers in sight and no manual memory
| management. Websites work everywhere. And everyone needs a
| website - so there's lots of demand for web programmers. The
| debugging tools are also great (and you already have them if
| you have chrome installed). And frontend engineering is
| visual and obvious - so when you mess it up, you can usually
| tell.
|
| So, yes. There's lots of people who learn _just enough_ to
| scrape by and start making websites. Its great and terrible.
| I 'm glad web programming is such an on-ramp for beginners.
| But npm is a disaster, and lots of websites are insecure,
| slow, amateurish messes.
| pjmlp wrote:
| The coolest framework of them all, vanilaJS.
| firefoxd wrote:
| I think it's still a good idea to learn by writing HTML
| pages, then adding a style and script tag in the head. The
| scripts and styles become enhancements to the page.
|
| If you go to a code bootcamp, you are learning react. A lot
| of new developers come from these places. Not a bad thing,
| but they could spend more time on fundamentals
| sergiotapia wrote:
| This is one of the first things I changed at a new job. I just
| opened a PR and made the change without asking anyone. It
| infriuriates me when apps can't Ctrl+click.
| notantigoogle wrote:
| You should go work for pornhub since their links don't work
| like links
| moron4hire wrote:
| The whole _site_ now doesn 't work here in Virginia.
| MostlyStable wrote:
| This is probably 50% of the reason I use nitter instead of
| twitter. Aside from not having to have an account, it lets me
| right click to open tweet threads in a new tab. Which, given
| the nature of twitter conversations, seems like pretty key
| behavior! I want to be able to view conversational threads, but
| I also want to keep my place in the original page so that I can
| keep opening new threads! It's really not that hard and the
| actual twitter UI makes it very difficult (although you can get
| around it with some browser tweaks, but it's still more
| annoying than a simple right click)
| SilasX wrote:
| Ugh. Yes. Bane of my web existence: a site will have a list
| view and a detail view. Can't right click (or use extensions)
| to open one item in its detail view.
|
| Even then, it would _almost_ be forgivable if going back to
| list view (via their button or the browser button) were instant
| and seamless, but...
|
| _It never is!_ Going back means waiting for all the content to
| reload again and losing my position.
|
| Why do you designers keep allowing this?
|
| Edit: and for the final kick in the balls, some websites force
| all tabs to be the same in some respect! Like, Facebook makes
| it (or at least did one time) so that you have to have the same
| chats popped up in every tab. If you close one in one tab, it
| closes in all other tabs. _Why?!_ There's a _reason_ I have
| multiple tabs open!
| scatters wrote:
| Sometimes you can duplicate the tab then open the detail view
| in the duplicate. I agree, it's ridiculous.
| iamnotjay wrote:
| I never knew <a onClick > was a thing :D nice thread
| 1vuio0pswjnm7 wrote:
| Is it possible the absence of "links" is unintentional.
|
| As a web user, this sort of "design" has made me focus as a
| practical matter more on HTTP (requests) instead of HTML
| (links). It's easy for me to make the links myself once I know
| where the requests need to go.
|
| It's easy to take JSON and make own HTML. No Javascript needed.
| cowsandmilk wrote:
| I've run into this, but it is coming from the UX designer for
| the product. There is an organization component library, with a
| corresponding figma library. They insist on using the button
| component instead of the link component.
| chefandy wrote:
| Specifying button-looking elements for regular navigation
| actions is definitely wrong, and nearly all UX and UI
| designers will understand that.
|
| If it triggers an action with consequences, or even navigates
| users to a single-purpose page where they can select options
| or confirm the action-- e.g. 'cancel subscription now' or
| similar-- then it probably should look like a button.
| tough wrote:
| <Button as={Link} />
| nosefurhairdo wrote:
| Most react component libraries correctly return <a> tags for
| <Button /> components with an href property, while still
| styling them as buttons. This preserves the expected link
| behaviors while satisfying the design obsession with buttons
| over traditional links.
| bunga-bunga wrote:
| Same boat. My blood pressure increased just reading your
| comment. The web is run by a bunch of amateurs who don't know
| the single core concept of the web: links.
| varrock wrote:
| I'd argue the link is the most influential and historic element
| of the web. Its behavior should rightfully be preserved.
| GloomyBoots wrote:
| The link and the URL are what made hypertext hyper. They
| turned words in a document into portals to other documents.
|
| But that web isn't the one we're dealing with anymore. We've
| moved from documents to applications. Like tabindex, I'm sure
| browsers or frameworks will gradually find ways to make any
| element behave link-like in every way. Which isn't really a
| bad thing, it's just development of the core idea of the web.
| KRAKRISMOTT wrote:
| It also made things slow. Modern SPA links have pre loading
| optimizations baked in. It's quite important especially if
| your users are on mobile.
| tough wrote:
| But not all buttons are links surely?
| traverseda wrote:
| They should for accessibility reasons. If they're not
| assistive tools might not know they're even click-able.
|
| Maybe if you're doing like a painting app or something you
| don't need to.
| Raicuparta wrote:
| Button elements and other clickable elements are all
| detected by accessibility tools as such. If links were the
| only thing they could click, the modern web would be almost
| completely unusable, which isn't the case.
| nosefurhairdo wrote:
| Of course not, but if your button pushes/replaces history
| then it should be an <a> tag with an href property.
| [deleted]
| dpacmittal wrote:
| The new reddit web version has all the links as buttons. You
| cannot open these links in a new tab. It drives me crazy and
| really strange that such a huge internet giant gas such glaring
| accessibility issues.
| maximinus_thrax wrote:
| > This is the only thing I'm a dictator about. There is zero
| room for negotiation when it comes to links.
|
| This is a hill I'm always willing to die on. Few things bother
| me more. Maybe fucking with my browser history...
| Buttons840 wrote:
| Finish the story. Did you die on this hill?
|
| Whenever I push for things that are technically correct I'm
| ignored and/or not treated well it seems.
| BlargMcLarg wrote:
| Wait until you get asked, by CTOs and business people, to
| disable F5/refreshing because it breaks the process flow
| but building a resilient process flow into an old app takes
| 10x-100x as long. Only for them to realize if you restart
| the system, disconnect the network, have a timeout, etc.
| the problem still exists. They even contemplated physically
| removing F5 before realizing "wait people can just click
| refresh or remap F5, that won't work".
|
| Same people will also claim "we don't need a frontend dev
| or a UX designer".
| Swizec wrote:
| I always attempt to die on the links should be links hill.
| So far the only times I didn't get my way was when the
| thing was in fact semantically a button, it just happened
| to use navigation to achieve its aim. Usually in these
| cases the markup is too complex to shove into a link
| anyway.
|
| Happy to report that our production site has more links
| that look like buttons than it does buttons that act like
| links. It's almost a meme on my team that Swiz will get you
| if you use onClick for navigation.
|
| The other hill I enjoy defending is that we should use more
| browser built-in components instead of trying to design our
| own.
| butterNaN wrote:
| Another reason why we shouldn't lose control of our own browsers.
| Today I can set my own fonts, block elements, basically re-style
| everything once it arrives at my browser, tailored to my
| accessibility preferences.
| archerx wrote:
| I agree with everything in this post and the thing that gets me
| the most is broken back buttons on ecommerce sits.
| simonbarker87 wrote:
| Here here!
|
| On the last point, the sites that hijack ctrl-f (or CMD-f) often
| let you through to the normal page browser search with a second
| attempts at it if their search UI is still on the page.
|
| So on the sites I know do it I just double tap CMD-f and I get
| the normal page search.
| megous wrote:
| And often they don't give a poopoo, like github.com.
| hansoolo wrote:
| I totally agree with all of this. But:
|
| >Let me see scroll bars Please don't hide them for the sake of
| your "slick" ui. Sometimes I want to click on the scrollbar and
| drag it. Just a normal web thing.
|
| I don't see any on FF Android :P
| lapcat wrote:
| [self-promotion] The article author appears to be using Windows,
| but on Mac and iOS there's StopTheMadness:
| https://underpassapp.com/StopTheMadness/
| bobbylarrybobby wrote:
| One of my favorite extensions!
| austin-cheney wrote:
| There are really only two problems here, and they are as old as
| the web itself:
|
| 1) Low Expectations
|
| 2) No definitions, standards, baselines defining people and/or
| practice
|
| As I have been looking at job posts quite a bit lately everything
| now is a "Senior Fullstack Engineer" position. This is just so
| lazy. Then you dive into it and what they really want is some
| combination of Java or Python, R, Spring, and SQL. Not fullstack.
| You are wasting peoples' time and worse you are advertising to
| the public that you either don't understand the technology or
| just don't care about it.
|
| Sigh.
|
| In programming we call this an "X/Y" problem. You want to solve
| for "X", a desired end state. Instead of X all you can talk about
| is "Y", the approach you wish you could take. This is a
| tremendous anti-pattern. Its also why employers are getting 500
| resumes for open positions and nobody seems qualified.
|
| Instead start with the goal: "We are hiring to build a
| client/server app that can do '_____'. We expect candidates to
| write/support features X, Y, Z. Your constraints are: A, B, C."
| The reason why companies don't do this is typically because they
| have no idea what they are actually doing and they have also gone
| down several wrong paths already and have a bunch of broken
| technology to support. That's why they call this tech debt.
|
| Then when it comes to interview time the employer and the
| candidates know exactly what the goals are and can ask the
| appropriate questions to appropriately eliminate each other.
| Otherwise, its just some horrible combination of a blind date and
| a game show where an audience gets to ridicule the contestants.
|
| Here is a quick hypothetical example:
|
| We are hiring to build a highly distributed media conferencing
| application. Developers are expected to write TypeScript, pipe
| stream data from sockets, work both in the browser and the
| server, and write test automation. Operating constraints include
| WCAG AA conformance, a privacy conformance checklist drafted by
| our legal department, and various performance considerations
| targeting both execution speed and network latency. Ideal
| candidates will demonstrate solutions during interview time for
| network latency, writing application logic in the browser, and
| state management of streamed data.
| megous wrote:
| Yeah, this is a life saver, for those affected by a recent fad:
| window.addEventListener('keydown', ev => { if
| ('kf'.indexOf(ev.key) >= 0 && ev.ctrlKey)
| ev.stopPropagation() }, true);
|
| For me this goes into a global userscript until browsers put back
| control into user's hands.
| Cyykratahk wrote:
| I believe most of the issues with broken link behaviour results
| from the lack of higher-level methods to override the default
| link behaviour.
|
| An example: I don't really want to add a click event listener to
| a link to make it display in a modal (or whatever). Because this
| event is too low-level and now my listener needs to check
| modifier keys. What I _really_ want is to somehow tell the
| browser "if the current window URL is about to change via this
| anchor element, call this function instead". The user is still
| free to open their links in new windows or tabs and my code will
| not be triggered for those cases.
|
| A CSS example: I don't really want to set cursor images for every
| element and pseudo-class. I'm forced to list every element that
| uses the cursor I'm overriding. What I _really_ want is to tell
| the browser "use this custom cursor image wherever you were
| going to use the default (hand/wait/resize/etc) cursor". My code
| would then be future-proofed for new elements/UI.
|
| Sometimes I feel that certain browser APIs suffer from the XY
| problem.
| josephg wrote:
| > What I really want is to somehow tell the browser "if the
| current window URL is about to change via this anchor element,
| call this function instead".
|
| This is pretty doable using javascript - just register an
| onclick on the <a> tag and have your event handler cancel the
| default navigation behaviour. Your website will then continue
| to work great even if the user has javascript disabled. And all
| the built in browser behaviour (like the right click "link"
| menu, and ctrl+click) still works perfectly.
|
| That said, this is a pretty obscure "trick". It would certainly
| be nice if the DOM API made this easier to do.
| wwweston wrote:
| Is there really anything easier to do? If you're disabling
| the default event, you're doing it to provide some other
| functionality, which is necessarily going to involve writing
| a function to attach to a handler, and adding
| event.preventDefault() at the top is about as easy as it
| gets. Anything easier would involve eliminating the attached
| handler, which doesn't make a lot of sense.
|
| Also, .preventDefault() wasn't obscure in the jQuery era; if
| it's obscure now that's a sad commentary.
| bunga-bunga wrote:
| Finally I read my sentiment online. We don't need clicks nor
| pointer events, we need high-level "visit" event.
| amelius wrote:
| We need a tool that can visit a website, build a summary out of
| it, and presents it in a standard way, customizable by the user.
| Like reader mode, but on steroids.
| RGBCube wrote:
| AI powered Reader Mode, there's your startup idea.
| Waterluvian wrote:
| This blog doesn't touch on the actual issue at hand: businesses
| make business decisions, not engineering decisions. It's easy to
| enumerate a bunch of technical asks and then blame their absence
| on technical reasons, because it doesn't require any exploration
| of the business details. It stays in a nice, safe realm.
|
| To be clear, I personally agree with, and want every single item
| listed in this blog. I'm a big nerd. But I also recognize that
| I'm nowhere near anything resembling a typical user. What I want
| is probably not even on the radar of 99% of users of these
| websites.
|
| It's easy to say, "I want X and having X would make me a happier
| user." The real question is, "is implementing X an appropriate
| expenditure of resources if the goal is to build a profitable
| business?" Usually not. Most users don't know or don't care about
| X. Be careful with the nerd echo chamber we live in that makes us
| think these things matter to the common person.
|
| For all of this, one could argue, "yeah but they're being
| foolish. Long term this is going to bite them." You might be
| right! I think you're right, too. But that's a business position,
| not a technical one.
| megous wrote:
| > is implementing X an appropriate expenditure of resources
|
| Lot of these things just require devs to not actively try to
| damage the usability of the defaults. It costs money to break
| the basics that work for free:
|
| - missing keyboard focus indicator? yeah, dev had to go out of
| his way to remove it, instead of just doing nothing and
| focusing on the job/content
|
| - can't paste into inputs? someone had to think about
| preventing this and implemented it
|
| - ctrl+k / ctrl+f is broken? it works if you just write you
| page and do nothing extra!
|
| - page is blank for people with JS disabled? someone wasted
| money on a person who had to learn a whole damn programming
| language and multi-billion dollar company's framework instead
| of just html/css
| Julesman wrote:
| Someone those businesses hired sold them on shortcuts that are
| just bad. Trading UX for production speed isn't a thing.
| Claiming bad UX is a business decision isn't a thing. Bad UX is
| bad for business. Sure, some of these concerns aren't as
| important as others. But generally speaking, the idea that
| saving time on development at the expense of observing very
| basic UI conventions is just silly.
| kijin wrote:
| For many businesses, there's a simple incentive that should
| make them care: SEO.
|
| Although Google and other search engines have said for more
| than a decade that their bots can execute javascript and
| navigate SPAs, the truth is that they are not going to simulate
| a click on every random element with onClick events attached.
| In many cases, they will not even execute any javascript.
|
| Even in 2023, <a href="URL"> is the best way to make search
| engines pay attention.
|
| Popular frontend development patterns have also made it nearly
| impossible to figure out the semantic structure of a page.
| Everything is a <div> now. But if you care about how your
| website looks in a search result, you might still want to
| designate some parts of the page as <main> or <article> and
| other parts as <aside> or <nav>. This is especially important
| if your website contains short user-generated snippets (like
| tweets) along with a lot of auxiliary information, as semantic
| tags make it easier for search engines to determine what the
| main content of each URL is.
|
| In short, many websites would still benefit from enforcing
| proper semantic markup, like we used to do in the good ol' days
| of the "no tables for layout" crusade.
|
| Now if the business doesn't care about SEO at all (an
| increasingly common attitude as websites become app-ified),
| there's always the atomic option: talk to the legal department
| about the possible consequences of ignoring accessibility.
| jfarmer wrote:
| Love this.
|
| The way I think about it is that you assume a level of
| responsibility whenever you tinker with default affordances. Your
| "feature" isn't restricted to whatever narrow conception or
| intention you had when you designed it. It consists in the
| totality of a visitor's _actual_ experience.
|
| If I change the logic of the the back button, I'm changing what
| the back button _affords_ on this particular website and become
| responsible for whatever happens as a result.
|
| That includes confused and frustrated users saying "Screw you and
| your broken website."
|
| Or take, e.g., the way scrollbars work, which can be very
| browser-and-OS-specific. Are you _sure_ you want to assume
| responsibility for that? How sensitive are you to the downside,
| _really_?
|
| Essentially, you're making your website speak a kind of creole.
| You've forgone any right to be upset if your visitors don't speak
| it and shouldn't be surprised if they persist in
| "misinterpreting" it.
|
| Forget about avoiding such "features" because you want to be nice
| to your visitors. It always seemed to me they offer limited
| upside and unlimited downside.
| loeber wrote:
| Yep, this is exactly right. Websites benefit from _design
| idioms_ that have been carefully crafted over many years. Every
| website that disregards these idioms makes itself harder to use
| because it doesn't speak the same language as what the user is
| (perhaps without noticing) used to. I wrote about the loss of
| design idioms at length: https://loeber.substack.com/p/4-bring-
| back-idiomatic-design
| jeffrallen wrote:
| We need Dogme95 for websites.
|
| https://en.m.wikipedia.org/wiki/Dogme_95
| KronisLV wrote:
| I remember the first time when I looked at the Flutter Gallery
| and was surprised at how things felt just broken in a web
| browser, for example: https://gallery.flutter.dev (I think it was
| the Reply example in particular)
|
| Ctrl + click or middle mouse button didn't work on links, right
| click didn't work, selecting and copying text didn't work,
| inspect element didn't work (due to how the technology is built),
| even attempting to zoom the page did nothing.
|
| This article does ring true both because of that experience, as
| well as some of the SPA implementations I've seen even with more
| conventional technologies.
| skybrian wrote:
| A very specific but related tip about not disabling zoom:
|
| You can stop using user-scalable=no and maximum-scale=1 in
| viewport meta tags now https://lukeplant.me.uk/blog/posts/you-
| can-stop-using-user-s...
| shadowgovt wrote:
| I hate when people do this on mobile. The Mastodon web app does
| this, and it's real unfortunate when I hit a picture in
| someone's stream and I can't make it bigger even though I have
| more pixels than cones in my eye.
|
| Please, dear God, I just want to see the whiskers on the cat.
| 8organicbits wrote:
| > beause "you can't hover or tab on mobile, right?" (wrong)
|
| I'm guessing you do this by adding an external mouse and
| keyboard?
| shadowgovt wrote:
| Right, or any one of many assistive devices. The line between
| "mobile" and "desktop" is a lot blurrier these days.
___________________________________________________________________
(page generated 2023-08-05 23:00 UTC)