mathias

Did you know that “old” Chrome Headless (2017–2023) was a separate, alternate browser implementation that just happened to be shipped as part of the same Chrome binary? It doesn’t share any of the Chrome browser code in //chrome.

--headless=new in Chrome 112 on the other hand works the way you'd expect.

https://github.com/puppeteer/recorder

The article includes a working polyfill that includes old IE support.

Author of the referenced article here.

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. ️

Thanks :) Glad to see people appreciate simplicity (and the performance that comes with it).

We do indeed measure improvements against more than one website. We wouldn’t want to improve website X while regressing the rest of the internet. See https://v8.dev/blog/real-world-performance (from 2016):

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.

The article links to the explanation by the proposal champions: https://github.com/tc39/proposal-class-fields/blob/master/PR...

I mean, they have been solved. With the exception of String#matchAll (which is currently a Stage 3 proposal), all these features are part of ES2018 and shipping in Chrome. Other browsers implement some of them already and are working on shipping more.

You can view the implementation status of the various features here: https://kangax.github.io/compat-table/es2016plus/#test-RegEx...

I make sure to keep the article up-to-date. It correctly states the status for each of the features. They’re all part of ES2018 with the exception of String#matchAll which is currently at Stage 3.

Hey, I’m the author of the article. Despite its age, it’s still accurate and up-to-date.

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.

That’s not very JavaScript-y. Where else in ECMAScript are constants used like this?

That would be a Chromium feature. V8 only implements ECMAScript and WebAssembly.

The article is two years old but still up-to-date. The links to the relevant browser bugs are in the document, and the Edge bug is still unresolved. https://wpdev.uservoice.com/forums/257854-microsoft-edge-dev...

In older browsers, useCapture is NOT an optional parameter

Which browsers are those?

Which means you can’t practically use the new form without feature detection.

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?

That’s not equivalent though — in the article’s example, imagine `element` is `undefined`, for example. `then()` wouldn’t be called in that case.

Correct. By Stage 3, the proposal is supposed to be stable enough to start shipping it in stable browsers.

Wondering what a given legacy HTML color value (as seen in `bgcolor`, `text`, `link`, `vlink`, and `alink` attribute values) looks like? This tool (which I made for a presentation years ago) shows you: https://mothereff.in/bgcolor#mathiasbynens

Present tense: https://domenic.github.io/streams-demo/

Replace `test` with `example.com` et voila.

+1. Still, code screenshots in Notepad?!

Nowhere in the blog post does Wright say “this is the proof I’m Satoshi”. The entire write-up reads like he’s just giving an example. Why does everyone think it’s some kind of proof?

That’s true for client-side JavaScript (like I said in the presentation).

It’s a whole different story if you’re using server-side JavaScript (e.g. Node.js), though.

It looks like this is possible because there is not an explicit 'access-control-allow-origin' header set on facebook

CORS has nothing to do with it, actually. This is where the strength of the attack lies.

“If you are logged in to a site that does this, it's a huge danger. Your private account information can be slurped down by ajax on any other sites.”

This is false (unless `Access-Control-Allow-Credentials` is set). See CORS 101: https://annevankesteren.nl/2012/12/cors-101

More details on the Unicode regex problems in JavaScript (slide 62) and how ES6 will solve most of these issues: https://mathiasbynens.be/notes/es6-unicode-regex

Luckily shaaaaaaaaaaaaa.com itself is fine: https://shaaaaaaaaaaaaa.com/check/shaaaaaaaaaaaaa.com

I spotted this earlier this week when ordering a t-shirt through TeeSpring using PayPal. I authorized a payment of 22.95 USD. Here’s a screenshot from the payment confirmation email I received: http://i.imgur.com/BGjKcsW.png The math doesn’t quite add up.

Please use http://meiert.com/en/indices/html-elements/ instead, as it’s based on the WHATWG HTML Living Standard rather than W3C’s versioned fork.

The point of typing a message in a webmail UI and sending it is to deliver the exact message you entered to the recipient. Adding hard line breaks, effectively altering the original message, is not useful.

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.