There is some interesting history to this change:

* servo#33495: Servo crashes on
  Cloudflare's turnstile, because we didn't compute style for
  elements inside shadow trees
* servo#34298: Resolves the issue
  by computing style for children of a potential shadow root,
  in addition to the children of an element
* servo#34701: Changes layout
  of elements with shadow roots such that only the contents
  of the shadow root are laid out

Now, we compute style for both the children of the element
and a potential shadow root, but only lay out the contents
of the shadow tree (if there is one).

This behaviour is not technically incorrect,
since regular children are not included in layout
their style doesn't matter. However, it is
inefficient: the only case where we need to compute
style for a child of a shadow host is when
that child is an assigned slottable in a slot
somewhere else.

This part 1/n of upstreaming the changes necessary
to lay out <slot> contents. Note that trying to compute
style for <slot> contents *and* children of shadow hosts
will crash in stylo, since it expects to see each
element only once.

Signed-off-by: Simon Wülker <[email protected]>

There is some interesting history to this change:

* servo#33495: Servo crashes on
  Cloudflare's turnstile, because we didn't compute style for
  elements inside shadow trees
* servo#34298: Resolves the issue
  by computing style for children of a potential shadow root,
  in addition to the children of an element
* servo#34701: Changes layout
  of elements with shadow roots such that only the contents
  of the shadow root are laid out

Now, we compute style for both the children of the element
and a potential shadow root, but only lay out the contents
of the shadow tree (if there is one).

This behaviour is not technically incorrect,
since regular children are not included in layout
their style doesn't matter. However, it is
inefficient: the only case where we need to compute
style for a child of a shadow host is when
that child is an assigned slottable in a slot
somewhere else.

This part 1/n of upstreaming the changes necessary
to lay out <slot> contents. Note that trying to compute
style for <slot> contents *and* children of shadow hosts
will crash in stylo, since it expects to see each
element only once.

Signed-off-by: Simon Wülker <[email protected]>

There is some interesting history to this change:

* servo#33495: Servo crashes on
  Cloudflare's turnstile, because we didn't compute style for
  elements inside shadow trees
* servo#34298: Resolves the issue
  by computing style for children of a potential shadow root,
  in addition to the children of an element
* servo#34701: Changes layout
  of elements with shadow roots such that only the contents
  of the shadow root are laid out

Now, we compute style for both the children of the element
and a potential shadow root, but only lay out the contents
of the shadow tree (if there is one).

This behaviour is not technically incorrect,
since regular children are not included in layout
their style doesn't matter. However, it is
inefficient: the only case where we need to compute
style for a child of a shadow host is when
that child is an assigned slottable in a slot
somewhere else.

This part 1/n of upstreaming the changes necessary
to lay out `<slot>` contents. Note that trying to compute
style for `<slot>` contents *and* children of shadow hosts
will crash in stylo, since it expects to see each
element only once.

Signed-off-by: Simon Wülker <[email protected]>

There is some interesting history to this change:

* #33495: Servo crashes on
  Cloudflare's turnstile, because we didn't compute style for
  elements inside shadow trees
* #34298: Resolves the issue
  by computing style for children of a potential shadow root,
  in addition to the children of an element
* #34701: Changes layout
  of elements with shadow roots such that only the contents
  of the shadow root are laid out

Now, we compute style for both the children of the element
and a potential shadow root, but only lay out the contents
of the shadow tree (if there is one).

This behaviour is not technically incorrect,
since regular children are not included in layout
their style doesn't matter. However, it is
inefficient: the only case where we need to compute
style for a child of a shadow host is when
that child is an assigned slottable in a slot
somewhere else.

This part 1/n of upstreaming the changes necessary
to lay out `<slot>` contents. Note that trying to compute
style for `<slot>` contents *and* children of shadow hosts
will crash in stylo, since it expects to see each
element only once.

Signed-off-by: Simon Wülker <[email protected]>