Need a clean and standardized way to retreive some informations about user agent enabled features from server side

[flavi1]

Imagine that Javascript is disabled by user, or simply non available on the used web browser.
Considering some problematic situations.

You are developper and you want to provide a specific response for those which actualy doesn't use javascript.
For now, you have to send a first response with a javascript test and store the result in the session for future requests.
But what about this first response? The first response have to be thinking to cover those actualy uses javascript AND those actualy not uses it. This is problematic and hard to do. Is the Schrödinger's cat alive or dead? A solution can be to load a page designed to silently perform the test "is javascript enabled" and then redirect the user to the first response. This can be problematic too regarding SEO constraints, and non optimal because it uses two requests instead of one.

Anymore, others informations will never be available from a non javascript enabled client to the server. Like screen height, screen width, window height, window width...

Another possible problem.
Some new html features are likely to break the HTML parser. For example in #2254
This proposition concerns the template element and if it's accepted, it is likely to change how the browser should parse the template element. We can imagine a simple server side solution for unsupported browsers : serve templates content between script tags instead of templates tags to avoid parser problems.
But we have first to retrieve the information "does the used HTML parser will able to interpret template content as a pure textNode or as HTML Fragment only?" And we have to retrieve this information before writting the page because it is crucial to know it if you don't want to break the parsing process!

[flavi1]

A possible solution is to inject a parsable JSON (see bellow) in the first request, on the "User Agent" header variable. The browser should naturally check if this first request is well received by the server to stop sending it in the next request.
If this variable appear a second time, this should mean that the situation is updated.

Example of parsable variable

{
    "last-supported-html-version" : "5.3",
    "enabled-features" : {
        "javascript" : true,
        "an-experimental-feature" : true,
        "something-usualy-enabled" : false
    }
    "screen-width" : "300px",
   (...)
}

[bathos]

You may be interested in client hints:

• RFC 8942, HTTP Client Hints
• Client Hints Infrastructure
• User Preference Media Features Client Hints
• Responsive Image Client Hints

Your example included “screen-width”, so in particular note that the last of those defines the sec-ch-viewport-width header. Some browsers already implement this.

Whether JS has been disabled is unusual among “features” in that it’s something the user configures rather than a matter of whether the agent itself supports it, so it might not be a stretch for it to fit into the client hints model. However it’s unclear to me why this would be a pressing need as HTML already includes a conditional mechanism for handling JS being disabled, <noscript>, and there need not be any “redirect” (navigation) at all; sites can “gracefully degrade” without serving different documents. If there must be a navigation, it can be done in the uncommon case (JS being disabled) instead of the common one via an http-equiv refresh meta element, iirc.

Re: ‘an-experimental-feature’ in the example: Most things we call “features” are fuzzy, intuitive concepts. The concrete granular units of “support” are things like individual steps of specification algorithms, which isn’t useful or realistic, but anything broader is pretty arbitrary. No notion of self-reported support for features in that sense will fly, not only because what’s reported won’t end up aligning with the real world problems people would hope to solve with it anyway, but because the data being exchanged would often cease to be relevant in short time. Meanwhile there’d be no safe point for the platform to stop reporting support for a feature — the list would expand indefinitely. This overhead / “memory leak” (in the abstract) isn’t tenable.

Re: last-supported-html-version: HTML is an unversioned, living standard.

[domenic]

Closing as this is indeed an already-existing technology where it makes sense, and otherwise is not a good fit for the web, as @bathos describes.

[flavi1]

@bathos : Thanks, your post reslove 80% of the issue.

After re-reading it, I realize that most of feature are javascript related.
Then to work, javascript must be enabled. So if javascript is not enabled, most of features are not enabled too.
If javascript is enabled, javascript can test if each feature is enabled.
For the others, I realize by reading your post how hard (maybe impossible) it is to find a good solution.

@domenic : Completed ? Partially yes. The ticket I proposed is surely "too large".
But the list of pointed problems is not enterly consumed.
The noscript tag is not enough since it can't be handled before page generation.
And you know the problem relative to the parser because you already pointed it on your own gitbub repository
https://github.com/domenic/template-parts#parser-problems
Without a possibility to know if the parser will be broken by the generated document,
any possible server side fallback is not possible (at least not without javascript - which is a problem)
It seems a little too hasty to close this ticket. And I don't even know if I could feel free to open a new one more clean...

[flavi1]

@domenic : I would like to open a new clean ticket stricktly about the "is javascript enabled" problem since <noscript> tag is not enough since it can't be handled before page generation.
But I don't want you to think I'm tring to pollute the html github repository and I realize this is maybe on the border between http and html concerns. Should I publish it? If yes, where?

[bathos]

@flavi1 I’m not sure what you’re picturing, but changes to HTML parsing behavior are very rare. When they do occur they are either corrective or behavioral rather than grammatical (e.g. declarative shadow roots). Cases where two agents parse the same document in different ways can lead to security issues, and cases where they do so lexically are especially fraught. In any case, there’s no need to open an issue about how to handle feature detection for a feature that itself is speculative and has no consensus, momentum, or spec text yet.

[flavi1]

Sorry for confusion. This is not a specultaive feature, but an actually opened ticket.
I explained it more clearly here #2254 (comment)
And the problem is already pointed here by domenic : https://github.com/domenic/template-parts#parser-problems
So this question is now moved to a more relevant place.

I need to explain that it is hard for me to organize my thoughts here, because, to say it with humor, I speak english like a spainish cow. And it's quite disabling.

From this ticket, the only remaining point is now the server side "is javascript enabled" which does not find a solution nor a more relevant place.

[flavi1]

Ok, I understand.
This feature has no consensus yet. Yes.
But we can't just wait for this feature to become a spec text before resolve this problem.
It sounds like intentionnaly produce a bug and resolve it later...
We should be able to imagine a credible implementation before valid the related feature.