WIP: add option to output xexpr of html

[stevebyan]

Output the body as an xexpr, and provide various metadata, including TOC links, in a struct rather than in html.

I've refactored html-render.rkt to optionally output the body of the document as an xexpr rather than as html, and provide document metadata including the TOC links in a struct rather than in html. My goal is to allow use of scribble's html in something like Greg Hendershott's Tadpole, and so I want to provide the document content in a form that can be applied to an xexpr template. I also want to provide the TOC links in a form that can be rendered by site templates using pure CSS to provide a responsive view of the navigation links.

I'm submitting this pull request to gather some feedback on my approach, before committing to doing more work to make this something actually mergeable into Scribble. To pull out the TOC as data rather than as html, I've duplicated a lot of code from the render-toc-view and render-onthispage-contents methods. A finished pull request would refactor render-toc-view and render-onthispage-contents to use the output of my list-of-toc-view and list-of-onthispage-contents. I'm also not sure at this point how I want to represent the TOC contents. Using structs would probably be better than the current hacked nested lists.

Is this a feature the Racket developers would consider including in Scribble? Except for the duplicated code, does my implementation approach look reasonable?

[stevebyan]

Regarding the build failures, while I prefer human-readable output files, if you don’t want to add fmt as a build dependency, I can just remove it from Scribble and add it to a build pass in my blog makefile.

[samth]

For human-readable sexp output, just use pretty-write from racket/pretty instead of using fmt.

[stevebyan]

For human-readable sexp output, just use pretty-write from racket/pretty instead of using fmt.

Thanks, I’ll make that change.

[mflatt]

This seems generally like a fine idea to me. I expected --xexpr to be an output option at the same level as --html, though. Would providing the choice that way match the intent?

[stevebyan]

I have intentions of supporting htmls and html-tree output as well as html. It was a little easier in the code to just add a single additional option used in addition to one of the html options, but it’s probably better to add xexprs and xexpr-tree options and not allow an html option.

[stevebyan]

I’ve just learned that xexprs are not fully serializable. A number of the structures in the representation are transparent rather than prefab. Greg Hendershott apparently gets away with writing and reading xexprs to a file in his tadpole blog system because, unlike Scribble, his Markdown source doesn’t introduce any html comments, CDATA, or PCDATA. I’m working on a separate pull request to enable serializing xexprs using read and write.

[stevebyan]

Closed in favor of PR #519

I mistakenly created this PR from the main branch of my fork. PR #519 changes the PR to be from my xexpr-dev branch.