Hacker News Reader

Feature author here.

I'd like to first clarify that this is still in the super-early stage of development; none of this is shipped or finalized yet. The feature hasn't even requested approval to ship at which point these kinds of issues would be brought up. We take web-compat very seriously. If this breaks even a small percentage of pages, it won't ship. Part of the shipping process is ensuring we have at least a draft spec (W3C,WHATWG) at least some support from other vendors.

Sorry, the explainer text came off more dismissive than I intended. I wanted to get something implemented so we could start experimenting and see how this would work in the wild. #targetText= is a a first attempt at syntax, any criticisms or data on how this might break would be appreciated.

From my (limited) understanding of how fragments are used like this today, the way this would break a page is if the page itself was using "targetText=..." and parsing the result. This is something we can and will measure and see if we have a naming collision. For pages that use a "#var=name" type fragment, we could append "&targetText=...".

I'm not tied to any particular syntax here so if I'm missing why this is a monumentally bad idea, please file a bug on the GitHub repo: https://github.com/bokand/ScrollToTextFragment/issues

Why is this not being pushed to become part of the web spec first? That seems more reasonable than pushing a feature with the possibility of breaking pages that are spec compliant.

This is my only gripe. Please work with a spec first, so that the feature flows naturally through to other vendors. Especially because it's changing the way URLs work.

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.

It will. The specification process needs to be informed by implementation and experimentation. When implementing a feature we'll learn all sorts of things and hit bumps that will help guide the design. Once we have a working implementation, it helps to be able to use it to answer things like:

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

I feel like the actual, underlying issue worth bringing to the standards body is: how do we address arbitrary content on a web page, even when it moves around or changes over time? Aside from these neat Chrome links, this would enable some super interesting features, such as the ability to add persistent and shareable annotations to webpages.

the ability to add persistent and shareable annotations to webpages

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

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

Historically, web specs often start more descriptive than proscriptive. Building a spec without a reference implementation is a great way to build an unimplementable spec.

Would you append the & to the fragment, or to the query? If to the fragment couldn’t that affect routing for SPAs?

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.

> Would you append the & to the fragment, or to the query? If to the fragment couldn’t that affect routing for SPAs?

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?

There was a time several spa frameworks used explicit hash routing rather than url-like push state but I don’t have sources handy. I thought angular was one of them but they may have done away with this behavior.

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.

Thanks, I'll make sure to dig into that some more!

This is not rare at all, I use it almost every time I link to a wikipedia article, for example: https://en.wikipedia.org/wiki/Newton%27s_method#Examples

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 said, it seems easy to make this backwards compatible: if the existing #blah syntax is a valid link, that should take precedence.

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.

Angular 1 does this.

The parent comment's example includes a trailing equals sign on the fragment that could be used to differentiate (#targetText= vs #targetText).

FYI, there's even a Chrome extension that makes this easier:

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

It could also break pages that rely on full control over the hash, having targetText= injected unexpectedly would break a lot of crude params parsers.

That's true, but presumably these pages would have the same problem with existing id-fragments, no?

At Microsoft, I worked on a popular Web app that for various reasons had to resort to using the # to enable deep linking. If you put anything in the hash it will break things. We assumed an empty hash unless it was something we set.

Thank you very much for replying on this thread. It's absolutely a very useful feature and - when done in a standardized and privacy conscious way, I think it would absolutely be an enrichment for the web platform. (Can we extend the same for images, too, btw?)

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

Everything after # in the URL is not sent to server, which makes it handy for storing tokens.

I’m not sure what internal resource exist or what access is available to your team, but I would think that Google’s search indices would be the best resources on the planet for analyzing existing URL fragment design patterns. It seems like you could classify various implementations and run tests against each of the major groupings so that you can be confident that xxx.xxx% of sites that currently use fragments will be supported by this design.

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.

Tell me how autoplay audio is doing with it's rollout, rollback, and butchered secondary rollout.

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

Just to clearify your phrasing. Are you saying that it would be ok of this breaks less than 20million webpages? Because that is still a hell of a lot of pages.

> It's an abuse of the purpose of URL fragments

So what they're saying is, they expect a clash of their abuse of URL fragments with others' abuse of URL fragmentsto be rare because...

The arrogance here is astounding: "It's OK for us to use this, because others shouldn't be using it"

Aren't url fragment originally used for page position already? Like url.com/#title would scroll to the page the div with id "title"? In that case I don't feel like using url fragment for a word position is so much breaking it, it keeps the use of url fragment for info about page position, right?

>Aren't url fragment originally used for page position already? Like url.com/#title would scroll to the page the div with id "title"?

That was the pre-SPA, traditional role of anchors...

If you did any html between 1995-6 and 2005, you'd use it for that.

Then, with AJAX/SPAs, # was used for state (pre-history API) -- and I'd assume many webpages are still left at that use.

Of course, page anchors are still in wide use, and not just on old pages. https://github.com/facebook/react/blob/master/README.md#inst...

Very wide use.

I just finished a large healthcare web site that uses page anchors.

Page anchors are recommended by one of the (many) federal web accessibility guidelines. This is so that people with limited motion or poor motor control, or visual impairments don’t have to scroll to find what they’re looking for on a page.

It’s also how the “Skip to content” links work, which is Accessibility 101.

Sorry, I’m not at work or on a computer so I can’t link to a reference.

Here's a reference for "Skip to content" for those who have never bothered to make their web sites usable for people who aren't 20-somethings in perfect health (Google):

https://webaim.org/techniques/skipnav/

Yes but this is about namespacing/syntax and likelihood of clashes.

Normally, url fragments were intended to be used by page authors, making clashes impossible (page author controls both page and anchor syntax). Google are breaking this contract, but argue that the fact that they're using parameter-style syntax should not clash with author usage, because using parameter-style syntax is "an abuse" of the feature.

This is a good point, which I didn't get until your comment. I think they should surface this on that page, because it seems everyone is thinking this will be a big clash, but as you say, if someone shares a sentence, the likelihood is low.

To double check, does this means things like,

  https://www.spa/#!/path/to/view

Can become

  https://www.spa/#!/path/to/view&targetText=percent%20encoded

The only part I don't get about the likelihood and this extension is how it interacts with these kind of hash routes.

I haven't thought that much about the next part, but how do people feel about the following?

  web+text://https://www.spa/#!/route/to/view#targetText=percent%20encoded

or something. Rather than extending URLs vertically, extend horizontally into a different protocol the URI of which can encode the syntax elegantly.

Googles’s fragment solution should gracefully degrade to behaving like the normal link in other browsers (as long as there isn’t some fragment conflict) but creating a new pseudo protocol would have to be supported by each browser to even get to the site.

I think that's more risky in that most browsers and many intermediate proxies or other traffic inspectors are likely to have special casing around http: (at least) and https: and for most traffic to be over http(s): and a tiny sliver over web+text: seems fraught with more peril than a (fairly small and intention-aligned) abuse of #fragments. Even mail agents, markdown processors, and other text-display applications often have special casing to turn http(s) URLs into touchable/clickable links.

Page authors are unlikely to use web+text: if it means cutting off old browsers from access.

You could use two hashes like that and stick with http. I reckon browsers would cope, and you could strip the second one.

That is true of any URL, the user can decide to use it in ways you don't want. But that is also an intrinsic feature of the web. The best approach is to give users flexibility, but accept that websites may overide that behaviour.

Well, if we're talking about intention, they were originally a browser feature allowing to scroll to a specific <a target=..>. They were invented before JS if I'm not mistaken, so the assumption was that the browser was handling it.

Originally used with <a> anchors IIRC. So, yes it breaks the original use, instead of scrolling to the anchor with the correct "name" it could/would scroll to a different text search point.

Why not "##" as a new URL fragment, or add a "scrollto" to the link tag that the browser can use?

I guess those were discussed, is there an RFC?

It's another story point in the tale of how Google shaped the neo-modern web.

Google's influence is massive, anyone wanting to build a profitable website needs to bend to their standards of performance and structure.

Normally this was a general push in the right direction for everyone. With how they've been handling AMP however, part of me wonders if they're not trying to build a feature moat around the web itself. Although misguided use of their power by individual product-managers is probably the less sinister, more likely reason.

Hmm, who provided the first popular JS framework that used fragments for navigation again?

I think it was called "Angular".

Gmail was probably the first very-widely-used app that used the fragment for navigation, and Google drove the whole #! thing.

That technique is now considered obsolete, with the History API (history.pushState and all that lot) having supplanted it. IE9 is the most popular browser currently in use that doesn’t support it; there are still definitely some systems out there that will use the History API if it’s available, or fall back to using the hash if it’s not, but I find that using the hash for navigation in deployed apps is surprisingly dead, given that it’s shy of six and a half years since IE10 came out, and Firefox and Chrome only had a year and two’s lead (and Chrome’s implementation especially was unreliable for quite some time).

Using the hash for navigation is still very common in development workflows. But that can be ignored for a feature like this.

pushState is bad for many use cases because it completely breaks linking.

It doesn't have to, if you also provide routes on the backend so that pushState URLs actually resolve to a real URL that serves the same content. Or just provide a wildcard route and use JS to detect the URL like you would with hash-based navigation.

It does require more coordination between the front and back-end though.

I meant using pushState using the state object for something other than caching. If I click on "About us" and this results in pushState({page:"about-us"}, "", "#") then linking just doesn't work any more. It's a regression back to the days of Flash.

Ah, gotcha. Yes, that's a truly awful way to use it.

You can go back even further. GWT (formerly Google Web Toolkit) uses the fragment to store navigation tokens. I actively maintain a GWT SPA in my day job.

> It's an abuse of the purpose of URL fragments

Would you just look at who's preaching... If it ain't the same Google that all but standardized the use of #! contraption in the pre-HTML5 days - "you don't use, we don't crawl it" kinda thing.

This is an abuse alright, but a better choice of wording might've been appropriate.

While it does smack a little of the arrogance of a big player, they are using the fragment part for more-or-less what it used to be used for (navigating to a specific location on a page), and if you use something in a way it isn't intended (using a navigation aid for state management) perhaps you should expect certain things to break at some point when combined with other hacks of the same feature.

It is important to note that this won't break your site/app in the normal use case. People using your work will continue to do so uninhibited unless/until they wish to use this new feature in Chrome.

Couldn't they put this in a second fragment? #pageNavigation=home##targetText=foo

That way both could live together, if the page uses # in the fragment, just percent encode it.

At most this would break old bookmarks.

It should only cause a problem for pages using “targetText” as an anchor or id where someone would link to “page#targetText”

I would expect that it’s possible for both to work since Chrome’s hack requires the equal sign and its parameters. So with no equal, works as spec. With equal works with hack (that will likely make it into spec).

Even when a page has the targetText anchor and receives the text link param, I think the desired user behavior is to link to the text, not the anchor.

The proposal, as currently stated, is to use fragment id processing first. If that fails to find a target, fallback to text matching.

In other words, even if you give an element "id='targetText=something'", this feature wouldn't break that.

Good lord, I see pages that would break from this constantly...

you constantly see pages with #targetText=blah fragments?

I think he means it the other way around. You have a Single page application with routing based on #someRoute, then someone tries to share some link with the #targetText=... which will lead to an invalid route. Or am I missunderstanding something?

You’re thinking of ?targetText= or &targetText=

Hash isn’t used for query parameters.

Not for query parameters sent to the remote server, but there are definitely pages/applications that store state in the hash.

For example, look at the URLs used by mega.nz, or any encrypted pastebin (they store the decryption key in the hash so it's not sent to the server).

lots of older or poorly written SPAs use the hash exactly in this way. I guess their fault for being poorly written, like those people who allowed GET requests to /deleteaccount based on the theory that you had to be logged in with a browser for it to ever happen and not considering that google would make an extension that did all get requests on a page on entry.

They didn't use it because they were "poorly written", it was a "state of the art" technique back in the day.

Gmail used, others used it.

https://stackoverflow.com/questions/15238391/hash-params-vs-...

sure, it was state of the art back in the day, but state of the art over time depreciates to technical debt, and the ones that are left using what was once state of the art are now poorly written.

>and the ones that are left using what was once state of the art are now poorly written.

They could just be perfectly written (for their time), just legacy and not updated, is my distinction.

at some point the accretion of legacy and not fixing issues to match better understanding turns a perfectly written for its time application into a poorly written application for the present.

That doesn't give Google the right to break all those sites though.

right, I guess I should have indicated sarcasm on the I guess it's their fault part.

It is in client-side JS single-page-apps...

It was used in SPAs. It was a common technique in the mid-2000s up to 2010 or so.

But not for query parameters per se, for app state stored in the query string (and bookmarkable).

https://stackoverflow.com/questions/15238391/hash-params-vs-...

One that quickly comes to mind...

https://store.steampowered.com/tags/en/Adventure/#p=3&tab=To...

doesnt seem to break on addition of a targetText "hash-param"

Backbone JS uses hash for routing. Case in point - http://backbonejs.org/#Router. There should be lot of sites that uses hash params as routes which still exists from the early SPA era.

This assumes all SPAs would ignore unknown parameters they see in the fragment part. Even if the SPA itself doesn't use "targetText", it could still try to validate the fragment and abort with errors on unknown data present.

Also, this would require the "targetText" parameter to live peacefully alongside other parameters. (That in turn would require there were a standard definition of "parameter" inside the fragment at all)

E.g, if Chrome encounters an url with an existing fragment, it would somehow have to combine this with its own targetText parameter and hope the SPA still understands the combined fragment.

Yes, in particular many B2B web apps' help systems (looking at you, adobe) do very unholy things with these fragments.

Which is exactly why we build an experiment first, to find potential issues before shipping.

If you do see a page that you think might break and you're on Chrome newer than 74.0.3706.0, try turning on chrome://flags#enable-text-fragment-anchor and giving it a try. If something looks out of place, that would be extremely useful data for us. File a bug either at

https://github.com/bokand/ScrollToTextFragment/issues

or

https://crbug.com/new

Wouldn't it be valid to anchor the link to a div with an 'id' of targetText? I fail to see how that's in any way an abuse of URL fragments.

> We'll just completely change the commonly understand processing model of fragment identifiers, but it'll be fine since we don't think anyone is using them anyway...

That's not true. Truth is:

> We'll just completely change the commonly understand processing model of fragment identifiers, it may not be fine, but can you really stop us?

We shall stop using the turning lights (blinkers)... It is an abuse but anyway, novody uses them.