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

61–70 of 141 posts

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

#61

Post by m-schuetz »

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.

That's a purist stance that's never going to work out in praxtice. Authors will always want to adjust the presentation of content, and html might be even better suited for that than Latex, which as bad at both.

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

#62

Post by carlosjobim »

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?

Except you can't have page breaks, three links in a row, anchor links.

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

#63

Post by vatsachak »

devnull3 wrote: post #33
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.

True but the webdev idiom is injecting things such as mathjax from a cdn. I guess one can pre-render the page and save that, but that's kind of like a PDF already

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

#64

Post by vatsachak »

recursive wrote: post #34
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.

Things like LaTeX equation rendering are hosted on a cdn

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

#65

Post by krapp »

vatsachak wrote: post #64
recursive wrote: post #34

Earlier quoted context omitted.

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

Things like LaTeX equation rendering are hosted on a cdn

They can be but don't need to be. Any javascript can be localized like HTML and CSS.

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

#66

Post by DominikPeters »

As an arXiv author who likes using complicated TeX constructions, the introduction of HTML conversion has increased my workload a lot trying to write fallback macros that render okay after conversion. The conversion is super slow and there is no way to faithfully simulate it locally. Still I think it's a great thing to do.

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

#69

Post by bawolff »

afavour wrote: post #37
bawolff wrote: post #30

Earlier quoted context omitted.

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.

How so? I can't think of any advantage to having client side xsl over outputting two files, in this context.

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

#70

Post by sansseriff »

JadeNB wrote: post #54
sansseriff wrote: post #41

Earlier quoted context omitted.

Seriously. More people need to wake up to this. Older generations can keep arguing over display formats if they want. Meanwhile younger undergrad and grad students are getting more and more accustomed to LLMs forming the front end for any knowledge they consume. Why would research papers be any different.

> Meanwhile younger undergrad and grad students are getting more and more accustomed to LLMs forming the front end for any knowledge they consume. Well, that's terrifying. I mean, I knew it about undergrads, but I sure hoped people going into grad school would be aware of the dangers of making your main contact with research, where subtle details are important, through a known-distorting filter. (I mean, I'd still be…

I admit it has dystopian elements. It’s worth deciding what specifically is scary though. The potential fallibility or mistakes of the models? Check back in a few months. The fact they’re run by giant corps which will steal and train on your data? Then run local models. Their potential to incorporate bias or persuade via misalignment with the reader’s goals? Trickier to resolve, but various labs and nonprofits are working on it.

In some ways I’m scared too. But that’s the way things are going because younger people far prefer the interface of chat and question answering to flipping through a textbook.

Even if AI makes more mistakes or is more misaligned with the reader’s intentions than a random human reviewer (which is debatable in certain fields since the latest models game out), the behavior of young people requires us to improve the reputability of these systems. (Make sure they use citations, make sure they don’t hallucinate, etc). I think the technology is so much more user friendly that fixing the engineering bugs will be easier than forcing new generations to use the older systems.

Post reply on HN