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.

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.

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.