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

[David Bokan via webkit-dev]

+1 that this seems like a really nice fit for text fragments, even if it's
only to reuse the text-matching implementation.

By way of an update, Chrome is rolling out a "copy-link-to-text" context
menu item (a built-in version of the earlier discussed extension):
https://blog.google/products/chrome/more-helpful-chrome-throughout-your-workday

Incidentally, the link above shows where text-fragments can be helpful. The
page lists many features and doesn't provide convenient `id` anchors. With
a text fragment, I can link you to
https://blog.google/products/chrome/more-helpful-chrome-throughout-your-workday/#:~:text=Link%20to%20your%20highlighted%20text.
Unfortunately, I can't know what browser the recipient will open the link
with (guessing webkit-dev@ typically doesn't use Chrome :). To be truly
useful, we'd need these links to be understood by WebKit and Gecko as well.

I've come across text-fragment links where they'd be helpful to the user:
 - The link in "Musk has previously spoken about" on this Verge article

 - Citation 9 in this Wikipedia page


With the built in functionality, I expect these links will become more
prevalent and seen by users of WebKit based browsers. We'll have more usage
numbers soon on how often these links are being generated from Chrome.

On Wed, Jun 9, 2021 at 12:37 PM Thomas Steiner  wrote:

> On Wed, Jun 9, 2021 at 6:27 PM Megan Gardner 
> wrote:
>
>> We are store the explicite range/position information in the associated
>> note, and also use text matching as a fallback.
>>
>
> Thanks for responding! Any desire to adopt the Text Fragment syntax (
> https://web.dev/text-fragments/) for the (brilliant) Quick Notes feature?
>
> Note that we have enabled this feature in Chrome for iOS (
> https://apps.apple.com/us/app/google-chrome/id535886823) by injecting a
> polyfill into the `WKWebView`. You can test it by opening this link
> https://blog.chromium.org/2019/12/chrome-80-content-indexing-es-modules.html#:~:text=ECMAScript%20Modules%20in%20Web%20Workers
> with Chrome.
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Thomas Steiner via webkit-dev]

On Wed, Jun 9, 2021 at 6:27 PM Megan Gardner 
wrote:

> We are store the explicite range/position information in the associated
> note, and also use text matching as a fallback.
>

Thanks for responding! Any desire to adopt the Text Fragment syntax (
https://web.dev/text-fragments/) for the (brilliant) Quick Notes feature?

Note that we have enabled this feature in Chrome for iOS (
https://apps.apple.com/us/app/google-chrome/id535886823) by injecting a
polyfill into the `WKWebView`. You can test it by opening this link
https://blog.chromium.org/2019/12/chrome-80-content-indexing-es-modules.html#:~:text=ECMAScript%20Modules%20in%20Web%20Workers
with Chrome.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Megan Gardner via webkit-dev]

We are store the explicite range/position information in the associated note, 
and also use text matching as a fallback.

Megan Gardner

> On Jun 8, 2021, at 2:24 AM, Thomas Steiner via webkit-dev 
>  wrote:
> 
> Hi all,
> 
> Seems like Quick Notes, announced at WWDC2021 (deep-link: 
> https://youtu.be/0TD96VTf0Xs?t=2832 ), 
> implements the behavior of Text Fragments, including the highlighting part 
> and the disambiguation of duplicate texts (see my screencast 
> https://youtu.be/4MzxJGZvt1Y ). I fail to 
> reverse-engineer how this works, but from observing the behavior it well 
> looks like it could be using the #:~:text=foo syntax. Can you shine some 
> light on this?
> 
> Thanks,
> Tom
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Thomas Steiner via webkit-dev]

Hi all,

Seems like Quick Notes, announced at WWDC2021 (deep-link:
https://youtu.be/0TD96VTf0Xs?t=2832), implements the behavior of Text
Fragments, including the highlighting part and the disambiguation of
duplicate texts (see my screencast https://youtu.be/4MzxJGZvt1Y). I fail to
reverse-engineer how this works, but from observing the behavior it well
looks like it could be using the #:~:text=foo syntax. Can you shine some
light on this?

Thanks,
Tom
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[David Bokan via webkit-dev]

Post-holiday ping.

On Mon, Nov 23, 2020 at 8:44 PM David Bokan  wrote:

> Friendly ping - have the above changes addressed the concerns?
>
> On Mon, Nov 16, 2020 at 6:57 PM David Bokan  wrote:
>
>> Hey Maciej/Ryosuke,
>>
>> I've updated the spec to be more precise around stripping the fragment
>> directive. Specifically, section 3.3.1
>> 
>>  is
>> fleshed out and makes the implications explicit, via examples, about how
>> various APIs behave. Let me know if I missed any.
>>
>> Regarding bookmarks, sharing, etc. To me, these seem to fall outside of
>> interop-affecting as I understand it so it makes sense to allow UAs some
>> leeway in determining how these features should work. That said, it might
>> be helpful for user expectations to have a consistent starting point so
>> I've added section 3.6.1
>>  which
>> contains non-normative recommendations. These should match Chrome's current
>> or upcoming behavior.
>>
>> If you just want to see changes, see pull-requests linked from issue #150
>> .
>>
>> Cheers,
>> David
>>
>> On Thu, Nov 5, 2020 at 2:55 PM David Bokan  wrote:
>>
>>> Thanks Maciej, that's helpful feedback. I'll work on the spec text to
>>> clarify all these cases and circle back when that's done.
>>>
>>> On Sun, Nov 1, 2020 at 8:24 PM Maciej Stachowiak  wrote:
>>>


 On Oct 30, 2020, at 1:40 PM, David Bokan  wrote:

 Hi Ryosuke,

 Would just like to clarify one point.

 On Fri, Sep 25, 2020 at 12:42 PM David Bokan 
 wrote:

> [Sorry, meant to reply-all]
>
> On Fri, Sep 25, 2020 at 1:25 AM Ryosuke Niwa  wrote:
>
>>
>> On Thu, Sep 24, 2020 at 8:19 AM David Bokan 
>> 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.
>>
>
 The change we've proposed and implemented in Chrome doesn't touch
 anything in the URL spec or handling; it's entirely an extension to
 fragment processing in HTML documents only. If this were implemented in
 WebKit and Gecko I think that'd address any compat issues? If you don't
 agree, could you clarify what you see as the main compat risk?


 It looks like the current spec does not affect URL per se, but does
 have this remark re the fragment directive: "It is reserved for UA
 instructions, such as text=, and is stripped from the URL during loading so
 that author scripts can’t directly interact with it.” <
 https://wicg.github.io/scroll-to-text-fragment/#the-fragment-directive>

 The is not specified precisely enough for interop. What does it mean to
 strop the fragment directive from the UR? When during loading does this
 occur?

 Section 3.3.1 is more specific <
 https://wicg.github.io/scroll-to-text-fragment/#parsing-the-fragment-directive>
 in that it monkeypatches the HTML create and initialize a Document object
 steps in a way that would affect what JavaScript sees.  However, it’s not
 clear what happens to other ways the UA exposes the URL, such as in the
 location field, or if the page is bookmarked or shared.

 Regards,
 Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[David Bokan via webkit-dev]

Friendly ping - have the above changes addressed the concerns?

On Mon, Nov 16, 2020 at 6:57 PM David Bokan  wrote:

> Hey Maciej/Ryosuke,
>
> I've updated the spec to be more precise around stripping the fragment
> directive. Specifically, section 3.3.1
> 
>  is
> fleshed out and makes the implications explicit, via examples, about how
> various APIs behave. Let me know if I missed any.
>
> Regarding bookmarks, sharing, etc. To me, these seem to fall outside of
> interop-affecting as I understand it so it makes sense to allow UAs some
> leeway in determining how these features should work. That said, it might
> be helpful for user expectations to have a consistent starting point so
> I've added section 3.6.1
>  which
> contains non-normative recommendations. These should match Chrome's current
> or upcoming behavior.
>
> If you just want to see changes, see pull-requests linked from issue #150
> .
>
> Cheers,
> David
>
> On Thu, Nov 5, 2020 at 2:55 PM David Bokan  wrote:
>
>> Thanks Maciej, that's helpful feedback. I'll work on the spec text to
>> clarify all these cases and circle back when that's done.
>>
>> On Sun, Nov 1, 2020 at 8:24 PM Maciej Stachowiak  wrote:
>>
>>>
>>>
>>> On Oct 30, 2020, at 1:40 PM, David Bokan  wrote:
>>>
>>> Hi Ryosuke,
>>>
>>> Would just like to clarify one point.
>>>
>>> On Fri, Sep 25, 2020 at 12:42 PM David Bokan  wrote:
>>>
 [Sorry, meant to reply-all]

 On Fri, Sep 25, 2020 at 1:25 AM Ryosuke Niwa  wrote:

>
> On Thu, Sep 24, 2020 at 8:19 AM David Bokan 
> 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.
>

>>> The change we've proposed and implemented in Chrome doesn't touch
>>> anything in the URL spec or handling; it's entirely an extension to
>>> fragment processing in HTML documents only. If this were implemented in
>>> WebKit and Gecko I think that'd address any compat issues? If you don't
>>> agree, could you clarify what you see as the main compat risk?
>>>
>>>
>>> It looks like the current spec does not affect URL per se, but does have
>>> this remark re the fragment directive: "It is reserved for UA instructions,
>>> such as text=, and is stripped from the URL during loading so that author
>>> scripts can’t directly interact with it.” <
>>> https://wicg.github.io/scroll-to-text-fragment/#the-fragment-directive>
>>>
>>> The is not specified precisely enough for interop. What does it mean to
>>> strop the fragment directive from the UR? When during loading does this
>>> occur?
>>>
>>> Section 3.3.1 is more specific <
>>> https://wicg.github.io/scroll-to-text-fragment/#parsing-the-fragment-directive>
>>> in that it monkeypatches the HTML create and initialize a Document object
>>> steps in a way that would affect what JavaScript sees.  However, it’s not
>>> clear what happens to other ways the UA exposes the URL, such as in the
>>> location field, or if the page is bookmarked or shared.
>>>
>>> Regards,
>>> Maciej
>>>
>>>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Rune Lillesveen via webkit-dev]

Hi,

Blink now has an intent to ship[1] for the `::target-text` selector as
specified in css-pseudo[2] which supports styling the text fragment
highlight.

[1]
https://groups.google.com/a/chromium.org/g/blink-dev/c/yN2lrq67a1c/m/_Giqh2g_AwAJ
[2] https://drafts.csswg.org/css-pseudo-4/#selectordef-target-text

On Tue, Nov 17, 2020 at 12:57 AM David Bokan via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> Hey Maciej/Ryosuke,
>
> I've updated the spec to be more precise around stripping the fragment
> directive. Specifically, section 3.3.1
> 
>  is
> fleshed out and makes the implications explicit, via examples, about how
> various APIs behave. Let me know if I missed any.
>
> Regarding bookmarks, sharing, etc. To me, these seem to fall outside of
> interop-affecting as I understand it so it makes sense to allow UAs some
> leeway in determining how these features should work. That said, it might
> be helpful for user expectations to have a consistent starting point so
> I've added section 3.6.1
>  which
> contains non-normative recommendations. These should match Chrome's current
> or upcoming behavior.
>
> If you just want to see changes, see pull-requests linked from issue #150
> .
>
> Cheers,
> David
>
> On Thu, Nov 5, 2020 at 2:55 PM David Bokan  wrote:
>
>> Thanks Maciej, that's helpful feedback. I'll work on the spec text to
>> clarify all these cases and circle back when that's done.
>>
>> On Sun, Nov 1, 2020 at 8:24 PM Maciej Stachowiak  wrote:
>>
>>>
>>>
>>> On Oct 30, 2020, at 1:40 PM, David Bokan  wrote:
>>>
>>> Hi Ryosuke,
>>>
>>> Would just like to clarify one point.
>>>
>>> On Fri, Sep 25, 2020 at 12:42 PM David Bokan  wrote:
>>>
 [Sorry, meant to reply-all]

 On Fri, Sep 25, 2020 at 1:25 AM Ryosuke Niwa  wrote:

>
> On Thu, Sep 24, 2020 at 8:19 AM David Bokan 
> 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.
>

>>> The change we've proposed and implemented in Chrome doesn't touch
>>> anything in the URL spec or handling; it's entirely an extension to
>>> fragment processing in HTML documents only. If this were implemented in
>>> WebKit and Gecko I think that'd address any compat issues? If you don't
>>> agree, could you clarify what you see as the main compat risk?
>>>
>>>
>>> It looks like the current spec does not affect URL per se, but does have
>>> this remark re the fragment directive: "It is reserved for UA instructions,
>>> such as text=, and is stripped from the URL during loading so that author
>>> scripts can’t directly interact with it.” <
>>> https://wicg.github.io/scroll-to-text-fragment/#the-fragment-directive>
>>>
>>> The is not specified precisely enough for interop. What does it mean to
>>> strop the fragment directive from the UR? When during loading does this
>>> occur?
>>>
>>> Section 3.3.1 is more specific <
>>> https://wicg.github.io/scroll-to-text-fragment/#parsing-the-fragment-directive>
>>> in that it monkeypatches the HTML create and initialize a Document object
>>> steps in a way that would affect what JavaScript sees.  However, it’s not
>>> clear what happens to other ways the UA exposes the URL, such as in the
>>> location field, or if the page is bookmarked or shared.
>>>
>>> Regards,
>>> Maciej
>>>
>>> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[David Bokan via webkit-dev]

Hey Maciej/Ryosuke,

I've updated the spec to be more precise around stripping the fragment
directive. Specifically, section 3.3.1

is
fleshed out and makes the implications explicit, via examples, about how
various APIs behave. Let me know if I missed any.

Regarding bookmarks, sharing, etc. To me, these seem to fall outside of
interop-affecting as I understand it so it makes sense to allow UAs some
leeway in determining how these features should work. That said, it might
be helpful for user expectations to have a consistent starting point so
I've added section 3.6.1
 which
contains non-normative recommendations. These should match Chrome's current
or upcoming behavior.

If you just want to see changes, see pull-requests linked from issue #150
.

Cheers,
David

On Thu, Nov 5, 2020 at 2:55 PM David Bokan  wrote:

> Thanks Maciej, that's helpful feedback. I'll work on the spec text to
> clarify all these cases and circle back when that's done.
>
> On Sun, Nov 1, 2020 at 8:24 PM Maciej Stachowiak  wrote:
>
>>
>>
>> On Oct 30, 2020, at 1:40 PM, David Bokan  wrote:
>>
>> Hi Ryosuke,
>>
>> Would just like to clarify one point.
>>
>> On Fri, Sep 25, 2020 at 12:42 PM David Bokan  wrote:
>>
>>> [Sorry, meant to reply-all]
>>>
>>> On Fri, Sep 25, 2020 at 1:25 AM Ryosuke Niwa  wrote:
>>>

 On Thu, Sep 24, 2020 at 8:19 AM David Bokan  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.

>>>
>> The change we've proposed and implemented in Chrome doesn't touch
>> anything in the URL spec or handling; it's entirely an extension to
>> fragment processing in HTML documents only. If this were implemented in
>> WebKit and Gecko I think that'd address any compat issues? If you don't
>> agree, could you clarify what you see as the main compat risk?
>>
>>
>> It looks like the current spec does not affect URL per se, but does have
>> this remark re the fragment directive: "It is reserved for UA instructions,
>> such as text=, and is stripped from the URL during loading so that author
>> scripts can’t directly interact with it.” <
>> https://wicg.github.io/scroll-to-text-fragment/#the-fragment-directive>
>>
>> The is not specified precisely enough for interop. What does it mean to
>> strop the fragment directive from the UR? When during loading does this
>> occur?
>>
>> Section 3.3.1 is more specific <
>> https://wicg.github.io/scroll-to-text-fragment/#parsing-the-fragment-directive>
>> in that it monkeypatches the HTML create and initialize a Document object
>> steps in a way that would affect what JavaScript sees.  However, it’s not
>> clear what happens to other ways the UA exposes the URL, such as in the
>> location field, or if the page is bookmarked or shared.
>>
>> Regards,
>> Maciej
>>
>>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[David Bokan via webkit-dev]

Thanks Maciej, that's helpful feedback. I'll work on the spec text to
clarify all these cases and circle back when that's done.

On Sun, Nov 1, 2020 at 8:24 PM Maciej Stachowiak  wrote:

>
>
> On Oct 30, 2020, at 1:40 PM, David Bokan  wrote:
>
> Hi Ryosuke,
>
> Would just like to clarify one point.
>
> On Fri, Sep 25, 2020 at 12:42 PM David Bokan  wrote:
>
>> [Sorry, meant to reply-all]
>>
>> On Fri, Sep 25, 2020 at 1:25 AM Ryosuke Niwa  wrote:
>>
>>>
>>> On Thu, Sep 24, 2020 at 8:19 AM David Bokan  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.
>>>
>>
> The change we've proposed and implemented in Chrome doesn't touch anything
> in the URL spec or handling; it's entirely an extension to fragment
> processing in HTML documents only. If this were implemented in WebKit and
> Gecko I think that'd address any compat issues? If you don't agree, could
> you clarify what you see as the main compat risk?
>
>
> It looks like the current spec does not affect URL per se, but does have
> this remark re the fragment directive: "It is reserved for UA instructions,
> such as text=, and is stripped from the URL during loading so that author
> scripts can’t directly interact with it.” <
> https://wicg.github.io/scroll-to-text-fragment/#the-fragment-directive>
>
> The is not specified precisely enough for interop. What does it mean to
> strop the fragment directive from the UR? When during loading does this
> occur?
>
> Section 3.3.1 is more specific <
> https://wicg.github.io/scroll-to-text-fragment/#parsing-the-fragment-directive>
> in that it monkeypatches the HTML create and initialize a Document object
> steps in a way that would affect what JavaScript sees.  However, it’s not
> clear what happens to other ways the UA exposes the URL, such as in the
> location field, or if the page is bookmarked or shared.
>
> Regards,
> Maciej
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Maciej Stachowiak]

> On Oct 30, 2020, at 1:40 PM, David Bokan  wrote:
> 
> Hi Ryosuke,
> 
> Would just like to clarify one point.
> 
> On Fri, Sep 25, 2020 at 12:42 PM David Bokan  > wrote:
> [Sorry, meant to reply-all]
> 
> On Fri, Sep 25, 2020 at 1:25 AM Ryosuke Niwa  > wrote:
> 
> On Thu, Sep 24, 2020 at 8:19 AM David Bokan  > 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.
> 
> The change we've proposed and implemented in Chrome doesn't touch anything in 
> the URL spec or handling; it's entirely an extension to fragment processing 
> in HTML documents only. If this were implemented in WebKit and Gecko I think 
> that'd address any compat issues? If you don't agree, could you clarify what 
> you see as the main compat risk?

It looks like the current spec does not affect URL per se, but does have this 
remark re the fragment directive: "It is reserved for UA instructions, such as 
text=, and is stripped from the URL during loading so that author scripts can’t 
directly interact with it.” 
>

The is not specified precisely enough for interop. What does it mean to strop 
the fragment directive from the UR? When during loading does this occur?

Section 3.3.1 is more specific 
>
 in that it monkeypatches the HTML create and initialize a Document object 
steps in a way that would affect what JavaScript sees.  However, it’s not clear 
what happens to other ways the UA exposes the URL, such as in the location 
field, or if the page is bookmarked or shared.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[David Bokan]

Hi Ryosuke,

Would just like to clarify one point.

On Fri, Sep 25, 2020 at 12:42 PM David Bokan  wrote:

> [Sorry, meant to reply-all]
>
> On Fri, Sep 25, 2020 at 1:25 AM Ryosuke Niwa  wrote:
>
>>
>> On Thu, Sep 24, 2020 at 8:19 AM David Bokan  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.
>>
>
The change we've proposed and implemented in Chrome doesn't touch anything
in the URL spec or handling; it's entirely an extension to fragment
processing in HTML documents only. If this were implemented in WebKit and
Gecko I think that'd address any compat issues? If you don't agree, could
you clarify what you see as the main compat risk?

Thanks,
David
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[David Bokan]

[Sorry, meant to reply-all]

On Fri, Sep 25, 2020 at 1:25 AM Ryosuke Niwa  wrote:

>
> On Thu, Sep 24, 2020 at 8:19 AM David Bokan  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.
>

Ok, thanks for the feedback. Is the compatibility issue the only/main
sticking point? That is, if we can mitigate or quantify the compatibility
risk as sufficiently low would this change your position?


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

The absolute number is small but what I was getting at is that installing
an extension requires discovery, some tech-savvy, and motivation so I think
even that number shows there is demand for this functionality (admittedly
non-representative, but still). OTOH, the feature is in use on Google
Search and Bing is reaching a very significant fraction of the user
population through those channels.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Ryosuke Niwa]

On Thu, Sep 24, 2020 at 8:19 AM David Bokan  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
> 
> 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[David Bokan]

On Wed, Sep 23, 2020 at 3:20 AM Ryosuke Niwa  wrote:

>
> On Fri, Sep 18, 2020 at 7:35 AM David Bokan  wrote:
>
>> Friendly ping to get an answer here.
>>
>> Do my answers above address those points or is there anything else I can
>> clarify?
>>
>> Thanks,
>> David
>>
>> On Mon, Aug 31, 2020 at 1:42 PM David Bokan  wrote:
>>
>>> [sending (again, sorry) from correct e-mail]
>>>
>>> I think Nick's replies mostly still apply, some updated answers to
>>> those questions.
>>>
>>> (1) We’re concerned about compatibility issues in a world where some
 browsers support this but not all. Aware browsers will strip `:~:`, but
 unaware browsers won’t. I saw that on the blink-dev ItS thread, it was
 mentioned that at least one site (webmd.com) totally breaks if any
 fragment ID is exposed to the page. This makes it difficult to create a
 link that uses this feature but which is safe in all browsers:
 - Since there is no feature detection mechanism, it’s hard for a
 webpage to know whether it should issue such a link. It would have to be
 based on UA string checks, which is regrettable.
 - A link meant for a supporting browser can end up in a non-supporting
 browser, at the very least by copy paste from the URL field, and perhaps
 through other features to share a link.

>>>
>>> We do have a feature detection mechanism for this.
>>>
>>> On the latter point, this is true but we think implementing fragment
>>> directive stripping (removing the part after and including `:~:`) is
>>> trivial even if the UA doesn't wish to implement the text-fragment feature.
>>> FWIW, we haven't seen or heard of another such example since.
>>>
>>
> We're continued to be concerned about this backwards compatibility issue.
>

Is there any kind of data we could gather that might allay concerns? Or
mitigations we could consider? Applications that generate these links
dynamically can feature detect for UA support. Pages should already be
considering unexpected hashes; the WebMD so far seems to have been an
outlier.


>
> (3) Text fragment trumping a regular fragment ID seems a bit strange. The
 more natural semantic would be that the text search starts at the fragment,
 so if there are multiple matches it’s possible to scroll to a more specific
 one. It’s not clear why the fragment is instead entirely ignored.

>>>
>>> This was discussed in more detail in issue#75; I agree with Nick's
>>> point that the disambiguation syntax is already specific enough that
>>> starting from a fragment isn't necessary. This also keeps us
>>> mostly-compatible with the TextQuoteSelector specified in
>>> WebAnnotations which I think may have benefits for interaction with
>>> annotation applications.
>>>
>>
> This will limit the utility of this feature. For something as board
> impacting as a URL format change, it seems rather short sighted.
>

Could you elaborate on why you think this limits its utility? From my point
of view keeping them independent is conceptually simpler and more robust
since we don't have to depend on two aspects of the page being unchanged.
Given that the syntax allows precise targeting of ambiguous text snippets I
don't really see a clear downside to this but maybe I'm missing your point?


>
> Also, Web Annotations Data Model allows other kinds of annotations:
> https://www.w3.org/TR/2017/REC-annotation-model-20170223/#selectors
>
> Is there any reason this particular matching algorithm was picked and only
> picked with no possibility of the future extensibility?
>

You mean why of all the selectors specified there only TextQuoteSelector
was chosen? We started with text as we think it's the most useful of the
set but this doesn't preclude eventually adding others. One natural
extension that we've heard demand for is scrolling to images.

Our original exploration
looked
at using arbitrary CSS selectors but this got rather complicated as being
able to target arbitrary parts of the DOM seemed potentially scary
from a security
perspective

(e.g.
a security flaw might expose CSRF tokens rather than just text).

As to the fragment syntax provided in WebAnnotations, there's two reasons
we chose a different syntax:

  * We needed some way to hide the fragment from the page so that it works
on pages with fragment routing
  * The WebAnnotations fragment syntax is quite verbose. We believe there's
benefit to keeping these links shorter and easier to hand-craft.

However, the model is effectively the same (exception being WebAnnotations
doesn't support start/end ranges); a WebAnnotation TextQuoteSelector can be
mechanically converted to a text-fragment.


>
> - R. Niwa
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[David Bokan]

>
> 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?)

 - 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

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.

Thanks,
David

On Thu, Sep 24, 2020 at 5:08 AM Maciej Stachowiak  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?
>
>  - Maciej
>
> On Sep 18, 2020, at 7:35 AM, David Bokan  wrote:
>
> Friendly ping to get an answer here.
>
> Do my answers above address those points or is there anything else I can
> clarify?
>
> Thanks,
> David
>
> On Mon, Aug 31, 2020 at 1:42 PM David Bokan  wrote:
>
>> [sending (again, sorry) from correct e-mail]
>>
>> I think Nick's replies
>>  
>> mostly
>> still apply, some updated answers to those questions.
>>
>> (1) We’re concerned about compatibility issues in a world where some
>>> browsers support this but not all. Aware browsers will strip `:~:`, but
>>> unaware browsers won’t. I saw that on the blink-dev ItS thread, it was
>>> mentioned that at least one site (webmd.com) totally breaks if any
>>> fragment ID is exposed to the page. This makes it difficult to create a
>>> link that uses this feature but which is safe in all browsers:
>>> - Since there is no feature detection mechanism, it’s hard for a webpage
>>> to know whether it should issue such a link. It would have to be based on
>>> UA string checks, which is regrettable.
>>> - A link meant for a supporting browser can end up in a non-supporting
>>> browser, at the very least by copy paste from the URL field, and perhaps
>>> through other features to share a link.
>>>
>>
>> We do have a feature detection
>> 
>>  mechanism
>> for this.
>>
>> On the latter point, this is true but we think implementing fragment
>> directive stripping (removing the part after and including `:~:`) is
>> trivial even if the UA doesn't wish to implement the text-fragment feature.
>> FWIW, we haven't seen or heard of another such example since.
>>
>>
>>> (2) The portions of this Community Group report that monkey patch other
>>> standards (HTML, URL and CSSOM View I think?) should be turned into PRs
>>> against those specifications. Monkeypatching other specs is not a good way
>>> to build specifications for the long term.
>>>
>>
>> We still need support from another vendor to start merging the monkey
>> patches into the real standards - if Apple's supportive I'd be happy to
>> start on that immediately.
>>
>>
>>> (3) Text fragment trumping a regular fragment ID seems a bit strange.
>>> The more natural semantic would be that the text search starts at the
>>> fragment, so if there are multiple matches it’s possible to scroll to a
>>> more specific one. It’s not clear why the fragment is instead entirely
>>> ignored.
>>>
>>
>> This was discussed in more detail in issue#75
>> ; I agree
>> with Nick's point that the disambiguation syntax is already specific enough
>> that starting from a fragment isn't necessary. This also keeps us
>> mostly-compatible with the TextQuoteSelector
>>  specified
>> in WebAnnotations which I think may have benefits for interaction with
>> annotation applications.
>>
>> On Mon, Aug 31, 2020 at 1:31 PM David Bokan  wrote:
>>
>>> I think Nick's replies
>>> 
>>> mostly still apply, some updated answers to those questions.
>>>
>>> (1) We’re concerned about compatibility issues in a world where some
 browsers support this but not all. Aware browsers will strip `:~:`, but
 unaware browsers won’t. I saw that on the blink-dev ItS thread, it was
 mentioned that at least one site (webmd.com) totally breaks if any
 fragment ID is exposed to the page. This makes it difficult to create a
 link that uses this feature but which is safe in all browsers:
 - Since there is no feature detection mechanism, it’s hard 

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

[Maciej Stachowiak]

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?

 - Maciej

> On Sep 18, 2020, at 7:35 AM, David Bokan  wrote:
> 
> Friendly ping to get an answer here.
> 
> Do my answers above address those points or is there anything else I can 
> clarify?
> 
> Thanks,
> David
> 
> On Mon, Aug 31, 2020 at 1:42 PM David Bokan  > wrote:
> [sending (again, sorry) from correct e-mail]
> 
> I think Nick's replies 
>  
> mostly still apply, some updated answers to those questions.
> 
> (1) We’re concerned about compatibility issues in a world where some browsers 
> support this but not all. Aware browsers will strip `:~:`, but unaware 
> browsers won’t. I saw that on the blink-dev ItS thread, it was mentioned that 
> at least one site (webmd.com ) totally breaks if any 
> fragment ID is exposed to the page. This makes it difficult to create a link 
> that uses this feature but which is safe in all browsers:
> - Since there is no feature detection mechanism, it’s hard for a webpage to 
> know whether it should issue such a link. It would have to be based on UA 
> string checks, which is regrettable.
> - A link meant for a supporting browser can end up in a non-supporting 
> browser, at the very least by copy paste from the URL field, and perhaps 
> through other features to share a link.
> 
> We do have a feature detection 
> 
>  mechanism for this.
> 
> On the latter point, this is true but we think implementing fragment 
> directive stripping (removing the part after and including `:~:`) is trivial 
> even if the UA doesn't wish to implement the text-fragment feature. FWIW, we 
> haven't seen or heard of another such example since.
>  
> (2) The portions of this Community Group report that monkey patch other 
> standards (HTML, URL and CSSOM View I think?) should be turned into PRs 
> against those specifications. Monkeypatching other specs is not a good way to 
> build specifications for the long term.
> 
> We still need support from another vendor to start merging the monkey patches 
> into the real standards - if Apple's supportive I'd be happy to start on that 
> immediately.
>  
> (3) Text fragment trumping a regular fragment ID seems a bit strange. The 
> more natural semantic would be that the text search starts at the fragment, 
> so if there are multiple matches it’s possible to scroll to a more specific 
> one. It’s not clear why the fragment is instead entirely ignored.
> 
> This was discussed in more detail in issue#75 
> ; I agree with 
> Nick's point that the disambiguation syntax is already specific enough that 
> starting from a fragment isn't necessary. This also keeps us 
> mostly-compatible with the TextQuoteSelector 
>  specified in 
> WebAnnotations which I think may have benefits for interaction with 
> annotation applications.
> 
> On Mon, Aug 31, 2020 at 1:31 PM David Bokan  > wrote:
> I think Nick's replies 
>  
> mostly still apply, some updated answers to those questions.
> 
> (1) We’re concerned about compatibility issues in a world where some browsers 
> support this but not all. Aware browsers will strip `:~:`, but unaware 
> browsers won’t. I saw that on the blink-dev ItS thread, it was mentioned that 
> at least one site (webmd.com ) totally breaks if any 
> fragment ID is exposed to the page. This makes it difficult to create a link 
> that uses this feature but which is safe in all browsers:
> - Since there is no feature detection mechanism, it’s hard for a webpage to 
> know whether it should issue such a link. It would have to be based on UA 
> string checks, which is regrettable.
> - A link meant for a supporting browser can end up in a non-supporting 
> browser, at the very least by copy paste from the URL field, and perhaps 
> through other features to share a link.
> 
> We do have a feature detection 
> 
>  mechanism for this.
> 
> On the latter point, this is true but we think implementing fragment 
> directive stripping (removing the part after and including `:~:`) is trivial 
> even if the UA doesn't wish to implement the text-fragment feature. FWIW, we 
> haven't seen or heard of another such example since.
>  
> (2) The portions of this Community Group report that monkey patch other 
> standards (HTML, URL and CSSOM View I think?) should be turned into PRs 
> against those specifications. Monkeypatching other specs is not a good way to 
> build specifications for the long 

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

[Ryosuke Niwa]

On Fri, Sep 18, 2020 at 7:35 AM David Bokan  wrote:

> Friendly ping to get an answer here.
>
> Do my answers above address those points or is there anything else I can
> clarify?
>
> Thanks,
> David
>
> On Mon, Aug 31, 2020 at 1:42 PM David Bokan  wrote:
>
>> [sending (again, sorry) from correct e-mail]
>>
>> I think Nick's replies
>>  
>> mostly
>> still apply, some updated answers to those questions.
>>
>> (1) We’re concerned about compatibility issues in a world where some
>>> browsers support this but not all. Aware browsers will strip `:~:`, but
>>> unaware browsers won’t. I saw that on the blink-dev ItS thread, it was
>>> mentioned that at least one site (webmd.com) totally breaks if any
>>> fragment ID is exposed to the page. This makes it difficult to create a
>>> link that uses this feature but which is safe in all browsers:
>>> - Since there is no feature detection mechanism, it’s hard for a webpage
>>> to know whether it should issue such a link. It would have to be based on
>>> UA string checks, which is regrettable.
>>> - A link meant for a supporting browser can end up in a non-supporting
>>> browser, at the very least by copy paste from the URL field, and perhaps
>>> through other features to share a link.
>>>
>>
>> We do have a feature detection
>> 
>>  mechanism
>> for this.
>>
>> On the latter point, this is true but we think implementing fragment
>> directive stripping (removing the part after and including `:~:`) is
>> trivial even if the UA doesn't wish to implement the text-fragment feature.
>> FWIW, we haven't seen or heard of another such example since.
>>
>
We're continued to be concerned about this backwards compatibility issue.

(3) Text fragment trumping a regular fragment ID seems a bit strange. The
>>> more natural semantic would be that the text search starts at the fragment,
>>> so if there are multiple matches it’s possible to scroll to a more specific
>>> one. It’s not clear why the fragment is instead entirely ignored.
>>>
>>
>> This was discussed in more detail in issue#75
>> ; I agree
>> with Nick's point that the disambiguation syntax is already specific enough
>> that starting from a fragment isn't necessary. This also keeps us
>> mostly-compatible with the TextQuoteSelector
>>  specified
>> in WebAnnotations which I think may have benefits for interaction with
>> annotation applications.
>>
>
This will limit the utility of this feature. For something as board
impacting as a URL format change, it seems rather short sighted.

Also, Web Annotations Data Model allows other kinds of annotations:
https://www.w3.org/TR/2017/REC-annotation-model-20170223/#selectors

Is there any reason this particular matching algorithm was picked and only
picked with no possibility of the future extensibility?

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[David Bokan]

Friendly ping to get an answer here.

Do my answers above address those points or is there anything else I can
clarify?

Thanks,
David

On Mon, Aug 31, 2020 at 1:42 PM David Bokan  wrote:

> [sending (again, sorry) from correct e-mail]
>
> I think Nick's replies
>  
> mostly
> still apply, some updated answers to those questions.
>
> (1) We’re concerned about compatibility issues in a world where some
>> browsers support this but not all. Aware browsers will strip `:~:`, but
>> unaware browsers won’t. I saw that on the blink-dev ItS thread, it was
>> mentioned that at least one site (webmd.com) totally breaks if any
>> fragment ID is exposed to the page. This makes it difficult to create a
>> link that uses this feature but which is safe in all browsers:
>> - Since there is no feature detection mechanism, it’s hard for a webpage
>> to know whether it should issue such a link. It would have to be based on
>> UA string checks, which is regrettable.
>> - A link meant for a supporting browser can end up in a non-supporting
>> browser, at the very least by copy paste from the URL field, and perhaps
>> through other features to share a link.
>>
>
> We do have a feature detection
> 
>  mechanism
> for this.
>
> On the latter point, this is true but we think implementing fragment
> directive stripping (removing the part after and including `:~:`) is
> trivial even if the UA doesn't wish to implement the text-fragment feature.
> FWIW, we haven't seen or heard of another such example since.
>
>
>> (2) The portions of this Community Group report that monkey patch other
>> standards (HTML, URL and CSSOM View I think?) should be turned into PRs
>> against those specifications. Monkeypatching other specs is not a good way
>> to build specifications for the long term.
>>
>
> We still need support from another vendor to start merging the monkey
> patches into the real standards - if Apple's supportive I'd be happy to
> start on that immediately.
>
>
>> (3) Text fragment trumping a regular fragment ID seems a bit strange. The
>> more natural semantic would be that the text search starts at the fragment,
>> so if there are multiple matches it’s possible to scroll to a more specific
>> one. It’s not clear why the fragment is instead entirely ignored.
>>
>
> This was discussed in more detail in issue#75
> ; I agree with
> Nick's point that the disambiguation syntax is already specific enough that
> starting from a fragment isn't necessary. This also keeps us
> mostly-compatible with the TextQuoteSelector
>  specified
> in WebAnnotations which I think may have benefits for interaction with
> annotation applications.
>
> On Mon, Aug 31, 2020 at 1:31 PM David Bokan  wrote:
>
>> I think Nick's replies
>> 
>> mostly still apply, some updated answers to those questions.
>>
>> (1) We’re concerned about compatibility issues in a world where some
>>> browsers support this but not all. Aware browsers will strip `:~:`, but
>>> unaware browsers won’t. I saw that on the blink-dev ItS thread, it was
>>> mentioned that at least one site (webmd.com) totally breaks if any
>>> fragment ID is exposed to the page. This makes it difficult to create a
>>> link that uses this feature but which is safe in all browsers:
>>> - Since there is no feature detection mechanism, it’s hard for a webpage
>>> to know whether it should issue such a link. It would have to be based on
>>> UA string checks, which is regrettable.
>>> - A link meant for a supporting browser can end up in a non-supporting
>>> browser, at the very least by copy paste from the URL field, and perhaps
>>> through other features to share a link.
>>>
>>
>> We do have a feature detection
>> 
>> mechanism for this.
>>
>> On the latter point, this is true but we think implementing fragment
>> directive stripping (removing the part after and including `:~:`) is
>> trivial even if the UA doesn't wish to implement the text-fragment feature.
>> FWIW, we haven't seen or heard of another such example since.
>>
>>
>>> (2) The portions of this Community Group report that monkey patch other
>>> standards (HTML, URL and CSSOM View I think?) should be turned into PRs
>>> against those specifications. Monkeypatching other specs is not a good way
>>> to build specifications for the long term.
>>>
>>
>> We still need support from another vendor to start merging the monkey
>> patches into the real standards - if Apple's supportive I'd be happy to
>> start on that immediately.
>>
>>
>>> (3) Text fragment trumping a regular fragment ID seems a bit strange.
>>> The more natural 

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

[David Bokan]

[sending (again, sorry) from correct e-mail]

I think Nick's replies

mostly
still apply, some updated answers to those questions.

(1) We’re concerned about compatibility issues in a world where some
> browsers support this but not all. Aware browsers will strip `:~:`, but
> unaware browsers won’t. I saw that on the blink-dev ItS thread, it was
> mentioned that at least one site (webmd.com) totally breaks if any
> fragment ID is exposed to the page. This makes it difficult to create a
> link that uses this feature but which is safe in all browsers:
> - Since there is no feature detection mechanism, it’s hard for a webpage
> to know whether it should issue such a link. It would have to be based on
> UA string checks, which is regrettable.
> - A link meant for a supporting browser can end up in a non-supporting
> browser, at the very least by copy paste from the URL field, and perhaps
> through other features to share a link.
>

We do have a feature detection

mechanism
for this.

On the latter point, this is true but we think implementing fragment
directive stripping (removing the part after and including `:~:`) is
trivial even if the UA doesn't wish to implement the text-fragment feature.
FWIW, we haven't seen or heard of another such example since.


> (2) The portions of this Community Group report that monkey patch other
> standards (HTML, URL and CSSOM View I think?) should be turned into PRs
> against those specifications. Monkeypatching other specs is not a good way
> to build specifications for the long term.
>

We still need support from another vendor to start merging the monkey
patches into the real standards - if Apple's supportive I'd be happy to
start on that immediately.


> (3) Text fragment trumping a regular fragment ID seems a bit strange. The
> more natural semantic would be that the text search starts at the fragment,
> so if there are multiple matches it’s possible to scroll to a more specific
> one. It’s not clear why the fragment is instead entirely ignored.
>

This was discussed in more detail in issue#75
; I agree with
Nick's point that the disambiguation syntax is already specific enough that
starting from a fragment isn't necessary. This also keeps us
mostly-compatible with the TextQuoteSelector
 specified in
WebAnnotations which I think may have benefits for interaction with
annotation applications.

On Mon, Aug 31, 2020 at 1:31 PM David Bokan  wrote:

> I think Nick's replies
> 
> mostly still apply, some updated answers to those questions.
>
> (1) We’re concerned about compatibility issues in a world where some
>> browsers support this but not all. Aware browsers will strip `:~:`, but
>> unaware browsers won’t. I saw that on the blink-dev ItS thread, it was
>> mentioned that at least one site (webmd.com) totally breaks if any
>> fragment ID is exposed to the page. This makes it difficult to create a
>> link that uses this feature but which is safe in all browsers:
>> - Since there is no feature detection mechanism, it’s hard for a webpage
>> to know whether it should issue such a link. It would have to be based on
>> UA string checks, which is regrettable.
>> - A link meant for a supporting browser can end up in a non-supporting
>> browser, at the very least by copy paste from the URL field, and perhaps
>> through other features to share a link.
>>
>
> We do have a feature detection
> 
> mechanism for this.
>
> On the latter point, this is true but we think implementing fragment
> directive stripping (removing the part after and including `:~:`) is
> trivial even if the UA doesn't wish to implement the text-fragment feature.
> FWIW, we haven't seen or heard of another such example since.
>
>
>> (2) The portions of this Community Group report that monkey patch other
>> standards (HTML, URL and CSSOM View I think?) should be turned into PRs
>> against those specifications. Monkeypatching other specs is not a good way
>> to build specifications for the long term.
>>
>
> We still need support from another vendor to start merging the monkey
> patches into the real standards - if Apple's supportive I'd be happy to
> start on that immediately.
>
>
>> (3) Text fragment trumping a regular fragment ID seems a bit strange. The
>> more natural semantic would be that the text search starts at the fragment,
>> so if there are multiple matches it’s possible to scroll to a more specific
>> one. It’s not clear why the fragment is instead entirely ignored.
>>
>
> This was discussed in more detail in issue#75
> 

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

[Darin Adler]

> On Aug 31, 2020, at 9:33 AM, David Bokan  wrote:
> 
> We've made lots of improvements to the spec, notably around issues raised in 
> Mozilla's standards-position 
> .

Do you think those improvements address Maciej’s concerns from last December? 
Since you didn’t say that explicitly I was wondering what your take on that was.

— Darin___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[David Bokan]

[Sending from correct account this time and on root thread]

Hello WebKit-dev,

Bumping this thread to give/get an update.

Text-fragments shipped in Chrome M80. We've made lots of improvements to
the spec, notably around issues raised in Mozilla's standards-position
.

>From Google Search's use (I've seen this being used on Bing as well), we've
seen improvements to user experience metrics and surveys. ajuma@ mentioned
his team might be interested in contributing this to WebKit. I'm wondering
if this is something that WebKit would accept or if there's any updated
concerns?

Thanks,
David

On Wed, Dec 11, 2019 at 2:39 PM Maciej Stachowiak  wrote:

>
> Hi David,
>
> Apple folks have discussed this internally. In general, we think this is
> useful functionality to expose. Some points of feedback (let me know if any
> of these should be filed as an issue against the spec):
>
> (1) We’re concerned about compatibility issues in a world where some
> browsers support this but not all. Aware browsers will strip `:~:`, but
> unaware browsers won’t. I saw that on the blink-dev ItS thread, it was
> mentioned that at least one site (webmd.com) totally breaks if any
> fragment ID is exposed to the page. This makes it difficult to create a
> link that uses this feature but which is safe in all browsers:
> - Since there is no feature detection mechanism, it’s hard for a webpage
> to know whether it should issue such a link. It would have to be based on
> UA string checks, which is regrettable.
> - A link meant for a supporting browser can end up in a non-supporting
> browser, at the very least by copy paste from the URL field, and perhaps
> through other features to share a link.
>
> It seems like the spec doesn’t provide a solution for this. We think some
> form of feature detection would slightly improve the situation. Other than
> that, We're not sure how to avoid potential breakage. Maybe evangelize
> WebMD if that’s the only major site that breaks on unexpected fragments?
>
> (2) The portions of this Community Group report that monkey patch other
> standards (HTML, URL and CSSOM View I think?) should be turned into PRs
> against those specifications. Monkeypatching other specs is not a good way
> to build specifications for the long term.
>
> (3) Text fragment trumping a regular fragment ID seems a bit strange. The
> more natural semantic would be that the text search starts at the fragment,
> so if there are multiple matches it’s possible to scroll to a more specific
> one. It’s not clear why the fragment is instead entirely ignored.
>
> We would frame these more as points of concern than opposition to the
> whole idea, but it seems wise to address them before shipping.
>
> Regards,
> Maciej
>
>
> On Dec 2, 2019, at 12:22 PM, David Bokan  wrote:
>
> Hello webkit-dev,
>
> I'd like to solicit feedback as well as an official position from Webkit
> on our proposal for the text fragment directive:
> https://github.com/WICG/ScrollToTextFragment.
>
> In summary: this is a feature that allows authors and users to craft URLs
> to pages and specify a snippet of text on the page as a subresource
> (visually highlighting it and scrolling it into view). Analogous to
> element-id based fragment anchors but for text.
>
> You can try this out today in Chrome Beta by enabling 
> chrome://flags/#enable-text-fragment-anchor.
> Here's an example link:
>
>
> https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#:~:text=An%20optional%20fragment,element%20into%20view
>
> Relevant Links:
>
> 
> Explainer
> 
> Spec 
> TAG Review 
> (Currently Suspended) Blink Intent Thread
> 
> Issue on Mozilla standards-positions
> 
>
> We've been using the GitHub repo for issue tracking but happy to take
> feedback (official or otherwise) in any form.
>
> Thank you!
> David
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Maciej Stachowiak]

> On Dec 11, 2019, at 12:48 PM, Nick Burris  wrote:
> 
> Hi Maciej,
> Thanks for the reply! David's away this week, my responses are inline:
> (1) We’re concerned about compatibility issues in a world where some browsers 
> support this but not all. Aware browsers will strip `:~:`, but unaware 
> browsers won’t. I saw that on the blink-dev ItS thread, it was mentioned that 
> at least one site (webmd.com ) totally breaks if any 
> fragment ID is exposed to the page. This makes it difficult to create a link 
> that uses this feature but which is safe in all browsers:
>   - Since there is no feature detection mechanism, it’s hard for a 
> webpage to know whether it should issue such a link. It would have to be 
> based on UA string checks, which is regrettable.
>   - A link meant for a supporting browser can end up in a non-supporting 
> browser, at the very least by copy paste from the URL field, and perhaps 
> through other features to share a link. 
>  
> It seems like the spec doesn’t provide a solution for this. We think some 
> form of feature detection would slightly improve the situation. Other than 
> that, We're not sure how to avoid potential breakage. Maybe evangelize WebMD 
> if that’s the only major site that breaks on unexpected fragments?
> 
> There is a feature detection mechanism that we have 
> [specified](https://wicg.github.io/ScrollToTextFragment/#feature-detectability
>  ) and 
> implemented, see [#19](https://github.com/WICG/ScrollToTextFragment/issues/19 
> ). Feature detection 
> can be done by checking `typeof(window.location.fragmentDirective) == 
> 'object'`. Indeed, there is still a compat concern as described in the intent 
> to ship, since these links will exist in the wild. Since WebMD is the only 
> broken site we've come across, I agree it would be good to make sure they're 
> aware of this. I'll reach out.

Great. (Why only add it to the Location interface and not also URL?
> 
> (2) The portions of this Community Group report that monkey patch other 
> standards (HTML, URL and CSSOM View I think?) should be turned into PRs 
> against those specifications. Monkeypatching other specs is not a good way to 
> build specifications for the long term.
> 
> Agreed - we're wrapping up on some smaller remaining issues and our next step 
> is to turn this into PRs.

Glad to hear it.
> 
> (3) Text fragment trumping a regular fragment ID seems a bit strange. The 
> more natural semantic would be that the text search starts at the fragment, 
> so if there are multiple matches it’s possible to scroll to a more specific 
> one. It’s not clear why the fragment is instead entirely ignored.
> 
> We wanted to keep this simple to ensure links are robust (generally they will 
> be generated algorithmically, where one can ensure the text directive is 
> unique in the page). If we add the dimension of relying on starting at a 
> fragment, that fragment or the text could move in the page and break the 
> link, even if the desired text is still present on the page. Feel free to 
> open a Github issue if you think this is worth discussing more!
https://github.com/WICG/ScrollToTextFragment/issues/75


> 
> Thanks,
> Nick
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Nick Burris]

Hi Maciej,

Thanks for the reply! David's away this week, my responses are inline:

(1) We’re concerned about compatibility issues in a world where some
browsers support this but not all. Aware browsers will strip `:~:`,
but unaware browsers won’t. I saw that on the blink-dev ItS thread, it
was mentioned that at least one site (webmd.com) totally breaks if any
fragment ID is exposed to the page. This makes it difficult to create
a link that uses this feature but which is safe in all browsers:
>   - Since there is no feature detection mechanism, it’s hard for a 
> webpage to know whether it should issue such a link. It would have to be 
> based on UA string checks, which is regrettable.
>   - A link meant for a supporting browser can end up in a non-supporting 
> browser, at the very least by copy paste from the URL field, and perhaps 
> through other features to share a link.



It seems like the spec doesn’t provide a solution for this. We think
some form of feature detection would slightly improve the situation.
Other than that, We're not sure how to avoid potential breakage. Maybe
evangelize WebMD if that’s the only major site that breaks on
unexpected fragments?


There is a feature detection mechanism that we have
[specified](https://wicg.github.io/ScrollToTextFragment/#feature-detectability)
and implemented, see
[#19](https://github.com/WICG/ScrollToTextFragment/issues/19). Feature
detection can be done by checking
`typeof(window.location.fragmentDirective) == 'object'`. Indeed, there
is still a compat concern as described in the intent to ship, since
these links will exist in the wild. Since WebMD is the only broken
site we've come across, I agree it would be good to make sure they're
aware of this. I'll reach out.

(2) The portions of this Community Group report that monkey patch
other standards (HTML, URL and CSSOM View I think?) should be turned
into PRs against those specifications. Monkeypatching other specs is
not a good way to build specifications for the long term.


Agreed - we're wrapping up on some smaller remaining issues and our
next step is to turn this into PRs.

> (3) Text fragment trumping a regular fragment ID seems a bit strange. The 
> more natural semantic would be that the text search starts at the fragment, 
> so if there are multiple matches it’s possible to scroll to a more specific 
> one. It’s not clear why the fragment is instead entirely ignored.


We wanted to keep this simple to ensure links are robust (generally
they will be generated algorithmically, where one can ensure the text
directive is unique in the page). If we add the dimension of relying
on starting at a fragment, that fragment or the text could move in the
page and break the link, even if the desired text is still present on
the page. Feel free to open a Github issue if you think this is worth
discussing more!

Thanks,
Nick
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Maciej Stachowiak]

Hi David,

Apple folks have discussed this internally. In general, we think this is useful 
functionality to expose. Some points of feedback (let me know if any of these 
should be filed as an issue against the spec):

(1) We’re concerned about compatibility issues in a world where some browsers 
support this but not all. Aware browsers will strip `:~:`, but unaware browsers 
won’t. I saw that on the blink-dev ItS thread, it was mentioned that at least 
one site (webmd.com) totally breaks if any fragment ID is exposed to the page. 
This makes it difficult to create a link that uses this feature but which is 
safe in all browsers:
- Since there is no feature detection mechanism, it’s hard for a 
webpage to know whether it should issue such a link. It would have to be based 
on UA string checks, which is regrettable.
- A link meant for a supporting browser can end up in a non-supporting 
browser, at the very least by copy paste from the URL field, and perhaps 
through other features to share a link.

It seems like the spec doesn’t provide a solution for this. We think some form 
of feature detection would slightly improve the situation. Other than that, 
We're not sure how to avoid potential breakage. Maybe evangelize WebMD if 
that’s the only major site that breaks on unexpected fragments?

(2) The portions of this Community Group report that monkey patch other 
standards (HTML, URL and CSSOM View I think?) should be turned into PRs against 
those specifications. Monkeypatching other specs is not a good way to build 
specifications for the long term.

(3) Text fragment trumping a regular fragment ID seems a bit strange. The more 
natural semantic would be that the text search starts at the fragment, so if 
there are multiple matches it’s possible to scroll to a more specific one. It’s 
not clear why the fragment is instead entirely ignored.

We would frame these more as points of concern than opposition to the whole 
idea, but it seems wise to address them before shipping.

Regards,
Maciej


> On Dec 2, 2019, at 12:22 PM, David Bokan  wrote:
> 
> Hello webkit-dev,
> 
> I'd like to solicit feedback as well as an official position from Webkit on 
> our proposal for the text fragment directive: 
> https://github.com/WICG/ScrollToTextFragment 
> .
> 
> In summary: this is a feature that allows authors and users to craft URLs to 
> pages and specify a snippet of text on the page as a subresource (visually 
> highlighting it and scrolling it into view). Analogous to element-id based 
> fragment anchors but for text.
> 
> You can try this out today in Chrome Beta by enabling 
> chrome://flags/#enable-text-fragment-anchor. Here's an example link: <>
> 
> https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#:~:text=An%20optional%20fragment,element%20into%20view
>  
> 
> 
> Relevant Links:
> 
>  
> Explainer 
> Spec 
> TAG Review 
> (Currently Suspended) Blink Intent Thread 
> 
> Issue on Mozilla standards-positions 
> 
> 
> We've been using the GitHub repo for issue tracking but happy to take 
> feedback (official or otherwise) in any form.
> 
> Thank you!
> David
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Frédéric Wang]

On 02/12/2019 21:22, David Bokan wrote:
> Hello webkit-dev,
>
> I'd like to solicit feedback as well as an official position from
> Webkit on our proposal for the text fragment
> directive: https://github.com/WICG/ScrollToTextFragment.
>
> In summary: this is a feature that allows authors and users to craft
> URLs to pages and specify a snippet of text on the page as a
> subresource (visually highlighting it and scrolling it into view).
> Analogous to element-id based fragment anchors but for text.
>
> You can try this out today in Chrome Beta by
> enabling chrome://flags/#enable-text-fragment-anchor. Here's an
> example link:
>
> https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#:~:text=An%20optional%20fragment,element%20into%20view
>
> Relevant Links:
>
> 
> Explainer
> 
> Spec 
> TAG Review 
> (Currently Suspended) Blink Intent Thread
> 
> Issue on Mozilla standards-positions
> 
>
> We've been using the GitHub repo for issue tracking but happy to take
> feedback (official or otherwise) in any form.
>
> Thank you!
> David
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
Hi,

I think some of the webkit-dev members have already replied on the Blink
thread. Just to repeat here, I think the concerns Igalia had regarding
the lack of details to implement the algorithm have been addressed in
the latest versions of the spec. We haven't checked again if the WPT
coverage is good enough now though.

-- 
Frédéric Wang

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev