Thanks for the comments @thibaudcolas.

I would point out that the guidelines are built to serve not just people working on the client-side but also on the server-side and it's important to recognize that emission savings can be made from all ends of the stack (and it's crucial that we try to address this as fairly as possible).

It's also worth remembering that examples are just that, examples. People can see them as a showcase of how a saving could be used in practice, but of course there are likely a million and one ways people can interpret and implement our guidelines to have the same effect (or potentially have a greater or lesser impact - of which we're hoping to be able to provide more guidance regarding implementations when possible). Other sources will notably provide their own ways of doing things and thats fine also, we just chose to have a single example for simplicity (to avoid the spec becoming too bulky as it's already a really weighty document as it is).

Relating to the use of Apache and NGINX - You mention that HTML, CSS, and JavaScript are fundamental web technologies because they are supported by all browsers, yet Apache and NGINX (between them) are used on over 90% of all web servers, and thus the scripting languages which they use to implement server-side caching, etc are as fundamental to the web infrastructure as any web standard like HTML. It would be doing these technologies a severe dis-service to ignore them, especially when their handling of caching and such (whether through htaccess, http.config or through a control panel like cPanel) has a significant impact on emissions and sustainability.

I do agree with you regarding the use of PHP and more languages could be included. When drafting the specification we really struggled due to a lack of server-side expertise, but we're hoping to address this in further drafts. If you have any useful links to contribute this would be greatly appreciated (note: we don't want to be exclusively JavaScript because we know that the web doesn't run like that). Being sustainable has to encompass the entire web stack and we need to welcome everyone (including beyond the browser). This includes people from the PHP, Python, Ruby and other server-side crowds (as they have much to offer!

Sorry for the long post but I hope this helps explain our choice in examples. I'll mark this as a non-issue however if you'd like to post replacement examples in a reply or provide lots of URLs for us to include I'll be sure to review them and include them within the next draft!

@AlexDawsonUK thanks for taking a look at this! There are specific points I disagree with / don’t understand so I’ll reply to those. On methodology:

I'll mark this as a non-issue however if you'd like to post replacement examples in a reply or provide lots of URLs for us to include

Generally if an issue is closed to me it means that people don’t consider there to be an issue and the person reporting should probably move on to something else. If replacement examples or extra resources are needed, then I’d probably expect the issue to remain open, or for you to open a new issue about that ("issue" in a task-tracker-entry sense).

I’m also surprised to see this closed without any further input from others and labelled as a "question" – I wasn’t asking for any information here, just pointing out a problem. Again from my expectations based on other projects, I don’t see how you disagreeing with it being a problem makes my report a question – but don’t have context on how this specific project does this type of triage.

Then on the examples:

I would point out that the guidelines are built to serve not just people working on the client-side but also on the server-side

I’m not suggesting this. JavaScript is used server-side plenty enough in "traditional" stacks and also I think plenty in serverless environments. HTTP headers which I suggest as a replacement for Apache/Nginx code are definitely a "server-side" concern since they’re set with server-side code.

It's also worth remembering that examples are just that, examples

From my perspective without the context, as-is each guideline has one example, so the example seems like quite a crucial illustration of what the guideline is about. I could easily see a future where there are more examples, and room for examples from more niche technologies – but right now that’s not what’s there.

Apache and NGINX (between them) are used on over 90% of all web servers

This doesn’t seem to me like the right metric. Though that might well be the case, it’s not uncommon these days for use of those technologies to be completely abstracted away by the stack (say in a PaaS or serverless environment), or be something that a developer has no control over in other ways. To me the right metric for relevance should be how many people have the opportunity to use the example, not how many servers.

Note the specific replacement I suggested for those is HTTP headers, not HTML/CSS/JS. HTTP headers are definitely used on 100% of web servers, and will definitely be relevant in all types of infrastructures (incl. PaaS & serverless), and therefore can be changed by 100% of web developers who have access to server-side code.

Regarding your points:

I can see where you're coming from. The rationale behind the soft closing of an issue is that (in this case), the issue had been reviewed, I had labelled it as "Further details ... requested" (the question tag) and at the bottom of my reply explicitly stated that any follow up would be subsequently reviewed and once a solution is agreed upon, integrated into the specification. It's not that I'm dismissing what you've said as irrelevant (I hope you didn't take it that way!), it's more to (in this case) note that your comments have been taken onboard and we will discuss it further (though you're fully welcome to keep adding additional context as you have in the reply box).

Regarding the examples:

It does make sense to include serverless within the scope though I do wonder for people who are simply building simple HTML websites (these do still exist!) as opposed to applications. Will the use of HTTP headers over an htaccess file (which natively comes in tools like cPanel) make the examples too high level? I pose this question because our content has to be approachable for non-techs as well as seasoned industry pros. This is partially why I'm nervous about recommending something which may be second nature to us, but too technical for others who wish to be sustainable.

@thibaudcolas I've been thinking about this issue further and come up with a potential compromise. In the cases of Apache / NGINX, this would be a perfect case to experiment with two examples. The first of which would have the HTTP header response (as you mentioned for stack abstraction), the second would include the existing material which is scoped for specific environments (of which non-tech individuals may be more used to seeing).

The PHP example we will also retain but include the dialog example as this way there is an example which represents both sides of the stack environment (with regards to API utilization and relevance).

Hopefully this matches what you were looking for in terms of broader relevance. I'll ensure it makes the next draft.
If you have any further comments, don't hesitate to add something below.

Examples for each equivalent HTTP Header response have now been included within the specification (alongside existing Apache & NGINX examples), plus a link for further implementation guidance has been added. Furthermore, a HTML dialog box example has been included with a link to the MDN reference page on the API for further information. This will be visible once the next version of the draft is published. I'll mark this as complete (and tag it as an enhancement as new content has been added) as re-reading the original issue it seems to meet the criteria but if you have any further advice on implementation, we're always open for further discussion and potential re-opening as appropriate.

Thanks @AlexDawsonUK! The specific points of feedback here aren’t things I necessarily feel super strongly about, but I suppose I did spend enough time writing them that I’m happy to have the chance to make them clearer if that’s helpful. And also to see whether small changes could help address them even just partly.

As far as managing feedback – to me if something in GitHub says "closed as completed" or "closed as not planned", I take it as "let’s move on to something else". If you as a maintainer would think there’s more to do I’d expect either to keep the issue open and triage with GitHub issue labels / Projects, or close and send me towards GitHub Discussions perhaps. Again not saying this is how this project has to run, just stating my expectations.

Absolutely, thanks again for your feedback it's always welcome and helpful.

I agree this can cause confusion so apologies for the misinterpretation, I'll be sure in the future to keep issues open until they have been fully settled. This new issue also may be helpful regarding contribution which we're planning for the next draft (for PR's) which hopefully will make things a lot easier, as we've hopefully solved the conundrum of how to allow direct editing but still be able to follow our review processes and ReSpec's clunky export format (to avoid dependency issues).