[eknathdj]

Resolves #12258

What

Adds an optional validator query parameter to the existing W3C Validation badge,
choosing which Nu validator deployment to query:

https://img.shields.io/w3c-validation/default.json?targetUrl=https%3A%2F%2Fexample.com&validator=validator.w3.org

• validator.nu (default) — unchanged behaviour, the original hsivonen-hosted service
• validator.w3.org — the W3C-hosted deployment at https://validator.w3.org/nu/

Both hosts run the same Nu engine with the same API (?doc=&out=json&schema=&parser=),
so this is a pure base-URL selection: presets, parser passthru, message counting and
error mapping are untouched. The old service is not removed and every existing badge
URL keeps working, as requested in the issue.

Why

validator.nu has become unreliable for some users (Cloudflare interference is reported
in the issue), while the W3C-hosted deployment of the same engine stays reachable.
Adding the host choice lets badge users switch without losing the existing service.

Verification

• A nock'd service-level probe confirms validator=validator.w3.org sends the request
  to https://validator.w3.org/nu/ (interceptor consumed) and renders the badge from
  its response.
• Two new live service tests hit validator.w3.org and pass.
• Notable side effect observed while testing: on the contributing machine, all 8
  pre-existing live tests (validator.nu) fail identically on unpatched master
  (0 passing / 8 failing, network-level), while the two new validator.w3.org live
  tests pass — a live reproduction of the connectivity problem that motivates this
  issue. CI with open network should show the full suite as before.

Run with: npm run test:services -- --only=W3cValidation (the runner filters by
service class id).

[github-actions]

	Messages
📖	✨ Thanks for your contribution to Shields, @eknathdj!

Generated by 🚫 dangerJS against 01c1d9c

[ngdangtu-vn]

I appreciate the sacrifice of your tokens here. However, I suggest avoiding the search param and its value validator=validator.w3.org.

1. It's long, too long in fact
2. It may mislead users that they can replace it with any self-hosted VNU instance

Lookin' at the bot's code, I can tell it doesn't behave like that. And please do not implement such a feature as it can introduce major potential security holes without careful validation.

As for the code, lgtm atm. The test is a bit weak, somewhat redundant I must say. Firstly, the logic here is very straightforward, only a boolean flag check. Secondly, the test only checks if the input params work, not if the switch actually works. Say the validator flag fails to switch to the new service, how does the test catch it? It won't, because it just aims for generic responses instead of specific ones.

For instance, the old service would return an error if the site has p tag nested in hgroup tag. The test sample has nothing to reproduce a case like that.

The more I think about this the more I see that this approach is wrong. If you still have some tokens left, may I suggest using those to compare the 2 versions? If the new version doesn't yield breaking changes from the old one then we should simply replace it rather than attempting to add a new input param for it.

[LitoMore]

I would say NO to fully AI-generated PRs. I even doubt whether the person submitting the PR request knows what they're doing.

Closing due to the low quality. @eknathdj If you think I'm doing it wrong, please tell us your thoughts and type your understanding of the implementation.

[eknathdj]

Fair enough, and thanks for the direct feedback LitoMore.

On the implementation: the service calls the Nu validator's JSON API and maps the messages array into a badge.
Each message has a type ( error, info, with subType: warning ), so the service counts errors and warnings and
renders colour and text from those counts. My change added a validator query param that only swapped the
request host between validator.nu and validator.w3.org/nu - the response shape is identical because both run
the same Nu engine, so nothing downstream changed.

@ngdangtu-vn is right that the test was weak. It asserted the parameter was accepted, not that the host actually
switched - if the switch silently failed the test would still pass. That's not a real test and I shouldn't have submitted it
as one.

And the more important point: if validator.w3.org/nu works and validator.nu doesn't, the fix is to change the
default, not add a parameter users have to discover. Adding an option to work around a broken default was the
wrong instinct. A param also implies arbitrary self-hosted instances are supported, which I agree shouldn't be done
without validation.

btw, I tried to share my findings and understandings as per my knowledge. Apologies if the above description is still viable here.

[ngdangtu-vn]

If you keep replying a human comment with an AI comment. I can understand why you got reject.