mailcheck VS WHATWG HTML Standard

Not an "instead of" approach, but the best thing I'd implemented when running an ecom site was a typo detector that prompted people to fix their email if it looked wrong, like "[email protected]", "Did you mean [email protected]?".

At the time I used "mailcheck": https://github.com/mailcheck/mailcheck

There appears to be a more modern implementation here: https://github.com/ZooTools/email-spell-checker

It reduced the amount of badly entered emails more than any other approach I tried.

It misses the very common mistake of typing a comma instead of a dot.

Otherwise, yeah, most people would be better served by a library that detects domain typos like https://github.com/mailcheck/mailcheck than spending time on regexes.

The most helpful thing I've used in the real world is something that looks for common typographical errors, even if the email is technically valid.

Like, if the user types "[email protected]", it pops a dialogue asking "Did you mean "[email protected]". But lets them keep what they typed, or do a different fix if needed.

I found some JS called "mailcheck": https://github.com/mailcheck/mailcheck

There are updated clones that use react, vue, etc, instead of jquery.

With a working ecommerce site, this improved the percentage of correct emails more than anything else I tried, and I had tried many things. Because it's a bad situation when you've taken someone's money and have nothing other than a shipping address to contact them if something goes wrong (bad shipping address, out of stock situation, etc).

I somewhat lol'd when the demo allowed "[email protected]" just fine. Guess kickstarter isn't using mailcheck anymore. Looks like it's an open issue:

https://github.com/mailcheck/mailcheck/issues/179

I suppose it depends on what we mean by validate. Running an ecommerce site, I got a lot of mileage out of prompting the customer to fix emails that "looked wrong". We allowed them to proceed if they wanted. A really common one was "[email protected]" when "[email protected]" was wanted. We used a slightly modified version of https://github.com/mailcheck/mailcheck and found it to be really useful.

It does work well. I used a customized version of https://github.com/mailcheck/mailcheck on an ecomm website and the amount of bounces due to typos went way down.

WHAT-WG HTML

There's a long-standing WHATWG feature request open for it here: https://github.com/whatwg/html/issues/2791

And several userland custom element implementation, like https://www.npmjs.com/package//html-include-element

One of the cool things that you can do with client-side includes and shadow DOM is render the included HTML into a shadow root that has s, so that the child content of the include element is slotted into a shell implemented by the included HTML.

This lets you do things like have the main page be the pre-page content and the included HTML be a heavily cached site-wide shell, and then another per-user include with personalized HTML - all cached appropriately.

The `allow` attribute on iframes is a relatively recent API addition from 2017

https://github.com/whatwg/html/pull/3287

I think there's a pretty strong argument at this point for this kind of replacing DOM with a response behavior being part of the platform.

I think the first step would be an element that lets you load external content into the page declaratively. There's a spec issue open for this: https://github.com/whatwg/html/issues/2791

And my custom element implementation of the idea: https://www.npmjs.com/package/html-include-element

Then HTML could support these elements being targets of links.

> Consider https://www.ietf.org/rfc/rfc1866.txt vs https://html.spec.whatwg.org/multipage/

I thought, oh, that's not so bad. Then I realized what I was looking at was a 10 page index.

I'd love to see something like HTMX get standardized, but I'm extremely pessimistic for HTMX's prospects for standardization in HTML.

In talking to a few standards folks about it, they've all said, "oh, yeah, you want declarative AJAX; people have tried and failed to get that standardized for years." Even just trying to get

to target a section of the page that isn't an has been argued about and hashed out for years.<p>Why is that? Well, for example, here's the form you have to fill out to start standardizing a front-end feature. <a href="https://github.com/whatwg/html/issues/new?assignees=&labels=addition%2Fproposal%2Cneeds+implementer+interest&projects=&template=1-new-feature.yml">https://github.com/whatwg/html/issues/new?assignees=&labels=...</a><p>It asks three main questions:<p>* What problem are you trying to solve?

The issue with a single global event handler is discussed here: https://github.com/WICG/close-watcher#a-single-event

If you use popover="", you get the kind of functionality you're discussing for free. For

, the discussion is in progress and reaching a conclusion: https://github.com/whatwg/html/issues/9373