3 ms·

There is nothing wrong with HTML evolving, the problem is that it has evolved in the completely wrong direction. HTML should be a document language, yet it has

There is nothing wrong with HTML evolving, the problem is that it has evolved in the completely wrong direction. HTML should be a document language, yet it has barely improved in that in the last 20 years and is still missing really basic features (e.g. long-form document support). Instead it can talk to my Bluetooth devices and my camera. Something went very wrong in the evolution of HTML. It's nice that we have a portable app platform now, but I really wish that would be a separate thing from the document centric Web, which slowly but surely is getting killed and replaced by a bunch of always-online apps.

onion2k 4y ago
HTML should be a document language, yet it has barely improved in that in the last 20 years and is still missing really basic features (e.g. long-form document support). I'm not sure what features you mean. Most things I can think of for long form content are right there in HTML. Instead it can talk to my Bluetooth devices and my camera. Something went very wrong in the evolution of HTML. That's not HTML though. That's not even really browsers and JavaScript. It's just Google and Chrome, and even then it's mainly there so it's available in ChromeOS more than the Chrome-the-browser. They just happen to share the same 'engine'. A random webpage is not hax0ring your bluetooth devices. They're very tightly coupled, so sometimes it's hard to see where one stops and the other begins, but Web Bluetooth has nothing to do with HTML. You only need look at the compatibility chart to see that - https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetoo...
- grumbel 4y ago
  > I'm not sure what features you mean. Most things I can think of for long form content are right there in HTML. If you publish a book as plain HTML scrolling becomes impossible, as any tiny movement will catapult you numerous pages forward. You can't bookmark a scroll position either and neither can you link it. If you split the document into multiple HTML files, you complete break the ability to search across the whole document. Performance also breaks down with long form documents. There is of course .epub, which fixes some of those short comings, but epub is not part of the Web, not supported by any browser and requires a separate app. So it really doesn't fix the fundamental problems either. There is also 'link rel=next/prev' that in theory would allow working around some of those issues as well, but that hasn't been supported in any browser as far as I know. If HTML would be any good at handling documents we wouldn't still be using PDF all the time.
  - acdha 4y ago
    > If you publish a book as plain HTML scrolling becomes impossible, as any tiny movement will catapult you numerous pages forward. This isn't true on any popular browser or platform. Single-page scrolling using the keyboard, mouse, or touchscreen is built-in for all common browsers and scrolling even extremely large documents has been fine for at least a decade – unless you load it up with tons of JavaScript even in the ranges of thousands of pages will be at least as snappy as a PDF. > You can't bookmark a scroll position either and neither can you link it. You can't, and also wouldn't want to since that's inherently unstable (e.g. I resize the window slightly and all of the links break). What you can do is what people have been doing since around 1993 and put anchors on logical sections, paragraphs, etc. so you have a linkable stable anchor which doesn't depend on the window or font size.
    - account42 4y ago
      > You can't, and also wouldn't want to since that's inherently unstable (e.g. I resize the window slightly and all of the links break). What you can do is what people have been doing since around 1993 and put anchors on logical sections, paragraphs, etc. so you have a linkable stable anchor which doesn't depend on the window or font size. Except there is no way to expose such anchors to the user without cluttering up the display. Giving users the option to create a bookmark to the nearest id-ed element + offset (perhaps with extensions to let the website specify which elements to consider) is an example of document support that is missing from browsers. Chrome does have an extension to bookmark text fragments: https://support.google.com/chrome/answer/10256233?hl=en&co=GENIE.Platform%3DDesktop https://support.google.com/chrome/answer/10256233?hl=en&co=G... Something like this should be standardized and also include a nearby ID to help find the location when the text changes. Most pages also don't change that significantly/often and if they do they can just disappear entirely so anchor links aren't that stable either. Most browsers already do remember your scroll position when you refresh the page because even if it sometimes gets you to a different part becaus the preceding content changed it is still useful most of the time.
      - acdha 4y ago

onion2k 4y ago

HTML should be a document language, yet it has barely improved in that in the last 20 years and is still missing really basic features (e.g. long-form document support). I'm not sure what features you mean. Most things I can think of for long form content are right there in HTML. Instead it can talk to my Bluetooth devices and my camera. Something went very wrong in the evolution of HTML. That's not HTML though. That's not even really browsers and JavaScript. It's just Google and Chrome, and even then it's mainly there so it's available in ChromeOS more than the Chrome-the-browser. They just happen to share the same 'engine'. A random webpage is not hax0ring your bluetooth devices. They're very tightly coupled, so sometimes it's hard to see where one stops and the other begins, but Web Bluetooth has nothing to do with HTML. You only need look at the compatibility chart to see that - https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetoo...

grumbel 4y ago
> I'm not sure what features you mean. Most things I can think of for long form content are right there in HTML. If you publish a book as plain HTML scrolling becomes impossible, as any tiny movement will catapult you numerous pages forward. You can't bookmark a scroll position either and neither can you link it. If you split the document into multiple HTML files, you complete break the ability to search across the whole document. Performance also breaks down with long form documents. There is of course .epub, which fixes some of those short comings, but epub is not part of the Web, not supported by any browser and requires a separate app. So it really doesn't fix the fundamental problems either. There is also 'link rel=next/prev' that in theory would allow working around some of those issues as well, but that hasn't been supported in any browser as far as I know. If HTML would be any good at handling documents we wouldn't still be using PDF all the time.
- acdha 4y ago
  > If you publish a book as plain HTML scrolling becomes impossible, as any tiny movement will catapult you numerous pages forward. This isn't true on any popular browser or platform. Single-page scrolling using the keyboard, mouse, or touchscreen is built-in for all common browsers and scrolling even extremely large documents has been fine for at least a decade – unless you load it up with tons of JavaScript even in the ranges of thousands of pages will be at least as snappy as a PDF. > You can't bookmark a scroll position either and neither can you link it. You can't, and also wouldn't want to since that's inherently unstable (e.g. I resize the window slightly and all of the links break). What you can do is what people have been doing since around 1993 and put anchors on logical sections, paragraphs, etc. so you have a linkable stable anchor which doesn't depend on the window or font size.
  - account42 4y ago
    > You can't, and also wouldn't want to since that's inherently unstable (e.g. I resize the window slightly and all of the links break). What you can do is what people have been doing since around 1993 and put anchors on logical sections, paragraphs, etc. so you have a linkable stable anchor which doesn't depend on the window or font size. Except there is no way to expose such anchors to the user without cluttering up the display. Giving users the option to create a bookmark to the nearest id-ed element + offset (perhaps with extensions to let the website specify which elements to consider) is an example of document support that is missing from browsers. Chrome does have an extension to bookmark text fragments: https://support.google.com/chrome/answer/10256233?hl=en&co=GENIE.Platform%3DDesktop https://support.google.com/chrome/answer/10256233?hl=en&co=G... Something like this should be standardized and also include a nearby ID to help find the location when the text changes. Most pages also don't change that significantly/often and if they do they can just disappear entirely so anchor links aren't that stable either. Most browsers already do remember your scroll position when you refresh the page because even if it sometimes gets you to a different part becaus the preceding content changed it is still useful most of the time.
    - acdha 4y ago