[webkit-dev] RFC: Page Collections

[David Bokan via webkit-dev]

Hi WebKittens,

A team of us in Chromium are thinking about a new linking primitive that
would allow links to point to multiple URLs. To give an idea: sharing a
link with a friend that, when clicked, opens a tab group with X pages
(where X > 1).

It's still early stages (so not looking for a standards-position), there's
some ideas for how this might work but nothing's firm yet. I've put up an
explainer  with our current
thinking.

Given that this affects linking, interop between browsers is top of mind so
I'm reaching out early; is this an area someone in WebKit cares about? Does
WebKit think these use cases are worth addressing? WDYT about some of the
specifics?

If someone in WebKit is interested we'd love to work together but would
also appreciate any kind of informal feedback (here or as issues on the
explainer are both fine).

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

[webkit-dev] In-browser annotations

[David Bokan via webkit-dev]

Hi webkit-dev!

A few of us over in Chromium are thinking of how we can enable annotation,
directly in the browser, without need for extensions. In a sentence: to
enable shared commentary over web content. We're very early in the stages
of thinking about this, there's no prototype or code written yet but we did
gather some thoughts and ideas in an explainer
.

This isn't a new idea - it's something that's been kicking around
since the early
days of the web
. Is there
anyone at Apple or in the WebKit community that's interested in this space
and would like to help in this effort? Or even just provide some feedback
along the way? Long term this is something that would need to work across
browsers to be successful so we'd really appreciate early involvement from
the WebKit side of the room.

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

