bokan

IMHO the argument on the blog mischaracterizes the situation - Chrome didn't break these properties but changed how they're interpreted under pinch-zoom. This was done precisely to keep backwards compatibility (on desktop browsers): at the time, the vast majority of pages assumed pinch-zoom can't happen on desktop (something that was becoming more common). The status quo meant zooming in on a desktop page would cause it to "swim" as various "fixed" elements shifted around, JS drop-down menus appeared in the wrong place, etc. This happened virtually everywhere one looked: facebook, twitter, apple.com, etc.

The blog basically argues for "make pages fix themselves" which, even if major sites do, is unrealistic in the long tail.

> They might pull the “proposal” only to just do it again later

It's not nefarious, this often happens in response to feedback and real world experience to try and minimize disruption. In this case, developers convincingly argued that there should be an API to better react to pinch-zoom before making the change.

The hope is that this is useful and adopted by other browser engines and links like this would eventually be interoperable.

If you're looking to link a citation to a statement, having the text is far more useful since the person following the link doesn't have to now find the statement in a potentially large and broad section. Also, if the page has since changed and the text no longer substantiates the cited claim, that'll be immediately apparent.

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.

Absolutely! Launching a change to the web platform is a long, arduous process. This feature is currently taking the very early first steps.

For more details, see https://www.chromium.org/blink/launching-features.

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

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?

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

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

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

The CSS timing attack actually influenced the design process heavily. The original design was to use a stripped down CSS selector but we found this too large of an attack surface.

There's definitely still concerns around making sure a 3rd party can't exfiltrate information from the page using this but we think we've found a set of restrictions that should prevent this: https://github.com/bokand/ScrollToTextFragment#security

Chrome's profiler actually shows synchronous layouts and style recals forced from JS as layout/style so it's not misleading in that way. The traces I've looked at (admittedly, not something I do terribly often) showed those to be typically ~20% or less of the time spent while content is loading.

> And, due to ads, a lot of the performance cost is cross-domain iframes, which have no reason to run on the main thread (process isolation is too heavyweight to scale this far, which is why Chrome-style Site Isolation isn't a solution).

I suppose the proof will be in the pudding, but I think process isolation could actually be a solution here. You don't have to have a separate process for every cross origin iframe. This is something desirable to do anyway for the security benefits so you might as well leverage it for performance as well. IMHO, this is the biggest problem with web perf and I don't see Servo as directly addressing it.

> If layout were fast, we wouldn't see people implementing layouts in JS

Are people re-implementing layout/paint because it's slow? Or because we didn't bake in the little detail they want into the platform through a multiyear standardisation process? I think it's naive to think developers will just stop writing JS if the browser gets x% faster.

> If the main thread weren't so bogged down all the time, then people wouldn't see the need to move a random subset of the Web platform to the compositor thread.

I disagree. Developers will always find something to fill it with. IMHO, the real goal - and the reason for the compositor thread - is to separate rendering from input and make it difficult for a page to tie the two together (or rather, easy to keep them separate). A user wont notice if the page takes an extra few hundred ms to render. She will notice if her scroll is delayed by 200ms.

I don't see Houdini as the main thrust here, there's lower hanging fruit. Practically speaking, non-blocking event handlers have had a bigger impact on user experience than anything I've seen in the last few years. I expect IntersectionObserver to have a big impact too. I think chasing the long tail of UX antipatterns, while not as sexy, is far more productive.

In any case, I'd be happy to be proven wrong here - Servo is doing some really cool stuff and no one would be sad to see things get faster; I just don't see it as the silver bullet it's often promoted to be. I think this is a great example of how having multiple rendering engines is healthy for the web. Lets all innovate independently and let the results speak for themselves :).

Disclaimer: I work on Chrome.