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

[David Bokan]

Post-holiday ping.

On Mon, Nov 23, 2020 at 8:44 PM David Bokan <bokan at chromium.org> wrote:

> Friendly ping - have the above changes addressed the concerns?
>
> On Mon, Nov 16, 2020 at 6:57 PM David Bokan <bokan at chromium.org> 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 <bokan at chromium.org> 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 <mjs at apple.com> wrote:
>>>
>>>>
>>>>
>>>> On Oct 30, 2020, at 1:40 PM, David Bokan <bokan at chromium.org> wrote:
>>>>
>>>> Hi Ryosuke,
>>>>
>>>> Would just like to clarify one point.
>>>>
>>>> On Fri, Sep 25, 2020 at 12:42 PM David Bokan <bokan at chromium.org>
>>>> wrote:
>>>>
>>>>> [Sorry, meant to reply-all]
>>>>>
>>>>> On Fri, Sep 25, 2020 at 1:25 AM Ryosuke Niwa <rniwa at webkit.org> wrote:
>>>>>
>>>>>>
>>>>>> On Thu, Sep 24, 2020 at 8:19 AM David Bokan <bokan at chromium.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Can you clarify what question you’re looking to have answered? Are
>>>>>>>> you asking for a new standards position in light of the replies below?
>>>>>>>>
>>>>>>>
>>>>>>>  There are two specific points:
>>>>>>>
>>>>>>>  - As I understand it, HTML requires multi-vendor interest to merge
>>>>>>> changes to specs. Is Apple's position sufficient to start that process? I'd
>>>>>>> be happy to start turning the spec into PRs but I interpreted the earlier
>>>>>>> position in this thread more as "not-opposed" rather than support (is that
>>>>>>> a fair reading?)
>>>>>>>
>>>>>>
>>>>>> Given we're concerned about compatibility and this affects how URL,
>>>>>> which is a pretty fundamental part of the Web, is interpreted, it's fair to
>>>>>> say we're not ready to endorse such a motion.
>>>>>>
>>>>>
>>>> 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
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20210107/0afbe97d/attachment.htm>