- From: Darien Maillet Valentine <notifications@github.com>
- Date: Sat, 13 May 2023 22:19:46 -0700
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/658/1546810465@github.com>
A builtin element becoming another underived element underfoot (as opposed to upgrading to a more-derived custom element that still has the same native brand/slots) doesn’t seem plausible or desirable. The number of new HTML behaviors that would need to be defined and implemented to account for the newly possible states this would bring into seems enormous. Despite the low value of most such possible states for users and developers, if they become possible at all, they must have defined behavior. For example, what happens when a builtin ceases to be that builtin during script execution when... - it’s an `<img>` or `<link>` with an associated ongoing fetch? - it’s an `<iframe>` with an associated ongoing navigation? what happens to its nested browsing context / document lifecycle? - it’s a `<form>` losing its formness in reaction to its own submit event being dispatched? Even in non-upgrade cases, consider all the implications for parsing if a script could have previously redefined: - `<base>` - `<meta>` - `<body>` - `<script>` - `<noscript>` - `<template>` - etc Also, ECMAScript objects branded with cross-realm slots cannot suddenly stop having those slots. While technically it wouldn’t violate a language-level invariant, it is an invariant-in-practice for all branded intrinsic and host objects and must remain so. -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/658#issuecomment-1546810465 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/658/1546810465@github.com>
Received on Sunday, 14 May 2023 05:19:52 UTC