You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: reports/2022.html
+24-5Lines changed: 24 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -56,6 +56,25 @@ <h2>Introduction</h2>
56
56
<p>The initial slate of APIs that browsers shipped with web components "v1" left many important features and use-cases on a future to-do list, to be finalized out after the core custom element and shadow DOM features landed. While the web components GitHub issues and face-to-face meets have tracked and discussed many of these features individually, there hasn't been a comprehensive overview of what's left to "finish" web components.</p>
57
57
<p>This document tries to highlight the main features that are lacking from the web components spec that either block adoption for more developers and frameworks, or cause pain points for existing developers.</p>
58
58
<p>It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers.</p>
59
+
<section>
60
+
<h3>Browser Parity</h3>
61
+
<p>We noticed the following specs already have a high degree of alignment from an implementation perspective, but support in browsers is still not equally distributed. Filling in these gaps would be a big win for users and developers alike for a more predictable web.</p>
<p>The following specs we see as highly valuable to the developer community for being able to deliver great web experiences to users when using Web Components. As it pertains to topics like Aria and SSR, these specs just need a little more alignment across browser implementors so that consensus can be achieved.</p>
@@ -245,11 +264,11 @@ <h3>Initial API Summary/Quick API Proposal</h3>
245
264
<p>The form-associated custom elements APIs are implemented within the attachInternals method on the HTMLElement prototype. Calling attachInternals returns an instance of an ElementInternals object which grants developers the ability to interact with form elements provided they designate their element as a form-associated element.</p>
246
265
<pre>
247
266
<code>
248
-
%gt;form>
249
-
%gt;fancy-input name="fancy">%gt;/fancy-input>
250
-
%gt;/form>
267
+
<form>
268
+
<fancy-input name="fancy"></fancy-input>
269
+
</form>
251
270
252
-
%gt;script>
271
+
<script>
253
272
class FancyInput extends HTMLElement {
254
273
static get formAssociated() {
255
274
return true;
@@ -270,7 +289,7 @@ <h3>Initial API Summary/Quick API Proposal</h3>
270
289
271
290
console.log(formData.get('fancy')); // logs 'I can participate in a form!'
272
291
});
273
-
%gt;/script>
292
+
</script>
274
293
</code>
275
294
</pre>
276
295
<p>The <code>setFormValue</code> method can accept several types of data including strings, <code>FileData</code> and <code>FormData</code> objects, the latter of which can allow a nested form to participate with a parent in its entirety.</p>
0 commit comments