How this affects CSS target pseudo-class :target, propose :target-within #1

laukstein · 2019-02-14T18:49:46Z

Currently target element https://drafts.csswg.org/selectors-4/#the-target-pseudo is capturable with CSS :target that applies to elements having attribute id.

Since Scroll-To-Text may target text inside element and not directly text,
I recommend to take an example from CSS :focus, :focus-within and to implement a new target pseudo-class :target-within that would capture element within is the targeted text part.

@tabatkins, any suggestions?

The text was updated successfully, but these errors were encountered:

bokand · 2019-05-28T13:24:56Z

I like :target-within, it makes a lot of sense to me.

Another interesting point here is that the proposal, as stated, would allow having multiple targets. Off hand, I expect we could just apply :target-within to multiple elements but am interested if anyone has some counter examples.

Sync so my fork is up to date

Rebase

hftf · 2019-09-16T21:21:30Z

Another interesting point here is that the proposal, as stated, would allow having multiple targets.

I would love the ability to target multiple fragments of a page and style them using the existing CSS :target selector – and not just text (this proposal), but IDs or other locators (source line numbers) too. Imagine these examples:

Can you look at sections 2 and 5? http://path/to/doc#sec2#sec5
The bug is caused by lines 175–180 and 243–248. http://path/to/doc#L175-180,R243-248
"Highlight passages featuring the Woodman" implemented in https://polm.github.io/Emphasis/

Although this is almost certainly off-topic, it is related to the quoted excerpt above.

bokand · 2019-09-20T18:51:39Z

Our proposal already allows for highlighting multiple passages: E.g. in Chrome enable chrome://flags/#enable-text-fragment-anchor and follow this link

We could trivially extend this mechanisms to element id's: https://example.org##id=section1&id=section2

However, given that there's no visual indication on element-id's today, this wouldn't really add anything (except maybe a fallback). Perhaps we should add some sort of highlight for element-id's too...

That said, I think this is interesting follow-up work. We're currently focusing on getting the text selector completed.

domenic · 2019-09-25T05:19:29Z

Note that the current spec seems to imply :target will continue working, as it intends to use "the indicated part of the document", which fuels the :target selector. There'd need to be some more legwork done if the idea was to avoid interaction with :target, and instead have some new selector.

Krinkle · 2019-10-10T02:37:20Z

Does this mean :target would point to the lowest common element that contains all the found text? That would, I think, be ideal and obsolete the need for :target-within.

If we do consider :target-within, we would likely also need to consider how to accomplish the presumed-common use case of wanting to highlight the inner most element only. As-is I would expect a :target-within to select all ancestor elements as well (e.g. <em>, and <p>, and <article> ,and <body>). This is great if the design-need in question is about styling a specific element based on there being a highlight within it. But, not so great when wanting to generically highlighting the individual span or paragraph where the highlighted text resides.

bokand · 2019-10-10T04:23:43Z

I think I agree that just applying :target to the inner-most containing element makes sense and probably solves most of the use cases we care about. I'll have to think about the compat implications a little more. Other issues to think about:

How to apply :target with multiple highlights?
How to apply :target when the text spans multiple siblings/parent-child elements

callionica · 2019-10-10T09:07:59Z

If the "highlight" mentioned in the spec as something the UA produces when a page is visited is intended to be stylable, there should be some explicit mention of exactly what the intention is with regard to preventing scripts from seeing the fragment directive (since styles are typically script-detectable).

The spec currently uses "highlight" in two distinct contexts: 1) To mean a text selection provided by the user 2) To mean a visual effect to indicate to the user on arrival which text is of interest

I assumed the spec did not intend to imply that the result of visiting a link with a fragment directive would be a standard text selection (both because I don't think that's useful and because it would be script-detectable), but it's not currently clear what is intended.

My preferred result would be that the visual highlight effect would be entirely under the control of the UA and would be absolutely undetectable to script. I would like the highlight on the text to be short-lived and easily turned on/off. Sites should not have to implement that functionality: it should be the job of the UA.

bokand · 2019-10-10T10:22:45Z

Thanks for pointing that out, I've opened GH-51 with some normative text around how the text match must be surfaced to the user and cleaning up some of the ambiguity.

It explicitly must not be a text selection as that could allow malicious sites an attack vector to drag/drop tricks on a user.

For the most part, I also prefer having it be UA defined. The one area I could see some customization is allowing pages to set the indication color for more optimal contrast/theme/branding. I think this could be done in a way that it's not script readable but I'm wondering why we'd need that? If it's related to security/privacy, if the page can execute script in the origin then it can already do much worse.

callionica · 2019-10-10T10:43:42Z

