Do you actually follow spec discussions, or are you just guessing? From what I have observed the Chrome, Firefox, and Safari teams are in constant communication. They discuss new features, implementation details, and potential pitfalls.

Despite all the suggestions of "browser wars", they're actually very friendly and collaborative.

The proof is in the article:

> It is most likely that this will be added to other browsers like Firefox too.

> Microsoft’s new version of Edge is going to be based on Chromium, so this will be available on Edge too.

So, although some discussions with Firefox may have begun, it's clearly using the Microsoft decision to use Chromium as a way to force their standpoint. Note also the lack of mention of Safari.

This is the kind of stuff that should go thru a central committee because different browsers will react differently to what should be a simple url.

I've followed a few directly, and as a web developer I generally have my ear to the ground for these things. It's possible this feature was discussed, but the article made it sound like it wasn't in a formal capacity, and I know for a fact that Google has forced things through in the past, even when there's been active protest from people at Mozilla. And that was while Microsoft still had their own engines.

I think he's right. SPDY and WebP both started as Chrome-only features, and the world has essentially been forced to adopt them.

So far I think that's been a good think on balance because they are good technologies. But it is worrying how much power Google has in this space.

SPDY was donated to the IETF for adoption into the HTTP/2 standard. Other browser vendors only implemented it at that time.

WebP is a file format and doesn't fall into the normal standardization process. Browsers implement support for new file formats at their own behest.

Yes. After SPDY had already been implemented and shipped in Chrome.

Of course, that's how it works. Chrome is hardly alone in field testing their new feature proposals.

You'll note that they're also willing to kill features which are not adopted, like PPAPI.

> You'll note that they're also willing to kill features which are not adopted, like PPAPI.

After adding whitelists for Google properties like Hangouts, of course.

It's not like interoperability suffered because of that. HTTP fallback was always there.

Nevertheless it's some kind of fait accompli, especially in a market with only three main actors.

Where one actor can also start using the new "standard" overnight and break lots of services for people which are not using their browsers... You know what I mean. It's some kind of enforcing to have a monopoly.

I agree with you on Google's monopoly but imagine if every browser has to go through proposal process to release any feature? Everything will just stagnate.

Browsers copy features from each other. If this is a useful feature, it would make its way to other browsers pretty soon.

It's not just a browser feature, now is it, it's an interoperability feature since you're supposed to share links (it's in the title). This means that the near-monopoly is going to drive people who receive the shared link to consider using the browser that supports this. That puts other browsers quite on the defense, does it not?

"Your link doesn't work with firefox" sounds indeed really bad.

Stagnation is not always bad. For one, it helps keep complexity down. We're at a point where building a browser is impossible unless you have literally millions and millions of dollars to invest. That is not good.

Why is the possibility of a wheel being reinvented a desirable thing?

Is a browser really a "wheel"? There are so many choices to make, so many lines drawn in the sand. And besides, you really don't want the marketing and tracking giant Google to make all the decisions regarding the software that delivers so much content to billions of users' screens, do you? They've been okay so far, but there's a huge conflict of interest here.

Because competition is good?

The hundreds if not thousands of ad supported calculator and flashlight apps on play store beg to differ.

Reasonable amount of competition is good.

Competition that spurs innovation is good, more like, but I am skeptical of the claim that competition is necessary to prompt innovation, and whether the costs of such a model (leading to massive waste of society's productive capacity) are worth the purported benefits. For instance, a good deal of mathematics and science was not done on the principle of competition, but search for improvement. The real question is whether the development in goods and services can be or could have used similar principles, which is not only more efficient but seems condusive to better mental well-being; I'd rather desire to improve than to slight (and possibly sabotage) someone who must be my opponent.

Good for the consumer.

If building from scratch maybe, but when was the last time a browser was built from scratch? Even Chromium was forked from WebKit.

That's my point. The web is so complex that browser engines are becoming a monoculture. Even if you forked Chromium now, you'd need hundreds of engineers just to keep up with all the new things that are constantly added.

Yeah, I was rather sad to see EdgeHTML go. Although I never used Edge, rendering engine diversity is good for the ecosystem.

And yet the fact that the major engine implementation is opensource still allows each vendor to innovate by adding new useful features to the users.

We're really far from IE6 era of complete stagnation.

Not really, as far as the core browser engine tech goes. In practice it's too difficult to maintain a Chromium fork that diverges in any significant way other than the front end. Opera and Edge (per announcement) use vanilla upstream Blink.

> new things that are constantly added

By golly, that's the problem right there.

One thing I’ve discovered from learning and using Common Lisp seriously is that it’s really important for a system to be specified in a way that allows for extensions to the system to be implemented in terms of primitives the language provides (e.g. you want a new language construct, write a macro to transform your desired syntax into Common Lisp). In languages and systems that don’t have this feature, an implementation that introduces useful extension begins to develop lock-in and makes it harder to compete. (E.g. no one writes the Haskell specified in the Haskell report anymore, because all the libraries you might want to use use one or more ghc-specific extensions.( )

There are significant tradeoffs between shared constructs and self contained systems. Self contained systems resist ossification; they can be unilaterally replaced. A shared construct has to evolve in step with all of its users.

But the self contained system will have thousands of incompatible implementations, and the shared system will be easier to interact with and build on top of.

What this means is that a browser should standardize on things meant to be interfaces, and leave out all of the rest. Unfortunately, they didn't and now browser engines are huge and impossible to evolve except by adding more stuff.

Similarly, the value of programming languages is almost entirely in the interfaces they provide which allow you to develop code. Lisp provides almost none of that, and that is why it failed to become mainstream.

> no one writes the Haskell specified in the Haskell report anymore, because all the libraries you might want to use use one or more ghc-specific extensions

This is a bit of a misconception. One can still write Haskell98 whilst using a library that use a GHC-specific extension. The library doesn't (have to) force its consumers to use extensions too!

I phrased that a bit wrong: my experience (from talking to the Haskellers in my company) is that Haskellers generally prefer to turn on a bunch of extensions when they write code. So, while you might be able to write pure Haskell98, it tends not to be idiomatic to do so.

But since when is it a good thing that the last time someone managed to build a web render engine from scratch was thousands of years ago?

Hopefully Mozilla will have some luck modernizing by replacing pieces one at a time with Rust components. ;)

What do Firefox implementation details have to do with this?

They are modernizing the browser by replacing pieces over time. That's relevant to the topic of browsers being built on legacy tech.

I don't see how this supports to the argument that you can easily build a new, competing browser by forking. If you fork and then need the same kind of resources to replyce the forked codebase with your own, I don't see what you'd win.

Even if you fork, you'll still need constant investment to just keep it up-to date with the ever-evolving "living standard".

It sounds not unlike what used to be the role of W3C before HTML5. Everything stagnated, while Microsoft with IE largely did not care, and everyone ended up making their pages in Flash because it was the only really consistent target.

> Everything will just stagnate.

And that is bad exactly why?

Because we've all been heavily brainwashed in to requiring constantly "new" stuff. It's going to take a World changing event to break us out of that cycle IMO.

in this case it looked OK

> Though existing HTML support for id and name attributes specifies the target element directly in the fragment, most other mime types make use of this x=y pattern in the fragment, such as Media Fragments (e.g. #track=audio&t=10,20), PDF (e.g. #page=12) or CSV (e.g. #row=4).

fragments is already there but most pages do not have a clickable ID attribute. If Chrome could automatically provide one I think it's more convenient than F12 a devtool for links.

Although there already was a proposed standard by a W3C group for doing this, although it is a lot more complicated (with a bunch of variations, but even implementing one of those would be nice): https://www.w3.org/TR/selectors-states/#json-examples-conver...

> in this case it looked OK

That’s not really the point

I’m fine skiing down this slippery slope

IE 5 was also welcomed with joy when it arrived.

web standards are descriptive not prescriptive, and have always been: nobody asked before adding the <blink> tag to their web browser, it was just added (and later removed) after it was used by more than one implementation and consensus was found how it's supposed to behave.

For example, WebSQL died because there was only one implementation: implementations come before the standards.

Not strictly true.

In the W3C process, a Working Draft can be written before any implementations. Even a CR doesn't need to have been realised. To progress to PR and Recommendation, it needs to have implementations.

WHATWG is more descriptive, HTML 5 has been described as a collection of everything Hixie has seen somewhere on the web and thought cool.

Not strictly true, okay.

Still, it's nothing new that browser vendors just add the things they think may be useful and see what sticks (which then eventually ends up in some standard at some point like asm.js/WebAssembly - or fizzles out like NaCl).

These days with vendor prefixes, polyfills and generally a focus on backward compatibility there's typically some care taken to not leave users of other browsers in the dust.

That's very different from past efforts like, for example, ActiveX which made a full (but undocumented) Win32 environment part of the web browser design.

Browsers have always done that

We've had a time when standards were at the forefront, between the death of the last browser monoculture, and the establishment of the current one.

It was good while it lasted.

if you don't specify a timeframe you can't be contested and therefore your nostalgia reads like it is for a time that never existed except in your mind

Judging from this chart[1], definitely somewhere between 2008 (the x-axis starts at 2009, but if I recall correctly Chrome was released in 2008) and second half of 2012. Possibly the original comment was referring to a larger time span than this, but judging from the linked chart that's when Chrome was still on the up-and-up compared to IE. In my opinion though, this timeframe was 2008 to about 2014, when Google (and Microsoft) essentially strong armed Mozilla into accepting EME[2]. I'm not sure that's when the slippery slope really started, but it's definitely when I started believing there's a new boss in town – same as the old boss.

[1]: https://en.wikipedia.org/wiki/Google_Chrome#/media/File:Web_...

[2]: https://hacks.mozilla.org/2014/05/reconciling-mozillas-missi...

I remember writing websites at that time. Developers were worried about there being "yet another browser to support". It was a big deal because supporting all the browsers was already a lot of work. Nothing rendered consistently. Javascript would run fine in one browser, but not in other. You got to deal with fun features like quirks mode and worrying about transparent pngs. You had to use Flash if you wanted to embed a video.

The web is a completely different place today. Everything renders consistently across the different browsers - even Edge for the most part. Javascript is a modern language now. Video/audio embeds were finally standardized. Layout tools are significantly better with flexbox and soon, grid.

The idea that we were at some web standards pinnacle in 2008-2012 is crazy to me. The pinnacle is now.

> The idea that we were at some web standards pinnacle in 2008-2012 is crazy to me. The pinnacle is now.

I don't think the point was that we were at a pinnacle in terms of standards quality, completeness, or user agent consistency. Rather I think the point – at least it for me – was that during those years it was more of a conversation, not Google choosing a direction and everyone else more or less forced to follow suit. We are certainly in a better spot today in terms of capability, I agree, but I'm not sure I'd agree that we're in a better spot in terms of collaboration.

At what time has there been better collaboration between browser vendors than right now? That is the reason that browsers are so well in sync with each other now.

Well that's the argument, isn't it? Collaboration doesn't mean necessarily mean being in sync or following suit. When there's a hegemony then a level of collaboration might still exist, but if the interests don't align with the dominant party they can just go ahead anyway and more or less force others to fall in line – e.g. EME. Even if everyone syncs up, it's not necessarily good collaboration. Conversely, the dominant party can choose to just ignore other's contributions and ideas if their interests don't align, effectively making those contributions largely pointless.

Whether or not you agree is one thing, but I hope my point is clearer now anyways. :o)

Thanks for being respectful and well-reasoned in your response.

My opinion is that the collaboration is probably the best it's ever been right now. The example I gave lower down in this thread is that when WebAssembly was introduced, the Chrome team decided to deprecate their own solution, PNaCl.

We're far from the days of ActiveX.

https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webass...

> Thanks for being respectful and well-reasoned in your response.

Likewise!

WebAssembly is a very good counter example, but still my feeling – or fear, really – is that this is not in spite of Google's hegemony but because of it. Let's say they hadn't gotten on board with WebAssembly and instead doubled down on PNaCL or come up with a different competing proposal. Even if all other parties rallied around WebAssembly there's a very good chance the dominance of Google would make it stillborn. If it's not in Chrome, it's simply not worth bothering, purely due to its dominance.

I recognize though that this is a bit of a straw man argument, and one based more in my opionins and feelings in the matter rather than anything resembling objective truths. I suppose that's also why we'll have to agree to disagree. :o)

