html table with pollen
#31
Closed
opened 10 years ago by ChristianSch
·
10 comments
Loading…
Reference in New Issue
There is no content yet.
Delete Branch '%!s(<nil>)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
Hi.
I’m having a hard time with more complex tags like table, trow and tdata (let alone optional thead and/or tfoot). This is the code for my custom
table
function:And this is the original code for the table:
The outcome looks like this:
Almost! But I can’t get it working without having the double quotes. Any thoughts on this?
You’ve almost got it.
When you're building a tag with quasiquote, and you have a list of elements that you want to put inside the tag, you need to use unquote splicing
,@
rather than plain unquote,
. Unquote will put your elements inside the tag as a nested list, whereas unquote splicing will merge them with the tag, like so:Thus, your function should use unquote splicing:
Keep in mind that the the arguments passed to
table
are a list of strings that also include the linebreaks ("\n"
) within the text block. So if you don't want those to appear in your table, you can filter them out ofrows
. Thepollen/decode
module has a function calledwhitespace?
for this purpose:Alternatively, rather than filtering the list, you could also recombine the
rows
into a single string withstring-append*
and thenstring-split
on\n
, with identical results:Great, thanks for your help! One problem still exists, though. The table tag (
Can you explain how you trigger this behavior? When I run your code in the Pollen server I get the right result:
Please see here: https://github.com/ChristianSch/french-script
I fiddled around a bit and even the minimal example
lecture4.html.pm
turns out like this: https://gist.github.com/ChristianSch/f25b320410e6c48d1d68Thank you for sharing your sample project. I'm afraid I can't reproduce your problem on OS X — DrRacket shows the correct X-expression when running your
lecture4.html.pm
:And Chrome, Opera, Safari, and Firefox all show the correct HTML, with the
table
tag wrapping the rows:What platform / browser is triggering the problem for you?
I’m using Racket 6.1.1 on OS X Yosemite with Safari 8. I testet it with Firefox 33.1.1, Chromium 39.0.2149.0 and curl. Guess what works as expected? …
I’ve never experienced something similar. This is weird.
It seems that I have to fiddle a bit. Any tips about debugging this with pollen especially?
I've occasionally seen behavior like this during development. I believe it has to do with the browser getting confused about what to do with the
root
tag. Keep in mind thatroot
is not a block element in HTML — it's an unspecified name, so by default, the browser treats it as an inline element. And inline elements aren't allowed to contain block elements (likeh1
andtable
). Even if your CSS makesroot
a block element (withdisplay: block
), the browser will sometimes do the right thing, sometimes not.You may ask, “why not use a name that is an HTML block tag for the
root
node, likediv
?” The answer is that Pollen is designed to be output-agnostic, and that would bind it too closely to HTML.But there is a solution. Look at the extra options of the
->html
function in thepollen/decode
module, which will let you changeroot
to something else. So instead of this:You could write this:
This will get rid of the
root
tag and automatically generate the<div class="content"> ... </div>
.I changed the code as you suggested but the problem remains. Funny thing tho, if I use a p tag instead of table it works. Any ideas how this could happen? (Update didn’t help.)
Thanks for the detailed explanation. I totally get the idea behind it and it’s ok as long as I can generate valid html like you just explained.
Got it. It was completely my fault. The weird behavior was caused by using
trow
andtdata
instead oftr
andtd
. Sorry for any inconveniences.Glad you found the source of the problem. Same idea, however — because
trow
andtdata
are not standard HTML tags, they were being treated as inline elements, not table-row and and table-cell elements, and the browser was parsing the DOM erratically.