Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTML as an Accessible Format for Papers (2023)

info.arxiv.org

Post reply on HN
Print view View original

31–40 of 141 posts

Re: HTML as an Accessible Format for Papers (2023)

#31

Post by simonw »

billconan wrote: post #27
dimal wrote: post #24

Earlier quoted context omitted.

Perfect is the enemy of good. HTML is good enough. Let’s get this done. And as another commenter has pointed out, HTML does exactly what you ask for. If it’s done correctly, it doesn’t contain font sizes or layout. Users can style HTML differently with custom CSS.

mixing rendering definitions with content (PDF) is something from the printer era, that is unsuitable for the digital era. HTML was a digital format, but it wanted to be a generic format for all document types, not just papers, so it contains a lot of extras that a paper format doesn't need. for research papers, since they share the same structure, we can further separate content from rendering. for example, if you w…

All of the interesting LLMs can handle a full paper these days without any trouble at all. I don't think it's worth spending much time optimizing for that use-case any more - that was much more important two years ago when most models topped out at 4,000 or 8,000 tokens.

Re: HTML as an Accessible Format for Papers (2023)

#33

Post by devnull3 »

vatsachak wrote: post #29

Why do we like HTML more than pdfs? HTML rendering requires you to be connected to the internet, or setting up the images and mathJax locally. A PDF just works. HTML obviously supports dynamic embedding, such as programs, much better but people just usually post a github.io page with the paper.

> HTML rendering requires you to be connected to the internet

Not really. One can always generate a self-contained html. Both CSS and JS (if needed) can be inline.

Re: HTML as an Accessible Format for Papers (2023)

#34

Post by recursive »

vatsachak wrote: post #29

Why do we like HTML more than pdfs? HTML rendering requires you to be connected to the internet, or setting up the images and mathJax locally. A PDF just works. HTML obviously supports dynamic embedding, such as programs, much better but people just usually post a github.io page with the paper.

Why would html rendering require a network connection? It doesn't seem to on my machine.

Re: HTML as an Accessible Format for Papers (2023)

#35

Post by tefkah »

teddy-smith wrote: post #32

It's extremely easy to convert HTML/CSS to a PDF with the print to PDF feature of the browser. All papers should be in HTML/CSS or Tex then just simply converted to PDF. Why are we even talking about this?

What are you talking about? No one’s writing their paper in HTML.

The problem is having the submissions be in TeX and converting that to HTML, when the only output has been PDF for so long.

The problem isn’t converting HTML to PDF, it’s making available a giant portion of TeX/pdf only papers in HTML.

If you’re arguing that maybe TeX then shouldn’t be the source format for papers then I agree, but other than Typst (which also isn’t perfect about HTML output yet) there aren’t that many widely accepted/used authoring formats for physics/math papers, which is what ArXiV primarily hosts.

Re: HTML as an Accessible Format for Papers (2023)

#36

Post by ACCount37 »

bob1029 wrote: post #28
billconan wrote: post #21

I don't think HTML is the right approach. HTML is better than PDF, but it is still a format for displaying/rendering. the actual paper content format should be separated from its rendering. i.e. it should contain abstract, sections, equations, figures, citations etc. but it shouldn't have font sizes, layout etc. the viewer platforms then should be able to style the content differently.

> HTML is better than PDF I disagree. PDF is the most desirable format for printed media and its analogues. Any time I plan to seriously entertain a paper from Arxiv, I print it out first. I prefer to have the author's original intent in hand. Arbitrary page breaks and layout shifts that are a result of my specific hardware/software configuration are not desirable to me in this context of use.

I agree that PDF is best for things that are meant to be printed, no questions. But I wonder how common actually printing those papers is?

In research and in embedded hardware both, I've met some people who had entire stacks of papers printed out - research papers or datasheets or application notes - but also people who had 3 monitors and 64GB of RAM and all the papers open as browser tabs.

I'm far closer to the latter myself. Is this a "generational split" thing?

Re: HTML as an Accessible Format for Papers (2023)

#37

Post by afavour »

bawolff wrote: post #30
afavour wrote: post #25

Earlier quoted context omitted.

Sounds like XML and XSL would be a great fit here. Shame it’s being deprecated. But you could still use HTML. Elements with a dash in are reserved for custom elements (that is, a new standardised element will never take that name) so you could do: And it would be valid HTML. Then you’d style it with CSS, with paper-author { display: list-item; } And so on.

Nothing is stopping you from using server side XSL. I personally dont think its a great fit, but people need to stop acting like xsl has been wiped from the face of the earth.

Yes but we’re specifically talking about a display format here. Something requiring a server side transform before being viewable by a user is a clear step backwards.

Re: HTML as an Accessible Format for Papers (2023)

#38

Post by kevindamm »

panzi wrote: post #26
billconan wrote: post #23

Earlier quoted context omitted.

no abstract text ... author one author two should be just: [abstract] abstract text [authors] author one | email | affiliation author two | email | affiliation

There is , but yes, and is missing as such. But there are meta tags for such things. Then there is RDF and Thing. Not quite the same, I know, but it's not completely useless.

and you could shim these gaps with custom components, hypothetically

Re: HTML as an Accessible Format for Papers (2023)

#39

Post by cubefox »

This is not new, the title should say (2023). They have shipped the HTML feature with "experimental" flag for two years now, but I don't know whether there is even any plan to move out of the experimental phase.

It's not much of an "experiment" if you don't plan to use some experimental data to improve things somehow.

Re: HTML as an Accessible Format for Papers (2023)

#40

Post by nkrisc »

teddy-smith wrote: post #32

It's extremely easy to convert HTML/CSS to a PDF with the print to PDF feature of the browser. All papers should be in HTML/CSS or Tex then just simply converted to PDF. Why are we even talking about this?

So, uh, where do the HTML versions of the papers come from?
Post reply on HN