Focus delegate algorithm doesn't consider elements assigned to slot

[sefeng211]

Is this expected?

Consider this test case

<section>
    <input type="text" />
</section>
<button>
  Open slotted dialog
</button>

<script>
document.querySelector('button').addEventListener('click', () => {
  document.querySelector('section').shadowRoot.querySelector('dialog').showModal();
});

document.querySelector('section').attachShadow({mode: 'open'});
document.querySelector('section').shadowRoot.innerHTML = '<dialog><slot></slot></dialog>';
</script>

The input element will not be focused upon clicking the button according to the current spec.

[annevk]

cc @rakina @domenic

[domenic]

Is this a duplicate of #7207?

[domenic]

In general if you look through https://github.com/whatwg/html/issues?q=%22focus+delegate%22 it looks like we've definitely done this intentionally.

On the other hand, maybe at the time we did this, we were thinking mostly of delegatesFocus, and not about <dialog>. Maybe using a single "focus delegate" algorithm for both cases was too ambitious?

[Westbrook]

Browser support for this is pretty important to development at Adobe. Our Spectrum Web Components library (leveraged in Photoshop, Express, soon to be Illustrator, and many more major efforts at the company) are very interested in moving towards leveraging <dialog> but this missing feature requires a good deal of timing orchestration and possibly expensive/encapsulation breaking client side DOM traversal to ensure. What's worse, while it works out of the box in Chormium, but not in WebKit/Gecko make the management of that nuance even more precarious.

We'd really appreciate this becoming part of the specification in this area. 🙏🏼 🙇🏼

[jpzwarte]

We have the same use case within our Sanoma Learning Design System. We have an <sl-dialog> web component where all the content is slotted into a <dialog> element.

[sefeng211]

Yeah, I think it might makes sense to have a different behaviour for <dialog>. The argument from Emilio made in #7207 still makes sense for Shadow DOM alone, which we consider the Shadow DOM tree separately from the light DOM, so it makes sense to delegate elements solely inside the Shadow DOM.

However for this use case, the container is not Shadow DOM, but rather <dialog> which is a light DOM element, so we should be able to delegate the focus to other light DOM elements.

cc @emilio in case Emilio has different opinions.

[josepharhar]

Browser support for this is pretty important to development at Adobe. Our Spectrum Web Components library (leveraged in Photoshop, Express, soon to be Illustrator, and many more major efforts at the company) are very interested in moving towards leveraging <dialog> but this missing feature requires a good deal of timing orchestration and possibly expensive/encapsulation breaking client side DOM traversal to ensure. What's worse, while it works out of the box in Chormium, but not in WebKit/Gecko make the management of that nuance even more precarious.

@Westbrook are you relying on the slot behavior in stable chrome? I am trying to remove it but running into issues in chrome:// pages which also rely on it

[Westbrook]

@Westbrook are you relying on the slot behavior in stable chrome? I am trying to remove it but running into issues in chrome:// pages which also rely on it

@josepharhar we can’t rely on it due to me not finding a quality test to show it is there, user agent not withstanding. Due to this, we’ve JS’ed around it, but it should work this way in all browsers. Yes, the flat tree can be annoying. Yes, there a many APIs new and old that avoid it and other forms of support for shadow DOM realities. But, shadow DOM is a part of the web platform and it needs to be respected as the number of people who build with it is growing and will continue to making it more and more important to do so.

[josepharhar]

A crbug about this has popped up: https://bugs.chromium.org/p/chromium/issues/detail?id=1459293
Someone wants to have slotted buttons be able to get initial focus in popovers