Re: [w3ctag/design-reviews] Other Spec Review: Extend CSP script-src hashes (Issue #1128)

toreini left a comment (w3ctag/design-reviews#1128)

Dear @carlosjoan91 and @meacer,

The document follows a familiar explainer pattern. This makes it consistent with other W3C/WICG explainers. However, some sections mix specification-level detail (precise directive semantics) with explainer-level narrative (use cases, goals). This makes the explainer confused between being an explainer and a spec draft. TAG endorses the conversations with relevant WG (https://github.com/w3c/webappsec-csp/pull/784#issuecomment-3221267545). We encourage the spec authors should always have a conversation in the target WG early on.

### The Proposed Solution

The Proposed Solution section is quite long and could benefit from some editing. We understand all these four techniques are parts of the solution; however, developers will choose any number of them depending on their situation, so the explainer needs to summarise the areas of coverage of each parts to help them decide effectively. TAG believes this section would benefit from:

* Clarifying that all parts of the proposed solutions are being specified as they all have use. This makes it cleared to the reader/developers that they are not alternatives.
* Including a table/diagram to provide the summary discussed above, so that developers can pick the appropriate combination of the four approaches for their situation.

### Backwards compatibility and Considered Alternatives

The way I read the explainer, this section proposes another two solutions for backward compatibility, but it was not clear on the first reading. If that is correct...

The way the section `Backwards compatibility` is written, it is essentially a `considered alternative` section. So, the two sections should be combined as a single `Considered Alternatives` section.  

Moreover, `Considered alternatives` section is informative and good, but it could benefit from cleared structure such as: Alternative → Pros → Cons → Reason for rejection. That makes the reasoning more transparent to external reviewers.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1128#issuecomment-3460430604
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1128/3460430604@github.com>