– DRAFT –
Web Components Community Group API and Specs Report 2022 - TPAC 2022 breakout

<westbrook__> dom are you in person today?

<dom> I'm in TPAC (but not in the Web COmponents CG breakout)

<westbrook__> https://w3c.github.io/webcomponents-cg/2022.html

westbrook: last year we presented a similar report at tpac for critical apis at the time

westbrook: but it was a small subset. based on feedback, we included everything but focused on a few

westbrook: centralized across several channels various apis

westbrook: browser parity is one issue. we've outlined 4 apis that have 2 impls

[ FACE, constructable stylesheets, css modules, imperative slots ]

westbrook: FACE allows custom elements to participate in forms

westbrook: constructable stylesheets allows to new a CSSStyleSheet, share styles across an app performantly

westbrook: css modules (assert type css) can create a custom stylesheet from a CSS file

westbrook: imperative slot, very recently safari put it in TP in 16.1

westbrook: these specs are much needed

leobalter: a browser compat matrix may help here to clarify

westbrook: +1

rego: there is an interop project asking for proposals. if these apis are important, should send them

westbrook: we're going to talk about specs that aren't as fully developed. definitely interested

<rego_> interop 2023 link: https://github.com/web-platform-tests/interop/tree/main/2023

westbrook: next up, not-so-complete specs, complications, early days. high-import specs that are incomplete. how to drive these

westbrook: cross-shadow-root aria. a11y with shadow roots is broken. there are workarounds but as of today most likely you create something inaccessible

westbrook: 2 specs, one by leobalter, another by me

westbrook: scoped registries - registering custom elements is currently on the global scope. register my-button a second time, it will throw an error

westbrook: scoped registries gives new registries. two registries can each have my-button. needed at scale at large companies

westbrook: only 2 or 3 sticking points, very close to agreement

westbrook: declarative shadow dom, already shipping in chrome but not yet fully agreed upon. SSR of custom elements and shadow doms within them

leobalter: overview of aria, w3c principles give priority to users then web authors, with custom elements I personally connect them to the web authors, good composition and encapsulation

leobalter: a11y is a main principle for the users. it should take priority

leobalter: basic example is button. you cannot connect the button to something outside of it

leobalter: we are already leveraging declarative shadow dom at salesforce, esp for b2c. we can test the chrome implementation and see perf gains

leobalter: 2 questions blocking SDS was perf. SDS vs imperative is already 1 to 1, no perf impact. in terms of servers and loading, there's an advantage

leobalter: other issue with DSD is scoped registries. we've identified polyfills, which impacts the priority. if there is a challenge, we'd prioritize DSD over scoped registries

justinfagnani: how useful is this work and this report for spec proposal and implementors. not sure how many browser implementors we have, but curious how to unblock

justinfagnani: we have some things with agreement, other things that are just vague concerns with no agreement. a lot has slowed down in the pandemic

justinfagnani: much left undone. shadow dom puts road blocks in the way of other features

justinfagnani: how can we move these things along faster?

caridy: we need to figure out how to move forward. it's self-organized, that doesn't seem to work. those proposals have been there for some time, no one is driving that. we're all busy

caridy: other models like ecma and tc39 with more cadence on meetings and getting implementors in the group. need to figure something out

caridy: so far it's frustrating

astearns: hard question. each item on list may need a diff solution for interop. first 4 items as interop 2023 is a good idea. all implementers will at least discuss. if they can find consensus that's a good push

astearns: that doesn't guarantee consensus. all of these except for aria have specs, have issue tracking. creating new ones, bring your experience with WCs to the standards group working on the spec

<astearns> nolanlawson: we had a discussion on this, cynthia has taken it up

<astearns> nolanlawson: starting a document going through the use cases

<astearns> nolanlawson: still in the ideation phase

leobalter: we sponsor igalia to try to tackle these a11y problems. we are early adopters of WCs. we use a synthetic shadow DOM which provides these a11y features. to roll out native shadow DOM, we cannot break a11y

leobalter: we had hopes with ID reflections, did some work, but identified some issues that prevented full a11y. the a11y provided is only partial. in this case we don't have a11y. it was not enough

leobalter: cross-root aria is now the bet

leobalter: both delegation and reflection which westbrook brought in, making it work both ways in the shadow root. this also works on the declarative form. on the path towards a declarative custom element

leobalter: can use low to no JS code

leobalter: you can connect things like you do in regular HTML

justinfagnani: who are we advocating to, and is that useful. any implementers who are here: is this useful work? should we be doing this?

justinfagnani: the report is a bit duplicative of the proposal threads themselves in github. report is a ToC and a ranking. we heard from chrome that the ranking is useful. but probably only at the very top

justinfagnani: at the bottom people don't have the bandwidth to care

<astearns> +1 to the top rankings being the most effective

justinfagnani: can we get feedback from implementors

emilio: prioritizing stuff is useful to know what to work on. not aware of issues with DSD and CSS modules. one issue with DSD is HTML parser and perf

emilio: addressing those concerns is most useful thing

justinfagnani: some things are at an impasse. don't know how to get past. perf in DSD, nobody is using it, it's chicken and egg

