Lead-Dev: "These links don't work as they should, I'm having you fix them, 'kay?"
Me: "I'll have a look."
> The link doesn't do anything when you click on it.
My internal monologue: (The href is probably just wrong)
> It's not wrong.
Me: "What the fuck?"
Lead-Dev: "Can you fix it?"
Me: "I don't think I can."
Lead-Dev: "Why don't you try looking in thisScript.js?"
Me: "Oh, you think the click event got prevented or something?"
Lead-Dev: "No, I think something went wrong with what that script is doing with the jQuery library this site uses."
Me: "..."
Lead-Dev: "..."
Me: "jQuery... library...?"

Those fucking cunts that put href="javascript:..." links, where a simple URL would suffice, deserve a horrible death

An app I'm making for a client currently has 23 "pages" that are simply web views.
Most of those pages have A HREFS which open other pages (some external pages that I have no access to as a developer).
Of course, some of the links aren't HREFS and are javascript calls to change the content on the screen without going to another page. So the user thinks they have gone to another web page when then system doesn't recognise it as another page...
Additional to this, there are multiple versions of the pages depending on which language the user has selected in the app.

And nobody seems to have considered how the default back button handles all these possible eventualities (whether it can go back to previous web page, IF it was an HREF and not just JS mimicking a new page (and how would my webview even catch that), and of course IF the language hasn't changed during the user journey etc etc)

Am I wrong for being annoyed about this? Am I the dick for not developing a clean solution to it? Or am I justified because webviews have no place inside an app!

I'm sort of hoping apple deny this app due to too many web views :S

And I found another fucked up page😂😂

It's CSS quick maffs time! Consider the following code:

<div class='container flex'>
<nav class='menu flex'>
<a href='#'>Menu item 1</a>
(arbitrary amount of links)
</nav>
<button type='button'>Sign in</button>
</div>

You want the layout to look like a horizontally scrolling, single line menu with a Sign in button to the right. Both container and menu are flex containers. So, here's the code for the menu:

.menu {
overflow: auto;
}

The problem is, as there is no flex-wrap, menu will not be wrapped, and it will occupy all the space it's needed to accommodate all the elements, breaking its container. Pesky horizontal scroll appears on the whole body.

Boubas will set menu's width to some fixed value like 800px, and this is a bouba approach because bye-bye responsiveness.

Here's what you should do:

.menu {
overflow: auto;
min-width: 0;
}

.menu * {
flex-shrink: 0;
}

This way, menu will occupy exactly the width of an empty div. In flexbox, its width will be equal to all free space that is not occupied by the Sign in button. Setting flex-shrink is needed for items to preserve their original width. We don't care about making those items narrower on narrower screens, because we now have infinite amount of horizontal real estate. Pure, inherent responsiveness achieved without filthy media queries, yay!

The menu will scroll horizontally just like you wanted.

aight bye