-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTML: Use HTML intermediate language before final Doc
rendering
#541
Comments
Definitely Alternative 3 is right out. I mostly like this proposal. Before committing to it though, I would like to investigate if backing up one level would be useful. Right now the definition of the data-structure that the HTML backend takes as input is somewhat ad-hoc. Could it be modified so that HTML generation (with ids in the right places, etc) would be easier? What would that look like? Another thing to look at is pandoc. We're been thinking of having more backends by going to pandoc instead. So before too much effort is spent on the HTML backend, I think it is worth taking a good close look. |
LayoutObjI do think some issues could be mitigated by improving As for upper level improvements helping with "tag folding" in HTML, the references (and thus That makes it possible (in the current implementation) to add something like PandocWhile I haven't looked at it too much, Pandoc seems to support math by means of LaTeX literal math code (doesn't seem like a real problem, but definitely something to note). Another thing to note, is if we generate directly to Pandoc AST there doesn't appear to be a way to "modify" lists the way we do in both HTML and TeX. In TeX, Another thing to note is, while trying Pandoc on the (terminal) command line, it chokes within the |
Ok, let's not rush to Pandoc then. We might still do it, but maybe as a 3rd printer rather than as the only one. In the meantime, it is indeed best to fix the design of Note that pulling ALUR out will require some non-trivial design. We want to move some of the concepts (such as 'Assumption') out of |
This may not end up in scope for @Mornix to do, but I'll still re-assign. I think once ALUR is dealt with, the rest of |
Doc
rendering
Rationale
As @JacquesCarette mentioned in this comment, the HTML backend currently "tags" references by wrapping the referenced content in a new
<div>
tag. In most cases, the wrapped DOM tree does not have anid
attribute making the<div>
redundant as theid
attribute could be folded into the wrapped DOM tree.For example:
<div id="abc">
<ul>
...
</ul>
</div>
is currently generated, but we could instead do:
<ul id="abc">
...
</ul>
because the
<ul>
had noid
.Complications
Currently, the HTML backend takes a
LayoutObj
and immediately serializes it to text effectively "preventing" any additional modification to that element. In most cases this is produces (nearly) standards compliant output, but sub-optimal and bulkier output than needed.Proposal
Structure
A solution which would be adequate for the HTML backend is to add a simple step between
LayoutObj
andDoc
. It may look something like:data DomElem = Elem String (Maybe String) [String] [Attrs] [DomElem] | Content String
Where
String
is the tag. (ex. div)Maybe String
is theid
. (ex. assump9)[String]
is a list of class names. (ex. ["code", "bases"])[Attrs]
is, loosely speaking, a list of key-value pairs for other element specific attributes. (ex. href="#top" for<a>
)[DomElem]
is a list of wrapped DOM elements. More information on the purpose of this below, but allows for functions to wrap sub-trees as needed.And
Content
is means to output text verbatim.Functions
The goal of adding this intermediary step is to enhance convenience without much code clutter while producing better output. For convenience, I will use existing function names (where possible) from the HTML backend to bridge what the back end currently does and how that would transition to use this added structure.
wrap :: String -> [String] -> DomElem -> DomElem
Small type signature change from what it currently is. Currently the last two arguments are
Doc
. This would do the same thing it currently does, creates a new tag with[String]
classes and aDomElem
body.A lot of places in the backend do not apply classes to the tags leaving
[]
all over. It would be nice to add:wrap' :: String -> DomElem -> DomElem
Which does the same as
wrap
but removes the need to specify an empty list.refWrap :: String -> DomElem -> DomElem
refWrap
takes anid
and tries to apply it to aDomElem
. If theDomElem
has anid
refWrap
would wrap theDomElem
in a<div>
and apply theid
to that, otherwise apply it directly to theDomElem
.addClasses :: [String] -> DomElem -> DomElem
Adds class names to a
DomElem
. Would allow for simplification ofmakeList
.addAttrs :: Attrs -> DomElem -> DomElem
Adds tag specific attributes to a
DomElem
toText :: DomElem -> Doc
Serializes a
DomElem
to a document. Can be a centralized place to properly omit end tags for void elementsAlternatives
DomElem
use currying to partially apply functions and defer string output until more is known. (Not completely sure if this would work in all cases, but was a thought I had when considering alternatives).refWrap
to do string searching to see if anid
attribute is present on the top level tag. (Hacky)The text was updated successfully, but these errors were encountered: