Hacker News Reader

Comment by ehnto | Hacker News Reader

It's tricky to balance user expectations with semantic HTML now that the web has evolved so far.

The easiest example I have from my industry is a product card in a grid of products. There really is no correct spot to link it in some designs, but the user expects to click any part of the box and be taken to the product page. So you wrap the whole box in an anchor tag, which has its own host of problems.

As you said though, that is a bygone problem, this ship has sailed in the land of SPAs. Even a simple blog is an SPAs these days.

View on HN

User expectations, or executive expectations?

In my experience, the effective expectations of users are remarkably low. If you were to survey users, you'd get the impression that users are very particular. In reality, users tolerate all sorts of things that most of us on HN would consider primitive or nearly broken. If most web applications actually relied mostly on constructs provided by the browser/DOM rather than JavaScript, the average user wouldn't notice or care.

But there are product owners who power trip on the possibility that they too could be just like The Google, so they want everything to be unnecessarily animated and dynamic. On top of that, many of them want Silicon Valley programming at San Fernando Valley prices, so not only do they request that their web applications be unnecessarily complicated, but the junior devs they hire are given no direction and the code gets bloated, wrecking performance (which matters more than "delightful" UIs).

I am entirely inclined to agree with you. It is definitely perpetuated by project stakeholders, even developers wanting to try new tech.

But now that we have spent years training eCommerce user behaviours you do find that people will be busy clicking everything but the product title, arguably the most semantic place to put the anchor, so it may take a user a few goes to get where they're going. The user might not care but many of the project stakeholders do.

While I am an evangelist of a utilitarian, semantic web, I feel it's an idealism that hasn't survived it's encounter with the real world in commercial software. We went from being worried about javascript image sliders being too heavy, to making the client compute and render the entire application, in about 8 years. I think the trajectory is clear, and I doubt we'll have a watershed moment where the whole tree of stakeholders suddenly wants less.

If this particular thing of clicking everything but the title is really a thing, nothing is blocking you to add some minimal JavaScript which « onclick » on the item div element, triggers a click on the link. Add some « cursor: pointer » in you Stylesheet and you are done.

It’s literally 2 loc, it doesn’t affect accessibility and it’s using JavaScript for what it was meant : adding some optional convenience.

I realize I’ve not done real server rendered sites for years, but adding good old « optional convenience » JS without jQuery and broken browsers, but with ES6, modules, and maybe WebComponents would probably be a really pleasant experience.

Yes you are right, that's a good approach. Another commenter linked a great article on accessibility and "card" style content which also recommended that approach, worth a read as it discusses a lot of the caveats and your approach tackles the majority of the issues you can encounter.

https://inclusive-components.design

Namely, cards: https://inclusive-components.design/cards/

That's a great exploration of the issues involved. Thanks for the link!

Yes. Here’s an article that builds on this:

https://css-tricks.com/block-links-the-search-for-a-perfect-...

> So you wrap the whole box in an anchor tag, which has its own host of problems.

Looks like the correct solution to me. What are the problems?

You can't have interactive elements inside anchor tags. Very often the box will have some additional buttons for different actions, like "Save for later". I like the approach of using an anchor tag just for the title and have another click handler on the box to serve as a fallback, but you don't get to ctrl-click on the box anymore. Alternatively you can have the link be a sibling of the buttons in the DOM, but visually cover the whole box and appear behind the buttons. As you can imagine, any solution like this is going to add more work and be a potential source for bugs.

This is one of the two things that I really wish browsers would fix, instead of cramming in completely new features. The second is how hard is it to make popovers work correctly, especially inside scrollable containers.

Oh, that's a problem.

That really looks like a task for image maps, except that they only work for images. Yeah, I agree with those two problems.

Cant you just use event.stopPropagation on the inner button’s event handler to stop the browser from following the link? Of course this requires JS but I assume you’re using Js if you have custom buttons.

You can, but you can also see how it isn't an elegant solution. What if the user has javascript disabled? Do you also have to capture the click for the space around the interactive spots so a misclick into whitespace doesn't click the link?

It is what is normally done but it isn't perfect.

The post I was replying to was specifically lamenting the inability to have interactive elements inside of anchor tags, which I think is solved by event.stopPropagation. If you have a button in an anchor tag and it's not a submit button, you need JS for the button to work anyways.

Sites breaking "ctrl+click" or open in a new tab shortcuts are the worst. Even JIRA does it on text ticket links, and it's a power user focused tool. Very frustrating.

Reply on news.ycombinator.com