Meeting minutes
<JaseW> https://
<JaseW> Slides ^
Slideset: https://
(see https://
<JaseW> dom: 2 points, one with the transition of W3C to Ecma, I think at least there is some good hopes to move forward. more generally speaking we're seeing several spaces where this can be looked at, another area relevant to WinterCG is isolated web apps, you mentioned sockets API, there is a proposal for direct sockets? API which in many ways gets browsers closer to some of the requirements to serverside environments. Theres questions on how do
<JaseW> we maintain convergence for the web, and the questions you were asking there's replies to many of these situations.
andreubotella: curious to hear about the CG transition idea you were suggesting
andreubotella: I'm not familiar with Isolated Web Apps, that sounds worth exploring
JaseW: moving to ECMA, is this a new committee?
Samina: TGs (technical groups) are under a Technical Committee (TC); this makes more sense as a group of its own
Aki: TC53 is doing ES for embedded devices is also independent as a precedent
JaseW: I noticed the CLI API; any chance of looking at unifying a testing API
andreubotella: I don't see why not
andreubotella: someone would have to come up with a proposal
MikeS: re working better with upstream - the scariest thing is moneky patching, even when temporary
… even worse if it gets semi-permanent
… we wouldn't want to see monkey patching as a basis for a process
… filing spec issues is the best way to work with upstream, starting from problem description
<igarashi> +1
MikeS: I think we could do this in W3C - not sure the resistance to doing it are necessarily valid; in particular, I think W3C would welcome it
… I'm not sure I understand the IPR RF commitments issues
… given that this is listing specs that are already having RF commitments, and is unlikely to need additional commitments
… most of these features are WHATWG features with a few exceptions
andreubotella: re needing additional commitments, given resistance from W3C members due to that IPR transition
… re monkey patching, we've moved away from e.g. forking the fetch spec
andreubotella: our main concern when contributing to upstream is resistance against adding things that aren't targeting browsers
mikeS: has that happened already?
andreubotella: it isn't that this is getting shut down, but is getting deprioritized if it doesn't affect browsers
… but you're right we should pursue that path until it gets blocked
mikeS: not getting enough consideration is not limited to this particular space
Yoav: there is a spectrum of "badness", forking is worse than monkey patching
… for things that aren't browser problems, what we need is hooks to allow building downstreams specs
… the main challenge of monkey patching is keeping up downstream with upstream changes
… We need some high level agreements from WHATWG editors that hooks are OK for non-browser needs
andreubotella: we might need flags to skip some non-relevant steps
yoav: we want to avoid overcomplexifying the browser specs, but allow downstream specs
anssik: what is your experience with aligning non-browser runtime? do you get disagreements between non-browser runtimes?
andreubotella: we do get some disagreements, e.g. how timeouts get handled
… part of it is recognizing legacy situations
anssik: is WinterCG the forum where these disagreements are discussed?
andreubotella: part of is is that each community/project may have different ways of expressing their engine viedws
sisidovski: many of the engine runtimes are running on the serverworker interface; is there a minimum common Web APi for the ServiceWorker surface itself?
andreubotella: some of the runtimes use directly the ServiceWorker API, some don't
… it would be interesting if changes to the serviceworker API could affect runtimes
… one of the things we're starting to look at is to define a server handler function for that
… it might be interesting to work with SW on that
gsnedders: you mentioned feeling blown off when filing issues upstream: how much was that getting "we don't care" responses, vs not getting people to work on your problem?
… if the latter, this is likely a mismatch of priorities, not a refusal to see the work done
andreubotella: e.g. the getSetCookie API doesn't have very obvious browser use cases
… server side runtimes would greatly benefit from it
… but I had to find a browser use case to justify the addition to the spec instead of the main use case that was driving the work
… and there are likely cases without justification in browsers
… and I ended up doing the browser implementation
… the runtime implementation was seen as not sufficient
mnot: I don't agree that we can't ask the community to block on the upstream community willingness to move
… browsers control WHATWG and have strong influence on W3C
… having a clear high level agreement feels like a useful prerequisite