This is the last of the static-optimization improvements I plan to do for this release. This one was a bit tricky, because we have some complex logic to decide when to apply the api_static_fragment scoping to <a href="#foo"> and <area href="#bar">.
Part of this is due to #1150 – we only apply the scoping if there is an id attribute somewhere in the template. This is not perfect (ids can be added dynamically, or via lwc:spread), but my goal in this PR is to preserve the existing behavior, not to fix inconsistencies in the existing implementation.
It should go without saying that all of this fragment scoping only matters for synthetic shadow DOM. So that's another reason not to change any of it.
Does this pull request introduce a breaking change?
😮💨 No, it does not introduce a breaking change.
Does this pull request introduce an observable change?
Details
Partially addresses #4280.
This is the last of the static-optimization improvements I plan to do for this release. This one was a bit tricky, because we have some complex logic to decide when to apply the
api_static_fragmentscoping to<a href="#foo">and<area href="#bar">.Part of this is due to #1150 – we only apply the scoping if there is an
idattribute somewhere in the template. This is not perfect (ids can be added dynamically, or vialwc:spread), but my goal in this PR is to preserve the existing behavior, not to fix inconsistencies in the existing implementation.It should go without saying that all of this fragment scoping only matters for synthetic shadow DOM. So that's another reason not to change any of it.
Does this pull request introduce a breaking change?
Does this pull request introduce an observable change?