LaTeX mark-up as a generic mark-up language

Question

Tremendous benefits can accrue, if TeX-like mark-up could be used in lieu of html and its variants, where a requirement exists to have a document both as (All)TeX mark-up and html format.

There are benefits both ways. For (All)TeX a browser interface is unquestionably the best means of providing a flexible and user friendly User Interface and requiring minimal programming. One could program settings to be captured via interactive screens to manage packages and variable settings. On last count a complicated document might need over 700 variable settings, and although most of us solve the problem with class selection the difficulties remain. Another benefit is the organization of the document data and managing files and directories through a visual interface, rather than a console and lastly and perhaps one of the most important consideration is the possibility of using server and scripting languages for calculations and access to web documents and databases, where (All)TeX is limited.

For html a macro language could be used to generate complicated html patterns such as code-blocks, complicated visual displays of images (that require a lot of divs) and similar. Additionally, if the mark-up was in (All)TeX, documents could be generated on the fly.

Here is the question, before I give a bit more background to satisfy the rules and to keep the closure squad happy.

What are your views? Is TeX-like mark-up a good way of structuring documents? I personally think the answer is yes with the exception of tables. What would be a suitable mark-up for tables?

Some more background. I have a personal CMS build with CodeIgniter that I use to keep a lot of documents and personal notes, especially on programming.

Any code in code-blocks can be run interactively and see the results within the browser. I have code for quite a few languages, such as javascript, lua, php, haskell, perl etc. Mark-up was originally based on using hard-coded html, markdown and wiki-style mark-up. I have now added a filter where it parses LaTeX code and produces the relevant html with simple environments, such as \begin{jscodeblock}..\end{jscodeblock}. I have also added code for most common LaTeX commands and a few for images.

Pressing the "texify" button sends the document through a filter that parses any markdown and wiki-like tags and produces the pdf, which can be viewed directly in the browser.

A major advantage for me, and possibly for anyone used to breaking up long documents in different files, is that the system can be used within the browser to "collate" all the files and produce the full document pdf. The menu on the left represents all the individual files and a main file is used, if the full document is required, otherwise it only prints the page. An automated 'menuing' system helps with the nightmare of managing hundreds of files. (On the left in first image).

I have been using, markdown and its variants and I am familiar with pandoc and LaTeX2html packages. They all have their limitations and usages. So far marking through LaTeX only commands have improved my workflow and productivity. I have managed to provide filters for most macros to display well in browsers - except tables. There is no problem parsing and translating simple table mark-up such as the one provided by mark-down, however anything more complicated and parsing is next to impossible.

I believe that the answer may lie in redefining the way we mark tables in LaTeX and I invite your ideas.

Maths mark-up, was solved with MathJax and a small filter. There is much more in the system that I can describe in a question, such as managing settings, cover-images, styles and the like.

As we lack an experimental tag, I have tagged the post as mark-up.

Edit: Similar idea in practice authorea give it spin.

Answer 1

I feel that as the point of all this is to have as human-friendly input as possible, it would make sense to use markdown or its derivatives (sidenote: I’ve pursued this idea previously).

Out of that format I would like to raise tables as an example of kramdowns markdown extensions:

| city     | age_range | gender | marketing_target |
|----------|-----------|--------|------------------|
| New York | < 30      | M      | Y                |
| Chicago  | < 30      | M      | Y                |
| Chicago  | < 30      | F      | Y                |
| New York | < 30      | M      | Y                |
| New York | < 30      | M      | Y                |

It does look like a table, right?

Answer 2

A bit of a description of my attempts so far to provide some answers and to expand a bit on the topic.

Consider the structure of a table irrespective of how and where it is displayed or printed. A simple table would normally contain some form of a dataset. For example,

 DATA_LABELS = ['city', 'age_range', 'gender', 'marketing_target'];

 DATA_SET = [
  ['New York', '<30', 'M', 'Y'],
  ['Chicago', '<30', 'M', 'Y'],
  ['Chicago', '<30', 'F', 'Y'],
  ['New York', '<30', 'M', 'Y'],
  ['New York', '<30', 'M', 'Y'],
  ...
  ['Chicago', '>80', 'F', 'Y']];

This is of course very similar to a csv file. To those familiar with JavaScript the above is valid code once you add a var in front of the variables and with some short code you can produce a table that would for example look like:

A pure html table uses the familiar code of a jumble of tags, with the advantage of having a good 'structure' enabling the separation of presentation from mark-up. The problem with html is verbosity leading to some solutions such as the various versions of markdown.

As TeX based systems provide powerful mechanisms an in-between mark-up language can help. For example,

\begin{table}
\tablecaption{\captionlorem}
\begin{tabular}{lllp{2.5cm} };
 \tr
   \th heading 1
   \th heading 2
   \th heading 3
   \th heading 3
\tr
   \td test
   \td test
   \td test
   \td test
\tr
   \td test
   \td test
   \td test
   \td test
\end{tabular}
\end{table}

This can easily be transformed within the browser and in pdfLaTeX and we get:

The table head can be simplified to:

\begin{Table}[class= \simple_table]
 ...
\end{Table}

where the class defines some css and the same name is used for LaTeX code that defines table head definitions. At the cost of further complicating parsing one could say:

\begin{Table}[class= \simpletable]
   \datalabels{...,...,...,}
   \dataset{...,...,...,}
\end{Table}

and be done with it. Data lives where it should live and the styling is left with the class. Multi-row and multi-column is still an issue; one point of view is that a multi-column refers to presentational details and should be added to the class and not to the data mark-up. A different point of view would be that data marked as [...,'F' + 'F',] means the two adjacent cells share the same value and they should be parsed as a multi-column spanning two cells.

ConTeXt coding of tables is very similar to my example above using \td,\tr etc, but it still has the drawback of mixing data, presentation and tags.