Unrelated to your thread, just mentioning that I found “writing reproducible setup documentation” one of the more satisfying activities in programming, whether for “as a genius here’s how I did it” or for “onboarding docs are waaay outta date and I’ll never remember how I did it”.

I agree with both points about 1.0 vs. 3.0 and *API* polyfill but these are separate different topics.

I’m mainly asking that the XSL processing instruction that fetches and applies templates to the parent XML be retained, so folks, firms, governments don’t have replace static code that works today

All the same, this issue is important to a few of us and we don’t feel heard.

If you could present my concern over XSLT I’d appreciate it. I’ll even make the case directly at the meeting if that would be better.

LMK

Declarative-reactive templating so that we don't have to install a single library to comfortably make reusable custom elements that pass data down to further elements in their shadow dom.

My nimble-html lib is a single file, but still it's a non-standard lib.

github.com/lume/nimble-...

Swear I’m not trying to play gotcha but it can’t be so hard it’s not maintainable when there’s already a polyfill.

How about using the polyfill to replace libxslt et al?

At least present the option…?

DO NOT DEPRECATE XSLT - super useful for static sites - can even generate a CSP nonce *dynamically* on the client, e.g. - without a build step.

I appreciate you asking for our input.

I know I speak for many who feel our voices don’t matter and doubt it has ever mattered.

What happened, how did this come up?