Suppose I receive a link from a friend that links me to a page that displays multiple legal decisions and that friend wants to direct me to a specific legal decision using a fragment. Is it desirable that the site and any 3rd party scripts it loads should be able to determine at a granularity lower than the page level what specific part of the page my friend and I are referring to? No. That's creepy. It's none of their business.

While true that scripts can monitor all kinds of activity on a page, I am hoping that the design of this feature will allow some forms of sharing that scripts can't creepily (or accidentally) monitor. It's worth pointing out that even when you can't technically create a security boundary, you can still create legal/social boundaries to undesired behavior. If scripts needs to start implementing a bunch of code to monitor specific interactions, it becomes clear that they are exploiting technical limitations and that can expose the authors to social and legal consequences.

bokand · 2019-10-10T10:57:42Z

Ah, yes yes, I was thinking that cross-origin cases were the only thing to worry about and we were covered by the same origin policy. I agree though that there's value in hiding the targeted text even from the destination origin.

There's a bit of a trade-off here though. E.g. on mobile Wikipedia where all sections are initially collapsed, the page must have some way to know which section to expand so we necessarily have to provide, e.g. :target on a nearest element.

One other thing to note: since style can only apply to an element (i.e. not text nodes) I don't think any kind of script-readable styling can be more granular than :target. i.e. if we did provide something like ::text-indicator-color: red, I don't think script can use it to determine what part of the text is indicated.

callionica · 2019-10-10T11:34:25Z

Thanks for thinking about this.

It's true that any scroll or expansion in the page leaks information to scripts. Definite trade-offs.

My initial thought is that even if color is harder to detect than just calling getComputedStyle, presumably it would still possible to detect it if the UA's visual indication were to be part of the standard UI surface of the HTML that is accessible to script. (I don't know what the state of the art is, but presumably it's still possible to get image data for HTML elements from script?)

This doesn't necessarily mean that there shouldn't be color styles, but it perhaps does suggest that the visual indicator should be implemented as an overlay, so that it's UA "chrome" and not page "content".

bokand · 2019-10-10T11:55:14Z

I'm not aware of any APIs that let you get the raw pixel data from the rendered page - is such a thing possible?

I think as long as there's no way to get at the text-graunularity differences via script (getComputedStyle or otherwise) then I think that's reasonably restricted.

Re: making the indicator short-lived. I think it's fair to leave that up to the UA. The current implementation in Chrome removes it as soon as the user taps/clicks anywhere on the page.

Krinkle · 2019-10-10T17:53:34Z

Regarding security/privacy: This is related to the restrictions behind :visited links. We may want to consider similar restrictions on this new styling ability.

On the other hand, if we are concerned about scripts able to access which text highlight you opened via link, I am not sure that is feasible with the current proposal. The implementation proposes to use # fragments in the URL. These are de-facto visible via location.hash, location.href, document.URL. This seems fundamentally incompatible with considering text highlights as private information. Note, I agree it should remain private. I merely want to point out that the styling attack scenario seems secondary to the simpler JS interface which is an easier and more obvious way to reveal this information.

@bokand wrote:
There's a bit of a trade-off here though. E.g. on mobile Wikipedia where all sections are initially collapsed, the page must have some way to know which section to expand so we necessarily have to provide, e.g. :target on a nearest element.

Regarding collapsed sections, this is something Wikipedia's mobile site is struggling with today as well, e.g. through the "Find in page" functionality (downstream task), and relates to the "Find in page API" proposed a while back by @rakina and others. (WICG Discourse, w3ctag/design-reviews#236).

bokand · 2019-10-10T18:45:14Z

These are de-facto visible via location.hash, location.href, document.URL.

See issue #15 the history and how we work around this (it was originally to prevent compat issues but improved privacy is a great bonus). From the explainer:

The targetText is delimited from the rest of the fragment using the :~: token to indicate that it is a fragment directive that the user agent should process and then remove from the URL fragment that is exposed to the site. This change has been proposed to the HTML spec.

This means that if you have a URL: https://example.com#fragment:~:text=some private text

location.hash will return "fragment" and document.URL will return "https://example.com#fragment".

Krinkle · 2019-10-10T19:00:24Z

@bokand Thanks, that makes sense. That would mean it is hidden from JS if it was already in the original navigation. And if assigned by JavaScript, it will be possible to intercept probably, but that's unavoidable within JS. It would also not see its own actions. Not sure how that goes compat-wise, but I'll leave that be, given it's a closed issue.

bokand · 2019-10-10T19:03:42Z

Correct, but as a security mitigation, we don't invoke the text fragment directive on same-site navigations so simply writing to location.hash wouldn't invoke the feature. But that's moot because if you're writing to location.hash you already know what's going in there :)

laukstein · 2019-10-10T19:16:51Z