[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
>> <https://wicg.github.io/scroll-to-text-fragment/#processing-the-fragment-directive>
>>  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
>> <https://wicg.github.io/scroll-to-text-fragment/#urls-in-ua-features> 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
>> <https://github.com/WICG/scroll-to-text-fragment/issues/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
> <https://wicg.github.io/scroll-to-text-fragment/#processing-the-fragment-directive>
>  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
> <https://wicg.github.io/scroll-to-text-fragment/#urls-in-ua-features> 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
> <https://github.com/WICG/scroll-to-text-fragment/issues/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]

Hey Maciej/Ryosuke,

I've updated the spec to be more precise around stripping the fragment
directive. Specifically, section 3.3.1
<https://wicg.github.io/scroll-to-text-fragment/#processing-the-fragment-directive>
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
<https://wicg.github.io/scroll-to-text-fragment/#urls-in-ua-features> 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
<https://github.com/WICG/scroll-to-text-fragment/issues/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

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

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

[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
<https://github.com/WICG/scroll-to-text-fragment/#css-selector-fragments>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
<https://github.com/WICG/scroll-to-text-fragment/#security-considerations>
(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
<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.

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
>> <https://lists.webkit.org/pipermail/webkit-dev/2019-December/030998.html> 
>> 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
>> <https://github.com/WICG/scroll-to-text-fragment/#feature-detection-and-future-apis>
>>  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
>> <https://github.com/WICG/scroll-to-text-fragment/issues/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
>> <https://www.w3.org/TR/annotation-model/#text-quote-selector> 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
>>> <https://lists.webkit.org/pipermail/webkit-dev/2019-December/030998.html>
>>&g

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
> <https://lists.webkit.org/pipermail/webkit-dev/2019-December/030998.html> 
> 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
> <https://github.com/WICG/scroll-to-text-fragment/#feature-detection-and-future-apis>
>  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
> <https://github.com/WICG/scroll-to-text-fragment/issues/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
> <https://www.w3.org/TR/annotation-model/#text-quote-selector> 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
>> <https://lists.webkit.org/pipermail/webkit-dev/2019-December/030998.html>
>> 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
>> <https://github.com/WICG/scroll-to-text-fragment/#feature-detection-and-future-apis>
>> 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 patc

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
<https://lists.webkit.org/pipermail/webkit-dev/2019-December/030998.html>
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
<https://github.com/WICG/scroll-to-text-fragment/#feature-detection-and-future-apis>
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
<https://github.com/WICG/scroll-to-text-fragment/issues/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
<https://www.w3.org/TR/annotation-model/#text-quote-selector> 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
> <https://lists.webkit.org/pipermail/webkit-dev/2019-December/030998.html>
> 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
> <https://github.com/WICG/scroll-to-text-fragment/#feature-detection-and-future-apis>
> 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 

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
<https://github.com/mozilla/standards-positions/issues/194>.

>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:
>
> <https://github.com/WICG/ScrollToTextFragment/blob/master/README.md>
> Explainer
> <https://github.com/WICG/ScrollToTextFragment/blob/master/README.md>
> Spec <https://wicg.github.io/ScrollToTextFragment/>
> TAG Review <https://github.com/w3ctag/design-reviews/issues/392>
> (Currently Suspended) Blink Intent Thread
> <https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/zlLSxQ9BA8Y/NLbg84m0EAAJ>
> Issue on Mozilla standards-positions
> <https://github.com/mozilla/standards-positions/issues/194>
>
> 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

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

[David Bokan]

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

Re: [webkit-dev] Buildbot upgrade on build.webkit.org

[David Bokan]

On Thu, Dec 7, 2017, 3:47 PM Aakash Jain  wrote:

> Hello WebKittens,
>
> We have been using an ancient (5 years old) version of Buildbot on
> build.webkit.org. I am starting to work on upgrading to latest Buildbot
> (0.9.x). New buildbot would look like this: https://nine.buildbot.net.
>
> For people using build.webkit.org, I would like to know what pages you
> use most of the time (e.g.: builder page, console view etc.) and what are
> your primary use-cases (purpose to visit build.webkit.org). Also if you
> have any feedback/concern about new Buildbot please let me know.
>
> Thanks
> Aakash
> ___
> 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] Enabling visual viewports by default

[David Bokan]

Hi Simon,

Blink had a problem with mixing viewports between APIs. I've summarized the
situation in this doc:
https://docs.google.com/document/d/1E6tBwLF1UlqSCMyIIemaRheJrtLncsNetV7y6we-muE/edit?usp=sharing

Basically, some APIs (window.scroll_) currently refer to visual while
others (getBoundingClientRect) to the layout viewport. This mixing has led
to a long tail of bugs. Conceptually, we'd prefer to make everything
relative to the layout viewport. We tried this by shipping "inert visual
viewport" in M48 but got push back from web devs and reverted it.

I don't know what your new implementation does w.r.t. these APIs but since
you're making a big change this would be a good time to settle on the same
behavior. What do you think of the "inert" model described in the doc (and
available in Chrome via chrome://flags/#inert-visual-viewport)?
Essentially, it locks the UA, as far as the page can tell, into the fully
zoomed-out state.

Edge engineers have expressed cautious support but were worried by the
compat impact. FWIW, we shipped for a whole milestone and didn't get any
reports of broken pages from users. We did get significant push back from
developers in http://crbug.com/571297 but it was mostly along the lines of
interop. If we could get all the engines on the same page I think it'd be a
significant improvement over the status quo.

In any case, we'll need to change one way or the other. Mixing the two
viewports in APIs is confusing devs and a source of bugs on existing pages.
The alternative is to make the "client" coordinates relative to the visual
viewport. Whatever we do, I'd like to improve interop by settling on the
same behavior between all the engines.

Thanks,
David

> Hi floks!
>
> I plan to enable visual viewports by default in WK1 and WK2 in the near 
> future.
>
> "visual viewports" is new behavior for position:fixed and sticky elements 
> under page zoom; they lay out relative to a "layout viewport" (which is the 
> size of the initial containing block), while the user pans around in the 
> "visual viewport". When the visual viewport hits the edge of the layout 
> viewport, it pushes this around.
>
> This is a better user experience, and also matches Chrome and Firefox 
> behavior more closely.
>
> Is there any platform which would object to having this new behavior by 
> default? I hope to remove the non-visual-viewport code at some point.
>
> The master bug for this is https://bugs.webkit.org/show_bug.cgi?id=164260 
> .
>
> Simon
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev