This follows the discussion on the HTML spec PR [1], and follows the
approach suggested by @rniwa [2]. A template element is still created
and added to the stack of open elements, but the template is *not*
added to the document. And then the template contents are parsed
directly into the open shadow root, so there is no moving of contents
or removal of the template element at the end.

The new behavior is behind the StreamingDeclarativeShadowDOM feature,
which is enabled for experimental only. A virtual suite tests the old
non-streaming behavior.

[1] whatwg/html#5465
[2] WebKit/WebKit#4822

Bug: 1042130
Change-Id: Iab9c9c1a2eb49eaa8f1f7c928f2477977e92b49b

A new feature flag, StreamingDeclarativeShadowDOM, guards the new
behavior in this CL. When that flag is enabled, upon seeing the
*opening* `<template>` tag, the parser will attach a shadow root to
the `<template>`'s parent element. All subsequent template content will
then be parsed *directly* into that shadow root. The closing
`</template>` tag is then basically a no-op: there is no more moving
of template content into shadow roots and removal of the `<template>`
element. In this new mode, there is never an actual `<template>`
element placed into the DOM tree. There is a "placeholder" template
that gets added to the parser's stack of open elements, just to keep
track of the parsing mode appropriately.

If the StreamingDeclarativeShadowDOM flag is disabled, the "old"
behavior is retained, of attaching the shadow root at the closing
`</template>` tag. A virtual suite tests this the old non-streaming
behavior.

This approach follows the discussion on the HTML spec PR [1], and
the approach suggested by @rniwa [2].

[1] whatwg/html#5465
[2] WebKit/WebKit#4822

Bug: 1042130
Change-Id: Iab9c9c1a2eb49eaa8f1f7c928f2477977e92b49b

A new feature flag, StreamingDeclarativeShadowDOM, guards the new
behavior in this CL. When that flag is enabled, upon seeing the
*opening* `<template>` tag, the parser will attach a shadow root to
the `<template>`'s parent element. All subsequent template content will
then be parsed *directly* into that shadow root. The closing
`</template>` tag is then basically a no-op: there is no more moving
of template content into shadow roots and removal of the `<template>`
element. In this new mode, there is never an actual `<template>`
element placed into the DOM tree. There is a "placeholder" template
that gets added to the parser's stack of open elements, just to keep
track of the parsing mode appropriately.

If the StreamingDeclarativeShadowDOM flag is disabled, the "old"
behavior is retained, of attaching the shadow root at the closing
`</template>` tag. A virtual suite tests this the old non-streaming
behavior.

This approach follows the discussion on the HTML spec PR [1], and
the approach suggested by @rniwa [2].

[1] whatwg/html#5465
[2] WebKit/WebKit#4822

Bug: 1042130,1379513
Change-Id: Iab9c9c1a2eb49eaa8f1f7c928f2477977e92b49b

A new feature flag, StreamingDeclarativeShadowDOM, guards the new
behavior in this CL. When that flag is enabled, upon seeing the
*opening* `<template>` tag, the parser will attach a shadow root to
the `<template>`'s parent element. All subsequent template content will
then be parsed *directly* into that shadow root. The closing
`</template>` tag is then basically a no-op: there is no more moving
of template content into shadow roots and removal of the `<template>`
element. In this new mode, there is never an actual `<template>`
element placed into the DOM tree. There is a "placeholder" template
that gets added to the parser's stack of open elements, just to keep
track of the parsing mode appropriately.

If the StreamingDeclarativeShadowDOM flag is disabled, the "old"
behavior is retained, of attaching the shadow root at the closing
`</template>` tag. A virtual suite tests this the old non-streaming
behavior.

This approach follows the discussion on the HTML spec PR [1], and
the approach suggested by @rniwa [2].

[1] whatwg/html#5465
[2] WebKit/WebKit#4822

Bug: 1042130,1379513
Change-Id: Iab9c9c1a2eb49eaa8f1f7c928f2477977e92b49b

A new feature flag, StreamingDeclarativeShadowDOM, guards the new
behavior in this CL. When that flag is enabled, upon seeing the
*opening* `<template>` tag, the parser will attach a shadow root to
the `<template>`'s parent element. All subsequent template content will
then be parsed *directly* into that shadow root. The closing
`</template>` tag is then basically a no-op: there is no more moving
of template content into shadow roots and removal of the `<template>`
element. In this new mode, there is never an actual `<template>`
element placed into the DOM tree. There is a "placeholder" template
that gets added to the parser's stack of open elements, just to keep
track of the parsing mode appropriately.

If the StreamingDeclarativeShadowDOM flag is disabled, the "old"
behavior is retained, of attaching the shadow root at the closing
`</template>` tag. A virtual suite tests this the old non-streaming
behavior.

This approach follows the discussion on the HTML spec PR [1], and
the approach suggested by @rniwa [2].

[1] whatwg/html#5465
[2] WebKit/WebKit#4822

Bug: 1042130,1379513
Change-Id: Iab9c9c1a2eb49eaa8f1f7c928f2477977e92b49b

A new feature flag, StreamingDeclarativeShadowDOM, guards the new
behavior in this CL. When that flag is enabled, upon seeing the
*opening* `<template>` tag, the parser will attach a shadow root to
the `<template>`'s parent element. All subsequent template content will
then be parsed *directly* into that shadow root. The closing
`</template>` tag is then basically a no-op: there is no more moving
of template content into shadow roots and removal of the `<template>`
element. In this new mode, there is never an actual `<template>`
element placed into the DOM tree. There is a "placeholder" template
that gets added to the parser's stack of open elements, just to keep
track of the parsing mode appropriately.

If the StreamingDeclarativeShadowDOM flag is disabled, the "old"
behavior is retained, of attaching the shadow root at the closing
`</template>` tag. A virtual suite tests this the old non-streaming
behavior.

This approach follows the discussion on the HTML spec PR [1], and
the approach suggested by @rniwa [2].

[1] whatwg/html#5465
[2] WebKit/WebKit#4822

Bug: 1042130,1379513
Change-Id: Iab9c9c1a2eb49eaa8f1f7c928f2477977e92b49b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3967571
Reviewed-by: David Baron <dbaron@chromium.org>
Auto-Submit: Mason Freed <masonf@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1065551}

A new feature flag, StreamingDeclarativeShadowDOM, guards the new
behavior in this CL. When that flag is enabled, upon seeing the
*opening* `<template>` tag, the parser will attach a shadow root to
the `<template>`'s parent element. All subsequent template content will
then be parsed *directly* into that shadow root. The closing
`</template>` tag is then basically a no-op: there is no more moving
of template content into shadow roots and removal of the `<template>`
element. In this new mode, there is never an actual `<template>`
element placed into the DOM tree. There is a "placeholder" template
that gets added to the parser's stack of open elements, just to keep
track of the parsing mode appropriately.

If the StreamingDeclarativeShadowDOM flag is disabled, the "old"
behavior is retained, of attaching the shadow root at the closing
`</template>` tag. A virtual suite tests this the old non-streaming
behavior.

This approach follows the discussion on the HTML spec PR [1], and
the approach suggested by @rniwa [2].

[1] whatwg/html#5465
[2] WebKit/WebKit#4822

Bug: 1042130,1379513
Change-Id: Iab9c9c1a2eb49eaa8f1f7c928f2477977e92b49b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3967571
Reviewed-by: David Baron <dbaron@chromium.org>
Auto-Submit: Mason Freed <masonf@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1065551}

A new feature flag, StreamingDeclarativeShadowDOM, guards the new
behavior in this CL. When that flag is enabled, upon seeing the
*opening* `<template>` tag, the parser will attach a shadow root to
the `<template>`'s parent element. All subsequent template content will
then be parsed *directly* into that shadow root. The closing
`</template>` tag is then basically a no-op: there is no more moving
of template content into shadow roots and removal of the `<template>`
element. In this new mode, there is never an actual `<template>`
element placed into the DOM tree. There is a "placeholder" template
that gets added to the parser's stack of open elements, just to keep
track of the parsing mode appropriately.

If the StreamingDeclarativeShadowDOM flag is disabled, the "old"
behavior is retained, of attaching the shadow root at the closing
`</template>` tag. A virtual suite tests this the old non-streaming
behavior.

This approach follows the discussion on the HTML spec PR [1], and
the approach suggested by @rniwa [2].

[1] whatwg/html#5465
[2] WebKit/WebKit#4822

Bug: 1042130,1379513
Change-Id: Iab9c9c1a2eb49eaa8f1f7c928f2477977e92b49b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3967571
Reviewed-by: David Baron <dbaron@chromium.org>
Auto-Submit: Mason Freed <masonf@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1065551}

…adow DOM, a=testonly

Automatic update from web-platform-tests
Add support for streaming Declarative Shadow DOM

A new feature flag, StreamingDeclarativeShadowDOM, guards the new
behavior in this CL. When that flag is enabled, upon seeing the
*opening* `<template>` tag, the parser will attach a shadow root to
the `<template>`'s parent element. All subsequent template content will
then be parsed *directly* into that shadow root. The closing
`</template>` tag is then basically a no-op: there is no more moving
of template content into shadow roots and removal of the `<template>`
element. In this new mode, there is never an actual `<template>`
element placed into the DOM tree. There is a "placeholder" template
that gets added to the parser's stack of open elements, just to keep
track of the parsing mode appropriately.

If the StreamingDeclarativeShadowDOM flag is disabled, the "old"
behavior is retained, of attaching the shadow root at the closing
`</template>` tag. A virtual suite tests this the old non-streaming
behavior.

This approach follows the discussion on the HTML spec PR [1], and
the approach suggested by @rniwa [2].

[1] whatwg/html#5465
[2] WebKit/WebKit#4822

Bug: 1042130,1379513
Change-Id: Iab9c9c1a2eb49eaa8f1f7c928f2477977e92b49b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3967571
Reviewed-by: David Baron <dbaron@chromium.org>
Auto-Submit: Mason Freed <masonf@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1065551}

--

wpt-commits: 80c57bdba06c47377a7abd550e3a371f8dd51b9f
wpt-pr: 36597

…adow DOM, a=testonly

Automatic update from web-platform-tests
Add support for streaming Declarative Shadow DOM

A new feature flag, StreamingDeclarativeShadowDOM, guards the new
behavior in this CL. When that flag is enabled, upon seeing the
*opening* `<template>` tag, the parser will attach a shadow root to
the `<template>`'s parent element. All subsequent template content will
then be parsed *directly* into that shadow root. The closing
`</template>` tag is then basically a no-op: there is no more moving
of template content into shadow roots and removal of the `<template>`
element. In this new mode, there is never an actual `<template>`
element placed into the DOM tree. There is a "placeholder" template
that gets added to the parser's stack of open elements, just to keep
track of the parsing mode appropriately.

If the StreamingDeclarativeShadowDOM flag is disabled, the "old"
behavior is retained, of attaching the shadow root at the closing
`</template>` tag. A virtual suite tests this the old non-streaming
behavior.

This approach follows the discussion on the HTML spec PR [1], and
the approach suggested by @rniwa [2].

[1] whatwg/html#5465
[2] WebKit/WebKit#4822

Bug: 1042130,1379513
Change-Id: Iab9c9c1a2eb49eaa8f1f7c928f2477977e92b49b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3967571
Reviewed-by: David Baron <dbaron@chromium.org>
Auto-Submit: Mason Freed <masonf@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1065551}

--

wpt-commits: 80c57bdba06c47377a7abd550e3a371f8dd51b9f
wpt-pr: 36597

…adow DOM, a=testonly

Automatic update from web-platform-tests
Add support for streaming Declarative Shadow DOM

A new feature flag, StreamingDeclarativeShadowDOM, guards the new
behavior in this CL. When that flag is enabled, upon seeing the
*opening* `<template>` tag, the parser will attach a shadow root to
the `<template>`'s parent element. All subsequent template content will
then be parsed *directly* into that shadow root. The closing
`</template>` tag is then basically a no-op: there is no more moving
of template content into shadow roots and removal of the `<template>`
element. In this new mode, there is never an actual `<template>`
element placed into the DOM tree. There is a "placeholder" template
that gets added to the parser's stack of open elements, just to keep
track of the parsing mode appropriately.

If the StreamingDeclarativeShadowDOM flag is disabled, the "old"
behavior is retained, of attaching the shadow root at the closing
`</template>` tag. A virtual suite tests this the old non-streaming
behavior.

This approach follows the discussion on the HTML spec PR [1], and
the approach suggested by @rniwa [2].

[1] whatwg/html#5465
[2] WebKit/WebKit#4822

Bug: 1042130,1379513
Change-Id: Iab9c9c1a2eb49eaa8f1f7c928f2477977e92b49b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3967571
Reviewed-by: David Baron <dbaron@chromium.org>
Auto-Submit: Mason Freed <masonf@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1065551}

--

wpt-commits: 80c57bdba06c47377a7abd550e3a371f8dd51b9f
wpt-pr: 36597