P99 0 ms* autocomplete for 240M domain names(ruurtjan.com) |
P99 0 ms* autocomplete for 240M domain names(ruurtjan.com) |
It seems like one purpose of an autocomplete box is help you avoid typos, so that makes it less useful.
Yes, it will autocomplete the most popular domains first, then known registered domains, and then fall back to appending popular TLDs.
The reason is that it's impossible to enumerate all domains. gTLDs (like .com, .info) mostly publish their zone files, but ccTLDs (like .cn, .de) usually don't.
But maybe you're right. After reading these comments, it's clearly confusing to people.
Similarly, domains can be registered since the last time you downloaded your lists. So you never have a complete or accurate list.
I think it's perfectly reasonable to suggest names that have recently expired or domains that could have been recently registered. The alternative requires an NS lookup.
Can't you just append any TLD to anything and get a domain that "might" exist? Or am I missing something?
I guess this behavior helps to autocomplete the domain extension for less-known domains that are not in the search list.
speedtest.me.uk exists, but typing speedtest.me does not suggest it, and speedtest.me.u suggests speedtest.me.us first (doesn't exist).
(.me.uk is a second level domain category in .uk, intended for personal domains.)
$ lynx doesnotexist2
Looking up doesnotexist2 first
Looking up www.doesnotexist2.com, guessing...
Looking up www.doesnotexist2.edu, guessing...
Looking up www.doesnotexist2.net, guessing...
Looking up www.doesnotexist2.org, guessing...
Can't Access `file://localhost/home/user/doesnotexist2'As a daily text-only browser user for over three decades, using it as a "daily driver", I'm no doubt biased. I was a lynx user before links was released. I would never go back to using lynx. When I see HN comments suggesting lynx as an example of text-only browsing I question whether the commenter is actually using it as "daily driver", or looked at the source code and compared it with alternatives
links doesnotexist2
Unlike elinks, w3m, etc.
One of the many reasons I prefer links (no graphics)
I use links as an offline HTML reader; I am opening local HTML files every day
That said, it's relatively easy to modify these programs to behave according to personal preference; they are relatively quick and easy to compile
One could remove the unwanted DNS lookups, for example
Contrast this with the so-called "modern" browser that almost zero users have the time and resources to modify and compile themselves
Instead, we see dissatisfied browser users beg browser vendors to make changes
To no avail
There are other ways to prevent unwanted DNS lookups besides modifying the source code
For example, I run own authoritative DNS on the loopback, with custom root.zone
All lookups by default return the same address: the address of the local forward proxy
The proxy's memory contains DNS data precollected periodically in bulk from a variety of sources. At startup/restart, the proxy loads the data into memory from a plain text file (a "map")
The map would not contain any DNS data for "doesnotexist2"
There is no way for DNS lookups to leave the loopback nor any way for HTTP requests to be sent to destinations other than the ones I approve
No Javascript engine in text-only browser
For use with "modern" (read: uncontrollable) browsers the proxy can deny requests for URLs ending in .js, add a Content-Security Policy response header that disables Javascript and, if the CSP were to be ignored, can rewrite pages to comment out or delete inline JS
This affects the functionality, too. It is in fact introducing latency by using keyup instead of keydown. Feels bad.
I think you could get a lot closer by framing this as an optimization problem, where you use the full alphabet dictionary, but add a residual prediction which aims to cover as much of the remaining domain name tree as possible weighted by popularity. This tree could then be pre-baked and stored with the same system. This would probably get you p99 0ms even in Australia.
I think most people search for domains they own, which doesn't correlate with Tranco popularity ranking. Treating 'popularity' not as a function of visitors, but as a function of number of known domain names with that prefix could work, though.
The time it takes to press a key is a reasonable target to aim at for API latency I suppose, but it is still an arbitrary target. Waiting to display until keyUp just adds more latency if your API is faster. Having it synced with keyUp doesn't make it feel more immediate to me.
Now the traversal can be done completely via CDN lookups!
3B existing URLs extracted from CommonCrawl, with instant search results. It was a fun project but didn't serve much real-world purpose besides curiosity and discovery. So I eventually ditched it, primarily because the link DB was a whopping 500 GiB in size, too much to just keep hosting.
I just used SQLite FTS5 as the backend search engine. Just a few lines of code, but immediate response from a 0.5 TiB DB. SQLite is amazing.
Yes, I read the post. A lot of words that were unnecessary in the face of a simple experiment.
How do you know if it's necessary? If Tranco returns less than eight?
I think you have this wrong, actions generally occur on button release, until that you can move the mouse cursor to a different target, tab to another control, use [ESC] to cancel, and so on. Typing, moving a slider with the cursor keys, and similar things that make use of key repetition while holding down the key are the exception to this.
TAB is otherwise immediate, as is ESC, and the examples of typing, as well. So I'm left wondering, how do they have it wrong?
Key up is used for when it’s important to only have one occurrence of that event.
Technically you could write code that made key down only react once. But the logical separation makes some sense.
Edit: I think people are misunderstanding me. I’m asking for an explanation of why, when you have a button focused, pressing Space activates on key up, rather than key down like literally everything else on the keyboard, including Enter on a focused button. (Mouse activates on release.)
What I mean is if "modern" browser vendors change their popular browsers to make it more difficult for users to control others' Javascript, we can use URL blocking, URL rewriting and/or page rewriting to modify or delete inline or sourced Javascript and/or substitute the user's own Javascripts
(I'm the author btw)
> And on keyUp (the user releases the key), we render the suggestions.
Because they listed the exceptions to the "act on keyup" rule
Basically anything that requires text input from OS-native text input fields to IDEs, word processors, spreadsheets, web browsers, terminal emulators and so on and so forth.
(I confess I’m getting frustrated at the ridiculously large fraction of messages in this thread that have somehow completely misunderstood things.)
In answer to your question: I’ve only really used keyup for either one time events (like keyboard shortcuts for UI elements) and for ending the status of repeated events (eg movement in games, dragging UI elements, etc).
I think if you were to search for key up events in GitHub, most of references might likely be games and other visual interactions rather than text entry.
But for reference browsers fire the keypress event on keyup
These two interactions should behave identically:
- Hover over a button, press mouse button 1, release button 1.
- Tab over to a button, press spacebar, release spacebar.
Why on-screen buttons are UX'd to behave this way is a logical follow-up question. I'd wager that it gives a means to bail out of the clicking (e.g. by moving the mouse out of the on-screen button before releasing mousebutton 1, or by pressing Esc while having spacebar still depressed).
You’re only answering half of the inconsistency: because Enter activates buttons like any other key, on keydown.
Qt: Esc cancels. Tab cancels.
Gtk-4: Spacebar auto-clicks before keyup (probably due to auto-repeat).
Win32: Esc sends Esc to the window. Tab cancels.
Firefox: Esc does nothing. Tab cancels.
So, mileage does vary.
Re. Enter key, that's a different key, so different discussion.
So this could be the oddity
Interestingly Ctrl+V on OP's website does update immediately when Ctrl+V is pressed.
Every UI I can find types the letter on keydown, and I don't know why you'd want typing and autocomplete to use different timings.
Waiting for release is for mice and touch, not keyboards. And that's only because they have to deal with dragging.
The GTK 4 behaviour feels very much like a bug. I can reproduce it in gtk4-demo and in gtk3-demo. It leads to obviously-nonsensical behaviour, including messed up window focus. I’m tempted to file a bug report, but haven’t had such productive experiences with filing things on GNOME historically as with Firefox or even Chromium.
Why should Enter being a different key be a different discussion? They’re both used to activate buttons, and one is behaving like every single other keyboard interaction, while the other isn’t. (Related: if a link is focused, Enter activates it, Space doesn’t, just doing the normal scroll-down-one-page.)
> if a link is focused, Enter activates it, Space doesn’t
It seems that you answered your own question: different keys, different purposes.
Enter is for "execute the focused action". Spacebar is for "operate the button".
The letter appears instantly, then after a moment a lot more copies of the same letter start showing up rapid-fire.
What are you calling flawed about my test?
This happens on both Windows 10 and Linux Mint, in Firefox.
I never meant to infer that the keyup event is specifically what should be listened to