[webkit-dev] Feedback on Blink's text fragment directive proposal
bokan at chromium.org
Mon Nov 16 15:57:23 PST 2020
I've updated the spec to be more precise around stripping the fragment
directive. Specifically, section 3.3.1
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
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
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.” <
>> 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
>> Section 3.3.1 is more specific <
>> in that it monkeypatches the HTML create and initialize a Document object
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev