News for hackers. Stuff that matters.

thro1

Re:Removing XSLT for a more secure browser on Friday November 14, 2025 @05:29AM (#45925625)
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).

Re:XSLT RIP on Friday November 14, 2025 @05:21AM (#45925596)
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: XIAO ESP32S3 has 6 AIO, 20 has e.g. ESP32-S3-WROOM-1, there are others with more pins but more functions too - what's overkill regarding price and energy waste.
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 .

Re:XSLT RIP on Monday November 10, 2025 @03:42PM (#45880687)
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, in such 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 - that: 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 ?

Re:Removing XSLT for a more secure browser on Sunday November 09, 2025 @06:30AM (#45864798)
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 ?

Re:Removing XSLT for a more secure browser on Sunday November 09, 2025 @04:08AM (#45864138)
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. 
XSLT shows up then to be very robust, if for decades (!), regardless of that, lack of support, key browser bugs not fixed - it's still being used in that working part - and if used it holds up well and last, in meantime, elsewhere:

  XPath And XSLT continue to evolve. They've really continued to evolve. And people are currently working on an XSLT-4.
Re:Removing XSLT for a more secure browser on Saturday November 08, 2025 @07:34PM (#45861696)
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?
(just like that)
Re:Removing XSLT for a more secure browser on Saturday November 08, 2025 @09:47AM (#45856970)
by definition XSLT is more secure than JavaScript.
Re:Removing XSLT for a more secure browser on Saturday November 08, 2025 @09:22AM (#45856827)
That's our freedom of not being forced to use JavaScript for everything being taken away !
Re:Intent to Deprecate and Remove XSLT on Monday November 03, 2025 @01:22AM (#45796359)
(?) - 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)

Re:Intent to Deprecate and Remove XSLT on Saturday November 01, 2025 @07:33PM (#45786482)
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.
Re:Intent to Deprecate and Remove XSLT on Saturday November 01, 2025 @05:22PM (#45785513)
- 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.

Re:Intent to Deprecate and Remove XSLT on Saturday November 01, 2025 @02:49PM (#45784237)
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.

Re:Intent to Deprecate and Remove XSLT on Saturday November 01, 2025 @08:44AM (#45781209)
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 ?
Re:Intent to Deprecate and Remove XSLT on Saturday November 01, 2025 @08:06AM (#45781014)
cute :) and instant
Re:Intent to Deprecate and Remove XSLT on Saturday November 01, 2025 @07:46AM (#45780924)
How about that:

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

Re:Intent to Deprecate and Remove XSLT on Saturday November 01, 2025 @06:44AM (#45780653)
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?

Re:AI Mafia Network – An interactive visualization on Monday October 27, 2025 @11:22AM (#45722005)
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) 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 skills - so DIY) ?

Re:Why Aluminum in Vaccines Is Safe–and Often Essential on Monday October 20, 2025 @01:29PM (#45646607)
They say Vaccines containing aluminum “are incredibly safe,”

not only just safe credibly ?

Re:Pianists Can Shape Piano Timbre Through Touch on Thursday October 09, 2025 @03:09PM (#45531781)
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.
Re:Pianists Can Shape Piano Timbre Through Touch on Saturday October 04, 2025 @10:47PM (#45478497)
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 ).

Older »