Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2025 Q1 Face-to-face #1083

Open
Westbrook opened this issue Nov 21, 2024 · 18 comments
Open

2025 Q1 Face-to-face #1083

Westbrook opened this issue Nov 21, 2024 · 18 comments

Comments

@Westbrook
Copy link
Collaborator

Westbrook commented Nov 21, 2024

👋🏼 Howdy everyone, hope you're having a great day, week, November, Q4, etc., etc.!

At TPAC 2023, the Web Components Community Group resolved with implementors to have a "Quarterly Face-to-face", and through out the course of 2024, we had some great sessions in Q1, Q2 and at TPAC, as evidenced by the amazing progress happening across a number of highly important APIs and features; like Reference Target, Scoped Registries, and :has-slotted, et al. Be sure to check through how we did on action items from those meetings in these issues:

If any of those actions items have your name on them...you now what to do 😉

Let's keep up the pace and come together to structure the work we'll be addressing in 2025 with out next face-to-face (virtually, unless other wise desired) in Q1.

👀 ACTION ITEM 👀
If the last week on January/first week of February works generally, I can share a when2meet here to gather more precise availability. Happy to take alternative suggestions if there are specific individual or professional requirements already placed on those two week. Look for a when2meet around the 6th of December if there isn't any major push back to this time frame.

Keep in mind, we've seen that a minimum of two separate two hour session are what's needed to be fully productive with the amount of work we're looking to do, so keep that in mind while sharing your availability.


At current, we have about two months to clarify agenda items for the discussion, so please share your desires in that area below. There may be some lingering questions around the APIs shared above, so we can definitely prioritize anything that remains in those areas by that point. Hot button issues that might be good places to start:

  • Declarative CSS Module scripts
  • DOM Parts
  • style and theme APIs
  • HTML Module scripts, or
  • Declarative Custom Element

Make sure to get your burning desires into a comment so we can have a proper agenda well before to prepare attendees for highest productivity.

@Westbrook
Copy link
Collaborator Author

Howdy all! 👋🏼

Here's the When2Meet for this session. Pleas share your availability over the course of these three weeks with the understanding that we'd be best served by AT LEAST two separate two hour sessions. 📆

Separately, the WCCG will be having a it's December meeting on Tuesday December 16 at 7pm ET if you want to get in on an early pass on any of these topics. The WCCG intends to also have a January meeting before the face-to-face to continue preparation, so keep an eye out on this calendar or in Discord for more information as it gets scheduled. 🗒️

@jpzwarte
Copy link

I would love for this to move along: "RESOLUTION: elementInternals.type='button' enables custom elements to get button-like semantics"

openui/open-ui#1088

@Westbrook
Copy link
Collaborator Author

@jpzwarte for the JS API outlined in the resolution, have you looked at adding any Web Platform Tests to support implementors in seeing the feature unfilled?

Other than raising this as a priority, are there remaining discussion points to work through?

@jpzwarte
Copy link

I haven't, but that is definitely something i can take a look at.

As far as open questions

  • How to do this declaratively, but i guess we need declarative CEs for that first
  • I don't know the process of OpenUI; does this need to move to WHATWG? Does it need "position issues" for every engine?

@Westbrook
Copy link
Collaborator Author

Right now the two session for this are looking like they will fall on February 7th and 14th at 1pm ET. If you don't like how that sounds, be sure to share you availability to this when2meet. I'll look to add these sessions to the calendar by the 10th of January at the latest, so look at have your availability in before by Monday or so.

@rniwa
Copy link
Collaborator

rniwa commented Jan 7, 2025

Isn't 2/14 Valentine's Day? It might make it harder for people in Europe to attend it if we schedule it at 1pm ET on 2/14.

@Westbrook
Copy link
Collaborator Author

@rniwa if you have some suggestions on people in Europe that we could tag in to ensure we get their availability included in the scheduling, please do! 🙇🏼‍♂️

It's difficult to speculative schedule, so working from what appears to be the best days/times from those who've shared their info to the when2meet feels like the best path forward.

@Westbrook
Copy link
Collaborator Author

I've added the events for February 7th and February 14th to the Web Components Community Group calendar. If you check this calendar out over the course of the month, you'll see that the WCCG is working through various proposals and features a number of times between now and the face-to-face, in case anyone wants to join in the preparations.

