More details about Proposed Correction 1, courtesy of @svgeesus

MQ3 is a W3C Recommendation, published 05 April 2022 with one proposed correction
https://www.w3.org/TR/mediaqueries-3/#changes-2012

An AC review was held 2022-04-05 to 2022-06-06 with 6 in support, one not supporting, and one abstention. No formal objections.
https://www.w3.org/2002/09/wbs/33280/mediaqueries-3-proposedcorrections-2022/results

The not supporting response gave the following rationale:

It is left as an exercise for the reviewer to determine how the tests provided cover the questions asked.

Apparently the Working Group couldn't manage to run the set of tests they have in Firefox, meaning the test results didn't provide sufficient information to show the criteria they set were satisfied.

There are still tests that do not seem to be passed by any browser, and tests for which it is possible that the reason for passing is not a correct implementation.

This work doesn't seem to reach the level of quality necessary. Being a small amount of work, it's probably close, but there is insufficient explanation and too much left to the reader to confidently provide support.

I answered this on 7 April 2022, copying w3c-archive
https://lists.w3.org/Archives/Member/w3c-archive/2022Apr/0117.html

In response, Chaals withdrew his informal objection
https://lists.w3.org/Archives/Member/w3c-archive/2022Apr/0118.html

and I clarified the Implementation Experience part of the WBS for the benefit of other AC reps.
https://lists.w3.org/Archives/Member/w3c-archive/2022Apr/0127.html

So we are all sorted from the AC review and Implementation Report points of view.
https://wpt.fyi/results/css/mediaqueries?label=experimental&label=master&aligned&q=mq-invalid-media-type

@astearns I feel this could easily be an async decision?

It also has one candidate correction.

Not, on /TR, but it is in the ED

@frivoal so that ED is all ready to go, once we have a WG resolution?

The CSSWG will automatically accept these resolutions one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support these resolution, please add a new comment.

Proposed Resolution: Edit in Proposed correction 1 to Media Queries level 3
Proposed Resolution: Upgrade Candidate correction 2 to Proposed Correction
Proposed Resolution: Republish Media Queries level 3 with those two edits

RESOLVED: Edit in Proposed correction 1 to Media Queries level 3
RESOLVED: Upgrade Candidate correction 2 to Proposed Correction
RESOLVED: Republish Media Queries level 3 with those two edits

@frivoal do you want to make the substantive edits, then ping me to do the publication?

@svgeesus I have:

• folded Proposed Correction 1 in place
• marked Candidate Correction 2 as Proposed
• Updated the changes Section
• Made a disposition of comments and linked to it from the headers
• Updated the implementation report to cover the implementation status of Proposed Correction 2
• Updated the headers to point to the updated implementation report
• Updated the reference to the current Process
• Bumped the date

As you may remember from #6962, this spec no longer has source to be generated from, and the edits must be manually done in the html. The text that's needed to change it from an ED to a REC is in the document, commented out. I hope the latest pubrules won't be demanding too many changes.

Can you take it from here?

Once the REC is republished (and has a date and a URL), I can update the implementation report to talk about the Proposed Correction 2 as being in the REC, rather than in the ED that wants to become a REC.

To later fold it it, we'll still be missing wide review on that change before we can submit an update request. There isn't much to review though, the change is pretty minimal: I wonder how extensive a review the Team would expect on this.

Note: the DoC lists one open issue (#5437), but that's not blocking because the Process says:

When publishing an updated version of an existing Candidate Recommendation or Recommendation, technical reports are expected to meet the same maturity criteria as when they are first published under that status. However, in the interest of replacing stale documents with improved ones in a timely manner, if flaws have been discovered in the technical report after its initial publication as a CR or REC that would have been severe enough to reject that publication had they be known in time, it is also permissible to publish an updated CR or REC following the usual process, even if only some of these flaws have been satisfactorily addressed.

Thanks, @frivoal there were only a few changes needed.

Publication requested 14 May, expected 16 May.

https://www.w3.org/TR/2024/REC-mediaqueries-3-20240516/Overview.html

The transition requirements mentions a review form, but does not say what it contains. There is no template, and the template for AC review of a Proposed Rec was not a good fit. I'm asking what is needed here.

REC Update Request raised 14 May

REC update request was approved, but now I need to re-date the spec to have two days notice to webmasters.

Also, @plehegar said

In addition, please consider using HTML and DOM LS for the 2 following references to the HTML specification:

https://www.w3.org/TR/1999/REC-html401-19991224/present/styles.html
https://www.w3.org/TR/1999/REC-html401-19991224/types.html

@frivoal the updated doc is at
https://www.w3.org/TR/2024/REC-mediaqueries-3-20240521/

this includes a fix to the TOC, the most recent changes entry was pointing at the wrong changes section.

Do you want the two references above updated to latest? It was a suggestion not a blocker.

this includes a fix to the TOC

thanks. Now fixed in the source: 607e8e0

Do you want the two references above updated to latest?

They are used to refer to what the HTML 4 spec said about what then-future features should do, and it serves as historical background for this spec, so I think it should stay as is.

• Updated the implementation report to cover the implementation status of Proposed Correction 2

The report about the status of the old PC1 could usefully be updated to show Safari passing, see wpt.fyi

Once the REC is republished (and has a date and a URL), I can update the implementation report to talk about the Proposed Correction 2 as being in the REC, rather than in the ED that wants to become a REC.

Sure, the date will be 21 May 2024

To later fold it it, we'll still be missing wide review on that change before we can submit an update request. There isn't much to review though, the change is pretty minimal: I wonder how extensive a review the Team would expect on this.

The update request has been made, and granted. I'm making the WBS for the Last Call. The process is the same for a one-word correction as for anything larger, of course.