thro1

But what I want only is XSLT on live DOM nodes, when editing. Simple templating good engine, and to stay. Not a fancy stuff (reredoxes adinfinis).

That are capabilities that progressing-processing-oriented people will never get even close to that which document(ing)-oriented people (users) transparently had and is about to get lost.

The World Wide Web, invented at CERN in 1989 by Tim Berners-Lee, is a system of interlinked hypertext _documents_ - not interlinked programs (opaque and superior to take control over any data).

But what I want only is XSLT on live DOM nodes. Not a fancy stuff.

(exception: Scrollpoint in IBM keyboards)

They use chips similar to that one: XIAO ESP32S3 nRF52840 Sense Plus - wireless, energy efficient, with 20 pins GPIO or more - one pin for one key - https://thepihut.com/products/xiao-nrf52840-sense-plus (there was an option of 16 pins extra using expander https://wiki.seeedstudio.com/io_expander_for_xiao/ - which is not made anymore, but you can use same chip MCP23017 to get that effect https://www.youtube.com/watch?v=lq6jbXaX4oQ https://www.youtube.com/watch?v=74DgM2nAeLo , up to 128 I/O pins: https://resinchemtech.blogspot.com/2023/10/IO-expander.html - in that case - 36 simultaneous inputs by hand) - and with Hall sensor keys or similar we are soon talking about _easy_ having ~40+

.. simultaneus muiltiple ANALOG inputs in "keyboards" - like in Mitt https://www.youtube.com/watch?v=Oj7HfcdJhi8 - or XBOX Controller Mods: Analog WASD Gaming Keyboard https://www.youtube.com/watch?v=gEwDImE0DU4 .

Because I wasted my time to reach some working ways to get the results by scripting, it leave me no time actually to think about it in any other way (like to prove for it the next few things I saw coming to the client side soon after, which I used to know from earlier thanks eXist-db). I took me some time, much later, to learn about such few incredible things - that if working, would make my job so.. basic - just, if, again few things described as bugs, were fixed at that time.

Without that, just that happen: you wanted the results you have code it yourself - regarding or regardless of few bugs making simple things being hard corner cases with interoperability problems that can't be solved.

Since then, I understand that with JavaScript it's just easier to keep fixing things ad hoc not worrying to much about standards, implementations

.

- than, actually to keep asking for few things or key bugs to be fixed, for more than 20 years - and to not see that ever.

.

The legacy is that, we can no longer get there where simple things can just interoperate (is it old school now ?) - but some generation later actually not aware why, has such imperative mindset of micromanagement that they can not even imagine self not implementing repetitively something just because in some other world after long way it was already abstracted once - but just not ever implemented once to work in same consistent way and as intended between browsers.

From that point of view it's quite easy to not worry about or to abolish standards - you can't do much about implementations elsewere or bugs - but you can do whatever you want with your code (so long no one will remind you - will it last when other things change ?).

That's sad actually, as I se it, that Javascript Document Programmers keep repeating and will be repeating same works, unaware of reasons for that - few bugs here and there, for 20 years not fixed once or in same common way.

But how "random" were all that things leading to that point: with JavaScript all is possible and everything else is redundant ? ( only a hammer can work ?) - then look at example: https://news.ycombinator.com/item?id=45183624 - what's there look like simplest abstract form and what's like redundant ?

P.S. RIP WWW

(?) (JS is not a W3 standard)