emilio: goog does this a lot, you ask for feedback from devs and partners. getting that data should have been done before shipping imo

emilio: I don't work on dom, I would love to take advantage of SSR. Things are at a stalemate or stalled. How can the CG help to unblock

^ should be justinfagnani, my bad

caridy: tc39 module harmony efforts, we got a bunch of proposals bucketed into a single group. move forward is get people in the same room

<westbrook__> reference for DSD questions, specifically: https://w3c.github.io/webcomponents-cg/2022.html#open-questions-8

leobalter: one good signal at tc39, we have stage 3 which means everyone in the room agrees it's ready to be implemented

leobalter: if we can have people in the room we can actually set a process

hober: what's tricky about applying tc39 is that these features are all over the place in different groups with different processes. difficult to say something in another channel

leobalter: we have 3 major browsers today. this works today at tc39. if anyone has one concern, this blocks that signal

leobalter: what the group is seeking is we're afraid we don't have signals

leobalter: all major browser vendors all have venues to provide signals. we have one for DSD. for webkit

hober: this report links to gecko and webkit's positions issues already. haven't seen report before, is useful to get a sense of prioritization from the community. if you had one wish this year, what would it be for

hober: in the browser parity section, it says support is not evenly distributed. my brain says, what are the gaps. is there a gap analysis. that is the doc I could bring to engineers

hober: this is just the introduction, there's more there?

westbrook: yes it has the status for the browser and in many cases we understand these are fairly large feature sets. we want deeper granularity. like FACE, which is built on ElementInternals

westbrook: putting element internals at the top would be disingenuous, no browser fully has it. we broke it up

westbrook: we raised these 4 because they are close to having full implementation. hard to sell gap analysis when firefox has something, when chrome has something vs when 2 have it

hober: where that could be effective is in the cases where the gap is small. ask one browser to fix 3 three things. 2 may be bugs, 1 is a feature, then we'd be at parity. I would love it as a browser engineer

hober: no one wants to do busywork. webkit doesn't need a 400 row table saying we don't implement things

justinfagnani: we talked about what are critical blockers, some would not be covered in gap analysis. bc we haven't gotten traction in spec discussions

justinfagnani: our users are saying we want to SSR web components for 10 years. our clients require having styles inherit into shadow. preventing people from using WCs. gap analysis useful for stuff we're close on. some things seem like obvious holes to the community. CG involvement interpreted as we personally care about this, but don't know if this is solving critical use cases. the CG can say that the community really cares [CUT]

owenbuckley: putting together this report, you get a sense of the history. some GH issues go back years, 100s of comments. we do our best to distill

owenbuckley: we tried to link to things to provide breadcrumbs. we as a CG can only go so far. would like to know how to better surface what you're looking for

astearns: leo suggested a browser compat matrix. that would help. green red matrix to drill down. if there are issues where the whole feature is not needed, breaking down the 10 things, 7 things are in chrome, 6 are in gecko, 3 are in webkit is even more useful than the grid

astearns: you can take interop's model to have a score for a given feature, calculated on your use cases

justinfagnani: only applies to things impl'ed in at least 1 browser

justinfagnani: we are prioritizing attention on the issue so it can be discussed and iterated on

astearns: constructable stylesheets looks close

westbrook: there are things that have specs that deserve that style, but there's also proposal-level work where need to find the right venue for conversations with implementers

westbrook: there's a good place for both of those things

<astearns> I confess I had not even noticed section 1.3

Alan_Davalos: the ToC has 20 different specs, many of which have at best partial at worst no spec defined yet. 2 different conversations

hober: observation on standards work: lots of specs that haven't been written that should be. some new features we should have, some that existed forever but not written down. some are punching bag jokes in tpac, e.g. hit testing spec.

hober: lack of engagement could just be the relevant people don't have the time. or switched jobs. no shortcut. but convos like these are one way to help. I have this problem frequently too

justinfagnani: we use to have f2f weeks which have been extremely productive. the world had other ideas. now the CG exists and can participate in f2fs. is it time to reboot those?

hober: we'd send somebody

kevinpschaaf: browser implementors are overtaxed, any forcing function, a regular sync with a cadence to keep momentum up. implementers: what cadence would implementors sustain to push forward on backlog?

kevinpschaaf: from the user's side we'll attend as frequently as possible if it means getting some attention and collaboration

leobalter: one thing that would be beneficial for the group would be specs that are blocked on impl concerns, challenging if implementors are not in the room

leobalter: we try to find ideas but all the responses have been negative

emilio: lots of edge cases in scoped registries. movement across the dom that can affect what CE are you effectively. another potential is prototyping in one engine and finding edge cases

justinfagnani: that is happening with scoped registries

emilio: i think open stylable shadow roots is a bad idea. what is the point of shadow dom if you don't get encapsulation

justinfagnani: users are asking for it every day

emilio: maybe they shouldn't be using shadow dom. or the component should expose shadow parts for people to style them. it depends

emilio: perf and implementability concerns, sometimes implementing it is a good way to find out maybe it's performant or maybe the concerns were right. all engines are open source today

leobalter: we are not c++ devs

leobalter: we have our partnership with igalia though

westbrook: thanks everyone. there's so much interest. having a f2f is a good takeaway