4 ms·

> 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

> 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
    > > 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. 1. Using unobtrusive anchors isn't that bad as far as clutter goes — if you have a discrete octothorpe or paragraph symbol consistently at the start or end of a paragraph it's not the end of the world, especially if they're styled to be in the margin outside of normal text flow. 2. Since approximately late 1995, people have used JavaScript to only display those symbols on hover/focus. This works well and is pretty common around the web. I'm not saying that there isn't room for improvement such as Chrome's extension but when there's 3 decades of common usage for something you say can't be done it suggests that the probably isn't that it's impossible but that there isn't enough social pressure to make publishers _want_ to publish books as HTML. Examples of massive documents are easy enough to find (e.g. W3C specs) so I'd prefer to spend time thinking about why other people aren't (e.g. DRM) and what you can do about the real problems.
onion2k 4y ago
Those are all flaws in browsers, not HTML. In the case of bookmarks that's not even a part of HTML. There's nothing stopping browser vendors solving the problems you're talking about but then you'll probably worry that browsers are becoming operating systems or something.
- grumbel 4y ago
  A bookmark is just a link and links are part of HTML. If you only workaround those issues only at the client level you aren't fixing anything, as the Web will still be crippled just the same. You need better ways to link content on the Web itself.
  - onion2k 4y ago
    A bookmark is just a link and links are part of HTML. Bookmarks are entirely part of the browser UI. They're an entry in a database of URLs that the browser presents to the user, and when the user clicks on one it tells the browser to navigate to that address. There is absolutely no HTML involved.

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
  > > 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. 1. Using unobtrusive anchors isn't that bad as far as clutter goes — if you have a discrete octothorpe or paragraph symbol consistently at the start or end of a paragraph it's not the end of the world, especially if they're styled to be in the margin outside of normal text flow. 2. Since approximately late 1995, people have used JavaScript to only display those symbols on hover/focus. This works well and is pretty common around the web. I'm not saying that there isn't room for improvement such as Chrome's extension but when there's 3 decades of common usage for something you say can't be done it suggests that the probably isn't that it's impossible but that there isn't enough social pressure to make publishers _want_ to publish books as HTML. Examples of massive documents are easy enough to find (e.g. W3C specs) so I'd prefer to spend time thinking about why other people aren't (e.g. DRM) and what you can do about the real problems.

onion2k 4y ago

Those are all flaws in browsers, not HTML. In the case of bookmarks that's not even a part of HTML. There's nothing stopping browser vendors solving the problems you're talking about but then you'll probably worry that browsers are becoming operating systems or something.

grumbel 4y ago
A bookmark is just a link and links are part of HTML. If you only workaround those issues only at the client level you aren't fixing anything, as the Web will still be crippled just the same. You need better ways to link content on the Web itself.
- onion2k 4y ago
  A bookmark is just a link and links are part of HTML. Bookmarks are entirely part of the browser UI. They're an entry in a database of URLs that the browser presents to the user, and when the user clicks on one it tells the browser to navigate to that address. There is absolutely no HTML involved.