Unexpected HTML output from raco pollen start
#164
Closed
opened 7 years ago by clozach
·
5 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?
Steps to reproduce:
test.html.pm
raco pollen start
test.html.pm
Expected:
Actual (note the empty
custom
tag):custom
is a nonstandard tag so the browser treats it as an inline tag. Inline tags can’t contain block tags likep
. So when the HTML is parsed by the browser, it moves thep
blocks outside.Does this mean that pollen can only generate standard and inline tags, so I can get this output…
…but not this…
…or am I missing something in the behavior of tag functions that would allow a custom block-level tag?
Pollen is behaving correctly. (Look at the generated HTML in a text editor, rather than doing “view source” in the browser — the
custom
tag is where you expect it.)If you want the web browser to treat
custom
as a block tag rather than inline, you have to notate that explicitly, either in CSS or in the tag itself. For instance, try this one:Pollen has its own setting for
block-tags
, but that’s an internal idea of block-ness that cooperates with functions likedetect-paragraphs
. So even if you define something as a block tag within Pollen, you still have to tell the web browser to treat it as a block tag (using CSS).“So why doesn’t Pollen just drop
display:block
into the HTML for every Pollen-defined block tag?“ It could. But —My policy is to minimize magic behavior.
Beyond the most vanilla situations, it backfires, because CSS properties that are in the tag itself will override anything in an external CSS declaration.
Anyone who wants that behavior can easily put it in a tag function:
Ah, I'm starting to see it a little more clearly. (Thanks, by the way!)
To be clear, I wasn't thinking that Pollen should drop
display:block
as a side effect…agree 100% that it shouldn't. In case it helps you see any other problems with my understanding, here's how I first arrived at this issue.I wanted to try my hand at laying out a short story in Pollen, and the story in question is written in sections, each section having a different "voice". So I naively threw some Pollen tags around the relevant paragraphs, similar to the
◊custom{…}
tag used above. I wasn't looking at the in-browser source just yet. Instead, I added a template.html.p to load a styles.css, and, in the latter, adisplay: block;
within each of the custom tags, and was surprised by the style's seeming failure to be applied.It seems that my chief misunderstanding was in believing the bug to be in Pollen when you could argue that the issue is with Firefox, Safari, and Chrome, all of which transform this:
into this:
I guess the browsers do a first pass at loading the dom before applying styles, and then, rather than communicate the apparent inline-can't-contain-block-tag error, they silently rearrange the tags. Ugh!
Thanks again for your help, Matthew.
Yes, the behavior is surprising. But to be a little fair to web browsers, this behavior is a feature not a bug. They’re designed to recover gracefully from malformed & illogical input. Though if you want a rule of thumb: make your block-level tag functions emit
div
elements qualified withclass
orid
attributes.