> We're far from the days of ActiveX.

Thankfully!

Cheers! It's a difficult thing to quantify anyway, so agreeing to disagree sounds good to me. Do enjoy your weekend!

Aren't they "obviously" talking about Internet Explorer's hegemony "then", Chrome's rise "now"?

That’s exactly what I would do in the same shoes I think. Proposals are cool and I understand why it is better for an open web etc… but getting features immediately is pretty cool too.

But then they only work in one browser and that is massively uncool.

So yeah, standards please. And not Googley “Comments? What do you mean ‘comments’? We’ve already shipped this and we’re not changing it, so you better follow suit”-standards.

It’s almost as if Google is the new Microsoft!

You mean: the old Microsoft!

No, no, Microsoft was the old Microsoft but now they're the new Apple. Google is the new Microsoft, and Apple looks like the new Google but is actually the old Apple (the old one, mind, not the middle one where Jobs came back). Oh, and Dell is the new Gateway. :P

Embrace, Extend, Extinguish

Who are they embracing? They ARE a web based company, why extinguish web browsing?

With AMP they are trying to become the web.

What does that even mean? AMP is built on WebComponents, which are an existing web standard. That's no less standard than anything else using custom elements.

amp is a self serving standard.

Nowhere in the standard "higher search ranking on google inc" is mentioned as a must have feature. Yet it is the only feature anyone care about when discussing adoption.

If that were true (and I'm not so sure it is), then you'd blame the search team for letting it be a ranking factor. It has nothing to do with web standards.

You are not wrong (about what is on the standards). But you are being downvoted because everyone who did implement AMP in the real world, did so for the SEO benefits.

Oh I have votes disabled on social media. I'd rather form my own opinion when reading comments.

Regarding AMP, I appraised it from a speed perspective and found it partially effective, but only a bandaid fix. Addressing real site speed issues is the better approach.

Are we blaming the wrong hand ?

They are caching a chunk of the web and routing traffic from google.com to their cache. Since traffic never leaves google.com, it is now in a way the web itself. This is achieved thanks to AMP.

Technically that's AMP Cache, not AMP itself, but I get your point. It's worth noting however that both Cloudflare and Bing also run their own instances of AMP Cache.

https://amp.cloudflare.com/

https://blogs.bing.com/Webmaster-Blog/September-2018/Introdu...

And they are going to hide from the user the fact that they are indeed on AMP page on google server by hiding all prefixes.

They already started doing part of this plan btw - https://bugs.chromium.org/p/chromium/issues/detail?id=881410

Reading the comments on this post and all seems to be envy.

While Chrome does useful stuff like this, Firefox progress in the web space is... eh... adding ads to the home page?

Maybe Firefox should've went with a proposal on how to add ads into the browser, or on how to send all of your URL history to a third party. :^)