
HTML as TeX replacement - epeus
http://www.kevinmarks.com/htmlversustex.html
======
dozzie
> [...] HTML doesn't give as much typographic control as TEΧ, but when you
> compare to the full web suite, including CSS and SVG, that conclusion can't
> be sustained

And the very formula that was a proof that HTML+CSS+SVG is enough shows that
it _is not_ enough. In my browser it looks terrible, subscripts and
superscripts are mixed, font is uneven, and what not. The formula is simply
unreadable, in the sense that I can't decipher it, not merely it's awful to
look at.

Moving out of TeX ground to HTML+stuff, you instantly give up plenty of goods
that were implemented in TeX well (kerning and hyphenation among the others),
you give up consistency of behaviour (font rendering), and in exchange you get
source code that looks obnoxious compared to pure TeX or LaTeX.

~~~
iamsohungry
And to expand on this, it's not even just display failings, it's also semantic
failings. There's no way I know of to do footnotes in HTML/CSS/SVG in a
reasonable way. I'd want something like:

    
    
        <p>Some text.<footnote>Footnote text</footnote> Some more text.</p>
    

...to be rendered as something like:

    
    
        Some text.[1] Some more text.
    

And at the bottom of the page:

    
    
        [1] Footnote text.
    

But as far as I know there's no reasonable way to do this. There are similar
problems for tables of contents, bibliographies, numbered figures, etc.

The idea that HTML is semantic in practice is pretty laughable.

All that said, I'd have a lot of objections to someone writing a "Using LaTeX
as an HTML replacement" article. LaTeX is better designed overall, but they're
also designed for fundamentally different use-cases.

~~~
carlob
Funnily enough Knuth was opposed to footnotes (or maybe it was his wife). Only
at the behest of some colleagues in the humanities were they later added in
TeX.

~~~
scott_s
Footnotes have their uses [1].

[1] Particularly when you have to say something which is almost, but not quite
right, and because you're writing an academic paper, you're both worried that
a reviewer will dock you for being so naive, and as an academic it pains you
to say something which is not technically correct, but you have this pesky 10
page limit, so you stuff the pedantry in scriptsize font on the bottom of the
page.

~~~
iamsohungry
Eh, don't ever say things that aren't correct. It's not wrong to say that
something is a way of approximating or whatever; use your linguistic
qualifiers. If you need more space, ask for it, or say less and write a second
essay/article/whatever.

Footnotes are much better used for pointing people to further reading
material.

------
verandaguy

        His first example is eiπ = −1. Note how that was displayed fine inline, just by
        using <sup>, which has been in HTML for years, along with <sub> which I
        used to show the TEΧ e. Writing in utf8 means I don’t need a special
        sequence like \pi for π.
    

... So all that tells me that instead of doing `^{content}` for superscripts I
have to use the longer and more painful `<sup>content</sup>`, and that I
should always have a Unicode table on hand to copy/paste from for special
characters that I can't write using my EN_US keyboard.

There's currently no strong case to use HTML (even with full CSS3 and SVG
support) as a replacement for LaTeX, mainly because HTML was made for web
typesetting - which is normally focused around shorter blocks of text - while
LaTeX was made for people who want to be able to typeset and read documents
which are tens and sometimes hundreds of pages long. The two domains just have
different requirements.

~~~
javajosh
_> `^{content}` for superscripts I have to use the longer and more painful
`<sup>content</sup>`_

This is superficial, and one could trivially write a markdown style pre-
processor if you wanted the former syntax (and I would be highly surprised if
someone hasn't already done that).

 _> I should always have a Unicode table on hand to copy/paste from for
special characters that I can't write using my EN_US keyboard_

One way or another, you need such a table. For TeX the table consists of ASCII
symbol names. (Note also that unicode characters do indeed have an ASCII
representation using character entity syntax, although it's ugly.)[0]

 _> HTML short...TeX long...The two domains just have different requirements._

What justification do you have for this claim? HTML was designed by TBL for
researchers to share papers, and there is plenty of long-form content written
in HTML.

TeX is great. HTML is great. They'll probably both be around for a long time.
There are trade-offs between them, but not the ones you've identified. (In
particular, TeX's great strength is similar to PDF in that it's output is
totally stable. Browsers by contrast are notoriously dynamic and won't, in
general, produce the same output.)

[0]
[https://en.wikipedia.org/wiki/Unicode_and_HTML](https://en.wikipedia.org/wiki/Unicode_and_HTML)

~~~
verandaguy

        This is superficial, and one could trivially write a markdown style pre-
        processor if you wanted the former syntax
    

That feels just a tiny bit circular. It's like if I wrote a huge set of C++
preprocessor macros so that I can write my code in JavaScript, have the
preprocessor do its magic and transpile it down to plain C++, and then have it
compiled down to machine code.

    
    
        One way or another, you need such a table. For TeX the table consists of ASCII
        symbol names.
    

Not necessarily. It's not difficult to memorize the commands that produce
commonly used symbols; `\pi`, `\sum_{}^{}`, `\int`, `\frac{}{}`, `\times`,
etc. They're all really, really mnemonic with a consistent naming scheme, and
if you don't like a symbol's command, you can always alias it to a new command
in the preamble.

I'll give you the last part though, that was my mistake - but I did meant that
the environments used to render HTML as well as certain associated standards
are shifting towards their more common uses, which are along the lines of
websites and blogs rather than research papers.

------
mixedmath
One aspect Of TeX on the web (via mathJax, say) is that the source is
meaningful. I maintain that in the not so distant future, someone is going to
write a math-search engine (or at least they should), and the key will be
interpreting the latex source behind documents and webpages. I do not think
this would be possible if we used mathML or raw svg data.

~~~
jahewson
On the contrary, TeX markup is mostly concerned with presentation and not
semantics. For example, in TeX we don't know if f(x + 1) means function
application or multiplication by f. MathML however, allows for a complete
semantic description of an equation, as well as a presentational description.
However, people are generally too lazy to use semantic MathML.

------
jbssm
I don't really get the point of this article. The author claims that HTML is
ready to replace TeX and then proceeds in presenting us 2 examples, and those
two examples look great in TeX and awful in HTML.

------
cosarara97
In the SVG Text version of ∫𝝨∇×𝐅∙𝑑𝝨 = ∮∂𝝨 𝐅∙𝑑𝐫, the r is invisible in firefox
(at least on my machine). It is visible on chrome.

[http://i.imgur.com/GhrHkbG.png](http://i.imgur.com/GhrHkbG.png)

------
abritishguy
No system that attempts to typeset from source in the browser will be able to
compete.

It can easily take more than a second to compile a laTeX document with a
moderate number of formulas. Sure, some of this could be optimised but not
_that_ much - the best you can do is either force the user to wait for you to
typeset accurately or show some close approximation that will never be on par
with TeX.

------
SeanLuke
> Also, I took out the spaces around the em-dashes that Lee Phillips oddly put
> in.

Perhaps Kevin Marks isn't an American? What he's doing is restoring a fairly
ill-considered British punctuation style.

Let's go with the Brit theory. While the Bris may rightfully lecture Americans
on grammar and other features of English, British punctuation is famously,
notoriously atrocious. I like the Louis Menand quote (regarding Lynne Truss):
"An Englishwoman lecturing Americans on semicolons is a little like an
American lecturing the French on sauces."

[http://www.newyorker.com/magazine/2004/06/28/bad-
comma](http://www.newyorker.com/magazine/2004/06/28/bad-comma)

~~~
LukeShu
No spaces round an em-dash is what's correct in American English. (Also,
Menand's piece that you cite has no spaces around em-dashes either)

~~~
dragonwriter
No spaces around em-dashes is what most commonly recommended in American style
guides though done recommend thin spaces and some have, or at least accept,
seeing them open (i.e., with normal spaces). This is a flexible issue of
style, though, more than of linguistic "correctness" (and even the choice
between an em-dag and an en-dash set open, for the same user, is a style issue
on which different American manuals will disagree.)

~~~
scott_s
I prefer no spaces around em-dashes for the entirely subjective reason that I
find it aesthetically pleasing. It boggles my mind that other people look at
an elegant em-dash and think, "Yes... with spaces... now it looks right."

There are some instances when I use spaces - such as in in forum posts or
emails, which are far more ephemeral, and I'm not going to hunt around for the
actual em-dash character, and I'll use us a space and a hyphen as an uglier,
but expedient, substitute.

~~~
SeanLuke
> I prefer no spaces around em-dashes for the entirely subjective reason that
> I find it aesthetically pleasing. It boggles my mind that other people look
> at an elegant em-dash and think, "Yes... with spaces... now it looks right."

I think it's because with no spaces, an em-dash looks like it's connecting two
words into a single word.

Name another phrase-level punctuation mark (period, comma, semicolon, colon,
quote, question mark, ellipses, parentheses) which isn't connected to a space.
There's a reason for that.

[Hyphens, apostrophes, slashes, etc. are word-level.]

------
peedy
One case where HTML won't work as a TeX replacement is when you have to think
in terms on a page. For example, if you're making a resume and don't want it
go over one page, it becomes a tedious process to "change CCS, Print preview,
repeat".

~~~
ben0x539
What is the comparable workflow in TeX? Change document, generate pdf, get
compile error because the page overflows, repeat?

------
wodenokoto
While it's micro see that html can render a lot of stuff on some devices, I
find the comparison to Tex redicoulous.

I have yet to meet a Tex document that on the fly can reformat itself to fit
anything from a phone to a large desktop screen, let alone link to documents
all over the web, handle banking or playing games.

Tex is really good at getting your print document to look a special kind of
way. Html is really good at getting text formatted to your current device, at
the loss of pixel (or mm) precision.

And neither format is nice to type your documents in. I guess that's the only
place they are comparable :)

------
jwdunne
Hrm. I write a lot of HTML/CSS. I have 0 experience maintaining TeX code. I
find the TeX code easier to read and prefer the end result. I'd learn TeX to
translate if I ever needed to maintain the equivalent HTML.

I don't actually think you can get a consistent result in HTML/CSS across all
browsers without a lot of effort. For me, the HTML version is missing
characters and styling.

I think those wanting to see the formulae would be happy enough to wait a
second for it to render than be at the whim of browser warts and the loss of
information.

------
pyramation
When expressing mathematics, you want to focus on the formulae and underlying
principles, not styling and layout. TeX provides a design spec inherently to
standardize and provide consistent published mathematical content.

HTML abstracts layout less, and TeX gives you more mathematical creative
expression.

I personally like using HTML5 as a rendering engine, and TeX as the "design"
spec. I built LaTeX2HTML5.com a while back for this purpose, so I could build
all of diagrams and mathematics in TeX, but publish to both HTML5 and paper.

------
tha_melonballer
Should be more like TeX as an HTML replacement.

~~~
pcwalton
TeX doesn't even support dynamic restyling, or things like flexbox. It works
great for article-style documents, especially those containing a lot of
mathematics, but let's not wear rose-colored glasses.

------
mangecoeur
I feel in truth it's not quite there, but on the other hand it's still worth
pursuing just to escape the insanity that is Tex and it's patchwork of
packages to support everything from things-that-should be core (multi column)
to oh-god-why-would-you-do-ath (drawing diagrams).

------
dredmorbius
What my experiments with various content creation and markup systems over the
past 30 years have shown me is that it's far less details of _presentation_
which are crucial, but in _enforcing document structure itself_.

Presentation changes with technology -- I've seen _and used_ systems with
toggle-and-light outputs, true ttys (paper), glass ttys, various terminal and
console outputs, the "standard" 24x80 terminal, desktop GUIs, and now handheld
and mobile GUI devices with sizes from wristwatch to ledger. Other displays
may be as large as a city block.

And that's just _viewable_ output. TTS (text to speech) and voice recognition
are also increasingly present.

The same _presentation_ systems don't work across these. But _well-encoded
semantic content_ is amazingly robust. I remember learning of the '-man -Tps'
(I think) nroff/groff argument -- that is, apply manpage macros, and format
for postscript output. The same manual page markup that is readable in a
console suddenly becomes pretty-printed (and created a brief market in the
late 1990s / early 2000s for "Linux Bible" manpage dump books). Groff has more
tricks up its sleeve, and as the Debian dwww package shows, manpages can be
converted directly to viewable HTML.

But groff is grotty. I knew it (or precursors) once, well enough to turn in
several Uni essays prepared via it. But those neural pathways have long since
eroded.

I'd replaced it for quite some time with HTML, a reasonably versatile
structured markup system, particularly given that most of what I was writing
was intended for online Web publication at some point.

In the past few years I finally cracked the Lion book and started using LaTeX.
I'd realised what the blocks were to my earlier attempts (ironically, "easy-
to-use" tools such as Lyx actually had gotten in the way), and discovered that
it was, as an _authoring_ tool, often far _lighter_ than HTML. Double carriage
returns as paragraph breaks replaces seven discrete keystrokes per paragraph.
Other constructs are a bit less lightweight, but remain clear.

But the real win is in how LaTeX is both a _structured_ and _validated_
document format. Screw up your HTML somehow, or follow some vendor's
proprietary extensions, and a browser will say "eh, close enough". Omit a
closing brace or backstroke or dollar sign, and your LaTeX compiler will
scream at you until it's blue in the face. Unsettling the first few times it
happens, but you begin to realise it's right.

The Web is an error condition: [http://deirdre.net/programming-sucks-why-i-
quit/](http://deirdre.net/programming-sucks-why-i-quit/)

But deeper than that, LaTeX offers _structure_.

Documents have titles, and authors, and publication dates. They quite
frequently have _references_ and _bibliographic citations_.

 _Text notes -- foot, side, end, whate 'er -- aren't some fucking foreign
bolted-on concept._

[http://codepen.io/dredmorbius/details/OVmBaZ](http://codepen.io/dredmorbius/details/OVmBaZ)

There are other bits and pieces that are missing from both, and LaTeX, not
_principally_ oriented to online publication, is short on stuff as well. But
then, HTML doesn't have a native concept of reputation-ranked, hierarchical,
collapsable comment streams either. Despite Usenet's prior art staring it
gloweringly in the face for 25 years.

And yes, LaTeX as a direct authoring environment has its downsides. I've
actually taken to preferring Markdown for my intial pass through writing
documents, and it's a langauge which can readily be front-ended by the GUI-
friendly tools most writers will want.

And HTML5's semantic structures and the valient attempts by some (see
Readability's Developers section and the hNews microformats specs) _are_
actually pretty cool. But until and unless someone steps in to _require_
validated content before they'll pass it (and "someone" tends to be spelled
"major search engine", which is spelled "Google" \-- who _have_ actually
stepped in to police some standards of online behavior and presentation),
we're stuck with the fact that crap HTML is still blindly accepted.

But if anything, front-ended by Markdown or other simple markup languages,
it's HTML that should be replaced by TeX.

~~~
JadeNB
I know this is a trivial response to such a thoughtful post, but what is "the
lion book"? Do you mean The TeXbook ([http://www-cs-
faculty.stanford.edu/~uno/abcde.html](http://www-cs-
faculty.stanford.edu/~uno/abcde.html))?

~~~
dredmorbius
No, though that's also worth buying.

Leslie Lamport's _LaTeX: A Documentation Preparation System_

[http://www.powells.com/book/latex-9780201529838/61-1](http://www.powells.com/book/latex-9780201529838/61-1)

It really is quite simple.

I set up a couple of templates for articles and books, and frequently re-tag
either straight text or HTML into LaTeX when I'm frustrated with existing
presentations.

~~~
JadeNB
Thanks! There's no need to convince me of the utility of (La)TeX; I am a
mathematician. I just hadn't heard the term "the lion book" before.

------
Avshalom
Of course if you include SVG we can eventually create TeX quality... because
SVG allows us to draw arbitrary images. If we're going to be using SVG we
don't even need HTML and CSS.

------
mbrock
I've had pretty good experiences with translating LaTeX into SVG via DVI. The
tools for this come with TeXLive and they're quite fast.

------
Kristine1975
Hyphens and ligatures are not all modern incarnations of TeX can do. pdfTeX
for example also supports margin kerning and font expansion.

------
Mimick
Hmmm, why not take ideas from HTML/CSS and that's all for a next version...

------
jzd
HELL NO.

If you need to, generate HTML et. al. from TeX. But HTML is not a substitute
for TeX. Forget it.

