[prev in list] [next in list] [prev in thread] [next in thread]
List: webkit-dev
Subject: Re: [webkit-dev] Feedback on Blink's text fragment directive proposal
From: Maciej Stachowiak <mjs () apple ! com>
Date: 2020-11-02 1:24:11
Message-ID: 6BEABD75-67C7-497A-8601-2AD320934E60 () apple ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On Oct 30, 2020, at 1:40 PM, David Bokan <bokan@chromium.org> wrote:
>
> Hi Ryosuke,
>
> Would just like to clarify one point.
>
> On Fri, Sep 25, 2020 at 12:42 PM David Bokan <bokan@chromium.org \
> <mailto:bokan@chromium.org>> wrote: [Sorry, meant to reply-all]
>
> On Fri, Sep 25, 2020 at 1:25 AM Ryosuke Niwa <rniwa@webkit.org \
> <mailto:rniwa@webkit.org>> wrote:
> On Thu, Sep 24, 2020 at 8:19 AM David Bokan <bokan@chromium.org \
> <mailto:bokan@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 \
<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 \
<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
[Attachment #5 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote \
type="cite" class=""><div class="">On Oct 30, 2020, at 1:40 PM, David Bokan <<a \
href="mailto:bokan@chromium.org" class="">bokan@chromium.org</a>> wrote:</div><br \
class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div \
class="">Hi Ryosuke,</div><div class=""><br class=""></div><div class="">Would just \
like to clarify one point.</div><br class=""><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Fri, Sep 25, 2020 at 12:42 PM David Bokan <<a \
href="mailto:bokan@chromium.org" class="">bokan@chromium.org</a>> wrote:<br \
class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" \
class=""><div class="">[Sorry, meant to reply-all]</div><br class=""><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 25, 2020 at 1:25 AM \
Ryosuke Niwa <<a href="mailto:rniwa@webkit.org" target="_blank" \
class="">rniwa@webkit.org</a>> wrote:<br class=""></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div dir="ltr" \
class=""><br class=""></div><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Thu, Sep 24, 2020 at 8:19 AM David Bokan <<a \
href="mailto:bokan@chromium.org" target="_blank" class="">bokan@chromium.org</a>> \
wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" \
class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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?<br class=""></blockquote><div class=""><br \
class=""></div><div class=""> There are two specific points:</div><div \
class=""><br class=""></div><div class=""> - 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?)</div></div></blockquote><div class=""><br class=""></div><div \
class="">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.</div></div></div></blockquote></div></div></blockquote><div class=""><br \
class=""></div><div class="">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?</div></div></div></div></blockquote><br \
class=""></div><div>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." <<a \
href="https://wicg.github.io/scroll-to-text-fragment/#the-fragment-directive" \
class="">https://wicg.github.io/scroll-to-text-fragment/#the-fragment-directive</a>></div><div><br \
class=""></div><div>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?</div><div><br class=""></div><div>Section 3.3.1 is more specific <<a \
href="https://wicg.github.io/scroll-to-text-fragment/#parsing-the-fragment-directive" \
class="">https://wicg.github.io/scroll-to-text-fragment/#parsing-the-fragment-directive</a>> \
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.</div><div><br \
class=""></div><div>Regards,</div><div>Maciej</div><br class=""></body></html>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic