Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google is killing the open web, part 2

wok.oblomov.eu

Post reply on HN
Print view View original

331–340 of 362 posts

Re: Google is killing the open web, part 2

#331

Post by Capricorn2481 »

rerdavies wrote: post #303
ndiddy wrote: post #81

Earlier quoted context omitted.

My guess is that a lot of the controversy is simply because this is one of the first times that a major web feature has been removed from the web standards. For the past 20+ years, people have grown to expect that any page they make will remain viewable indefinitely. It doesn't matter that most people don't like XSLT, or that barely any sites use it. Removing XSLT does break some websites and that violates their expe…

Sounds like EVERYBODY agrees that there isn't sufficient market value then. Even the original maintainer. And the that is indeed why the feature is being dropped: insufficient market value. Happy happy happy!

I don't think a maintainer refusing to answer spam issues from billion dollar corporations that contributes nothing back is evidence of no value to the maintainer. Unless you think FFmpeg has no market value, who has taken the same stance.

Re: Google is killing the open web, part 2

#332

Post by ndriscoll »

basscomm wrote: post #325
dfabulich wrote: post #310

Earlier quoted context omitted.

It would have been murderous with just CSS, but it would have been trivial to do with JS, much easier than the hundreds of lines of XSL you wrote. https://wyrm.org/inventory/skylanders.xsl

> but it would have been trivial to do with JS Maybe! How much Javascript would I have to learn before I could come up with a 'trivial' solution? > the hundreds of lines of XSL you wrote. Those hundreds of lines are the same copy/pasted if statement with 5 different conditions. For each game, I create a table by: alphabetizing the XML > going through the list searching for figures that match the game > each time I fi…

Aside: you could factor that out by making an that does the choose on element, then your repeated code can just expand that template. The immense power in XSLT comes from xpath to make it easy to match on things like "all figures that contain a ":

  
  Skylanders figureNote
If you further refactor the XML, you could do e.g.

  
    
    
    
     ...
And then you can entirely eliminate the verbosity in your XSL. The templates become:

  
  
  
    Skylanders figureNote
...

  
  .element-air      td { background: skyblue;      color: black; }
  .element-dark     td { background: dimgrey;      color: black; }
  .element-earth    td { background: saddlebrown;  color: white; }
  .element-fire     td { background: firebrick;    color: white; }
  .element-life     td { background: darkgreen;    color: white; }
  .element-light    td { background: ivory;        color: black; }
  .element-magic    td { background: purple;       color: white; }
  .element-tech     td { background: orangered;    color: white; }
  .element-undead   td { background: midnightblue; color: white; }
  .element-water    td { background: blue;         color: white; }
  .element-none     td { background: black;        color: white; }
...

Then in your body area:
You can actually use XSL to do the XML refactor too! ChatGPT happily obliges a template to do so:

  
  

  

  
    
      
    
  

  
    
      
        
      
      
        
          
        
      

      
        
      
      
        
      
    
  
  
    
    
      air
      dark
      earth
      fire
      life
      light
      magic
      tech
      undead
      water
      none
      unknown
Then `xsltproc refactor.xsl skylanders.xml > skylanders-refactored.xml`

As I've said elsewhere, I like XSL for its beginner-approachability, so not doing a bunch of factoring is fine, but I also like it for its power: such factoring into simple templates is possible once you wrap your head around the idea (as with CSS). Using for-each or choose should be a sign you're doing it wrong. Ideally if you did your data model well, you just do simple template expansions everywhere.

Re: Google is killing the open web, part 2

#333

Post by LtWorf »

dfabulich wrote: post #313
LtWorf wrote: post #174

Earlier quoted context omitted.

No you can't, since opening an RSS feed won't run a javascript.

https://github.com/dfabulich/style-xml-feeds-without-xslt

You mean if instead of generating a feed you rewrite your server to generate a webpage then it will be a webpage?

What will feed readers do with it?

Re: Google is killing the open web, part 2

#334

Post by ErroneousBosh »

kuschku wrote: post #324
ErroneousBosh wrote: post #323

Earlier quoted context omitted.

How many people out of the world's nearly eight billion population, would you estimate, are attempting to host their blog including HTML posts and RSS feeds on an Arduino?

A lot of IoT devices use this strategy, actually. A lot . Significantly more than are using e.g. WebUSB. Nonetheless, by that same argument you could just kill HN off. A lot of projects have a benefit that far outweighs their raw usage numbers.

I guess that tracks for Internet of Shitty Insecure Badly-Designed Things.

Come up with the worst possible way to present information over a web page.

What device with 2kB of RAM is going to generate any kind of useful RSS feed? Why would you not use something more capable, which is not only going to have more memory but also a lower power consumption?

Re: Google is killing the open web, part 2

#335

Post by koakuma-chan »

ErroneousBosh wrote: post #316
koakuma-chan wrote: post #253

Earlier quoted context omitted.

I wrote a tool that took screenshots automatically and used FileZilla to upload :) And my comment is in support of removing FTP because it was lame.

Aha, fair. Why the hell did they need you to do that? I used to work in a web dev job where when they brought in "time tracking" they wanted everyone to update a spreadsheet with what they were doing every half an hour. A spreadsheet, as literally a .xls, on a shared Windows drive. Everyone spent more time waiting for access to the spreadsheet than they did doing any work. This situation persisted for about two weeks…

> Why the hell did they need you to do that?

Because it's was a shitty company and I only worked there for one month. I absolutely hate any type of time tracking or attempts to micro manage.

Re: Google is killing the open web, part 2

#336

Post by kuschku »

ErroneousBosh wrote: post #334
kuschku wrote: post #324

Earlier quoted context omitted.

A lot of IoT devices use this strategy, actually. A lot . Significantly more than are using e.g. WebUSB. Nonetheless, by that same argument you could just kill HN off. A lot of projects have a benefit that far outweighs their raw usage numbers.

I guess that tracks for Internet of Shitty Insecure Badly-Designed Things. Come up with the worst possible way to present information over a web page. What device with 2kB of RAM is going to generate any kind of useful RSS feed? Why would you not use something more capable, which is not only going to have more memory but also a lower power consumption?

> What device with 2kB of RAM is going to generate any kind of useful RSS feed?

Such devices usually don't generate RSS feeds, but e.g. sensor measurements as XML (which can be processed directly, or opened in a browser with XSLT to generate a website and an SVG chart from it)

> Why would you not use something more capable, which is not only going to have more memory but also a lower power consumption?

Because anything else will have >100× more power consumption?

Re: Google is killing the open web, part 2

#337

Post by croes »

dpark wrote: post #217
hluska wrote: post #210

Earlier quoted context omitted.

I can’t understand why you’re splitting hairs to this extent. The web is protocols; some are implemented at server side whereas others are implemented at browser side. They’re all still protocols with a big dollop of marketing. That statement was accurate enough if you’re willing to read actively and provide people with the most minimal benefit of the doubt.

My response is in a chain discussing browsers in response to someone who literally said “The web wasn’t the browser it was the protocols.” I responded essentially “it was indeed also the browser”, which it seems you agree with so I don’t know what you’re even trying to argue about. > willing to read actively and provide people with the most minimal benefit of the doubt. Indeed

My point is, you could write your own server and your own browser to participate in the web, but you have to follow the protocols.

Re: Google is killing the open web, part 2

#338

Post by svieira »

akerl_ wrote: post #223
svieira wrote: post #221

Earlier quoted context omitted.

A nice recent example is "smooshgate", wherein it was determined that breaking websites with an older version of Mootools installed was not an acceptable way to move the web forward, so we got `Array.prototype.flat` instead of `Array.prototype.flatten`: https://news.ycombinator.com/item?id=17141024 > I don't recall a part of the web where browser developers were viewed as not having agency Being a servant isn't "not…

I think you're reading way too much into that. For one thing, that's a proposal for Javascript, whose controlling body is TC39. For another, this was a bog standard example of a draft proposal where a bug was discovered, and rollout was adjusted. If that's having a "servant-oriented mindset", so do 99% of software projects.

> this was a bog standard example of a draft proposal where a bug was discovered, and rollout was adjusted

Yes, but the "bug" here was "a single website is broken". Here, we are talking about an outcome that will break many websites (more than removing USB support would break) and that is considered acceptable.

> That's a proposal for Javascript, whose controlling body is TC39

Yes, and the culture of TC39 used to be the culture of those who develop tools for using the web (don't break the Space Jam website, etc.)

Re: Google is killing the open web, part 2

#339

Post by akerl_ »

svieira wrote: post #338
akerl_ wrote: post #223

Earlier quoted context omitted.

I think you're reading way too much into that. For one thing, that's a proposal for Javascript, whose controlling body is TC39. For another, this was a bog standard example of a draft proposal where a bug was discovered, and rollout was adjusted. If that's having a "servant-oriented mindset", so do 99% of software projects.

> this was a bog standard example of a draft proposal where a bug was discovered, and rollout was adjusted Yes, but the "bug" here was "a single website is broken". Here, we are talking about an outcome that will break many websites (more than removing USB support would break) and that is considered acceptable. > That's a proposal for Javascript, whose controlling body is TC39 Yes, and the culture of TC39 used to be…

Where are you seeing that it’s a single website? Mootools is a JavaScript library used by tons of websites.

Also, the entire measurement is fundamentally just part of the decision. Removing Flash broke tons of sites, and it was done anyways because Flash was a nightmare.

Re: Google is killing the open web, part 2

#340

Post by James_K »

shadowgovt wrote: post #277
kuschku wrote: post #173

Earlier quoted context omitted.

> So put them on separate pages because they are separate protocols Would you also suggest I use separate URLs for HTTP/2 and HTTP/1.1? Maybe for a gzipped response vs a raw response? It's the same content, just supplied in a different format. It should be the same URL.

Then the server should supply the right format based on the `Accept` header, be it `application/rss+xml` or `application/atom+xml` or `text/xml` or `text/html`. Even cheaper than shipping the client an XML and an XSLT is just shipping them the HTML the XSLT would output in the first place.

So in other words, no more static sites?
Post reply on HN