That said, it seems easy to make this backwards compatible: if the existing #blah syntax is a valid link, that should take precedence.

FWIW, I think there's way too much cynicism in this thread. My first reaction on seeing the title was "cool! I would use that!".

edit: Hmm, I may have misunderstood the compatibility issue.

That's indeed how it works. The majority of the compatibility concerns appear to be with apps that a using _custom_ parsing of the fragment to perform app-specific logic, which is a valid concern.

https://chrome.google.com/webstore/detail/display-anchors/po...

- How does this perform on existing pages - How does this feel from a user perspective - How can I write pages that user this

Specification-up-front is very theoretical in the absence of an implementation. IMHO, where it's (rarely) happened in practice, the specification is often unimplemented. The value of a specification is that it allows other browser vendors to add an interoperable implementation.

Again, I'd like to stress, this is in the very early-stage experimental phase. We aren't dropping a feature that'll break the existing web.

Edit: To clarify, "implementation" does not necessarily mean shipped to users.

Literally just today we got an article about Web Bluetooth on the front page of HN, a user-shipped capability in Chrome that is still in the Draft phase of standardization.[0]

Beyond that, we have the Web USB API, which is also in the draft phase, but is of course shipping to users in Chrome, on by default.[1]

Beyond that, we have HTML imports, which have been rejected from the standard but are still shipping to users in Chrome.[2]

I don't doubt your intentions, but if you think that Chrome is going to wait for standardization on this before it ships, you are not paying enough attention to the teams you're working with. And once Chrome ships a feature to users, the web standards body has basically two options: accept Google's vision of the standard wholesale, or change the standard and break websites that are already using Google's implementation.

I would be more confident and trusting of the process you describe if there was some kind of official commitment from the Chrome team that this feature will stay behind a browser flag until the standardization process is completely finished. But I think some of the reason you're getting immediate pushback to an extremely early draft of the spec is because developers don't trust Google not to ship this on-by-default once it reaches a WD stage.

[0]: https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetoo...

[1]: https://developer.mozilla.org/en-US/docs/Web/API/USB

[2]: https://developer.mozilla.org/en-US/docs/Web/Web_Components/...

Microsoft did this many moons ago. People ended up defacing web sites like the New York Times and spreading proto fake news.

You're going to get people generating millions of these links around the web. That's a long term legacy of hyperlinks generated by the citizens of the web. Although the fallback is obviously pretty harmless, what about a future feature? If this doesn't work out, but some other feature down the line does, suddenly thousands of these links start working in weird ways. Or worse, the feature doesn't happen at all, because of the legacy of broken links. I know that's pessimistic, but URLs are the foundation of the web, changing how they work should be funneled through the spec.

I think the reason this sparked concern is because (by using fragments) this intrudes into a field that was previously under full author control.

I think clear guarantees about which aspects of a webpage are the responsibility of authors and which are under browser control are important - only going by real-world usage and assuming everything not directly used is free for the taking is not enough here.

E.g., I think there are failure modes for SPAs that are not easily found with a usage search. [1] Additionally, this would make it harder to know for new applications which kinds of fragment identifier are "safe" to use and which are not.

There seem to be some existing specs that deal with the same problem [2].

Maybe those could be a starting point for the feature to to forward without interop/responsibility problems?

[1] https://news.ycombinator.com/item?id=19170230

[2] https://news.ycombinator.com/item?id=19169582

It’s an exciting possibility to link more directly to resources. I hope it is implemented in such a way that all browsers can follow those links with parity in the future. If that is the case I have a few hundred thousand outlinks that could be refined for clarity.

To be clear, I agree that this format is exceedingly unlikely to collide with real fragments, but still seems like there is a safer approach.

To the fragment. Tt could, depending on how the app was written. Is there a framework or some common techniques that use this I could read-up on?

I work in analytics so I’ve seen things like UTM params get couched into the hash, breaking parsing, so at least it’s something to keep an eye out for.

You can claim to have high standards, but Google is trying to dictate the future of the web.