281–290 of 332 posts
Technical question, apart from the (valid IMO) political arguments: Google's idea to implement this is to append the text fragment to the URL in a "#targetText" pseudo-query-argument in the URL fragment part. This sounds like it would extremely easily break existing web pages who use the fragment part for their own state. In the blog post, there doesn't seem to be anything addressing this (or even just specifying how…
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 dra…
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.
It seems like more and more, Google is leveraging their near-monopoly on web browsing to just skip the proposal process and do whatever they want without discussion.
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.
Earlier quoted context omitted.
“#” Fragments aren’t sent to the server at all. They are ONLY used to get to a specific anchor (old school) or processed by JavaScript to do something (often fake navigation by showing and hiding content). This article is adding a 3rd magic use for them.
Yeah, I know. Parent was saying that the History API doesn't need any server support, because you can just serve the same file no matter what the subpath, but my point is that lots of servers don't even have support for that. That's why the fragment is still more useful than the History API in some cases.
Earlier quoted context omitted.
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 dra…
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.
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?
Earlier quoted context omitted.
> 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 s…
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.
Whether or not you agree is one thing, but I hope my point is clearer now anyways. :o)
Technical question, apart from the (valid IMO) political arguments: Google's idea to implement this is to append the text fragment to the URL in a "#targetText" pseudo-query-argument in the URL fragment part. This sounds like it would extremely easily break existing web pages who use the fragment part for their own state. In the blog post, there doesn't seem to be anything addressing this (or even just specifying how…
Good lord, I see pages that would break from this constantly...
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
Earlier quoted context omitted.
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.
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…
Earlier quoted context omitted.
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 domin…
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...