[Shadow]: url fragment identifiers should be followed into ShadowDOM (bugzilla: 23161)

[hayatoito]

Title: [Shadow]: url fragment identifiers should be followed into ShadowDOM (bugzilla: 23161)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23161

---

comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23161#c0
Steve Orvell wrote on 2013-09-05 02:16:51 +0000.

Given the following:

1. a user navigates to: foo.com/#footer
2. at the requested url inside some shadowRoot we have:

<div>
SR
  <footer id="footer"></footer>

In this case, the #footer resource should be navigated to (page scrolls to it) even though it is inside a shadowRoot. There is one url for a page and it must be shared by all the shadowRoots.

Since id's are scoped inside ShadowDOM, there may be a lot of duplicates page-wide. So, which one should be followed? The answer here is to do what browsers do now in this case: navigate to the first fragment identifier.

[hayatoito]

I do not have a strong opinion. This is a typical situation where pros and cons conflict.

1. Allow to navigate #id even it's in a shadow tree
2. Do not allow that. #id is navigate-able only if it is in a document tree

Which is preferred? Any opinions?

[uniqname]

Isn't the point of the shadowDOM to abstract away the inner workings of the component/element? Allowing fragment identifiers to penetrate the shadowDOM seems to violate that. Fragment id's are used to either scroll to a portion of a document (doesn't seem to fit the desired use case here), or to represent a particular state of a page. ID's are supposed to be unique across a document, they are not expected to be unique across all shadow boundaries, thus should element A and element B each have id X in their shadow tree, there would be no way of telling the document X of A but not X of B, no?

[domenic]

The point about non-uniqueness is pretty strong; I think do not allow (option 2) makes the most sense in that regard.

[rniwa]

Indeed, we can have multiple shadow DOMs that contain same IDs. We don't want to be conflating all those elements.

Having said that, there is something to be desired here about deep-linking into shadow DOM. We probably need some sort of nesting syntax for identifiers to do that though. e.g. #<id>!<id-in-shadow>

[hayatoito]

I'm pretty sure that people will prefer [option 2] at the first glance because [option 1] violates an encapsulation.
However, I am also afraid that we would receive a lot of complaints from web developers if #id is not navigate-able if it is in the shadow tree.

As Ryosuke suggested, it would be nice to have an alternative way to link into Shadow DOM.
I thought a similar nesting syntax too, but I'm not confident whether it's a good idea or not.

Any ideas are welcome.

[TakayoshiKochi]

hashchange event looks available across all browsers (except Opera Mini),
http://caniuse.com/#feat=hashchange

therefore if an web author wants to route (navigate, scroll to) some hash ID into
a deep id in a shadow, he/she can emulate whatever syntax (like Ryosuke suggested above)
even when option 2 is adopted.

So option 2 sounds good to me.

[hayatoito]

IMO, I prefer option 1. I am aware that this is a minor opinion.
I'd like to let web developers play with this wildness. In theory, this is ugly, but in practice, this is not so bad. Am I optimistic?

[annevk]

This seems like a thing (same with event retargating) that developers want to be able to control on a per-ShadowRoot basis.

For closed shadow trees we obviously cannot do this, but for open ones both might make sense. You probably want this if you use shadow trees for templating, but don't want it for controls.

[hayatoito]

+1. That sounds a good idea.

[hayatoito]

Does someone has a strong opinion how we should resolve this issue?

Looks this issue has not gotten much attention so far.
I'm okay to defer this to v2 unless someone really wants this feature.

[annevk]

When proposing to close an issue, it helps if you state the resolution. Are you saying the resolution should be that for v1 fragment identifiers will not go beyond the document tree? So either open or closed shadow trees with matching IDs will not be navigated to?

[hayatoito]

My bad. I should have clarified it.

Are you saying the resolution should be that for v1 fragment identifiers will not go beyond the document tree?

Yes. I meant this behavior. Fragment identifiers in shadow trees will not be leaked at all.

We have two options here:
A). Fragment identifiers in shadow trees are not effective at all.
B). Fragment identifiers in open shadow trees connected to a document can be navigated.

The current behavior is A). The proposed idea is B).
If someone really wants the behavior of B), please let us know that.

[rniwa]

We're fine with going with (A) and potentially revisiting new API surface in v2.

[annevk]

Closing this. If someone wants this they will need to create a new issue with a clear proposal.

[acarlstein]

I would like to add that using :target has other applications other than just following identifiers.
There are pure CSS effects that can be created with it.

For example, normally I could change the color of a header when clicking on a link using pure CSS:

CSS:

#message:target {
	color: red;
}

HTML:

<a href="#message">Make the message red</a>
<h2 id="message">Message in a bottle</h2> 

Before:

After:

By using pure CSS, we can keep a button highlighted in a toolbox, until we press another button:

by just doing:

CSS:

#toolbar .item-switch:target {
  background: white;
  color: black;
}

HTML:

  <a href="#btn-pencil">
    <span id="btn-pencil" class="item item-switch"><i class="fas fa-pencil-alt" alt="Pencil"></i></span>
  </a>

All this without having to write even one line of JavaScript yet.

However, by not allowing :target into the Web Component, this feature has being nullified.
Plus, I had to spend hours until I found that the root cause of the problem was that event target wasn't in the shadow-root.

So, the code below will not work:

let template = `
	<div>
		<a href="#message">Make the message red</a>
		<h2 id="message">Message in a bottle</h2>
	</div>
	<style>
		#message:target {
			color: red;
		}
	</style>
`;
class MyElement extends HTMLElement {
	constructor() {
		super();
		let shadowRoot = this.attachShadow({ mode: 'open' });
		shadowRoot.innerHTML = template;
	}
}
customElements.define('my-component', MyElement);