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

111–120 of 141 posts

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

#111

Post by crazygringo »

teddy-smith wrote: post #100
crazygringo wrote: post #87

Earlier quoted context omitted.

Have you ever written a paper for publication? HTML doesn't support the necessary features. Citations in various formats, footnotes, references to automatically numbered figures and tables, I could go on and on. HTML could certainly be extended to support those, but it hasn't been. That's why we're talking about this.

Come on are you serious? HTML/CSS is more powerful than TEX or PDF. https://csszengarden.com/

Did you fully read my comment? Please point me to where HTML/CSS provide the features I listed.

It doesn't really matter if HTML/CSS is more powerful at a hundred other layout things, if it doesn't provide the absolute necessary features for papers.

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

#112

Post by RandyOrion »

For arXiv papers, I prefer HTML format much more than PDF format.

Compared to PDF format, HTML format is much more accessible because of browsers. Basically I can reuse my browser extensions to do anything I like without hassle, like translation, note taking, sending texts to LLMs, and so on.

For now, arXiv offers two HTML services: the default one in https://arxiv.org/html/xxxx.xxxxx , and the alternative one in https://ar5iv.labs.arxiv.org/html/xxxx.xxxxx , here 'x' is a placeholder for a number or digit.

The most glaring problem of the default HTML service is the coverage of papers. Sometimes it just doesn't work, e.g., https://arxiv.org/html/2505.06708 . The solution may be switch to alternative HTML service, e.g., https://ar5iv.labs.arxiv.org/html/2505.06708 .

Note that alternative HTML service also has coverage problem. Sometimes both HTML services fail, e.g. https://arxiv.org/abs/2511.22625 .

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

#113

Post by o11c »

cluckindan wrote: post #46
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 alone is in fact not a format for displaying/rendering. Done properly, it is a structural representation of the content. (This is often called ”semantic HTML”.) They are converting to HTML to make the content more accessible. Accessibility in this context means a11y, in effect ”more accessible” equates to ”more compatible with screen readers”. While PDF documents can be made accessible, it is way easier to do it…

The hope for semantic HTML died the day they said "stop using , use ", regardless of what the actual purpose of the italics was (it's usually not emphasis).

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

#114

Post by bsder »

austinjp wrote: post #109
bsder wrote: post #107

Earlier quoted context omitted.

> No matter what fancy things you do with superscripts and subscripts, you're not going to be able to do even basic things you need for equations like use a fraction bar, or parentheses that grow in height to match the content inside them. Why not? Things like Arabic ligatures already do that, no?

This is interesting to me, but I am very naive about this. Can you explain, or point to where I could learn more?

I'd start with HarfBuzz: https://github.com/harfbuzz/harfbuzz

That's the open source font shaping engine. It does a lot of work to handle font shaping and rendering for languages that can't really be reduced to characters.

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

#115

Post by notorandit »

Thee problem is the viewer, not the format. We are talking about accessibility and scientific papers, where fancy animations and transitions are not core features.

LaTeX and TeX are the de facto standard for this context and converting all existing documents is a lot of work and energy to be spent for basically little gain, if any.

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

#116

Post by toastal »

hannahnowxyz wrote: post #79
ComputerGuru wrote: post #76

If the Unicode consortium would spend less time and effort on emoji and more on making the most common/important mathematical symbols and notations available/renderable in plain text, maybe we could move past the (LA)TeX/PDF marriage. OpenType and TrueType now (edit: for well over a decade, actually) support the necessary conditional rendering required to perform complicated rendering operations to get sequences of U…

Have you tried a two-pass approach? For example, where prompt #1 is "Which elliptic curves have rational parameterizations?", and then prompt #2 (perhaps to a smaller/faster model like Gemma) is "In the following text, replace all LaTeX-escaped notation with Markdown code blocks and unicode characters. For example, $F_n = F_{n - 1} + F_{n - 2}$ should be replaced with `Fₙ = Fₙ₋₁ + Fₙ₋₂`. ". Although it's not clear ho…

reStructuredText support :math: roles. AsciiDoc has stem blocks. Why do folks keep trying to shoehorn Markdown into everything, creating yet another fork, when there are other lightweight markup languages that support actual features for technical blogs/documentation?

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

#117

Post by constantcrying »

Reading this thread many people do not seem to understand what to the problem even is. What researchers writing Papers want is a low effort/high flexibility way to write documents (Nobody wants to write their paper in HTML). For a paper to be printed it needs to be in some printable format, like PDF. To provide accessibility and accommodate the changing ways papers are read, which is increasingly online, HTML is also a desirable output.

What really is needed is a markup language which natively can target both PDF and HTML. This is something typst is working on, but I am not aware of any other project, which either comes close to the features of LaTeX or supports both target formats.

To me this is the only reasonably way to address the accessibility and usability issues around Papers. Have one markup, with sufficient accessibility features, which simultaneously targets HTML and PDF.

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

#118

Post by tosti »

fooofw wrote: post #92
Tagbert wrote: post #6

Earlier quoted context omitted.

From the paper... Why "experimental" HTML? Did you know that 90% of submissions to arXiv are in TeX format, mostly LaTeX? That poses a unique accessibility challenge: to accurately convert from TeX—a very extensible language used in myriad unique ways by authors—to HTML, a language that is much more accessible to screen readers and text-to-speech software, screen magnifiers, and mobile devices. In addition to the tec…

It's kind of fun to compare this formulation with the seemingly contradictory official arXiv argument for submitting the TeX source [1]: > 1. TeX has many advantages that make it ideal as a format for the archives: It is plain text, it is compact, it is freely available for all platforms, it produces extremely high-quality output, and it retains contextual information. > 2. It is thus more likely to be a good source…

Working with both at the same time makes their strengths and pitfalls shine. It's like that dual-boot computer where you're constantly in the wrong OS.

HTML has better separation of concerns than latex. Latex does typesetting a lot better than html. HTML layout can differ wildly in the same document. Latex documents are easier to layout in the first place.

...etc...

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

#120

Post by fph »

pwdisswordfishy wrote: post #81
percentcer wrote: post #80

Dumb question but what stops browsers from rendering TeX directly (aside from the work to implement it)? I assume it's more than just the rendering

For starters, TeX is Turing-complete, and the tokenizer is arbitrarily reprogrammable at runtime.

As far as I know the Tex team has been working hard lately on supporting accessible "tagged pdfs". Hopefully one day Tex/Latex output will be accessible by default and conversion to HTML will not be needed.
Post reply on HN