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

351–360 of 362 posts

Re: Google is killing the open web, part 2

#351

Post by ErroneousBosh »

kuschku wrote: post #336
ErroneousBosh wrote: post #334

Earlier quoted context omitted.

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 anythi…

Compare the power consumption of the atmega328p on an Arduino Uno 3 mentioned further up this thread, with the power consumption of literally any ARM chip smaller than the sort of thing you'd use in a laptop.

Re: Google is killing the open web, part 2

#352

Post by ErroneousBosh »

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…

> Maybe! How much Javascript would I have to learn before I could come up with a 'trivial' solution?

Less than the amount of XSL you'd need.

> Those hundreds of lines are the same copy/pasted if statement with 5 different conditions.

With a programming language, you could have used loops.

Re: Google is killing the open web, part 2

#353

Post by James_K »

shadowgovt wrote: post #350
James_K wrote: post #346

Earlier quoted context omitted.

A static site cannot inspect headers. There is no HTML, or even JavaScript function you can put in a file to inspect the headers before the file is sent to the client. A static site is a collection of static files. It doesn't need a server, you could just open it locally (in browsers that don't block file:// URI schemes). If you need some special configuration of the server, it is no longer a static site. The server…

Oh, difference in definitions. You mean "non-configurable web server." Because you could definitely use a static site generator to create multiple versions of the site data and then configure your web server to select which data is emitted. But agreed; if your web server is just reflecting the filesystem, add this to the pile of "things that are hard with that kind of web server." But perhaps worth noting: even Apach…

A static site is one that you can serve through static hosting, where you have no control over the web server or its configuration. There is not some extra thing which is a static site with dynamic content. “Static” means “doesn't change.” The document served doesn't change subject to the person receiving it. You are talking about a solution that is dynamic. That does change based on who is making the request.

>you could definitely use a static site generator to create multiple versions of the site data and then configure your web server to select which data is emitted

And this web-server configuration would not exist within the static site. The static site generator could not output it, therefore it is not a part of the static site. It is not contained within the files output by the static site generator. It is additional dynamic content added by the web server.

It breaks the fundamental aspect of a static site, that it can be deployed simply to any service without change to the content. Just upload a zip file, and you are done.

Re: Google is killing the open web, part 2

#354

Post by ndriscoll »

ErroneousBosh wrote: post #352
basscomm wrote: post #325

Earlier quoted context omitted.

> 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…

> Maybe! How much Javascript would I have to learn before I could come up with a 'trivial' solution? Less than the amount of XSL you'd need. > Those hundreds of lines are the same copy/pasted if statement with 5 different conditions. With a programming language, you could have used loops.

What an odd comment to have as a sibling to mine from yesterday showing how to do it with two small templates in xsl (after a minor tweak to the xml):

  
  
  
    Skylanders figureNote
No explicit loops necessary.

Re: Google is killing the open web, part 2

#355

Post by shadowgovt »

James_K wrote: post #353
shadowgovt wrote: post #350

Earlier quoted context omitted.

Oh, difference in definitions. You mean "non-configurable web server." Because you could definitely use a static site generator to create multiple versions of the site data and then configure your web server to select which data is emitted. But agreed; if your web server is just reflecting the filesystem, add this to the pile of "things that are hard with that kind of web server." But perhaps worth noting: even Apach…

A static site is one that you can serve through static hosting, where you have no control over the web server or its configuration. There is not some extra thing which is a static site with dynamic content. “Static” means “doesn't change.” The document served doesn't change subject to the person receiving it. You are talking about a solution that is dynamic. That does change based on who is making the request. >you c…

Like I said, difference in definitions. https://www.google.com/search?q=static+site+serving+with+apa...

I get your meaning; I've just heard "static site" used to refer to a site where the content isn't dynamically computed at runtime, not a site where the server is doing a near-direct-mapping from the filesystem to the HTTP output.

> Just upload a zip file, and you are done.

This is actually how I serve my static sites via Dreamhost. The zipfile includes the content negotiation rules in the `.htaccess` file.

(Perhaps worth remembering: even the rule "the HTTP responses are generated by looking up a file matching the path in the URL and echoing that file as the body of the GET response" is still a per-server rule; there's no aspect of the HTTP spec that declares "The filesystem is directly mirrored to web access" is a thing. It's rather a protocol used by many simple web servers, and most of them allow overrides to do something slightly more complicated while being one step away from "this is just the identity function on whatever is in your filesystem, well, not technically the identity function because unless someone did something very naughty, I don't serve anything for http://example.com/../uhoh-now-i-am-in-your-user-directory").

Re: Google is killing the open web, part 2

#356

Post by svieira »

akerl_ wrote: post #339
svieira wrote: post #338

Earlier quoted context omitted.

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

https://news.ycombinator.com/item?id=17141024 links to https://developer.chrome.com/blog/smooshgate which says:

> Shipping the feature in Firefox Nightly caused at least one popular website to break.

and links to https://bugzilla.mozilla.org/show_bug.cgi?id=1443630 which points to a single site as being broken. There's no check as to the size of the impacted user base, but there is a link in the blog post to https://www.w3.org/TR/html-design-principles/#support-existi... which says:

> Existing content often relies upon expected user agent processing and behavior to function as intended. Processing requirements should be specified to ensure that user agents implementing this specification will be able to handle most existing content. In particular, it should be possible to process existing HTML documents as HTML 5 and get results that are compatible with the existing expectations of users and authors, based on the behavior of existing browsers. It should be made possible, though not necessarily required, to do this without mode switching.

> Content relying on existing browser behavior can take many forms. It may rely on elements, attributes or APIs that are part of earlier HTML specifications, but not part of HTML 5, or on features that are entirely proprietary. It may depend on specific error handling rules. In rare cases, it may depend on a feature from earlier HTML specifications not being implemented as specified

Which is the "servant-oriented" mindset I'm talking about here.

> Removing Flash broke tons of sites

Yes, but Flash wasn't part of a standard, it was an ad-hoc thing that each browser _happened_ to support (rough consensus and working code). There were no "build on this and we'll guarantee it will continue to work" agreement between authors and implementers of the web. XSLT 1.0, as painful as it is, is part of that agreement.

Re: Google is killing the open web, part 2

#357

Post by akerl_ »

svieira wrote: post #356
akerl_ wrote: post #339

Earlier quoted context omitted.

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.

https://news.ycombinator.com/item?id=17141024 links to https://developer.chrome.com/blog/smooshgate which says: > Shipping the feature in Firefox Nightly caused at least one popular website to break. and links to https://bugzilla.mozilla.org/show_bug.cgi?id=1443630 which points to a single site as being broken. There's no check as to the size of the impacted user base, but there is a link in the blog post to https://…

I think you’re pretty off-base about how web standards work and how much of an “agreement” they constitute.

Flash doesn’t have an RFC because it was a commercial design by Adobe, not because it wasn’t a defined spec that was supported by browsers.

Meanwhile SSLv2 and v3 and FTP and gopher have RFCs and have been removed.

Making an RFC about a technology is not a commitment of any kind to support it for any length of time.

You’ve conjured a mystique around historical browser ideology that doesn’t exist, and that’s why what you’re seeing today that feel at odds with that fantasy.

Re: Google is killing the open web, part 2

#358

Post by righthand »

shadowgovt wrote: post #302
righthand wrote: post #296

Earlier quoted context omitted.

Yes while their chosen formats directly aligned with their business get first class citizenship and suffer many larger and well known security issues. Xml will be next just wait.

What would that mean? XML is just text on the wire. If a browser stops supporting it... It's text on the wire. I slurp it in with JavaScript and parse it how I want. ... Actually, that seems like a fine idea...

Great lets remove the Html and Css renders too then. I can just slurp it in with Javascript and parse it how you want. No standards, do what you want!

Re: Google is killing the open web, part 2

#359

Post by svieira »

akerl_ wrote: post #357
svieira wrote: post #356

Earlier quoted context omitted.

https://news.ycombinator.com/item?id=17141024 links to https://developer.chrome.com/blog/smooshgate which says: > Shipping the feature in Firefox Nightly caused at least one popular website to break. and links to https://bugzilla.mozilla.org/show_bug.cgi?id=1443630 which points to a single site as being broken. There's no check as to the size of the impacted user base, but there is a link in the blog post to https://…

I think you’re pretty off-base about how web standards work and how much of an “agreement” they constitute. Flash doesn’t have an RFC because it was a commercial design by Adobe, not because it wasn’t a defined spec that was supported by browsers. Meanwhile SSLv2 and v3 and FTP and gopher have RFCs and have been removed. Making an RFC about a technology is not a commitment of any kind to support it for any length of…

Flash was a plugin to the browser ecosystem that no one ever made a commitment to other than "here it is".

SSLv2 and v3 all are protocol versions that anyone can still support, and removing support for them breaks certain web properties. This is less of a problem because the implementations of the protocol are themselves time-limited (you can't get an SSL certificate that is valid until the heat death of the universe).

FTP and gopher support wasn't removed from the browser without a redirect (you can install an FTP client or a Gopher client and the browser will still route-out-to-it).

The point isn't "RFC = commitment", the point is that "the culture of the web" has, for a very long time, been "keep things working for the users" and doing something like removing built-in FTP support was something that was a _long_ time in coming. Whereas, as I understand it, there is a perfectly valid way forward for continuing to support this tech as-is in a secure manner (WASM-up-the-existing-lib) and instead of doing that, improving security for everyone and keeping older parts of the web online, the developers of the browsers have decided that "extra work" of writing that one-time integration and keeping it working in perpetuity is too burdensome for _them_. It feels like what is being said by the browser teams is, "Yes, broken websites are bad for end users, yes, there are more end users than developers, yes, those users are less technical and therefore likely are going to loose access to goods they previously had ... but c'est la vie. Use {Dusk, Temple}OS if you don't want the deal altered any further." And I object to what I perceive as a lack of consideration of those who use the web. Who are the people that we serve.

Re: Google is killing the open web, part 2

#360

Post by akerl_ »

svieira wrote: post #359
akerl_ wrote: post #357

Earlier quoted context omitted.

I think you’re pretty off-base about how web standards work and how much of an “agreement” they constitute. Flash doesn’t have an RFC because it was a commercial design by Adobe, not because it wasn’t a defined spec that was supported by browsers. Meanwhile SSLv2 and v3 and FTP and gopher have RFCs and have been removed. Making an RFC about a technology is not a commitment of any kind to support it for any length of…

Flash was a plugin to the browser ecosystem that no one ever made a commitment to other than "here it is". SSLv2 and v3 all are protocol versions that anyone can still support, and removing support for them breaks certain web properties. This is less of a problem because the implementations of the protocol are themselves time-limited (you can't get an SSL certificate that is valid until the heat death of the universe…

It’s interesting that you are trying really really hard to explain away every counter example.

C’est la vie, I suppose.

Post reply on HN