lunamark
lunamark copied to clipboard
inline <style> element results in parse error
example markdown contents:
a
<style>
img.grid2 {
width: 370px;
height: auto;
}
img.grid3 {
width: 244px;
height: auto;
}
img.grid2 + img.grid2 {
margin-left: 4px;
}
img.grid3 + img.grid3 {
margin-left: 4px;
}
</style>
hello
error:
lua: .../vi/.luarocks/share/lua/5.4/lunamark/reader/markdown.lua:196: parse_blocks failed on:
a
<style>
im
stack traceback:
[C]: in function 'error'
.../vi/.luarocks/share/lua/5.4/lunamark/reader/markdown.lua:196: in upvalue 'parse_blocks'
.../vi/.luarocks/share/lua/5.4/lunamark/reader/markdown.lua:1193: in upvalue 'md_to_html'
version info:
> luarocks --local --lua-version 5.4 show lunamark
lunamark 0.5.0-1 - General markup format converter using lpeg.
Running with the latest master (as 0.5.0-1 starts being fairly old), I didn't observe any error, but this being said, the output doesn't seem to meet the expectations...
The <style>
tag not a registered as a block element, and is therefore considered as an inline element (so doesn't accept blank lines, and processes anything looking as markdown inside it).
It seems to me it should have been a block element (as <script>
is, for instance, and thus be added here:
https://github.com/jgm/lunamark/blob/ae3091ad9f0e2cb3cea2571663b2c39e508bf5a7/lunamark/reader/markdown.lua#L436-L454
(The HTML standard allows <style>
to occur in the body of a document (though having in it head is recommended), so it seems supporting it is probably legit.)
BTW, is the above analysis is approved by the maintainers, it's one line fix... With it and the few current pending PR, and possibly another one (e.g. I could propose a backport of what I did in my vendored copy for #50), perhaps it could be the nice time for having a 0.6.0 release?
I think my original problem was related to DOS line-endings fwiw. I need to go try to reproduce it again, but I'm not having problems right now. but it's also true what you wrote about the <style>
element, I am working around that in other ways