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 <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 webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
