[css-contain-1] Pubrules issues with the 2020 Rec text

[svgeesus]

@frivoal @deniak @plehegar

The checker complains as follows:

Errata paragraph not found.

The checker is correct here. All W3C Recommendations must have an errata link, which is a blank document when first published. I can make one, so this is an easy fix, although @tabatkins the CSS WG Rec boilerplate should be corrected to include this paragraph so it doesn't have to be added manually to the generated output each time.

Unless there is a choice of either errata or candidate corrections, in which case the checker needs to be updated. Process Document seems to treat these as equivalent:

When annotated inline, errata—including their candidate corrections—must be marked as such

This document doesn't contain substantive changes, paragraph 
<p class="correction">Proposed corrections are marked in the document.</p> should be removed.

Modifications in W3C Recommendation are divided into "new features" and "changes". 
Recommendations with modifications must include the following paragraphs depending 
on the changes.

For substantive changes, there should be a paragraph with class="correction":

    Proposed corrections are marked in the document.

<p class="correction">Proposed corrections are marked in the document.</p>

For new features, there should be a paragraph with class="addition":

    Proposed additions are marked in the document.

<p class="addition">Proposed additions are marked in the document.</p>

I suspect the checker is misled by not finding the exact paragraph "This document was published by the @@ Working Group as a Recommendation. It includes proposed corrections" which is why it asks for the separate paragraph to be removed.

I think the checker is wrong, because the process document uses the term candidate corrections, as does the 2020 Rec text for Contain 1, while the checker seems to want proposed corrections. Thus, I believe the checker is wrong and should be updated to match the term used in the Process Document.

Cannot find the paragraph introducing document type and publisher in Status of This Document.
W3C Recommendation must include one of the four paragraphs below in the
 "Status Of This Document" depending on the type of Recommendations:

    This document was published by the @@ Working Group as a Recommendation.

Recommendation with proposed changes:

    This document was published by the @@ Working Group as a Recommendation. It includes 
    proposed corrections

Recommendation with new features:

    This document was published by the @@ Working Group as a Recommendation. It includes 
   proposed addition, introducing new features since the Previous Recommendation.

Recommendation with proposed changes and new features:

    This document was published by the @@ Working Group as a Recommendation. It includes 
    proposed changes, introducing substantive changes and new features since the 
    Previous Recommendation.

Include one of these source codes:
<p>This document was published by the @@ Working Group as a Recommendation.</p>
<p>This document was published by the @@ Working Group as a Recommendation. This document was published by the @@ Working Group as a Recommendation. It includes <a href="https://www.w3.org/2020/Process-20200915/#proposed-correction">proposed corrections</a>.</p>
<p>This document was published by the @@ Working Group as a Recommendation. This document was published by the @@ Working Group as a Recommendation. It includes <a href="https://www.w3.org/2020/Process-20200915/#proposed-addition">proposed addition</a>, introducing new features since the Previous Recommendation.</p>
<p>This document was published by the @@ Working Group as a Recommendation. This document was published by the @@ Working Group as a Recommendation. It includes <a href="https://www.w3.org/2020/Process-20200915/#proposed-changes">proposed changes</a>, introducing substantive changes and new features since the Previous Recommendation.</p>

Note that, except for existing Recommendations, the checker wants a duplicate paragraph. This should also be corrected.

Besides the insistence on the term proposed corrections as noted above, the checker wants the "This document was published " paragraph to also have the corrections note.

That is an easy fix to do, but rather buries the lede, and personally I prefer the way @frivoal did it with a separate paragraph that is styled the same as the corrections themselves.

I'm fairly sure that the precise form of wording that the checker asks for is not mandated by the Process Document, particularly since it contains grammatical errors both in the explanation and the checker-mandated paragraphs. These should be corrected, for example

This document was published by the @@ Working Group as a Recommendation. It includes
proposed additions, introducing new features since the Previous Recommendation.

or, even better

This document was published by the @@ Working Group as a Recommendation. It includes
candidate additions, introducing new features since the Previous Recommendation.

[svgeesus]

Oh, I just noticed that the "proposed correction" link in the mandated text is a broken fragment, while https://www.w3.org/2020/Process-20200915/#candidate-correction resolves correctly. I'm guessing the Process Document changed the term and the checker was written based on an earlier draft.

The perils of bikeshedding which breaks early implementations!

[plehegar]

I believe your document should not contain a link to an errata page, w3c/specberus#1076 .

The pubrules got confused and believed your document contained proposed corrections while it only contains candidate corrections (the CSS classes got modified recently), w3c/specberus#1077 .

[plehegar]

Oh, I just noticed that the "proposed correction" link in the mandated text is a broken fragment, while https://www.w3.org/2020/Process-20200915/#candidate-correction resolves correctly. I'm guessing the Process Document changed the term and the checker was written based on an earlier draft.

The perils of bikeshedding which breaks early implementations!

actually, the link should be
https://www.w3.org/2020/Process-20200915/#proposed-additions

w3c/specberus#1078

[frivoal]

https://www.w3.org/2020/Process-20200915/#errata

Working Groups decide how to document errata. Such documentation must identify the affected technical report text and describe the error; it may also describe some possible solution(s). Readers of the technical report should be able easily to find and see the errata that apply to that specific technical report with their associated tests. Errata may be documented in a separate errata page or tracking system. They may, in addition or alternatively, be annotated inline alongside the affected technical report text or at the start or end of the most relevant section(s).

Thus, errata must indeed be maintained, but the WG now has a choice about how to do so, and inline in the spec is an acceptable way of doing it.

I think the checker is wrong, because the process document uses the term candidate corrections, as does the 2020 Rec text for Contain 1, while the checker seems to want proposed corrections. Thus, I believe the checker is wrong and should be updated to match the term used in the Process Document.

Agreed. the process now recognizes both candidate and proposed corrections (as different stages of the same thing), and the checker should allow both.

I'm fairly sure that the precise form of wording that the checker asks for is not mandated by the Process Document

Indeed it doesn't. I'll let the team figure out precisely what wording you want to allow and how you want to check for it, but the Process is not the constraining factor here.

[svgeesus]

CSS 2020 was accepted for publication, and PLH said no changes are needed, so I believe we are all good and the checker errors will be fixed.