4 ms·

I've started advocating for a subset of html5 that - drops all legacy features tht aren't needed to provide documents anymore - provide sane defaults - a cho

I've started advocating for a subset of html5 that - drops all legacy features tht aren't needed to provide documents anymore - provide sane defaults - a choice between - 1) no JS - 2) JS based on a small number of vetted packages for stuff line autocomplete etc No DRM. No JS frameworks. Just plain old HTML goodness plus more modern goodness (autocomplete) on top. In my view there's even room for ads as long as they are injected server side and don't report back anything. Hopefully this could be so much faster that it could become a hit in tech and academic circles.

krapp 7y ago
The problem I have whenever I see arguments along these lines is that nothing is stopping anyone from writing simple HTML using that "subset" if they want to, so a completely separate simpler HTML isn't necessary. If you don't want JS, don't use JS. If you want to vet packages, start a service that vets Node packages. That last part would actually probably be really useful.
- eitland 7y ago
  Almost. The idea is to make our browser extremely much faster than the rest of them for rendering such pages. This should hopefully get people to switch to our new browser and force other browsers to start competing.
  - krapp 7y ago
    Most people don't want the modern web replaced with an extremely minimalist version only good for publishing whitepapers, and they wouldn't want to use a browser that enforces such a restriction. Pages with minimalist HTML already render extremely fast in modern browsers, that's not a problem anyone actually has. So why would other browsers even bother to compete with you? Do they bother competing with Lynx?
    - eitland 7y ago
      No, it doesn't need to be minimalist. Styling is totally OK. And the browser could even be Firefox, just with a separate rendering path if it detects the page is html5core or whatever. Old pages works just as before. New, html5core compliant pages loads blazingly fast and displays just as nice though.
      - krapp 7y ago
        But as far as I can tell, 'html5core' is just a subset of HTML meant for static documents, meaning it's just HTML. There's no reason for that to have its own separate rendering path, or even to be its own thing. The process of validating it as 'html5core' would probably take more time than just rendering it as is.
        eitland 7y ago
        I think you misunderstand. Html and a limited subset of css is OK. I'd try to remove unused constructs but more importantly for the speed: as much as possible of what stands in the way for efficient rendering. In the second model there's even room for limited Javascript, think autocomplete and reloading of parts of a page etc, the only thing is it will work more like components with parameters instead of a Turing complete language. It will definitely not take more time to decide: you add a marker to the start of the document. The browser then sends it the fast path.
- ken 7y ago
  That sounds backwards to me. It's corporations which are generating the vast majority of the HTML in the world. Individuals can stop writing JS (and for content-first websites, I have), but that won't stop us from having to see it. Turning off JS entirely will kill a lot of common webpages, so that's not really an option any more. Instead, everybody runs a content blocker, to try to battle with corporations over what dumb junk we're exposed to, or exposed by. Corporations are also writing most of the popular web browsers. This isn't a fair fight.
  - zzo38computer 7y ago
    I do disable scripts. I find that some web pages will still work if you delete or hide an element that covers up everything else (and the script would presumably hide or delete), or unhide an element that is normally hidden (that the script would normally unhide). This doesn't always work, but sometimes it does.
  - krapp 7y ago
    > Individuals can stop writing JS (and for content-first websites, I have), but that won't stop us from having to see it. And that's the rub. None of this is actually about wanting to improve the web with a sane minimalist subset of HTML, or separating "documents" from "apps", it's about wishing the web never left universities, never got mainstream, and never got complicated by modernity or tainted by capitalism. But you can't put that genie back into the bottle and, honestly, I don't think it should be done were it possible. The modern web enables a great deal of creative freedom and cultural expression which simply wouldn't be possible if it were only plain hypertext documents.
