[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: Rune Lillesveen via webkit-dev <webkit-dev () lists ! webkit ! org>
Date: 2020-11-20 14:59:05
Message-ID: CACuPfeRSjZDbSO208gy0d+A9ZqGbBYU-xA5Le8LbQL-_FbsMsw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
> <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@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@apple.com> wrote:
>>
>>>
>>>
>>> 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> wrote:
>>>
>>>> [Sorry, meant to reply-all]
>>>>
>>>> On Fri, Sep 25, 2020 at 1:25 AM Ryosuke Niwa <rniwa@webkit.org> wrote:
>>>>
>>>>>
>>>>> On Thu, Sep 24, 2020 at 8:19 AM David Bokan <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>
>>>
>>> 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
>
[Attachment #5 (text/html)]
<div dir="ltr">Hi,<div><br></div><div>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.</div><div><br></div><div>[1] <a \
href="https://groups.google.com/a/chromium.org/g/blink-dev/c/yN2lrq67a1c/m/_Giqh2g_AwA \
J">https://groups.google.com/a/chromium.org/g/blink-dev/c/yN2lrq67a1c/m/_Giqh2g_AwAJ</a></div><div>[2] \
<a href="https://drafts.csswg.org/css-pseudo-4/#selectordef-target-text">https://drafts.csswg.org/css-pseudo-4/#selectordef-target-text</a><br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 17, 2020 at 12:57 \
AM David Bokan via webkit-dev <<a \
href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a>> \
wrote:<br></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"><div \
dir="ltr">Hey Maciej/Ryosuke,</div><div dir="ltr"><br><div>I've updated the spec \
to be more precise around stripping the fragment directive. Specifically, <a \
href="https://wicg.github.io/scroll-to-text-fragment/#processing-the-fragment-directive" \
target="_blank">section 3.3.1</a> is fleshed out and makes the implications \
explicit, via examples, about how various APIs behave. Let me know if I missed \
any.</div><div><br></div><div>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 \
<a href="https://wicg.github.io/scroll-to-text-fragment/#urls-in-ua-features" \
target="_blank">section 3.6.1</a> which contains non-normative recommendations. \
These should match Chrome's current or upcoming \
behavior.</div><div><br></div><div>If you just want to see changes, see \
pull-requests linked from issue <a \
href="https://github.com/WICG/scroll-to-text-fragment/issues/150" \
target="_blank">#150</a>. \
</div><div><br></div><div>Cheers,<br>David</div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 5, 2020 at 2:55 PM \
David Bokan <<a href="mailto:bokan@chromium.org" \
target="_blank">bokan@chromium.org</a>> wrote:<br></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">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. </div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Sun, Nov 1, 2020 at 8:24 PM Maciej Stachowiak <<a \
href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div><br><div><br><blockquote type="cite"><div>On \
Oct 30, 2020, at 1:40 PM, David Bokan <<a href="mailto:bokan@chromium.org" \
target="_blank">bokan@chromium.org</a>> wrote:</div><br><div><div \
dir="ltr"><div>Hi Ryosuke,</div><div><br></div><div>Would just like to clarify one \
point.</div><br><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" \
target="_blank">bokan@chromium.org</a>> wrote:<br></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"><div>[Sorry, meant to \
reply-all]</div><br><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">rniwa@webkit.org</a>> wrote:<br></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"><div dir="ltr"><br></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">bokan@chromium.org</a>> wrote:<br></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"><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></blockquote><div><br></div><div> There are two specific \
points:</div><div><br></div><div> - 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><br></div><div>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><br></div><div>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></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" \
target="_blank">https://wicg.github.io/scroll-to-text-fragment/#the-fragment-directive</a>></div><div><br></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></div><div>Section 3.3.1 is more specific <<a \
href="https://wicg.github.io/scroll-to-text-fragment/#parsing-the-fragment-directive" \
target="_blank">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></div><div>Regards,</div><div>Maciej</div><br></div></blockquote></div>
</blockquote></div></div>
_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org" \
target="_blank">webkit-dev@lists.webkit.org</a><br> <a \
href="https://lists.webkit.org/mailman/listinfo/webkit-dev" rel="noreferrer" \
target="_blank">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br> \
</blockquote></div>
_______________________________________________
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