XSLT is WWW standard, JavaScript is not (it's ECMA standard) - and there is no JavaScript specification on W3C pages .

( https://www.w3.org/wiki/JavaScript )

Shall JavaScript to become a web standard first - then to be used to "replace" already standard solution ?

  So basically browsers had this [..] the question now is there is no investment in this. None. And there hasn't been for a really long time from the browser's perspectives. 

  XPath And XSLT continue to evolve. They've really continued to evolve. And people are currently working on an XSLT-4.

And because it's a declarative way of transforming trees and collections of trees. And declarative means you don't say how to do it. You say, 'This is what I want'..

.. it's timeless: _abstracted definition_ to which imperative solutions could be reduced in the best case - with unaware of that authors repetitively trying (and soon having to) to reimplement that "not needed" ( - if abstracted already out ! - ) part ( ex. https://news.ycombinator.com/item?id=45183624 ) - in more or less common or compatible ways

- so, better keep it - as not everybody can afford expensive solutions and there are nonprofits too that don't depend on % of money wasted repeating same work and like to KISS !

  panos: next item, removing XSLT. There are usage numbers.
  stephen: I have concerns. I kept this up to date historically for Chromium, and I don't trust the use counters based on my experience. Total usage might be higher.
  dan: even if the data were accurate, not enough zeros for the usage to be low enough.
  mason: is XSLT supported officially?
  simon: supported
  mason: maybe we could just mark it deprecated in the spec, to make the statement that we're not actively working on it.
  brian: we could do that on MDN too. This would be the first time we have something baseline widely available that we've marked as removed.
  dan: maybe we could offer helpful pointers to alternatives that are better, and why they're better.
  panos: maybe a question for olli. But I like brian's suggestion to mark it in all the places.
  dan: it won't go far unless developers know what to use instead.
  brian: talk about it in those terms also. Would anyone want to come on the podcast and talk about it? I'm guessing people will have objections.
  emilio: we have a history of security bugs, etc.
  stephen: yeah that was a big deal
  mason: yeah we get bugs about it and have to basically ignore them, which sucks
  brian: people do use it and some like it
  panos: put a pin in it, and talk with olli next time?

  As for the rest of your [working for Google] comment. To put it simply, you come off as someone inexperienced, maybe I'm wrong and you have a big list of features you've successfully removed and public discussions you had in the process, if so, there's probably something to learn from those that's different here.

now how about that:

Chrome voluntarily decides to disjoint self from parts of the web where it can't take profits - saying they are not in fashion ..

- and if then, actually no one would like to have to follow ever again anything like that ?. (ocean is _big_ and.. blue)

But I see less of that money but much better used - to support any of open, independent, not for profit, conforming to standards browsers instead - in not following what a big corporation says and want.

Can be "made with JS" doesn't mean that by chance it would be in any bit better than long proved and still used solution - not a one of many crippled, always changing, excluding imitations of it - for example like that one: https://news.ycombinator.com/item?id=45183624 (no caching, not instant, transparent or othogonal etc.).

With XSLT removed, Chrome can not claim to be a standard internet browser neither.

There is nothing wrong with XSLT - it's just Google not wanting to fix few bugs since decades - but others have to follow, nothing changes.

Actually.. I can't care less about Chrome - if others will not follow neither allow Google to reach such position claiming to be able to dastandardize working and used solutions.

Google's unilaterally tries to kill part of the web that not let them track or profit from ads so easy ?

.. and with all that money they get (and brains), still to lazy to fix few old bugs (stuck at old version).

JS is very needed for ads, tracking and other strings attaching - and XSLT is not for that - but would make JS mostly obsolete in many cases.. [..]

Google pay Mozilla to criple Firefox. It's money from ads, to not let the web be free. Right now, how much $ and CPU power a JS engine could cost, for that, is irrelevant - except for the final user [paying for that saving on costs by some big company - or having to redo NOW in less efficient way something that still works well so far regardless of decades passed] !

https://news.ycombinator.com/item?id=44994459 - with answering lame questions of a developer not having a clue what is all about.

(Just.. live and let others live too ? Thx.)

Moreover.. Content First - and browser is a secondary thing to existing content (Chrome came after) - not the (double) opposite (primary, for ads n tracking instead)

- isn't Google as a public servant - so part of their job is to fix their bugs - but not in the position to decide to kill someone else existing content or solution - for not displaying ads so easy?

Why I'm forced to interact with it in some unusual way, instead of let me just have a look or print it - is it made in such way for some purpose (document programmer has some, but no DTP/design skills - so DIY) ?

not only just safe credibly ?

Is that similar: https://news.ycombinator.com/item?id=45600132 ?

( https://patents.google.com/patent/US4877983A/en expired 2006, https://www.freepatentsonline.com/4877983.html )

Edit: https://www.paranetics.com/electric-motors - there is more details. And parametric motor https://patents.google.com/patent/JPH04344155A/en is more similar.

(and magnetic experiments https://www.youtube.com/watch?v=UZaRMt6xhoE explains a lot nicely)

@4d4m: Yes. - and more.. to have such freedom of expression (and some fun, https://www.youtube.com/watch?v=fRj9I5qiiI4 ).

Leszek Możdżer - Piano ( - Exploris, .. ) https://www.youtube.com/watch?v=QOicB0vcbf8&list=PLMigLc8yVp...

- moreover, he may indeed be touching strings occasionally - with or without using the hammers :)

"The feature is often the source of significant security issues."

(how often ? - I see ONE potential security issue there, so long since a month ?)

"Browsers currently support a ~25 year old version of XSLT"

----

As usually, the programmer basically and ignoring Users Case for his reward ($ impedance mismatch), is saying that the later is better than the former as he likes to use some JS magic (..there is nothing going on?) - because then.. he can debug it (!):

  <xsl:template name="book">
  <div class="book">
    <img class="cover" src="{cover}" alt="" />
    <div class="book-info">
      <div>..
        <span class="author"><xsl:value-of select="../name" /></span>
      </div>..
    </div>
  </div>
  </xsl:template>


  [..]
  const bookHTML = (bookEl) => html`
  <div class="book">
    <img
      class="cover"
      src="${bookEl.querySelector(':scope > cover').textContent}"
      alt=""
    />
    <div class="book-info">
      <div>..
        <span class="author">
          ${bookEl.parentNode.querySelector(':scope > name').textContent}
        </span>
      </div>..
      </div>
  </div>
  `;
  [..]