> The web spec

There are hundreds of web technologies, each with their own spec. None of which are actually that complicated if you read them.

> Simpler primitives ... formatting rules ... better from a security perspective.

So you mean CSS? What does that have to do with security?

> Designing the web for average users

Not sure what you're trying to say.

>There are hundreds of web technologies, each with their own spec. None of which are actually that complicated if you read them

The first part is true. There are indeed hundreds of web technologies. The second is absolutely false. A lot of them are (and have historically been) horribly complicated to implement, with lots of edge cases and strange interactions. In fact prominent web standards people have talked about such cases many times.

>So you mean CSS? What does that have to do with security?

No, he means "simpler primitives" across the board. And even CSS has to do with security (e.g. loading third party fonts, etc).

>>Designing the web for average users >Not sure what you're trying to say.

He's obviously tries to say that W3C et al piled features to please end users and satisfy end user needs, without giving much care about how to make them more consistent and coherent for web developers.

Complicated to implement, yes. Complicated to read and understand why the browser is doing x? No.

I'm not sure if end users are the people W3C is trying to satisfy. Browser vendors do enough of that. If anything, they're trying to satisfy media corporations that want DRM standards, or ad corporations that want pervasive tracking.

>Complicated to implement, yes. Complicated to read and understand why the browser is doing x? No.

CSS, for one, is notorious for being complicated to understand, with tons of complex cases, especially in the layout department, where whole cottage industries of "tips" and "workarounds" for the simplest of stuff -- and I'm not talking browser incompatibilities -- thrived for decades (until, at least, flexbox and the like).

>There are hundreds of web technologies, each with their own spec. None of which are actually that complicated if you read them.

I agree with your overall point, but there is a reason sites like MDN exist. It's because some of the HTML/CSS/JS specs are crazy complicated, contain years and years of edge cases and bugs that have become standard, and are written in standard-eze (which is easy enough to read once you know it, but it can be a bit of a learning curve for someone who just wants to know the order of function parameters).

MDN will be a huge legacy for Mozilla. Of all of their projects, I think MDN will have the biggest impact on the web. It's absolutely needed for someone who just wants to know the order of function parameters.

For a more nuanced understanding of browser behavior, you have to read the spec. Worked on a high performance network app, and I think I know the XHR spec by heart now.

> Worked on a high performance network app, and I think I know the XHR spec by heart now.

I am curious, can you elaborate on this? :) What part of the performance related work involved peeking at the XHR spec so much?

For mapping applications, tiles are loaded to display data. These requests have to be handled carefully, especially when there is a lot of data, because every map movement causes 10s of requests to be fired at once. Their lifecycles have to be managed so they can be cancelled as soon as their result isn't needed (user panned away, or changed zoom level).

I couldn't agree more, and I also think it influenced the standards bodies. New ES[year] specs include lots of very MDN-esque explanations, examples, and "polyfills" for the new features.