For the events, if you'd prefer a direct invite, feel free to contact me somewhere (Discord, Mastodon) with the email you'd like used for that. I've got access to professional grade Google Meet, so we can stay in one link for each session, I'll add that a little closer to the event.

Let's try to and gather a more complete agenda/schedule by the 31st, if we can. So far the WCCG has reviewed the following for deeper conversations:

  • Scoped Element Registries and the updated proposal from Apple
  • Reference Target and the outstanding questions from Microsoft
  • :has-slotted and the recent "resolution" on this from the CSSWG

Please comment here, or join one of the work session in preparation for the face-to-face to share out additional topics we can all be prepared to discuss.

@annevk
Copy link
Collaborator

annevk commented Jan 20, 2025

I can't make it the 7th. The 14th I could do, but 7PM to 9PM on a Friday is pretty far from ideal. I'll probably just do the first hour again.

@Westbrook
Copy link
Collaborator Author

@annevk if you were also able to share you availability to https://www.when2meet.com/?27975110-QRLAz, we can see if other times become opportune. Are there other members of your team that will be able to represent in your absence?

@annevk
Copy link
Collaborator

annevk commented Jan 21, 2025

Ah thank you, when I initially looked at that I didn't realize one could use it without account. It's filled in now.

@rniwa
Copy link
Collaborator

rniwa commented Jan 31, 2025

Hi, Is this still happening? If so, when?

@Westbrook
Copy link
Collaborator Author

Westbrook commented Jan 31, 2025

Yes. Please see: #1083 (comment) The WCCG is meeting this morning and we will have proposed agenda available shortly there after.

@Westbrook Westbrook pinned this issue Jan 31, 2025
@bkardell
Copy link

@Westbrook that link is to an availability poll? If it is also a meeting link, or possible to get one from it - I do not understand.

@Westbrook
Copy link
Collaborator Author

Sorry, updated the link.

Pertinent info:

I've added the events for February 7th and February 14th to the Web Components Community Group calendar. If you check this calendar out over the course of the month, you'll see that the WCCG is working through various proposals and features a number of times between now and the face-to-face, in case anyone wants to join in the preparations.

@Westbrook
Copy link
Collaborator Author

Westbrook commented Jan 31, 2025

Proposed agenda for the next two weeks, happy to take notes on availability, importance, and of course anything that I've missed. I'll be working on getting links to relevant GitHub issue, etc. as well, see keep an eye out for changes to this comment.

Feb 7

  1. [5 minutes] Celebrating the 2023 report
  2. [20 minutes] @sheet
  3. [20 minutes] Declarative CSS Module Scripts
  4. [30 minutes] styling
  5. [30 minutes] theming
  6. Overflow? Likely not. Most likely things fall into the next week.

Time: [105 minutes] + [5 minute break]


Feb 14

  1. [25 minutes] Reference target
  2. [20 minutes] Scoped Registries ongoing questions
  3. [20 minutes] :has-slotted(...) & /slotted/
  4. [30 minutes] HTML Module Scripts
  5. Overflow? Possibly, depends on what holds over from session no. 1

Time: [95 minutes] + [5 minute break]

@Westbrook
Copy link
Collaborator Author

Today's joining information for anyone having issues with the calendar:

To join the video meeting, click this link: https://meet.google.com/fam-igtc-yft
Otherwise, to join by phone, dial +1 530-738-1393 and enter this PIN: 124 266 666#
To view more phone numbers, click this link: https://tel.meet/fam-igtc-yft?hs=5

@Westbrook
Copy link
Collaborator Author

Westbrook commented Feb 7, 2025

Great session today! Thanks you so much for everyone who was able to make time to join in the conversation. 🙇‍♂

Notes from today's session are available here.

Action Items:

  • @sheet: @KurtCattiSchmidt to process feedback from the conversation into issues
  • Declarative CSS Module Scripts: @KurtCattiSchmidt to process feedback from the conversation into issues
  • Adopting non-Constructed StyleSheets:
    • @sorvell to prepare cross document testing of the feature
    • continued testing of the Firefox Nighty implementations
  • Expanding export parts: @sorvell to process feedback into the next round of discussion
  • :host(:has(...)) and :host:has(...)
    • should we expand or contract this unspecified functionality?
    • @justinfagnani to share some recent use cases to help clarify the benefits of each for implementors
    • @rniwa, @smaug---- and (maybe) @kbabbitt to get insight from there respective teams if there are any blockers to expanding the spec to include this
  • Everyone is asked to review Shadow DOM mode as opt-in feature flags #1049 to see if it is worth developers spending time on thinking through before the Q2 face-to-face for deeper exploration

