5 ms·

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 l

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?

coldtea 8y ago
>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.
- tyingq 8y ago
  Of course, page anchors are still in wide use, and not just on old pages. https://github.com/facebook/react/blob/master/README.md#installation https://github.com/facebook/react/blob/master/README.md#inst...
  - reaperducer 8y ago
    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.
    - reaperducer 8y ago
      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/ https://webaim.org/techniques/skipnav/
lucideer 8y ago
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.
- deepstream 8y ago
  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.
  - croddin 8y ago
    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.
  - sokoloff 8y ago
    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.
pbhjpbhj 8y ago
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?

coldtea 8y ago

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

tyingq 8y ago
Of course, page anchors are still in wide use, and not just on old pages. https://github.com/facebook/react/blob/master/README.md#installation https://github.com/facebook/react/blob/master/README.md#inst...
- reaperducer 8y ago
  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.
  - reaperducer 8y ago
    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/ https://webaim.org/techniques/skipnav/

lucideer 8y ago

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.

deepstream 8y ago
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.
- croddin 8y ago
  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.
- sokoloff 8y ago
  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.

pbhjpbhj 8y ago

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?