Readit NewsI was writing an email validator for my project which I'm so excited to announce soon. And my research (some stackoverflow answers) suggested that, yeah, you can have "a@b" as a valid email, as long as there's a one-letter TLD that can have MX records.
Which it seems there can be!
So my email validator is essentially just /^.{1,}@.{1,}$/ ... yay.
In the footnotes you said:
> One complication is that the counters have an "anti-tearing" feature for additional security
Two questions:
1. Why is it a "complication"? Is it just that it makes the counters more complicated, or is there something frustrating about the counters? 2. I would love to learn more about how the anti-tearing feature works!
Sure.
It recently got a lot faster, which is nice, but I'd happily pay $30/month instead for a small fraction of the bandwidth. But I can't.
I wouldn't qualify for the hypothetical state enforced $15 option anyway.
Firstly, we can see that they're using the email exactly as provided (for sending, at least), else filters on the mail we receive wouldn't work.
Secondly, the + trick works because it's valid in email addresses under RFC 5321 and RFC 5322 - the fact that Gmail (and others?) direct all addresses of the format 'foo+bar@gmail.com' to the mailbox of 'foo@gmail.com' is a quirk, not a given. Anyone wanting to trim '+bar' would have to know it's safe to do so for particular providers, and I doubt anyone wants to maintain that list and do extra backend work just in case they want to share on the sly.
Gmail is also pretty popular, so it's not much work to just hardcode it there.
Not any time soon. The unfortunate truth is that nobody implements the entirety of the SVG spec. It's not even close when it comes to SVG 2. This is a good read on that topic:
https://razrfalcon.github.io/notes-on-svg-parsing/
> Whenever I receive bug reports for my SVG library, people often use the phrase "my SVG isn't rendering correctly". Which cracks me up every time. There is no such thing as a correctly rendered SVG. As soon as you start using "advanced" features such as text, filters, or, God forbid, animations - it would simply not work. Never. And even if you will manage to make it work, as soon as you try a different render - it will fall apart again.
> The idea behind this "book" is to answer the popular question of "how hard can it be?". A reader expected to have some prior knowledge about SVG, but it should be a fun read either way.
Closed duplicate of <something that is totally different>