Intent to Implement: Scroll to CSS selector

[Bryan McQuade]

Contact emails

bmcq...@chromium.org, pno...@chromium.org

Explainer

https://github.com/bryanmcquade/scroll-to-css-selector

Summary

To enable users to easily navigate to specific content in a web page, we propose adding support for using a CSS selector to specify the indicated part of the document.

Motivation

Web standards currently specify support for scrolling to anchor elements with name attributes (now obsolete), as well as DOM elements with ids, when navigating to a fragment. While named anchors and elements with ids enable scrolling to limited specific parts of web pages, not all documents make use of these elements, and not all parts of pages are addressable by named anchors or elements with ids.

We see the ability to scroll to specific parts of a document being useful for a variety of websites (e.g. search engine results pages, Wikipedia reference links), as well as by end users when sharing links from a browser.

Risks

Low risk: A browser that doesn’t yet support this feature will attempt to match a CSS selector encoded in the URL fragment using the existing logic to find a potential indicated element. A fragment-encoded CSS selector is prefixed with ‘targetElement=’ (see explainer), which is unlikely to match an id or name attribute, so we do not expect a matching element to be found. Thus, browsers that do not support this feature should fall back to the default behavior of not scrolling the document.

Low risk: If a web page is modified, existing links to that page with CSS selectors encoded in the fragment may either (a) no longer find a matching element, in which case the browser will not scroll (default/existing behavior), or (b) match an unintended element. To minimize the likelihood of these scenarios, we will publish recommendations for creating stable CSS selectors, based on related work to serialize and restore scroll anchors.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Link to entry on the feature dashboard
https://www.chromestatus.com/features/4771915918999552

 

Requesting approval to ship?

No.

[Boris Zbarsky]

On 5/21/18 2:34 PM, Bryan McQuade wrote:
> https://github.com/bryanmcquade/scroll-to-css-selector

Note that Firefox used to support this sort of thing with XPointer or
FIXptr in non-tagsoup documents. No one ever used either, as far as we
could tell, so it was removed.

It's entirely possible that the more-familiar CSS syntax, and the
ability to do this for HTML, not just XHTML/XML would get better
traction, of course.

> A fragment-encoded CSS selector is prefixed with ‘targetElement=’ (see
> explainer), which is unlikely to match an id or name attribute

Do we have any data on this? Seems like it would be useful to gather
some, just to quantify things.

Also, why "targetElement=" as opposed to "css=", say? The latter would
make it clearer what query language is being used and not preempt future
attempts to use other query languages if those come up.

-Boris

[Ian Kilpatrick]

Hi,

Please make sure you file a TAG review as per: https://docs.google.com/document/d/1vlTlsQKThwaX0-lj_iZbVTzyqY7LioqERU8DK3u3XjI/edit#bookmark=kix.p5nalpch13qw

Thanks,

Ian

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/97dc5d16-29f5-f634-e3bc-abdfc2f26e8d%40mit.edu.

[PhistucK]

