Open hsablonniere opened 12 years ago
First time I come across this fork : https://github.com/mojavelinux/dzslides
It has interesting ideas (transitions, themes...)
mojavelinux's fork is interesting... Also, while I, in part, prompted this thread by trying to figure out how to best maintain my slides while being able to take advantage of new underlying features, I do like the simplicity and capacity of single file slides. I would hope we'd not lose that capacity.
I have a pandoc template in a fork which produces a more full featured (i.e., slide types) dzslides template.html
.
Note for future : maybe we need some kind of explicit versions for core CSS, JS etc...
FYI, I also have begun looking at splitting HTML, CSS and JavaScript. I intend to use 20+ slides on a single site. Since this is the companion site to a book where I teach web dev, and mention the DRY-principle, I expect lots of comments from students all over Sweden if I keep the current monolithic system.
OTOH, DZSlides is about to enter classrooms in 50 - 100 schools all over Sweden :-)
I also teach web dev and that was my first thought about the one file paradigm. It's good but not when you're trying to explain DRY-principle...
So now DZSlides <3 Sweden ;-)
DZSlides is about to enter classrooms in 50 - 100 schools all over Sweden :-)
Wow!
Here is the situation :
As we discussed it in #52, the one-file paradigm doesn't always fit with these different cases.
What we could/should provide :
template.html
(like the current one)Questions :
How does someone contribute to DZSlides core? Which files are the source?
We can use the 3 standalone files as source and build the different examples (template.html and others) with a simple script (bash, makefile, node...).
What would be the source tree and the branch repartition?
gh-pages
like a CDN.Pros
Cons
How could we reuse duplicate code from shells and
template.html
?Still thinking...
Request for comment!
Let me know all your impressions on that subject...