See you all next week for even more great discussion! 👋🏼

Session chat hidden within...
You
12:59 PM
https://docs.google.com/document/d/1yfYARhuobQb3lKOGYLhD1D6NlVEYvel-RBzA-mjAPT4/edit?tab=t.0#heading=h.8cs25bxv3n61
keep
Pinned
Kurt Catti-Schmidt
1:09 PM
https://docs.google.com/presentation/d/1OUr5IYQ-t4jlqPCalkTG55e8SHbkXTGCeIqv1uR1dyA/edit#slide=id.p
Dan Clark
1:13 PM
nit: the `assert` keyword is now `with` :)
Rob Eisenberg
1:15 PM
Hate to bike shed too much, but what about an "import" attribute instead of "sheet" to use existing terminology and make things a bit more extensible for other link types in the future.
Andy Luhrs
1:16 PM
Definitely could make sense once we stabilize direction a bit
Mayank
1:17 PM
The advantage of "sheet.css#sheet1" is that it avoids introducing new API. It's "just" a URL.
Justin Fagnani
1:18 PM
right, but that still leaves the question of how to reference a sheet from an inline style
Rob Eisenberg
1:18 PM
It seems as if there are two proposals, but frankly the first one should be rejected because it doesn't meet the requirements. So, really only the sheet attr meets all the requirements.
Justin Fagnani
1:24 PM
and what about nested @sheet? Is nesting disallowed?
Justin Fagnani
1:25 PM
IMO, we shouldn't talk about "the global sheet" we have multiple nested scopes. What works "globally" should work the same in a shadow root
Mayank
1:27 PM
Lifting the `constructed` limitation on `adoptedStyleSheets` also implies allowing `@import`, no?
You
1:27 PM
👆 great added case for testing the change Keith is working on to remove that in Firefox as of late.
Justin Fagnani
1:28 PM
not directly, I don't think. The big question was whether @import from within an constructed stylesheet created a new stylesheet object or reused a shared object
^ re: Mayank
Pascal Vos
1:29 PM
i wonder if with custom elements will start streaming css in to one file
SRR wise
Mayank
1:30 PM
`<link rel layer>` is being proposed.
Mayank
1:32 PM
I would love for CSS modules to export mixins, functions, keyframes, properties, sheets, etc. A lot of these are more relevant for CSS than for JS.
Jochen Kühner
1:34 PM
maybe we need levels in the javascript export like { sheets: ..., classes: .... }, so they are not directly on the object
Rob Eisenberg
1:36 PM
Well, especially when we get functions, combined with properties, we're talking about all the same things that JS needs.
So, some sort of generic way to export things from a .css file and some way to generically import/apply any of those things in a variety of contexts.
Mayank
1:39 PM
The advantage over named `{ sheet1 }` import over `default.sheet1` needs to be justified.
s/over/of
Rob Eisenberg
1:41 PM
I think making exports explicit is something we should definitely consider. +100
Pascal Vos
1:41 PM
react has a lot of librarys like styled-components that uses importing class i think i remember there are others as well already in userland
Mayank
1:43 PM
Re: layer attribute on link, here's the proposal: https://css.oddbird.net/layers/link-layer/
Justin Fagnani
1:45 PM
I think the TAG was just wrong on this point though. Might be worth going back to them on it.
Rob Eisenberg
1:46 PM
I think tag was wrong in focusing on @sheet. It should be focusing on the general problem of export/import. Wiht that in place, we can have an HTML syntax that will work for not only css but js, wasm, and html as well.
Rob Eisenberg
1:51 PM
+1 to what Justin is saying. Need to consider how a server will actually work when streaming nested component trees.
Pascal Vos
1:52 PM
would scoping to CE scoped registry make  sense?
Rob Eisenberg
1:54 PM
I think we need to consider that all this should be usable independent of custom elements.
Justin Fagnani
1:54 PM
it needs to be global
Justin Fagnani
1:56 PM
<link> doesn't help here because in order to not have many network requests you need to href the same file, but you don't know the contents of the file yet as you're streaming
Pascal Vos
1:56 PM
would this also work with ShadowRealm ? cause it got seperated vm then right like iframe
Mayank
1:57 PM
Kurt was describing `<link rel="stylesheet" href="#style-element">` earlier, which should help with streaming.
re: Justin
Justin Fagnani
1:57 PM
<script> would usually be tool output. Humans wouldn't write styles that way
Mayank
2:00 PM
Not everyone uses tooling.
Rob Eisenberg
2:00 PM
I know that adding new tags to html are difficult, but what about having a <module> element with a type attr. And then having an <import> element to import from any type of module?
You
2:00 PM
is="sheet"?
Dan Clark
2:00 PM
We should think ahead to declarative HTML modules scripts too. Would we write those in a <script> tag too? IMO it would be a lot nicer for it to be a <template>.
Mayank
2:01 PM
<template> makes a lot of sense.
Justin Fagnani
2:01 PM
it doesn't to me
Pascal Vos
2:01 PM
why not put style tag in a template?
Justin Fagnani
2:01 PM
you're not instantiating a HTML module times
*multiple times
Pascal Vos
2:01 PM
<style-template?
Dan Clark
2:02 PM
I think the case where you'd want to instantiate an HTML module a bunch of times is if you have multiple instances of a component with a shadow DOM. You'd want to define the HTML module in one place, then include it into each component's shadow somehow.
Mayank
2:02 PM
(I write DSD by hand all the time)
Danny Blue
2:02 PM
And there are uses for it outside of web components which means they are outside of tooling
or your SSR would be handled by something like liquid or handlebars or something which will need to have the tags themselves
Pascal Vos
2:03 PM
you could stream css in to a css file i guess and add it by sheet..
Steve Orvell
2:04 PM
Don't mean to pile on Kurt: super happy to have you and M$ working on this!
Olli Pettay
2:06 PM
Browsers cache the parsed stylesheets in case of same-origin page loads.  No need to even parse anything
...when loading a new page. Just do basically a hashtable lookup
Justin Fagnani
2:08 PM
https://github.com/w3c/csswg-drafts/issues/3714
Pascal Vos
2:08 PM
yes
Dan Clark
2:11 PM
That's what I was going to ask :)
Kurt Catti-Schmidt
2:12 PM
https://github.com/w3c/csswg-drafts/issues/10013
Kurt Catti-Schmidt
2:16 PM
https://web.dev/articles/css-module-scripts#import_rules_not_yet_allowed
Justin Fagnani
2:17 PM
https://github.com/w3c/csswg-drafts/issues/6130 is relevant
You
2:17 PM
🙇‍♂️
Mayank
2:19 PM
constructed ≠ adopted
You
2:20 PM
Great point!
Mayank
2:23 PM
StyleSheetObserver issue might be relevant to the contructed discussion: https://github.com/WICG/webcomponents/issues/1041
Jochen Kühner
2:24 PM
Does the cross document case work at the moment with JS created adopted Stylesheets?
At the moment I need to clone them in chrome manualy
Pascal Vos
2:28 PM
probably if you want to use astrix people would also want regex like things here
^startswith-*
You
2:32 PM
Possibly related microsyntax discussion? https://lea.verou.me/specs/var-groups/
Jochen Kühner
2:32 PM
maybe the * should only match at the end at a first draft, otherwise the comparison would be much complexer and slower
Pascal Vos
2:42 PM
this is tree up, there not a better way to think of style tree down somehow
Jochen Kühner
2:47 PM
now we see someone using the tooling only syntax in a demo ;-)
Steve Orvell
2:47 PM
Great explanation Westbrook
Justin Fagnani
2:49 PM
re @sheet and what's exported, I updated some thoughts on the CSS Reference Selector issue that maybe we want to use at-rules for references insteadL: https://github.com/w3c/csswg-drafts/issues/3714#issuecomment-2643886033
You
3:01 PM
https://github.com/WICG/webcomponents/issues/1049
Steve Orvell
3:02 PM
Homework for implementers...

appetite for 
1. decomposing shsaodw DOM
2. exposing the shadow tree as Lea proposed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants