Meeting minutes
<westbrook__> dom are you in person today?
<dom> I'm in TPAC (but not in the Web COmponents CG breakout)
<westbrook__> https://
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://
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://
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