jay_kyburz 7y ago
I have a project I would like to build one day called web 3.0. It's HTML only. No JS or CSS. All styling is done browser side under user control. All interactions are done using simple GET or forms and POST. There are no cookies, and not even hidden form fields, All data you send with a request is visible to the user.
- zzo38computer 7y ago
  I also had similar ideas. Note, however, that doing styling on the browser side under user control is already possible (although due to how CSS works, it doesn't work in the ideal way). Furthermore, what you mention is a subset of existing specifications and can be done easily if you are writing the web page. (I generally do this too when writing my own web pages, although often I will just write plain text instead anyways.) However, there are some features missing from HTML unfortunately; I had a different idea for how icons should have been displayed instead (I posted before on Hacker News), and that there should be a special tag for footnotes, but there isn't. Still, it is probably good enough.
ksec 7y ago
I often thought of the same. Or even more Radical, something that is better than HTML and CSS at presentation but compiled to ( Good ) subset of Modern HTML and CSS. Move more functions to Browsers without the use of Javascripts. At least standardise subset of something like TinyMCE, and Ajax / Pjax. Basically we need to pick all the good part of HTML, CSS, and Javascript without the "Apps" baggage.
zzo38computer 7y ago
Actually, this "JS based on a small number of vetted packages" is similar to my <widget> idea, so that could be how it is implemented. However, another feature I want (which you did not mention) is better user customization, and it would allow that, too. As an example: <script widgettype="http://example.org/ns/widget/unitconv" src="unitconv.js"></script> ...more stuff in between... <li><widget widgettype="http://example.org/ns/widget/unitconv" a-unit="cups:236.5882365mL">4 cups</widget> of water (Although not used above (due to being unneeded in this case), the widgettype attribute is also allowed for <noscript>.) It has the following benefits: - You can host all of the files yourself if you want to; no need for a separate package manager. - Full backward compatibility. - Works with browsers that don't implement <script> or <widget>, as well as browsers that implement one or the other, or both. (However, it needs to implement either <script> or the "unitconv" widget, and one or the other has to be enabled, in order for automatic unit conversion to work.) - The user can disable features they don't want, or customize them. - If <widget> is implemented and enabled, then the script need not be downloaded, even if <script> is implemented and enabled. There are other possibilities too. For example, autocomplete could use wrapping a <input> inside of a <widget>.

krapp 7y ago

The problem I have whenever I see arguments along these lines is that nothing is stopping anyone from writing simple HTML using that "subset" if they want to, so a completely separate simpler HTML isn't necessary. If you don't want JS, don't use JS. If you want to vet packages, start a service that vets Node packages. That last part would actually probably be really useful.

eitland 7y ago
Almost. The idea is to make our browser extremely much faster than the rest of them for rendering such pages. This should hopefully get people to switch to our new browser and force other browsers to start competing.
- krapp 7y ago
  Most people don't want the modern web replaced with an extremely minimalist version only good for publishing whitepapers, and they wouldn't want to use a browser that enforces such a restriction. Pages with minimalist HTML already render extremely fast in modern browsers, that's not a problem anyone actually has. So why would other browsers even bother to compete with you? Do they bother competing with Lynx?
  - eitland 7y ago
    No, it doesn't need to be minimalist. Styling is totally OK. And the browser could even be Firefox, just with a separate rendering path if it detects the page is html5core or whatever. Old pages works just as before. New, html5core compliant pages loads blazingly fast and displays just as nice though.
    - krapp 7y ago
      But as far as I can tell, 'html5core' is just a subset of HTML meant for static documents, meaning it's just HTML. There's no reason for that to have its own separate rendering path, or even to be its own thing. The process of validating it as 'html5core' would probably take more time than just rendering it as is.
      - eitland 7y ago
        I think you misunderstand. Html and a limited subset of css is OK. I'd try to remove unused constructs but more importantly for the speed: as much as possible of what stands in the way for efficient rendering. In the second model there's even room for limited Javascript, think autocomplete and reloading of parts of a page etc, the only thing is it will work more like components with parameters instead of a Turing complete language. It will definitely not take more time to decide: you add a marker to the start of the document. The browser then sends it the fast path.
ken 7y ago
That sounds backwards to me. It's corporations which are generating the vast majority of the HTML in the world. Individuals can stop writing JS (and for content-first websites, I have), but that won't stop us from having to see it. Turning off JS entirely will kill a lot of common webpages, so that's not really an option any more. Instead, everybody runs a content blocker, to try to battle with corporations over what dumb junk we're exposed to, or exposed by. Corporations are also writing most of the popular web browsers. This isn't a fair fight.
- zzo38computer 7y ago
  I do disable scripts. I find that some web pages will still work if you delete or hide an element that covers up everything else (and the script would presumably hide or delete), or unhide an element that is normally hidden (that the script would normally unhide). This doesn't always work, but sometimes it does.
- krapp 7y ago
  > Individuals can stop writing JS (and for content-first websites, I have), but that won't stop us from having to see it. And that's the rub. None of this is actually about wanting to improve the web with a sane minimalist subset of HTML, or separating "documents" from "apps", it's about wishing the web never left universities, never got mainstream, and never got complicated by modernity or tainted by capitalism. But you can't put that genie back into the bottle and, honestly, I don't think it should be done were it possible. The modern web enables a great deal of creative freedom and cultural expression which simply wouldn't be possible if it were only plain hypertext documents.

jay_kyburz 7y ago

I have a project I would like to build one day called web 3.0. It's HTML only. No JS or CSS. All styling is done browser side under user control. All interactions are done using simple GET or forms and POST. There are no cookies, and not even hidden form fields, All data you send with a request is visible to the user.

zzo38computer 7y ago
I also had similar ideas. Note, however, that doing styling on the browser side under user control is already possible (although due to how CSS works, it doesn't work in the ideal way). Furthermore, what you mention is a subset of existing specifications and can be done easily if you are writing the web page. (I generally do this too when writing my own web pages, although often I will just write plain text instead anyways.) However, there are some features missing from HTML unfortunately; I had a different idea for how icons should have been displayed instead (I posted before on Hacker News), and that there should be a special tag for footnotes, but there isn't. Still, it is probably good enough.

ksec 7y ago

I often thought of the same. Or even more Radical, something that is better than HTML and CSS at presentation but compiled to ( Good ) subset of Modern HTML and CSS. Move more functions to Browsers without the use of Javascripts. At least standardise subset of something like TinyMCE, and Ajax / Pjax. Basically we need to pick all the good part of HTML, CSS, and Javascript without the "Apps" baggage.

zzo38computer 7y ago

Actually, this "JS based on a small number of vetted packages" is similar to my <widget> idea, so that could be how it is implemented. However, another feature I want (which you did not mention) is better user customization, and it would allow that, too. As an example: <script widgettype="http://example.org/ns/widget/unitconv" src="unitconv.js"></script> ...more stuff in between... <li><widget widgettype="http://example.org/ns/widget/unitconv" a-unit="cups:236.5882365mL">4 cups</widget> of water (Although not used above (due to being unneeded in this case), the widgettype attribute is also allowed for <noscript>.) It has the following benefits: - You can host all of the files yourself if you want to; no need for a separate package manager. - Full backward compatibility. - Works with browsers that don't implement <script> or <widget>, as well as browsers that implement one or the other, or both. (However, it needs to implement either <script> or the "unitconv" widget, and one or the other has to be enabled, in order for automatic unit conversion to work.) - The user can disable features they don't want, or customize them. - If <widget> is implemented and enabled, then the script need not be downloaded, even if <script> is implemented and enabled. There are other possibilities too. For example, autocomplete could use wrapping a <input> inside of a <widget>.