Intent to Implement: Scroll to CSS selector

469 views
Skip to first unread message

Bryan McQuade

unread,
May 21, 2018, 3:13:25 PM5/21/18
to blink-dev, Patrick Noland

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

unread,
May 21, 2018, 3:44:36 PM5/21/18
to Bryan McQuade, blink-dev, Patrick Noland
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

unread,
May 21, 2018, 4:18:49 PM5/21/18
to Boris Zbarsky, bmcq...@chromium.org, blink-dev, pno...@google.com

--
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

unread,
May 21, 2018, 5:57:34 PM5/21/18
to Bryan McQuade, blink-dev, pno...@google.com
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.

phi...@google.com

unread,
May 21, 2018, 8:02:53 PM5/21/18
to blink-dev, pno...@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

unread,
May 22, 2018, 6:30:10 PM5/22/18
to Boris Zbarsky, Bryan McQuade, blink-dev, Patrick Noland
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

unread,
May 22, 2018, 7:03:01 PM5/22/18
to Bryan McQuade, blink-dev, Patrick Noland
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

unread,
May 22, 2018, 10:38:52 PM5/22/18
to blink-dev, pno...@google.com
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

unread,
May 22, 2018, 11:02:43 PM5/22/18
to blink-dev, pno...@google.com
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

unread,
May 23, 2018, 3:06:05 AM5/23/18
to bmcq...@chromium.org, blink-dev, pno...@google.com
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

unread,
May 23, 2018, 10:36:52 AM5/23/18
to blink-dev, Patrick Noland
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:

> 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
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.

> 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.

> 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:

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.

> 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

unread,
May 23, 2018, 3:52:44 PM5/23/18
to Bryan McQuade, blink-dev, Patrick Noland
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.

Bryan McQuade

unread,
May 23, 2018, 4:10:28 PM5/23/18
to PhistucK, blink-dev, Patrick Noland
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

unread,
May 24, 2018, 2:07:15 AM5/24/18
to Bryan McQuade, blink-dev, Patrick Noland
As long as there is an opt (either in or out), it sounds good to me. Thank you!

PhistucK

fantasai

unread,
May 24, 2018, 12:32:05 PM5/24/18
to Bryan McQuade, blink-dev, Patrick Noland
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

unread,
May 24, 2018, 4:54:47 PM5/24/18
to blink-dev, bmcq...@chromium.org, 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

unread,
May 29, 2018, 2:22:55 PM5/29/18
to pno...@google.com, blink-dev, bmcq...@chromium.org
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

unread,
Jun 19, 2019, 8:38:19 PM6/19/19
to blink-dev, pno...@google.com
Reply all
Reply to author
Forward
0 new messages