You have a good point about the rendering oddities with whitespace. There's a lot of room for improvement here. Rendering hints would definitely be nice. For instance, <link> and <input> tag don't typically close themselves. And tags like <a> <b> <u> <em> should just print on a single line.
> I'm definitely a fan of this 'annotate approach to building HTML. I like the idea that as the framework gets more refined, it might be possible to output the same page as either HTML or XHTML with just a configuration change.
haha, I didn't quite think of this at the beginning.
My 'render-html is completely decoupled from the building of the HTML. It's just one type of a printer, and it likes to pretty-print things for readability.
We could add easily imagine adding several more printers, and even a system for registering and choosing one, with 'render-html being merely an alias to the chosen one.
...perhaps it's a good thing that rendering hints aren't part of the tag object.
I have tag-by-tag hints in mine just in case I want two otherwise identical HTML tags to have different rendering behavior, for a browser hack or something. Eventually I do hope to have an 'html hint that causes the element's tag name to be looked up in the renderer's HTML specification of choice, but I may still want to leave that hint out occasionally just to have better control.
Actually, it could just be a matter of laziness. The only hint I use right now is 'collapsible, which I put on the <meta> and <link> tags so that they don't have closing tags when their contents are empty. Since it's only one hint, I haven't bothered to make a whole extensible system based on objects that represent HTML specifications.
Oh hell, I'm not writing a complete system for html specs. Just a quick hack for the most commonly used tags and the way I think they work.
For that matter, I didn't know link and meta could have content.
I changed the rendering engine to print some tags inline and self-close some tags.
(render-html (page 'title "Test" 'js "js.js" 'css "css.css"
(p "Hello world" (e 'em "emhasis!!!") "did you see that?")
(p "Btw, this is" (e 'a 'href "google.com" "mylink"))))
<!doctype html>
<html>
<head>
<title>Test</title>
<script type="text/javascript" src="js.js"></script>
<link rel="stylesheet" type="text/css" href="css.css" />
</head>
<body>
<p>Hello world <em>emhasis!!!</em> did you see that?</p>
<p>Btw, this is <a href="google.com">mylink</a></p>
</body>
</html>
> I have tag-by-tag hints in mine just in case I want two otherwise identical HTML tags to have different rendering behavior
The tag object is just a hashtable, you can always hack it and insert whatever custom attributes you want, and then use these as rendering hints in the rendering engine/function.
Oh hell, I'm not writing a complete system for html specs.
I sort of am, but only in the very long term. It can start as a tiny type that just holds its own specific special-casing behavior, and then it can grow in complexity as complexity is needed. That said, it may be difficult to predict what behavior is specific to a single HTML specification until one's tried to provide a choice between multiple specs.
I changed the rendering engine to print some tags inline and self-close some tags.
Awesome. :D
For that matter, I didn't know link and meta could have content.
They're not supposed to. (It would be interesting to look at the DOM to see if they can in practice.) I'm talking about when I might potentially want to give them content for a weird browser-specific hack.
The tag object is just a hashtable, you can always hack it and insert whatever custom attributes you want, and then use these as rendering hints in the rendering engine/function.
