Written by Ramón Saquete
Before getting into the subject, let’s remember what web componentsare : they encompass several technologies, including the shadow DOM.
The shadow DOM is one of the technologies that we have been talking about for years, used by the web components. Since then, the specification has evolved from v0web components (which were only compatible with Chrome while requiring polyfills or frameworks for other browsers), to v1web components, which are compatible with all of them.
This type of components should not be confused with the components of a framework such as Vue, Angular JS or React, as they directly replace the component with HTML code in the DOM light and can do it on the server using their version of universal and therefore do not pose as many indexability problems as the real ones. web components.
Difference between light DOM, shadow DOM and composed DOM
The composed DOM is the mixture of both, since in the shadow DOM we can define holes, called slots, in which we can assign pieces of the light DOM.
<mi-componente> <span slot="titulo">Título en el light DOM pero con H3 en el shadow DOM</span> <p>Texto en el light DOM</p> </mi-componente>
In addition, we assume that the component has a template declared as follows, in which there is a slot with the name “title” and another, initially unnamed, which will take the contents of the component that has no slot name assigned to it:
<slot></slot> <h3><slot name="titulo"></slot></h3> <p>Texto en el shadow DOM</p>
<p>Texto en el light DOM</p> <h3>Título en el light DOM pero con H3 en el shadow DOM</h3> <p>Texto en el shadow DOM</p>
How to know which parts of a web component are in the shadow DOM?
In this Google Chrome screenshot, where we see the component of the previous example with the inspect element tool, we can see that the shadow DOM appears inside the #shadow-root tag, indicating that it is the root of the shadow DOM. In addition, if we click inside a slot, it highlights the associated HTML in the DOM light.
How to make the shadow DOM indexable?
Another option is, as suggested by Google, to bring all content likely to affect positioning to the light DOM. But we can do this only in certain cases. For example: if the component is a button that performs an action, such as sharing the page on a social network, it is not even necessary to have light DOM. If, on the other hand, it is a component that formats a question and answer block, it can be more problematic, especially if we want to keep the semantic markup of headers and other semantic HTML tags in the DOM light, and that the page styles do not affect these tags.
Web components are very useful for custom development and, if their use is extended to CMSs, it will be possible to better isolate the code of different plugins to avoid incompatibilities. However, to ensure the indexability of the pages, we must either not use web components or bring all the important code into the component’s light DOM or force developers to use the complex solution of rehydrating the DOM.
None of these approaches is good, because the ability to encapsulate the code is lost, which is the main reason for using web components. So it is to be expected that in the future the specification will evolve to allow declaring the shadow DOM in the HTML in an explicit and indexable way.