Live data from Hacker News

"Remove mentions of XSLT from the html spec"

github.com

521–530 of 559 posts

Re: "Remove mentions of XSLT from the html spec"

#521
post #516

Earlier quoted context omitted.

wow, thank you. your first example is actually what i have been trying to do but i could not get it to work. i did search for examples or explanations for hours (spread over a week or so). i found the documentation of each of the parts and directives used, but i just could not figure out how to pull it together. your last example is what i started out with, including the pass through template. you may remember this m…

Yeah, unfortunately the one criticism of XSLT that you can't really deny is that there's no information out there about how to use it, so beyond the tiny amount of documentation on MDN, you kind of have to just figure out your own patterns. It feels a little unfair though that it basically comes down to "this doesn't have a mega-corporation marketing it". That and the devtools for it are utterly broken/left in the ea…

devtools for it are utterly broken

right, that's a big issue too. when the xsl breaks (in this case when i use ) i get an empty page and nothing telling me what could be wrong. if i remove the $ the page works, and the apply-templates directive is just left out.

Re: "Remove mentions of XSLT from the html spec"

#522
post #520
post #516

Earlier quoted context omitted.

wow, thank you. your first example is actually what i have been trying to do but i could not get it to work. i did search for examples or explanations for hours (spread over a week or so). i found the documentation of each of the parts and directives used, but i just could not figure out how to pull it together. your last example is what i started out with, including the pass through template. you may remember this m…

unfortunately i hit another snag: https://stackoverflow.com/questions/3884927/how-to-use-xsl-v... nodes you output don't have type "node-set" - instead, they're what is called a "result tree fragment". You can store that to a variable, and you can use that variable to insert the fragment into output (or another variable) later on, but you cannot use XPath to query over it. the xsl documentation https://www.w3.org/TR/…

Ah, I could've sworn that it worked in some version of the page that I tried as I iterated on things, but it could be that the browser just froze on my previously working page and I fooled myself.

Adding xmlns:exsl="http://exslt.org/common" to your xsl:stylesheet and doing select="exsl:node-set($nav-menu-items)/item" seems to work on both Chrome and Librewolf.

Re: "Remove mentions of XSLT from the html spec"

#523
post #520

Earlier quoted context omitted.

unfortunately i hit another snag: https://stackoverflow.com/questions/3884927/how-to-use-xsl-v... nodes you output don't have type "node-set" - instead, they're what is called a "result tree fragment". You can store that to a variable, and you can use that variable to insert the fragment into output (or another variable) later on, but you cannot use XPath to query over it. the xsl documentation https://www.w3.org/TR/…

Ah, I could've sworn that it worked in some version of the page that I tried as I iterated on things, but it could be that the browser just froze on my previously working page and I fooled myself. Adding xmlns:exsl=" http://exslt.org/common " to your xsl:stylesheet and doing select="exsl:node-set($nav-menu-items)/item" seems to work on both Chrome and Librewolf.

tried that, getting an empty match.

here is the actual stylesheet i am using:

    
    
      

      
        Home
        About
      

      
        
          
            
            
            
          

          
             -->
            
              
            
            
          
        
      

      
        
        
          
            
          
          
            
          
        
      

      
        
      

      
        
          
        
      
    

documents look like this:

    
    
    
    
      About Us
      
        html content here, to be inserted without change
      
    
if i use the document() function, with nav-menu.xml looking like this:

    
      Home
      About
    
then i get the menu items, but the test fails

Re: "Remove mentions of XSLT from the html spec"

#524

Earlier quoted context omitted.

The web has been prospering?

Obviously not things like blogs, or things you’d find via search, or independent forums, or newspaper websites. They certainly aren’t prospering. But walled gardens like YouTube, Discord, ChatGPT and suchlike that are delivered via the browser are prospering. And as a cross platform GUI system, html is astonishingly popular.

(things which are not the web but happen to be delivered by the same protocols)

Re: "Remove mentions of XSLT from the html spec"

#525

Earlier quoted context omitted.

Another way to look at this is: Billions of people use the web every day. Should the 99.99% of them be vulnerable to XSLT security bugs for the other 0.01%?

If the usage/risk of XSLT is enough to remove it, you'd have to remove webusb, webbluetooth, webmidi, webxr, and countless more

Yes, please.

Re: "Remove mentions of XSLT from the html spec"

#526
post #523

Earlier quoted context omitted.

Ah, I could've sworn that it worked in some version of the page that I tried as I iterated on things, but it could be that the browser just froze on my previously working page and I fooled myself. Adding xmlns:exsl=" http://exslt.org/common " to your xsl:stylesheet and doing select="exsl:node-set($nav-menu-items)/item" seems to work on both Chrome and Librewolf.

tried that, getting an empty match. here is the actual stylesheet i am using: Home About --> documents look like this: About Us html content here, to be inserted without change if i use the document() function, with nav-menu.xml looking like this: Home About then i get the menu items, but the test fails

It looks like it's related to your setting the default namespace xmlns="http://www.w3.org/1999/xhtml". You could either add a xmlns:example="http://example.org/templates" and then replace `item` with `example:item` everywhere, or you can override the default namespace within your variable's scope:

    
        Home
        About
    
