Notes from 17th August open eng meeting

[AndrewJakubowicz]

If you want to attend future meetings, they're held every Thursday at 9am PST. The invite is is shared in https://lit.dev/discord

Below are the raw notes from the meeting today.

Topic: SSR compatibility for lit-labs/context

Speaker: Vladislav

Discussed the following open PRs: #4091 and #4082.
Amazing work and thank you!

Next steps: When [labs/ssr] Context support via Event.composedPath() shim is ready for review please ping in the Discord chat so it's not missed.

Topic: Scoped elements & disabled attribute

Speaker: Michael

Discussed: webcomponents/polyfills#547

The crux of the issue is the following native behavior:

A web component cannot be focused if the following are all true:

• It is formAssociated.
• It has a disabled attribute.
• tabindex is 0.

Example: https://lit.dev/playground/#gist=9d496c1c10fa04b195db39df45c180d7

This is an issue for users of the scoped custom elements polyfill because it is not possible to set formAssociated on a per element basis, because there is only one chance at defining formAssociated, and that is when the browser registers the custom element.

The blocked use–case is:

• A menu-item component that can be disabled, but should still be focusable as per the recommended pattern, that is also using the scoped-custom-element-registry polyfill which automatically sets formAssociated to true.

Two plans considered:

1. Review fix(scoped-custom-element-registry): resolve formAssociated getter fr… webcomponents/polyfills#548 which allows the first element with a tag name to set the formAssociated property. All later elements will be stuck with whatever the first element set. This may be the only option even though it's still not ideal behavior.
2. Find some hack to allow focus when the conditions above are met, and document or integrate that hack into the polyfill.

Standard decorators update & open questions

Speaker: Justin

Related RFC: lit/rfcs#20
Related PR: #3982

Getting close! What is interesting is that standard decorators let you override the get/set for an auto accessor field. The decorator initializer also goes through a separate codepath – through a callback called init.

A current behavior in Lit is that if you create a set accessor, then reactive properties will require you to call requestUpdate. With standard decorators it's much easier to wrap user-accessors and call requestUpdate after them.

Do we want to change the behavior to auto-wrap? Looking for feedback and use-cases where users are intentionally creating a setter to avoid a requestUpdate being queued.

Otherwise we probably want to make sure this change has an escape hatch to turn off requestUpdate.

The other open question is around providing default values & the memory concern. It was raised that a default value which is sufficiently complex could result in memory being held which is not ideal.

Justin/Peter/Steve to discuss more on the implementation.

Topic: Signals update

Signals package is in great shape and has landed: #3879

This adds a @lit-labs/preact-signals package with:

• A SignalWatcher mixin that automatically observes signal access from within a ReactiveElement and re-renders the element when used signals change.
• A watch() directive that directly updates a DOM binding when a signal changes, but doesn't re-render the whole element.
• html and svg template tags that automatically apply the watch() directive to signals passed to templates.

Slotted combinator update

Speaker: Elliott

There is progress on a slotted combinator. Reference: w3c/csswg-drafts#7922

Provides a way to fix the following:

• No way to get slotted elements with querySelector()
• No ability to target descendants (see also)
• No ability to target siblings
• No ability to target pseudo-elements

Topic: RFCs

For advancing open RFC's (Compiler, Standard Decorators, Signals) decided to schedule an open RFC meeting on Tuesday, 22nd of August at 11am PT. Event will be posted on Discord.

RFCs repo: https://github.com/lit/rfcs

Thank you so much everyone!

[bennypowers]

Exciting stuff! Slotted combinator + DSD already solves so many problems! Being able to SSR context would also be a huge advantage.