All <li> are converted to fragments and [[[]]]=frag- remove <li>
jamiefolson opened this issue · comments
It seems desirable to respect the pandoc behavior for markdown, where
> - item
> - item
can be used to create incremented lists or non-incremented lists (depending on settings).
reports converts all <li> items to .fragment elements.
On a similar note, [[[]]]=frag- removes any existing <li> tags, which seems odd. From the example:
# Slide 5d
- point 1
- point 2
- point 3
- point 4 [[[]]]=frag-rollin
- not a point [[[]]]=frag-highlight-green
- just colorful [[[]]]=frag-highlight-blue
- huh? [[[]]]=frag-highlight-red
Only points 1-3 are converted to <li> items, despite being contained in the <ul> that contains points 1-3.
Both of these behaviors seem surprising to me.
Also, why does everything for reveal.js use grepl and regexes and not an html manipulator like XML?
Would you be open to using an html library like jsoup?
Jamie,
You have very valid points. For me the idea of the reports package was to make my life simpler and I found it did. I'm primarily a literacy researcher not a programmer. I work a ton with regexes and am very familiar with these tools (though still not proficient yet). I'm not familiar to any great extent with html manipulators and for the work I do, I don't plan to invest time in this (this would take me far away from my research agenda). That being said I used what tools I had to accomplish the goals I wanted.
The reason I shared the reports package is so that others in the R community could grab a hold of areas of weakness like the places you point out and strengthen them. I see the project as a communal event whereas packages like knitr are written by experienced programmers and are generally progressed by a sole author. reports is not of this caliber because my focus is not in programming, but the conceptual framework is (IMO) solid and I'd like to have others contribute to improve it's quality. I've never heard of jsoup but would be interested to see what it can do.
Your background seems well suited to tackling these issues (currently beyond my skill set). Please feel free to fork a branch of reports from github and tackle the problems you suggest and upload them via a pull request.
Tyler
@jamiefolson I'm not that experienced with html and at first I didn't see what the concern with
All
are converted to fragments and [[[]]]=frag- remove
was. After this issue was raised I understood the consequences. This is a learning experience for me. You github indicates you have a great deal of experience in this area please continue to share, fork and contribute.
I closed this issue because it addresses the original problem. I did not address the use of regexing. To some extent this is necessary because the quasi markup I'm adding for reveal.js is not html language. I'm familiar with extracting html elements using XML but not putting them back together. If you still would like to pursue this please open another separate issue, though this is beyod my current skill set.
Before doing anything rash, I'm doing a bit of looking around in the pandoc source. I think that there are a few things that can be best accomplished via an actual reveal.js output for pandoc (e.g. basics like adding "fragment" class to
Ultimately, while I understand what you needed to do, I'm not totally thrilled with the syntax you ended up using for frag- classes and attributes. There've been various requests for pandoc to support custom classes/attributes for arbitrary markdown elements, but it's not clear if/when that will happen. I've also asked about pandoc supporting a general syntax for delayed/incremental/fragment elements in slides, since beamer (latex) also supports more than just delayed display of list items. I'll keep you posted.
Yeah Jamie that was the original hope I had. In fact if you notice I first use pandoc to convert to dzslides and grab part of that output. I knew the coding was ugly but given my abilities it was the only thing I knew how to do. I appreciate your expertise on this. If you have a better approach (or if one becomes available) I'm very open.
Pandoc is definitely an awesome tool and I think it's going to get even better.
Thanks again.
Yeah. I'd imagine haskel to look a bit scary to non-programmers. I haven't actually used it, before but the pandoc Writers look pretty straightforward.
If you're interested, it's probably not worth trying to bundle with your package until it makes its way through to distro packages, but I submitted pull requests from my pandoc fork, which supports reveal.js output with -t reveal_js. In addition to the basics, ie correctly inserting fragment classes, it makes headers work the way you'd want for reveal.js, so that level-one headers/slides become horizontal stacks containing level-two header/slides. I'm going to play with the css a bit eventually, because I'd like to be able to get the kinds of signposts that beamer gives you. The fancy animations in reveal.js are going to make it a little tricky to find something that makes sense, though.
I've been looking at slidify as a solution to the problems reports was experiencing with presentations (slides). It seems that slidify could be added to the reports package in a much more developed fashion than I was attempting with reveal.js and html5. I am working through understanding Ramnath's package but it's looking very promising as the best solution to this problem.