I think you also don't really need to set the default namespace to xhtml, so I believe you could remove that and not worry about namespaces at all (except for xsl and exsl).

The test is failing because it's `/about.xhtml` in the template but `about` outside. You'd either need to add a name attribute to item to compare on or make it match the href.

That should make your thing work if I haven't fooled myself again. :)

Re: "Remove mentions of XSLT from the html spec"

#527
post #523

Earlier quoted context omitted.

tried that, getting an empty match. here is the actual stylesheet i am using: Home About --> documents look like this: About Us html content here, to be inserted without change if i use the document() function, with nav-menu.xml looking like this: Home About then i get the menu items, but the test fails

It looks like it's related to your setting the default namespace xmlns=" http://www.w3.org/1999/xhtml ". You could either add a xmlns:example=" http://example.org/templates " and then replace `item` with `example:item` everywhere, or you can override the default namespace within your variable's scope: Home About I think you also don't really need to set the default namespace to xhtml, so I believe you could remove th…

I think you also don't really need to set the default namespace to xhtml

you are right. i removed it, and it works. typical "copy from stackoverflow" error. these namespaces are a mystery and not intuitive at all. i suppose most people don't notice that because it only applies to xml data within the stylesheet. most people won't have that so they won't notice an issue. the less the better.

for the other error, my mistake, duh! in my original example in https://news.ycombinator.com/item?id=44961352 i am comparing $current/@name to a hardcoded value, so if i want to keep that comparison i have to add that value to the nav-menu data. or use a value that's already in there.

i went with adding a name="about" attribute to the nav-menu because it keeps the documents cleaner: just looks better, and it also allows me to treat it like an ID that doesn't have to match the URL which allows renaming/moving documents around without having to change the content. (they might go from about.xhtml to about/index.xhtml for example)

i am also probably going to use the document() function instead of exsl:node-set() because having the menu data in a separate file in this case is also easier to manage. it's good to know about that option though. being able to iterate over some local data is a really useful feature. i'll keep that around as an example.

the final piece of the puzzle was:

     | 
to put a separator between the items, but not after.

that sorted, now it all works. thank you again.

btw, it's funny that we are turning hackernews into an xsl support forum. i guess i should write all that up into a post some day.

Re: "Remove mentions of XSLT from the html spec"

#528
post #381

Earlier quoted context omitted.

Also, according to Chrome's telemetry, very, very few websites are using it in practice. It's not like the proposal is threatening to make some significant portion of the web inaccessible. At least we can see the data underlying the proposal here.

1. Chrome telemetry underreports a lot of use cases 2. They have a semi-internal document https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpS... that explicitly states: small usage percentage doesn't mean you can safely remove a feature --- start quote --- As a general rule of thumb, 0.1% of PageVisits (1 in 1000) is large, while 0.001% is considered small but non-trivial. Anything below about 0.00001% (1 in…

>Chrome telemetry underreports a lot of use cases Sure; in that case, I would suggest to the people with those use cases that they should stop switching off telemetry. Everyone on HN seems to forget telemetry isn't there for shits and giggles, it's there to help improve a product. If you refuse to help improve the product, don't expect a company to improve the product for you, for free.

Re: "Remove mentions of XSLT from the html spec"

#529
post #527

Earlier quoted context omitted.

It looks like it's related to your setting the default namespace xmlns=" http://www.w3.org/1999/xhtml ". You could either add a xmlns:example=" http://example.org/templates " and then replace `item` with `example:item` everywhere, or you can override the default namespace within your variable's scope: Home About I think you also don't really need to set the default namespace to xhtml, so I believe you could remove th…

I think you also don't really need to set the default namespace to xhtml you are right. i removed it, and it works. typical "copy from stackoverflow" error. these namespaces are a mystery and not intuitive at all. i suppose most people don't notice that because it only applies to xml data within the stylesheet. most people won't have that so they won't notice an issue. the less the better. for the other error, my mis…

Nice. Fwiw I believe you can also use css for the separators if you've put them in a list:

  li + li::before {
    content: " | ";
  }
If xslt survives maybe I should make a forum and/or wiki. Using xslt of course.

Re: "Remove mentions of XSLT from the html spec"

#530
post #206

Earlier quoted context omitted.

Isn't this something that could be implemented using javascript? I don't think anyone is arguing that XSLT has to be fast. You could probably compile libxslt to wasm, run it when loading xml with xslt, and be done. Does XSLT affect the DOM after processing, isn't it just a dumb preprocessing step, where the render xhtml is what becomes the DOM.

It could be. The meaningful argument is over whether the javascript polyfill should be built into the browser (in which case, browser support remains the same as it ever was, they just swap out a fast but insecure implementation for a slow but secure one), or whether site operators, principally podcast hosts, should be required to integrate it into their sites and serve it. The first strategy is obviously correct, bu…

As discussed in the GitHub thread, strategy two is fundamentally flawed because there’s no other way to make an XML document human readable in today’s browsers. (CSS is close but lacking some capabilities)

So site operators who rely on this feature today are not merely asked to load a polyfill but to fundamentally change the structure of their website - without necessarily getting to the same result in the end.

Post reply on HN