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

[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 <bo...@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 <m...@apple.com> wrote:
>>> On Oct 30, 2020, at 1:40 PM, David Bokan <bo...@chromium.org> wrote:
>>> Hi Ryosuke,
>>> Would just like to clarify one point.
>>> On Fri, Sep 25, 2020 at 12:42 PM David Bokan <bo...@chromium.org> wrote:
>>>> [Sorry, meant to reply-all]
>>>> On Fri, Sep 25, 2020 at 1:25 AM Ryosuke Niwa <rn...@webkit.org> wrote:
>>>>> On Thu, Sep 24, 2020 at 8:19 AM David Bokan <bo...@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
webkit-dev mailing list

Reply via email to