Open Westbrook opened 1 month ago
Session no. 1 happened on 19 July at 11:30am ET.
Notes are available here.
TPAC Prep no. 2 is in the books! Thanks everyone for joining. 🙇🏼
Take a look at the notes here.
Action Items:
So I am not super well versed on the current status of all of these, but I pulled the full list of items from our 2022 report which was when we last had a full list of these and tried to apply my understanding of current status to each of them, with some liberty taken to also try and use this as latest and greatest "state of" reference.
On going
Spec | Status | Link | WCCG Notes (at the time) |
---|---|---|---|
Children changed callback | ⚠️ | WICG/webcomponents#809 | Uncertain |
Composed Selection | ⚙️ | WICG/webcomponents#79 | Partial consensus, divergent partial implementations |
Cross-root ARIA | ⚙️ | WICG/aom#169 / WICG/aom#107 / WICG/webcomponents#917 / WICG/webcomponents#916 / https://github.com/WICG/webcomponents/blob/gh-pages/proposals/reference-target-explainer.md | Uncertain |
CSS Module Scripts | 🔧 | WICG/webcomponents#759, https://github.com/tc39/ecma262/pull/3057 | Some implementation |
CSS Properties and values inside shadow root | ⚠️ | ||
Custom Attributes | ▶️ | https://github.com/w3c/webcomponents-cg/discussions/31#discussioncomment-3163644 | Not addressed |
Declarative CSS Modules | ⚙️ | WICG/webcomponents#939, see Edge team research | Not Addressed |
Declarative custom elements | ⚙️ | https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Declarative-Custom-Elements-Strawman.md | Not addressed |
DOM Parts | 💡 | https://github.com/WICG/webcomponents/blob/gh-pages/proposals/DOM-Parts.md | Uncertain |
HTML modules | ▶️ | WICG/webcomponents#645 | Partial consensus, no implementations |
Lazy custom element definitions | ⚠️ | WICG/webcomponents#782 | Uncertain |
Open styling of shadow roots | 💡 | WICG/webcomponents#909 | Not addressed |
Scoped Element Registries | ⚙️ | WICG/webcomponents#716 | Consensus |
Styling children of slotted content | ❓ | ||
Theming | ▶️ | WICG/webcomponents#864 | Uncertain |
❓ - Not sure, please help me give it a more accurate status 🔧 - under review in appropriate spec'ing body :shipit: - Shipped x-browser ⚙️ - On our radar / active ▶️ - Let's pull this over and put it on our radar ⚠️ - Uncertain 💡 - Just an idea 🪦 - Abandoned
My thought was that anything with statuses ⚙️ , 💡 , ⚠️, or ▶️ we could maybe pull over into an issue / discussion per the workflow we're considering in https://github.com/w3c/webcomponents-cg/issues/99?
Shipped
Spec | Status | Link | WCCG Notes (at the time) |
---|---|---|---|
Constructable Stylesheets & adoptedStyleSheets | :shipit: | WICG/webcomponents#468 | Some implementation |
Custom CSS State | :shipit: | https://html.spec.whatwg.org/multipage/custom-elements.html#custom-state-pseudo-class | |
Declarative Shadow DOM | :shipit: | whatwg/dom#831 | Partial consensus, some implementation |
Form-Associated Custom Elements | :shipit: | WICG/webcomponents#187 | Some implementation |
Imperative Slot Assignment | :shipit: | whatwg/html#3534 | Partial Implementation |
@thescientist13 with so many things covered in this table it may be more productive to start a Discussion where each of the APIs could be individual responses that then can have their own threads each? I've definitely got some updates on various things, but don't know how to share that data based on this structure.
My hope was that we could use the list as a basic cutline of things that should get pulled over into their own discussions. For example, Declarative Shadow DOM is shipped / baseline, right? If so, then we don't have to pull that one over.
Otherwise, sure I could create a single discussion for each item and we can use a thread per item to see if each item should be turned into its own discussion / issue.
Let's chat on the next TPAC session if we have a minute. 👍
Notes: https://docs.google.com/document/d/1jOz2Mu8y49j81WPE7__sHkyoUQey6X09JNiYmEh4b1I/edit
Action items
Held over
Here's a link to an issue I just made re: our orgs and repos - https://github.com/w3c/webcomponents-cg/issues/100
Really great conversation about what we want to bring to the TPAC breakouts that have been proposed by Ryosuke. See the notes here.
Action Items:
Held over:
Had some time to make a basic CSS Modules Script demo, including sharing CSS between light and shadow DOM contexts and put together a draft comment to suggest a slight tweak to the goal of the TPAC CSS Modules Breakout session. Not sure if I need to evangelize as much as I am here or just get right to the point, but figured it wouldn't hurt. ☺️
Let me know your thoughts and I can post there, or we can review first at our next planning session
Just wanted to get some thoughts on this session's description and goal
Session to discuss CSS modules and how they work with declarative shadow DOM: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md
Concrete proposal for CSS Module MVP
To my knowledge, CSS Module Scripts are already accepted as a web standard, building on top of Import Attributes and already implemented in Chrome, and having positive positions from both Webkit and Firefox.
I was wondering if this session could have two goals?
- Get implementor consensus on getting CSS Module Scripts (including Import Attributes) to the next available browser's baseline commitment
- With remaining time, explore the role CSS Module Scripts in Declarative Shadow DOM (or any other relevant topics)
I think advancing CSS Module Scripts would be an extremely valuable addition to the platform across all browsers, as managing CSS otherwise is often a pain point, often requiring some sort of build tooling to inline CSS into
<style>
tags within the<template>
of the Shadow Root or some other form of scripting to "adopt"<link>
tags into the<template>
.With CSS Module Scripts, at least for first party code, developers would have a standards compatible way to not only import CSS into their Web Components, but also to share styles across the Shadow and Shadow DOM.
I made a little demo repo you can check out if it helps, hosted here, which basically showcases a custom element importing a global "theme.css" in addition to its own component styles, highlighting the style sharing opportunities between light and shadow DOM.
import themeSheet from './theme.css' with { type: 'css' }; import componentSheet from './component.css' with { type: 'css' }; const template = document.createElement('template'); template.innerHTML = ` <h2>This should be blue and centered (theme.css)</h2> <h3>This should be red and centered (component.css)</h3> `; export default class SomeComponent extends HTMLElement { connectedCallback() { if (!this.shadowRoot) { this.attachShadow({ mode: 'open' }); this.shadowRoot.appendChild(template.content.cloneNode(true)); } this.shadowRoot.adoptedStyleSheets = [themeSheet, componentSheet ]; } } customElements.define('some-component', SomeComponent);
Hope this can be a consideration all browser vendors! ✌️
Starting the 18th or 19th of July, the Web Components Community Group will be hosting bi-weekly (one every two weeks) session for our preparation of 2024's "Web Components Spec/API status" report to the implementors gathered at TPAC. We'll keep this issue open while we continue meeting on a regular basis.
Join in the conversation!