What features are supported in a HTML page, but not through PDFLaTeX

As a math educator with limited knowledge of TeX and even more limited knowledge of HTML, I want to know if I can use a PDF page (generated through PDFLaTeX) as a web page. I am hoping not to have to learn one more language, namely HTML!, and not lose the attractiveness of TeX output.

Of course I can, but what features will I lose?

I would like to have a list of HTML-based web page features that can be duplicated, packages that perform the task, and links showing what the feature actually is, in layman's terms.

Here are a few things I have learned.

1. There are ample tools for hyper-referencing as in hyperref, url, and href packages: wikibooks.
2. You can embed media using movie15 and media9 packages.
3. You can have a drop down menu using popupmenu package.
4. You can have mouse-over tool tips: fancytooltips.

On the negative side (not advisable/not possible/problematic cases)

2. Resizing a page (Adobe Reflow).
3. Dynamic page (as in a page dropping down).

Edit 1:

I am looking for advice on successful examples of online textbooks which combine the traditional look of a book with a high level of interactivity. Imagine a Harry Potter style newspaper with embedded mathematically interactive elements (as in Matlab/Maple/Mathematica windows or an interactive web page). Among non-commercial software that offer a notebook is Sage.

-
As you say, 'of course you can' (sort of), but as you also point out, not everything translates (well / at all). What kind of features do you want? Perhaps the ever-popular <blink>blinking text</blink>? –  jon Dec 20 '12 at 3:48
For example I would like to be able to open a web page, an app, a Mathematica/Maple/Matlab window within a PDFLaTeX page. In general I wish for interactivity in an online text that, otherwise, looks like a traditional book. –  Maesumi Dec 20 '12 at 4:10
Right, well I wonder if this question couldn't do with some more focus. There exist (La)TeX to HTML converters (e.g., tex4ht, which can do a lot of the work for you. But if you want your web page to look and behave like a PDF (do you? -- e.g., the 'size' of the page is fixed whether 'browsed' from a phone or a 22" monitor; the text has margins, headers, and footers and footnotes; etc., etc.), that is a different question entirely. I think the former route is better, personally, though I suppose you would need to learn some html.... –  jon Dec 20 '12 at 4:18

This is really a great question, because it's exactly the kind of thing somebody starting out would need to know, but it's very hard to figure out how to ask about or google for.

Unfortunately, to do what you're describing you're going to have to make some concessions somewhere to achieve what you're talking about. Double unfortunately, because I think you're probably going to want to go the route of the web app, unless print quality is the major overriding concern.

For starters, let me point out Mathematica Player and their "open" CDF format. This might do what you need right off the bat, although you're likely to wind up spending big Mathematica money to make it all work out.

On the subject of HTML and PDFs, while it's possible to embed JavaScript and movies in PDFs, this kind of thing is rarely done. It's much easier to "embed" (link, really) a PDF in a webpage than to try to perform the kinds of things that are best done in a webpage in a PDF instead.

What kinds of things are easier with a webpage? Most things:

• Interacting with other users in realtime
• Social nonsense
• Most kinds of dynamically generated content
• Interactive charts and graphs, e.g. with d3.js
• Interactive 3D visualizations, e.g. with canvas 3D
• Real-time updating—fix a typo, everybody sees the fix as soon as they reload the page

What you'll be giving up by using HTML, essentially, are the following things:

• The ability to perfectly control how it looks on somebody's computer.

Different computers and different browsers render the same pages differently. Even the same browser on the same system can be configured differently—replacement fonts, minimum sizes, and user stylesheets can all radically alter the display. You'll just have to accept this if you go HTML and just do the best you can.

• The ability to control how it looks printed. There are print CSS rules that enable you to achieve a nice-looking printout, but a lot of the things TeX does for you and well (page numbering, for example) you will lose. The browser will attempt to do these things for you, and will do a bad job. Little direct control over headers and footers.

• Fancy TeX algorithms. There's no automatic hyphenation, no TeX justification rules, no hanging punctuation. Math is not automatically rendered well—MathML is much more manual than TeX math.

• Any sort of procedural stuff TeX does. No table of context generation. No bibliography management. No automatic footnotes.

• To some extent, the ability to have an offline reference.

Now, the good news is that you can ameliorate a lot of these problems with judicious use of JavaScript.

• MathJax renders TeX math.
• Sweet Justice implements hyphenation.
• Typeset implements the actual TeX justification algorithm.
• Pandoc can convert between various formats, including LaTeX and HTML; some of these plain text formats support some of these features—Markdown supports footnotes, for instance.
• jQuery is frequently used to implement odd/even rules and could easily be employed to implement various procedural effects, though it is a lot more of a general purpose tool than the rest of the items in this list.

It wouldn't be terrifically hard to take these various technologies and create a kind of "TeX template" for the web. At this point, what you'd mainly be missing is style, but mostly book-level features like headers and footers. Of course TeX will still do a better job than these libraries at some of these purposes, because it has better information, is better debugged, and can afford to take the time to do it right, but you can certainly achieve a passable quality (not quite typesetting) and get all the other things you need to do going as well.

On the subject of learning yet another markup language, I really do suggest looking into Pandoc. There's probably a simplified format that won't require much brain power that you can use from there. On the other hand, HTML is not particularly complex. CSS is more complex, but the two of them taken together are not as bad as TeX, in my opinion, largely because there is cleaner separation of appearance and meaning—at least, there ought to be, and it isn't hard to achieve it. But you could go pretty far with a CSS reset like Blueprint plus Pandoc with Markdown, plugging in a few of these libraries and maybe 30 lines of JavaScript.

I'd expect this will get you closer to where you want to be than banging PDF into shape. But I'm a web developer by trade and do TeX on the side for fun (lately) so I am probably biased.

-
(I ask this as a non-web developer who also never has to worry about converting complex equations or diagrams) is pandoc really at the point of being superior to tex4ht in terms of *tex to HTML conversions? –  jon Dec 20 '12 at 14:55
It really can't be, because it's converting from procedural markup to fully declarative markup, and it doesn't embed a full TeX implementation (to my knowledge). I think the loss of fidelity there is probably justified by the other gains, since @Maesumi didn't made a big deal out of having existing stuff to migrate in the question. –  Daniel Lyons Dec 20 '12 at 15:12
Nice answer, but I would like to point out that you do have counters with CSS which you can use to automate the numbering. –  morbusg Dec 22 '12 at 21:27
@morbusg Thanks, I was unaware of that! –  Daniel Lyons Dec 24 '12 at 5:25