thro1

There is no way to make JavaScript so limited in scope as XSLT is.

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).

There is no way to make JavaScript so limited in scope as XSLT is.

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

Edit: nRF52840 chip can have 12 Analog Inputs, ESP32S3 20 - e.g. ESP32-S3-WROOM-1 - but XIAO ESP32S3 and XIAO nRF52840 have 6 only, there are others with more pins (AFAIR up to ~128, not all analog) but more functions too - what's overkill regarding price and energy waste - not so cool. (BTW. of A beginner tries PCB assembly (2020) https://news.ycombinator.com/item?id=32549736 )

It looks like all Hall sensor or similar analog keyboards came after that ?

(exception: Scrollpoint in IBM keyboards)

There are diodeless (no matrix) split keyboards (https://www.reddit.com/r/ErgoMechKeyboards/comments/1dh9o8k/...) like Cantor: https://github.com/diepala/cantor .

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 .

For me, it happened in that moment when XMLHttpRequest was the only working common denominator for few "new" techniques browsers - as iframe was over everything you couldn't just load some content into target like in Netscape - but you had to use JS anyway after that to move it out of first plane.

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)

Just.. and for so long:

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 ?

https://www.igalia.com/chats/xslt-liam

  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 !

https://github.com/whatwg/html/issues/11146#issuecomment-275...

  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.

by definition XSLT is more secure than JavaScript.

That's our freedom of not being forced to use JavaScript for everything being taken away !

(?) - then more about the tactic: https://news.ycombinator.com/item?id=44994459 (web looks like nails for that tool we have)

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)

The standard so far is to respect existing standards still in use, peoples effort and work done already - but not to outsource bug fixing costs by forcing any of that to be redone or lost.

- as in Europe, I don't see neither how taxpayers money or users time (if still alive) could be forcibly used to cover the costs of some far away corporation savings (on bug fixing) and profit, downgrading then a lot into more costly, less maintainable, not standard solutions.

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.

Moreover: there is no JS solution being so stable and for so long as that standard: "25 year old version of XSLT".

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.

Wasn't the social contract that get the market share that you can use Chrome to browse all the web already existing as well as by using the other browsers - means not discriminating (non-profit, government, older sites or those working well without JS for ads to be tracked), and not to kill parts of that web when convenient ?

cute :) (focused and instant)

How about that:

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).

Gecko currently has much deeper integration of the XSLT engine with the browser internals: The XSLT engine operates on the browser DOM implementation. WebKit and Chromium integrate with libxslt in a way that's inherently bad for performance ( https://github.com/whatwg/html/issues/11578#issuecomment-321... )

Just Firefox XSLT is faster, better, cheaper than Google's (and JS), same, old Firefox extensions were to powerful Google could compete with Firefox (or block adblocks).

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?

Can't say about the content so far as I can't read it - letters are to small (so much space wasted in that boxes, still clip letters) and with browser zoom 200% blurry (on 27" 4k), using that page special zoom can't see the whole picture - neither scroll it with my Scrollpoint mouse beacuse now it's zooming :(

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) ?

They say Vaccines containing aluminum “are incredibly safe,”

not only just safe credibly ?

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

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

Howard JOHNSON, Permanent Magnet Motor http://www.rexresearch.com/johnson/1johnson.htm - is that similar ?

( 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)

and this (regarding that study..) : https://www.youtube.com/watch?v=a_uL29CKzW8 (Mazurka in G Minor, Op. 24, No. 1) for all that colors and the shadow in the shape.

or this https://www.youtube.com/watch?v=PnzQP4M_BQk (Pi) or this https://www.youtube.com/watch?v=a_uL29CKzW8&list=PLpn7yEHjyr... and others (Impressions On Chopin). Not some theory, you can hear the strings bending. Enjoy!

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

I think that's good example (you can easy study yourself - as he did practice enough - mostly Chopin, as a child, then jazz):

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 :)

- but isn't the universe converting time into space ? (we don't see the speed of light as changing ?)

Shallow FUD tactic ??

"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>
  `;
  [..]

(now I see it, obviously, you does not seem to know what you are talking about - in any case, just.. can you live and let others live too ? Thx.)

But JS can't do things in the way XSLT so far still can, transparently etc. operating at differrent level ( e.g. https://news.ycombinator.com/item?id=45000600 )