Keep in mind that pseudo-elements ::before, ::after may affect textual context too.
For example

p::before {
    content: "Hello ";
}
p::after {
    content: " World";
}

of

<p>This</p>

would result Hello This World and Scroll-To-Text should consider supporting this whole text.

tabatkins · 2019-10-10T21:11:38Z

I think I agree that just applying :target to the inner-most containing element makes sense

Yes, the nearest common ancestor of all the matched text is def what :target should match.

How to apply :target with multiple highlights?

Nothing wrong with having multiple elements match :target. Need to define how target navigation works (first one in document order? or closest to the page origin after layout?).

Keep in mind that pseudo-elements ::before, ::after may affect textual context too.

They don't show up (currently) in find-in-page, tho. I think we should be consistent with that feature, and include/exclude ::before/::after the same as f-i-p.

chrishtr · 2019-10-11T15:46:20Z

Regarding collapsed sections, this is something Wikipedia's mobile site is struggling with today as well, e.g. through the "Find in page" functionality (downstream task), and relates to the "Find in page API" proposed a while back by @rakina and others. (WICG Discourse, w3ctag/design-reviews#236).

Finding / linking within collapsed sections can be achieved with display locking. This feature is going to an Origin Trial in the upcoming Chrome 79. Would Wikipedia be able to give feedback and participate?

bokand · 2020-11-26T01:24:41Z

The spec and Blink implementation are now clear that :target is applied to the nearest common ancestor, and only on the first target.

I'm going to close this as it seems to work reasonably. Feel free to reply or file a new issue if there's use cases we're missing or improvements we could make.

laukstein mentioned this issue Feb 14, 2019

The :target pseudo-class bryanmcquade/scroll-to-css-selector#4

Open

bokand mentioned this issue May 28, 2019

How to deal with text that's initially hidden #17

Closed

bokand pushed a commit that referenced this issue Aug 16, 2019

Merge pull request #1 from WICG/master

e466dd8

Sync so my fork is up to date

bokand pushed a commit that referenced this issue Sep 12, 2019

Merge pull request #1 from WICG/master

0a3f827

Rebase

domenic mentioned this issue Sep 25, 2019

Need a way to feature detect #19

Closed

Treora mentioned this issue Sep 2, 2020

Allow customizing highlight style #143

Closed

bokand closed this as completed Nov 26, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

How this affects CSS target pseudo-class :target, propose :target-within #1

How this affects CSS target pseudo-class :target, propose :target-within #1

laukstein commented Feb 14, 2019

bokand commented May 28, 2019 •

edited

Loading

hftf commented Sep 16, 2019

bokand commented Sep 20, 2019

domenic commented Sep 25, 2019

Krinkle commented Oct 10, 2019 •

edited

Loading

bokand commented Oct 10, 2019

callionica commented Oct 10, 2019

bokand commented Oct 10, 2019

callionica commented Oct 10, 2019

bokand commented Oct 10, 2019

callionica commented Oct 10, 2019

bokand commented Oct 10, 2019

Krinkle commented Oct 10, 2019 •

edited

Loading

bokand commented Oct 10, 2019

Krinkle commented Oct 10, 2019 •

edited

Loading

bokand commented Oct 10, 2019

laukstein commented Oct 10, 2019 •

edited

Loading

tabatkins commented Oct 10, 2019

chrishtr commented Oct 11, 2019

bokand commented Nov 26, 2020

How this affects CSS target pseudo-class :target, propose :target-within #1

How this affects CSS target pseudo-class :target, propose :target-within #1

Comments

laukstein commented Feb 14, 2019

bokand commented May 28, 2019 • edited Loading

hftf commented Sep 16, 2019

bokand commented Sep 20, 2019

domenic commented Sep 25, 2019

Krinkle commented Oct 10, 2019 • edited Loading

bokand commented Oct 10, 2019

callionica commented Oct 10, 2019

bokand commented Oct 10, 2019

callionica commented Oct 10, 2019

bokand commented Oct 10, 2019

callionica commented Oct 10, 2019

bokand commented Oct 10, 2019

Krinkle commented Oct 10, 2019 • edited Loading

bokand commented Oct 10, 2019

Krinkle commented Oct 10, 2019 • edited Loading

bokand commented Oct 10, 2019

laukstein commented Oct 10, 2019 • edited Loading

tabatkins commented Oct 10, 2019

chrishtr commented Oct 11, 2019

bokand commented Nov 26, 2020

bokand commented May 28, 2019 •

edited

Loading

Krinkle commented Oct 10, 2019 •

edited

Loading

Krinkle commented Oct 10, 2019 •

edited

Loading

Krinkle commented Oct 10, 2019 •

edited

Loading

laukstein commented Oct 10, 2019 •

edited

Loading