Hacker News new | past | comments | ask | show | jobs | submit login

> HTML Lite

Couldn't agree more with this. People approximate it with e.g. noscript, it would be awesome to have a standard which describes a minimal HTML Lite spec though.

Edit: It would be awesome as another option in the link context menu: open in new tab, open in incognito tab, open in lite tab




Having this enforced by the browser as a mode would be brilliant. The HTML stack has grown enormous, with it the potential for a abuse and misuse. If you are just looking for a digital version of paper, so to speak, 95% of that is simply completely unnecessary.

Right now the AMP CDN enforces the restrictions of AMP (you can't simply pretend it conforms to AMP to Google and then feed the client something else) which is something that is fundamentally misunderstood when this is discussed on HN. AMP is a protection and guarantee of behavior for the user, it is not for the publisher, it is not for the developer. Google has a profound vested interest in trying to maintain people's interest in the web, especially in the face of various alternative walled gardens like Facebook feeds, Apple News, etc.


> Google has a profound vested interest in trying to maintain people's interest in the web, especially in the face of various alternative walled gardens like Facebook feeds, Apple News, etc.

To me, AMP is just Google trying to turn the open web in its own walled garden.


there's NOTHING technically requiring google to serve AMP from their own domain. None of the benefits you cited answered that. AMP could just be another standard where the basic lib is preloaded.


I feel like this conversation, like all AMP conversations, is going in circles, spittle-filled comments denoted by unnecessary angry screeds of all caps.

Yes, right now there is a technical need for an intermediary because it guarantees AMP is actually AMP. It is trivial for a page to say it's AMP, load the AMP standard library, and then do everything disallowed by AMP. There is absolutely nothing preventing that but that intermediary rejecting non-compliant content.

Now of course we've talked about an HTML Light and that would be the browser enforcing that limited sandbox. It could send a relevant cookie and then reject content that steps outside the bounds. But we don't have that right now.


> Yes, right now there is a technical need for an intermediary because it guarantees AMP is actually AMP. It is trivial for a page to say it's AMP, load the AMP standard library, and then do everything disallowed by AMP. There is absolutely nothing preventing that but that intermediary rejecting non-compliant content.

That's because the standard is not well defined. If you had a doctype just for AMP at the top, that would work. I don't see any technical reason why google's servers are necessary. I see a business reason for Google of course but there's nothing technically that makes sense.

> Now of course we've talked about an HTML Light and that would be the browser enforcing that limited sandbox. It could send a relevant cookie and then reject content that steps outside the bounds. But we don't have that right now.

Well, AMP could be just that if it was standardized.


Good idea. As a starting point, let's define "HTML Lite" as "HTML without Javascript".

Then "HTML Fat" and "HTML Light" could even be served as one document. If you execute the Javascript, you get the fat version. Else, you get the light version.

If you use Javascript not just to improve the behaviour but also to display content at all, you can provide fallback content that is only displayed in light mode. The fallback content is marked by a special tag. Let's call it `noscript`.

My point is: Making it easier to serve sane and lightweight HTML will not help fix the problem. Publishers don't want to do that, they like all that crap. If we want them to make sane web pages, we must force them.


Reader Mode on Safari maybe?


Maybe roll back to an old browser?


Along with all the security risks? Or do I get to choose just the good parts? :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: