-
Notifications
You must be signed in to change notification settings - Fork 21
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
Standards home? #32
Comments
I have a mild preference for keeping it standalone, since in my mind it is a separate entity. However, adding it into Streams would certainly be the shortest route to standardisation. |
It might be time to consider this more seriously now that this is shipping in both Chrome and Safari. |
Keeping it standalone seems reasonable. Not sure if it neatly fits into the scope of an existing Workstream. Probably worth asking the WHATWG SG for advice? |
Given the successful incubation, would be great to move this out of the WICG! 🎉 How can the @wicg/chairs help? |
I'm happy to try and get it adopted at WebPerfWG, if that works. |
Ok, cool. It's good to have options... for WebPerfWG, it would require a recharter, right? I wonder if going through the WHATWG might be less bureaucratic... 🤔 |
We're in the middle of a rechartering, so I don't think this is an issue. For WHATWG, are you thinking of creating a work stream for it? |
I would guess so (just going from what @annevk said above) - I'm not at all familiar with the WHATWG process for setting up a work stream, but I believe either Anne and Domenic should be. @CanonMukai, @ricea, @domenic, would be great to hear your preferences and opinions about venue. |
Thanks @marcoscaceres. I don't have a particular preference, so whichever way is less overhead is best. This spec doesn't require much attention, so any overhead is likely to form a large part of the work. |
This is now implemented in all three browser engines 🎉 If this goes to WebPerfWG, does it mean the official inclusion will happen after 2023-08-31 per the end date of the current extension in https://www.w3.org/2021/02/webperf.html ? |
Yeah, that would be the easiest. |
I think it would make more sense if compression streams lived in WhatWG, just like 'plain' streams live, and transform streams and encoding streams. |
I tend to agree with @smaug---- (and @annevk), as the WHATWG being the place where streams seem to live... and I guess also why I was looking to get @domenic's input too. @yoavweiss, any objections to just letting the WHATWG take it? Easiness aside, it seems like the logical home for it or is there some strong incentive to move it to WebPerf? |
If WHATWG is interested in creating a workstream for it, and @ricea is on board, I have no objections. (In that case, I would just ask for ricea@ to update the WG on future work, as the WG has a lot of interested consumers of this API, that can provide useful feedback IMO) |
Has there been some progress over this? This is staying here way too long given the implementation status, is there something we can help from our side? |
@yoavweiss Thoughts? |
As I said previously, I'd be happy to bring adoption to the WebPerfWG for discussion, but there seemed to be some desire for WHATWG adoption, at least at the time. Has that not materialized? |
whatwg/sg#231 will discuss about this. |
I think this can be considered done. #59 and whatwg/sg#231 track the remainder. Thanks everyone! |
Will this become part of Streams or do we create a new "top-level" compression standard somewhere?
The text was updated successfully, but these errors were encountered: