Implement Search as ARIA spec compliant* dialog and combobox pattern

[phoneticallySAARTHaK]

Pretty much a complete rewrite of the UI and UI logic for search.

UI Changes:

• fix height calculations in sectioning containers to remove extra scrollbars/overflows
• Fixes tab order of toolbar links
• Replaces search input with a button in toolbar, which in turn open a dialog, that has the search, which can be opened by clicking the button or pressing "/", or Ctrl+K
• Implement search as combobox pattern (and all the changes that comes along with it)
• Enabled virtualKeyboard API to adjust dialog height when keyboard opens in mobile (currently only chromium browsers support it)
• Removes the ready class from search element.
• Updat color variable to satisfy WCAG level AA

More details are in commit messages. I haven't updated the changelog, because I don't know what's relevant.

Visual Regression script probably won't detect the change?

*Mostly. There might be minor variations

[Gerrit0]

A couple general issues:

1. With no search history, typing something and then clearing the search field results in the claim "No Recent Searches"... which is rather confusing, I just searched for something! Didn't click on anything, but... maybe that's expected, but it greatly confused me for a bit.
2. This introduced some contrast issues in the new search dialog (run chromium's lighthouse checks)

This is looking really awesome! It seems to behave significantly better on mobile and I like the change on desktop as well

[phoneticallySAARTHaK]

Regarding the recent searches message, yup, totally agree, I think even left a comment about in the code that it's actually search results. I picked up it up from remix.run, and I'm confused what to show there, "no recent... What?"

[Gerrit0]

Would it be better to just not show anything there? It's a different dialog size, but just showing a search bar the first time it is opened doesn't seem completely wrong to me.

I also just realized that storing IDs is not necessarily the way we should go about that. IDs are somewhat likely to change between rebuilds of the site as they are dependent on conversion order, so if the very first class TypeDoc converts gets a new property, all the IDs will end up shifted.

[phoneticallySAARTHaK]

Edit: Removing it.

...

Yup, I mainly added for cosmetic UX purposes. It's not important and I already had doubts about it (that's why it's the last commit).

Without anything it feels.. empty. I'll get some quick design advice on this, otherwise I'll just remove it.

And yes I tested the change of IDs, I still added it on the premises that atleast it won't crash.

From commit message:

• This implementation prevents broken links, but refs might change, changing the suggestions

It was the simplest way to achieve it, and I don't wanna make it complicated, so I'll probably just remove it. But I don't think occasional changing suggestions is a big deal. But after all, it is a bug.

So here's my confusion:

• last search is mainly for UX, to not have a tiny search dialog
• The message "no recent search" is a bit confusing, it should probably be changed.
• it could be a useful feature, but current implementation has a minor bug.
• That shouldn't be a big issue, and a lot of people probably wouldn't even notice.

Tradeoffs everywhere.. What are your thoughts about it?

[Gerrit0]

I've merged this into the beta branch

[Gerrit0]

Thank you!