This proposal clashes with SPA routers and hash-persisted state
Closed this issue · 12 comments
This proposal will break all kinds of apps.
SPA routers like the one bundled with Mithril let one transparently use either the path, the querystring or the hash part of the URL to store the route params. So URLs ending with #/foo/bar?baz=5&qux=6 are not uncommon. Even adding another &targetText=... could break existing pages.
Some apps also serialize their state in the hash part for sharing and saving (bookmark).
As much as I agree it's probably not ideal, he did cite substantial precedent in current, active standards. Also, it's not like he's proposing anything starting with either #! or #/, so I don't find it likely to conflict in practice.
Flems is another story though...
@pygy Flems starts with #V=... where V is a version number. That still won't intersect.
I'd prefer using %% as a delimiter, and I do feel this should've been done at least with standards bodies' input, so they could inform them on how to avoid conflicting with stuff in practice - they get accused a lot of being disconnected from developers (think: web components), but they're not that disconnected from reality.
The original Fragmention proposal suggested using ## but I found that violated the URL parsing spec (and caused exceptions in some apps). Using %% is likely to cause problems too.
In practice, a page with state in the hash is very unlikely to collide with a space separated word list. Your SPAs already need to cope with links without fragments, or fragments you can't parse, so a text fragment link would fall in that case.
Welp...somehow this doesn't surprise me. BTW, I was specifically looking for things that break the URL spec, so the parser can be adjusted to accomodate it, but apparently that's not sufficient. I'm probably only +0 on this whole bug anyways - I don't like the current situation, but there's not any real alternative because URLs appear as extensible as a brick.
I think that current ideas and consecutive comments misses one substantial opportunity for UA vendor implementing such feature: It is fact that introducing any such "URL extension" could (and probably should) be accompanied with mechanism that will prevent the non-standard alterations to "fall into the webpage", i. e. that web page should not know about it, scripts in the page should see "original" location.hash as well as target identifiers and so on.
protocol://host/path?search#original hash<magical delimiter>something only UAs will see
Exploiting something syntactically wrong or weird like %% seems like a brilliant idea to me. (That is, if I'm not mistaken it is sequence that could not appear in any conforming URL implementation, could it?)(I was thinking about %00 that in naïve implementation could "end" the URL, but although unlikely is it somewhat valid and thus could hypothetically collide).
(For record, I'm not completely comfortable with this idea as well, just was surprised that debate still unnecessarily circulates around "it will break our hasbangs!!1".)
@myfonj This is precisely the reason why I suggested %%. It's intentionally invalid, and no conforming URL parser should accept it. The only time % is valid currently is if it's followed by two case-insensitive hexadecimal digits. (However, parsers following RFC 3986 directly don't necessarily have to do UTF-8 decoding, unlike the WHATWG spec!)
(For record, I'm not completely comfortable with this idea as well, just was surprised that debate still unnecessarily circulates around "it will break our hasbangs!!1".)
BTW, I'm the one who debunked the proposed risk of breakage in this bug. I'm not comfortable with the proposal personally, but breakage isn't one of the reasons why.
I do have concerns that the proposal itself needs to take into account how existing hashes get parsed for things like routing and anchors, just so it plays well with it.
I do think we'll need to look at how the proposal will interact with existing SPAs, but I also think we should try to make it work with fragments before trying other approaches. For one, this falls into exactly what fragments are specified to do so it'd be a shame to duplicate the functionality using new syntax.
It is fact that introducing any such "URL extension" could (and probably should) be accompanied with mechanism that will prevent the non-standard alterations to "fall into the webpage"
I think there's value to exposing the targetted text to the page content. Consider the case of an app with an infinite scroller. If the URI targets a bit of text that requires loading additional content, the page needs to be designed to take that into account. If we hide the target from the page there's no way to target anything that's not available at load. Allowing content to see it would allow the page to read the hash, load the appropriate content, and scroll it into view (manually if needed).
Something that'd be useful here, does anyone have any live examples of SPAs they could link that use a routing scheme that might conflict?
For a real world example of where specifying anything in a hash breaks the page, see:
https://www.webmd.com/skin-problems-and-treatments/lice-treatment
Sigh...
I think something as proposed by @myfonj / @isiahmeadows might be the way to go. Lets continue tracking this issue in #15