Well, there is a risk that a website already expects and parses this string (...URL...#targetElement=foo) for a different goal and the browser will unexpectedly scroll.

Also, unsuspecting authors can have certain parts of the page revealed before they intended (an answer to a question, a surprise...), this sort of creates a public API out of implementation details.

Perhaps adding a way to designate certain (or all) elements as externally scroll-able would alleviate the concern.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADLGQyAkgPxP7iCPniLyiB5XUXt%3DZwLJoEZG3_NrfjWNrSixVA%40mail.gmail.com.

[phi...@google.com]

+1 - Google Search is interested in using this capability to improve our ability to link to relevant parts of web pages for a given user query. We've wanted a capability like this on the web for some time, so we're glad to see this moving forward.

 -- Phiroze

[fantasai]

I'd use selector= or, preferably, selector(). Selectors are used in more than just CSS, e.g.
querySelector() has nothing to do with CSS.

~fantasai

[fantasai]

On 05/21/2018 11:34 AM, Bryan McQuade wrote:
> *
>
> Contact emails
>
> bmcq...@chromium.org <mailto:bmcq...@chromium.org>, pno...@chromium.org <mailto:pno...@chromium.org>
>
> Explainer
>
> https://github.com/bryanmcquade/scroll-to-css-selector

Is this on the standards track somewhere? I don't see anything
indicating your plans for putting it on the standards track or
otherwise coordinating with other implementors and getting wide
review.

It doesn't seem to me that implementing it would be particularly
difficult, so the benefits of a proof-of-implementation (as
opposed to a shipping implementation) seem minimal. However,
getting consensus on the design and intent to implement across
browsers would be valuable, since that type of review will often
raise issues you haven't thought of but need to address, and will
help get other browsers on board to implement and ship the feature
with you, assuming everyone agrees it's valuable.

(I'm assuming you mean for this not to be a Chrome-only thing, and
intend to have other browsers interoperate with Chrome inasmuch as
possible. Correct me if I'm wrong.)

Also wrt the Explainer, Media Fragments might be another thing
to link to as prior art:
https://www.w3.org/TR/media-frags/

> Low risk: ... browsers that do not support this feature should

> fall back to the default behavior of not scrolling the document.

If the document is using :target to alter the styling of the
element (e.g. to make it visible), then the default behavior
could be that in browsers that do not support the feature, the
targetted element is not accessible at all. I don't know whether
that still qualifies as “low risk”.

~fantasai

[Chen Zhixiang]

I thought the real rish is, this new url syntax enhancement will break many existing url parser code,

which may assume the last '#' in url starts a fragment,

but the css selector embedding in url will break this assumption.

[smcg...@chromium.org]

I have no opinion on the original proposal, but would like to note: any parser that assumes the last '#' in a url starts the fragment is already broken AFAIK. The first '#' in a URL is the fragment indicator; everything that follows is part of the fragment. Please read the spec: https://url.spec.whatwg.org/, specifically the treatment of '#' in the basic URL parser state machine (https://url.spec.whatwg.org/#concept-basic-url-parser)

That said, I think by spec you do need to percent-encode '#' in fragments. I think. The spec is a little hard to follow, I actually am going to file an issue that I think I've found regarding this.

[Mike West]

Hey Bryan!

If you haven't already, I'd suggest reaching out to security folks for a review. A few folks on Twitter noted some concerns (e.g. slekies@, koto@, and aaj@ in https://twitter.com/slekies/status/998961323663863808), and I think you and I talked briefly about making clickjacking easier by scrolling to a target UI element. It would be helpful if the explainer and eventual spec addressed these kinds of concerns.

Thanks!

-mike

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

[Bryan McQuade]

Thanks everyone for feedback. I've replied to all responses below.

Two common areas of feedback were the name we use in the fragment, as

well as our plans for standardization. I'll address those here:

Regarding standardization, it is our intent to go through the

standards process, and we would like to see this capability available

in other browsers. We're interested in collaborating with other

browser vendors and wanted to share this I2I as a starting point for

public discussion.

Regarding naming, there are lots of good potential names. We don't

feel strongly that the name needs to be targetElement. We'll continue

to iterate on potential name choices as we go forward. We'd ideally

like to see any discussions on naming choices being guided with data

to support one name over another, to avoid bikeshedding. There's some

additional discussion on considerations when choosing a name in the

replies below.

Additional replies below:

> bzba...@mit.edu wrote:

> Note that Firefox used to support this sort of thing with XPointer or 

> FIXptr in non-tagsoup documents.  No one ever used either, as far as we 

> could tell, so it was removed.

> 

> It's entirely possible that the more-familiar CSS syntax, and the 

> ability to do this for HTML, not just XHTML/XML would get better 

> traction, of course.

Yes, there's been interest in this feature from web developers

recently. We agree that not coupling to XPointer and using more 

familiy CSS syntax is the right approach here.

We also see this being useful within the share functionality

of the browser, to enable users to optionally share a link directly to

a specific passage in a document. For example in

https://twitter.com/mathias/status/998737698868416512 and similar

tweets, users currently have to share screenshots to reference a

passage in a web page. We think it would be better to enable users to

share a link directly to that passage, either in place of or in

addition to a screenshot, to enable their readers to easily engage

with the original web content. Some of this work, e.g. scrolling to a

text passage and/or highlighting the scrolled-to region in the

browser, is described in the 'Future Work' section of the

explainer. We're interested in pursuing these but see support for

scrolling to elements identified by CSS selectors as an initial

starting point.

> > A fragment-encoded CSS selector is prefixed with ‘targetElement=’ (see 

> > explainer), which is unlikely to match an id or name attribute

> 

> Do we have any data on this?  Seems like it would be useful to gather 

> some, just to quantify things.

We can collect data on how often a fragment that contains an encoded

CSS selector (e.g. 'targetElement=.myclass') ends up matching an id or

name attribute in a document. We'd need to find an id or name attr

that contains this full string (e.g. <div id='targetElement=.myclass'>)

which seems unlikely but I agree that having data to support this would

be beneficial.

> phis...@gmail.com wrote:

> Well, there is a risk that a website already expects and parses this string (...URL...#targetElement=foo) for a different goal and the browser will unexpectedly scroll.

> Also, unsuspecting authors can have certain parts of the page revealed before they intended (an answer to a question, a surprise...), this sort of creates a public API out of implementation details.

> Perhaps adding a way to designate certain (or all) elements as externally scroll-able would alleviate the concern.

That's right, any new token has the potential for having some meaning

in existing web apps. We elected to use a slightly longer and more

unique name, 'targetElement', to reduce the likelihood of collision,

relative to shorter names that are already commonly used on the web

such as 'css'. We're still iterating on the exact token we choose

and want to make sure we choose.

> fantasa...@inkedblade.net wrote:

> It doesn't seem to me that implementing it would be particularly

> difficult, so the benefits of a proof-of-implementation (as

> opposed to a shipping implementation) seem minimal.

I agree that implementation of this feature should be

straightforward. We think it's still important to provide an initial

implementation that developers can experiment with. My experience is

that it's important to put a feature in developers' hands and get

their feedback in using it as part of validating that what you hope to

build and standardize is indeed useful. So we see implementation and

origin trials, in parallel with standadization, as being important

here.

> However,

> getting consensus on the design and intent to implement across

> browsers would be valuable, since that type of review will often

> raise issues you haven't thought of but need to address, and will

> help get other browsers on board to implement and ship the feature

> with you, assuming everyone agrees it's valuable.

> 

> (I'm assuming you mean for this not to be a Chrome-only thing, and

> intend to have other browsers interoperate with Chrome inasmuch as

> possible. Correct me if I'm wrong.)

(see comments at the beginning of this message for standards plans)

> 

> Also wrt the Explainer, Media Fragments might be another thing

> to link to as prior art:

>    https://www.w3.org/TR/media-frags/

Absolutely, we reviewed the Media Fragments document but somehow

missed referencing it in the explainer. Thanks for suggesting! I've

added a link to this doc in the section where we talk about fragment

support for other mime types.

> 

> If the document is using :target to alter the styling of the

> element (e.g. to make it visible), then the default behavior

> could be that in browsers that do not support the feature, the

> targetted element is not accessible at all. I don't know whether

> that still qualifies as “low risk”.

I don't follow this. Can you elaborate? We're definitely interested to

better understand any potential risks here.

> 

> 

> 

> mk...@chromium.org wrote:

> Hey Bryan!

> 

> If you haven't already, I'd suggest reaching out to security folks for a review. A few folks on Twitter noted some concerns (e.g. slekies@, koto@, and aaj@ in https://twitter.com/slekies/status/998961323663863808), and I think you and I talked briefly about making clickjacking easier by scrolling to a target UI element. It would be helpful if the explainer and eventual spec addressed these kinds of concerns.

> 

> Thanks!

Sure, we're planning to start the security review process soon, thanks!

[PhistucK]

You did not respond to the other concern -

> Also, unsuspecting authors can have certain parts of the page revealed before they intended (an answer to a question, a surprise...), this sort of creates a public API out of implementation details.

> Perhaps adding a way to designate certain (or all) elements as externally scroll-able would alleviate the concern.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADLGQyAMGxVkKa1_D6KDoP7LAB2K5hGJOPs31zvKtdBkM-d2ig%40mail.gmail.com.

[Bryan McQuade]

On Wed, May 23, 2018 at 3:52 PM PhistucK <phis...@gmail.com> wrote:

You did not respond to the other concern -

> Also, unsuspecting authors can have certain parts of the page revealed before they intended (an answer to a question, a surprise...), this sort of creates a public API out of implementation details.

> Perhaps adding a way to designate certain (or all) elements as externally scroll-able would alleviate the concern.

I missed this earlier. For pages where developers don't want to allow for this scrolling, we plan to allow developers/authors to disable this feature, at the page level.

RE: adding a way to designate elements as scrollable, the primary way for developers to identify which elements are scrollable is by giving them id or name attributes, which is already broadly supported today. This proposal is intended to complement that existing mechanism. Shaun Inman explains how the 2 are complementary in a blog post (he refers to these selectors as 'CSSFrags'): "CSSFrags are not meant to replace more concise, author-designed urls [using id or name attributes]. CSSFrags enable a site’s users to address specific sub-content that the site’s author may not have anticipated as being interesting. Think about user stylesheets and how they afford another layer of control above author-designed stylesheets."

[PhistucK]

As long as there is an opt (either in or out), it sounds good to me. Thank you!

☆PhistucK

[fantasai]

On 05/23/2018 10:36 AM, Bryan McQuade wrote:
>
> > If the document is using :target to alter the styling of the
> > element (e.g. to make it visible), then the default behavior
> > could be that in browsers that do not support the feature, the
> > targetted element is not accessible at all. I don't know whether
> > that still qualifies as “low risk”.
>
> I don't follow this. Can you elaborate? We're definitely interested to
> better understand any potential risks here.

When an element is the target of the URL, it matches the :target pseudo-class.
Authors can use this pseudo-class to make an element visible or hidden depending
on whether it is targetted.

section:not(:target) { line-clamp: 3; } /* Collapse content when not targetted */

The fallback behavior in this case isn't just that we land at the top of the page
instead of at the targetted element, but that the content is never visible.

~fantasai

[pno...@google.com]

I see what you're saying. If a page relies on the :target pseudoclass to style a certain element, non-implementing browsers will both fail to scroll to that element and fail to style it as intended, which could result in not showing it at all. 

This seems unavoidable in general. My sense is that page authors should avoid relying on 

1) Features implemented in only one browser, generally

2) The uncontrolled contents of the hash fragment to control element visibility, specifically

That's not to say that authors shouldn't use the :target pseudoclass at all, or even that they shouldn't use it to control visibility. Just that doing so when they don't control the contents of the hash fragment(either via the inbound link or controls on the page) is asking for trouble. Of course there is still a risk that they'll do so anyways. I'm open to suggestions to how to mitigate the risk technically, but I don't think there's much we can do in that dimension(we could provide a temporary, Chrome-only :css-selector-target pseudoclass but that's pretty kludgy and will break validation tools). It seems most mitigation would come from ensuring people don't end up in this situation in the first place, and reducing the amount of time that there's not cross-browser support.

[fantasai]

On 05/24/2018 01:15 PM, pnoland via blink-dev wrote:
> I see what you're saying. If a page relies on the :target pseudoclass to style a certain element,
> non-implementing browsers will both fail to scroll to that element and fail to style it as intended,
> which could result in not showing it at all.
> This seems unavoidable in general. My sense is that page authors should avoid relying on
> 1) Features implemented in only one browser, generally

Page authors don't tend to do this as much as we might want them to,
especially when that one browser is the market leader. Google itself
has a pretty terrible track record on this point (which is not the
fault of the Chrome team, but if even your own company can't adhere
to that guideline, it's not exactly something you can rely on, is it).

> 2) The uncontrolled contents of the hash fragment to control element visibility, specifically
>
> That's not to say that authors shouldn't use the :target pseudoclass at all, or even that they
> shouldn't use it to control visibility. Just that doing so when they don't control the contents of
> the hash fragment(either via the inbound link or controls on the page) is asking for trouble. Of
> course there is still a risk that they'll do so anyways. I'm open to suggestions to how to mitigate

> the risk technically, but I don't think there's much we can do in that dimension ...

Right. And as you note, this:

> reducing the amount of time that there's not cross-browser support.

is probably the way to deal with that problem, which means engaging
with other browsers up front to get it standardized and on their
implementation roadmap as part of your risk mitigation plan.

~fantasai

[nbu...@google.com]

Update: This has evolved into "Scroll to Text".

Here is the updated explainer: https://github.com/bokand/ScrollToTextFragment

Design doc: https://docs.google.com/document/d/1ftMneoES1_8heCuE5RgU93GjqdEFBAT3ins2ihS0ExA
Chrome status entry: https://chromestatus.com/feature/4733392803332096