I have found many useful things about tiddlywiki, one is learning and building html. One way to do this is to use wikitext or script (widgets etc…) to generate content then using the preview/HTML that comes with the Internals plugin to review the HTML.
I am aware that the html displayed is post render and is thus somewhat hard to read as there is no surplus formating. We could call this somewhat uglified.
I was wondering if we could build a Better HTML view in preview by creating a new preview and prittefying it. Are there some programatic ways to prittify HTML?
Inserting new lines after various tags such as </ol> </li> etc…
I ask here in the developer forum as this requires someone with a strong background in HTML
I think it would be relatively easy to add one of the many HTML formatters to TW and offer the ability to paste code we’ve copied from the preview into a text area to view a reformatted and highlighted version of the code. But, to my mind, that doesn’t offer much benefit over simply having one of the online formatters open in another tab.
But I’m pretty sure that we could not do as you suggest and make the browser’s preview itself prettier. Someone please correct me if I’m wrong, but I believe TW does not generate HTML when rendering. Instead, it generates DOM nodes. We didn’t tell the browser to render the string <p>hello</p>; we tell it to create a Paragraph object with the text “hello”. When we ask the browser for a preview it uses it’s own non-prettified DOM-to-HTML converter.
One alternative I’ve never investigated: there may be browser plugins to prettify the preview code.
Unless I’m wrong about the straight-to-DOM technique, I think this should remain firmly in userland.
It actually does. TW creates and sanitises HTML elements before they are rendered.So we internally do know the html structure. It’s the same as our widget-tree.
But we would need to modify the render process, and add additional line-breaks and indentation markup to show html in a somewhat structured way.
But does it generate HTML text? I know it can; otherwise we couldn’t render static versions of the wiki. But when I look, for instance, at the render method for the Checkbox widget, it’s all DOM manipulation. Does that get turned back into HTML before it’s handed off to the browser?
Never mind; I just reread the OP, and realized again why I shouldn’t post anything when I first wake up! Tony is looking for a preview feature, not for changes to what is available in the Developer tools.
So yes, we could well use a HTML beautifier to wrap around the output of wiki.renderTiddler, and make it an alternative preview. I still don’t support putting this in core, but I would not object strenuously.
This may be the final result but I raise it here to ask for insight and ideas before making such a suggestion.
I am not sure I completely follow, all I know is the preview output is effectivly a copy of what is rendered but remains in html format.
If anything I would hope it may eventualy become part of the internals plugin, but I am fine with a plugin that someone wanting to leverage tiddlywiki for handling html code design, review and learning.
Are you saying that there may be a point where the HTML is easier to read before its sanitised?
As you know there are other previews that display intermediate results in the render process the Parse Tree and Widget Tree. So if there is a posibility of an intermediate result that is pretty html we could use that.
Otherwise we need to take the final HTML and pretify it inside an additional preview.
Details
The HTML preview is stored in $:/plugins/tiddlywiki/internals/EditTemplate/body/preview/raw and invokes the following;
If you paste what’s in the “raw HTML” preview pane into https://www.htmlbeautifier.org/, and press the “Beautify It” button, you will get a readable version of the HTML. All I was saying was that we could bring a tool like that in-house and add another preview pane that showed this format, either with or without syntax highlighting.
But I’m pretty sure, reading the source code, that the HTML that we’re showing now is not currently hand-crafted. Instead we use DOM methods to create the document and call .innerHTML on that doc. That means that we can’t easily interrupt the process earlier to simply generate prettier HTML. We have to beautify the HTML the browser backfills from the DOM. I haven’t ported an external JS tool to become a TW internal module, but I don’t think it’s a terribly difficult process. If we did that with one of these beautifiers, I think we could use it to give us the sort of preview pane you want.
We do this currently to generate the ugly html, then its just a matter of giving this to an inbuilt …
So you are correct, but it is not as difficult as you imply.
It makes me ask what if the $view widget permitted other formatters to be installed, permitting additional values for the $view widgets formats can be specified in the format attribute:
This would be a hackability request and easier to get into the core, a user/plugin would then provide an additional formatter. In this case pretty HTML.
See $:/core/modules/widgets/view.js each format is just calling a javascript function such as $tw.utils.htmlEncode
We would then give the result of this function to the function provided by www.htmlbeautifier.org (I dont know how to do this)
We do not create HTML text. That’s complex. Browsers can do that much better and according to the current spec. You are right we do create DOM elements. As I wrote. We would need to add functionality to the .render() functions to add some “debugging” HTML text nodes like line breaks and tabs for indentation. Those elements would be shown inside a <pre> element.
The main problem I do have with 3rd party HTML formatters and syntax highlighters in general is: That they are huge in file size. For a formatter we would probably add several hundred of kilobytes. For syntax highlighting we will be up to 1 MByte. See CM6 and co.
Using the finished HTML text - analysing it - pretty print it - is complex if done right.
The TW internal structure already knows the “parent” / “child” relations, that are needed for line breaks and indentation. Which IMO would be enough to make the HTML structure clearer for humans.
It’s not difficult, not at all. But the beautifiers are large.
I can buy that, although I would be much more inclined not to add nodes to the widget tree but only to turn the tree directly into appropriate HTML But there would still be interesting questions about formatting to address:
<p
class = "class1 class2 class3"
>Some
<strong>
highly emphasized
</strong>
text with a
<a
class = "class4 class5"
href = " http://link.to.somplace.com/info.pdf"
download
hreflang = "en-GB"
rel = "alternate help"
target = "_blank"
aria-label = "PDF Help"
aria-description = "Help text supplied as a downloadable PDF document"
>help link</a>
included.
</p>
Or
<p class = "class1 class2 class3">
Some <strong>highly emphasized</strong> text with a
<a class = "class4 class5" href = " http://link.to.somplace.com/info.pdf" download hreflang = "en-GB" rel = "alternate help" target = "_blank" aria-label = "PDF Help" aria-description = "Help text supplied as a downloadable PDF document">help link</a>
included.
</p>
Perhaps another approach is while displaying in the second format one could click on a given html tag and have it expanded/collapsed into a new line every < or > or key=value pair.
