3,588 karma · joined December 26, 2009
--headless=new in Chrome 112 on the other hand works the way you'd expect.
The article includes a working polyfill that includes old IE support, so I’m not sure what you’re complaining about.
Also, saying “jsvu is the justification for the polyfill” doesn’t make much sense. jsvu is just how I happen to test in various standalone JavaScript engines. There are other, non-jsvu ways of getting such binaries, e.g. compiling one yourself, and there are JS engine binaries that jsvu doesn’t provide (Rhino, Ringo, Nashorn). jsvu usage does not correspond to anything you seem to be talking about, and comparing its download count with IE10 usage is one of the more extreme apples-to-oranges comparison I’ve seen. ️
> We now monitor changes against a test suite of approximately 25 > websites in order to guide V8 optimization. In addition to the > aforementioned websites and others from the Alexa Top 100, we selected > sites which were implemented using common frameworks (React, Polymer, > Angular, Ember, and more), sites from a variety of different geographic > locales, and sites or libraries whose development teams have > collaborated with us, such as Wikipedia, Reddit, Twitter, and webpack. > We believe these 25 sites are representative of the web at large and > that performance improvements to these sites will be directly reflected > in similar speedups for sites being written today by JavaScript > developers.
You can view the implementation status of the various features here: https://kangax.github.io/compat-table/es2016plus/#test-RegEx...
> these features aren't entirely new
Depends on what you mean by that. These features are still not universally supported by all modern browsers, for example, so I can imagine they’re still new to a lot of developers.
Chrome supports all these features (except for String#matchAll, which is currently at Stage 3). Other browsers don’t yet support the full set, but they’re all working on getting there.
Which browsers are those?
That does not follow.
`{ capture: true }` works in both, since it’s an object, and thus truthy.
There’s no need for feature detection in the case you describe.
Sadly, that’s the whole premise of this article.
It’s only a problem if you want `capture: false` combined with other options — since you’d need to pass in an object, that would be truthy in the old implementations expecting a boolean instead. But then again, the additional options wouldn’t be supported in those old implementations either.
I’m confused — what’s the actual use case that’s breaking here?
It’s a whole different story if you’re using server-side JavaScript (e.g. Node.js), though.
CORS has nothing to do with it, actually. This is where the strength of the attack lies.
This is false (unless `Access-Control-Allow-Credentials` is set). See CORS 101: https://annevankesteren.nl/2012/12/cors-101
Making text fit on a 80-character fixed-width screen is not something the email sender should do; the recipient’s email client should do it based on their preferences.