[webkit-dev] Feedback on Blink's text fragment directive proposal

Ryosuke Niwa rniwa at webkit.org
Thu Sep 24 22:24:55 PDT 2020


On Thu, Sep 24, 2020 at 8:19 AM David Bokan <bokan at chromium.org> wrote:

> Can you clarify what question you’re looking to have answered? Are you
>> asking for a new standards position in light of the replies below?
>>
>
>  There are two specific points:
>
>  - As I understand it, HTML requires multi-vendor interest to merge
> changes to specs. Is Apple's position sufficient to start that process? I'd
> be happy to start turning the spec into PRs but I interpreted the earlier
> position in this thread more as "not-opposed" rather than support (is that
> a fair reading?)
>

Given we're concerned about compatibility and this affects how URL, which
is a pretty fundamental part of the Web, is interpreted, it's fair to say
we're not ready to endorse such a motion.

 - Would Apple accept contributions to WebKit implementing this feature?
>
> Google Search uses this on supporting UAs - user surveys have found this
> improves the user experience. A recently published extension
> <https://chrome.google.com/webstore/detail/link-to-text-fragment/pbcodcjpfjdpcineamnnmbkkmkdpajjg?hl=en>
> to generate links to text already has over 50,000 users. This is clearly
> useful to users but would really be helped if we can make it interoperable
> across browsers.
>

Given the number of internet users is roughly 3.4 billion, and Chrome seems
to have ~1 billion users, 50,000 (0.005%?) seems like a rather small number
of users. I'm not saying that there aren't any user interests and I
disagree with the underlying use cases. However, the fact this may pose a
compatibility issue and affect millions of users who are using (sometimes
very) old browsers to browse the internet, that doesn't seem to suggest a
good risk-reward tradeoff.

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20200924/1230f8e8/attachment.htm>


More information about the webkit-dev mailing list