Add some information for authors about the intent of the spec

[robinwhittleton]

As discussed in #102, this adds additional non-normative information to help authors understand the point of the specification. This primarily takes the form of an extra paragraph in the introduction, and new “Authoring Considerations” section (inspiration from the CSP3 spec for that name). I’ve also added version numbers to all of the example URLs given, apart from the hello-world example.

As well as that, I’ve made one normative change. It doesn’t change the intent, but changes a will to a MUST when discussing the expected behaviour of user agents when a hash fails to match. I believe this doesn’t require new web platform tests for that reason.

I’ve also tidied up a few double spaces I found, some of which were user visible.

This is, I think, my second PR to a W3C document, and I’m not sure I fully understand the licensing / patent exemption documents. But I’m happy to state here that I disclaim all patents and grant a permanent licence to include the contents of this PR into the SRI spec. If more needs to be done then perhaps someone can help me through the process?

---

💥 Error: 500 Internal Server Error 💥

PR Preview failed to build. (Last tried on Aug 9, 2021, 11:14 AM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 CSS Spec Preprocessor - CSS Spec Preprocessor is the web service used to build Bikeshed specs.

🔗 Related URL

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

[mozfreddyb]

this looks great, I think it's pretty close :)

[mozfreddyb]

Looks good to me.
@mikewest did you want to take another look?

[mikewest]

@mikewest did you want to take another look?

I've been OOO for a while, apologies for the delay. I'm happy to defer to your review, Freddy! Land it if you're happy. :)

[mozfreddyb]

@samuelweiler I'm leaning towards marking this a "non-substantive" change and waive through, but I am not entirely sure.
Here's my thinking:

• the added section is non-normative
• the remaining changes are nits
• neither of those change would lead to any of the implementing browsers to change their behavior

The only change we expect is that more websites which use SRI are more likely to look for error events on failing script loads.
Ideally, most websites already do that, but we're adding that section to be more explicit.

Looking forward to your guidance.

[mozfreddyb]

@samuelweiler Can you help answer the question above? I'm arguing this is a non-substantive enhancement and want someone else to weigh in.

[samuelweiler]

I would rather get the licensing commitment for this one.

@robinwhittleton, would you create a W3C account, link it to your Github account, and poke me again?

[robinwhittleton]

Will do. My current employer (Ingka, a part of IKEA) has no direct relationship with W3C yet so this might take a couple of weeks to navigate internal politics. But I’ve kicked the process off.

[robinwhittleton]

Hej @samuelweiler; I’ve brought my case to my organisation but it’s kicked off a bigger discussion about membership contributions and what brings the most value. So given that it might be quite a while, if ever, before my org decides to join W3C as a paying member (which incidentally would be €68k/year for us, or €731 per added character in this PR 😅) is there a change I could make which would drop this into the non-substantive bracket? For example, if I removed the normative change (e806583) would that help?

[mozfreddyb]

@samuelweiler pls advise how to proceed here :)
I'm happy to take the non-normative bits and find my own words for the normative stuff that ought to then happen as a follow-up.