Open reagle opened 12 years ago
@paulrouget will correct me if I'm wrong but DZSlides does not intend to provide a default stylesheet (for now).
The template.html
only provides styles needed for the current demo example. So even if I really like Takahashi style presentations DZSlides shouldn't impose it to its users.
Google HTML5 slides provides default styles that look like common cases seen in Keynote or Powerpoint.
I think DZSlides could provide some really different examples (contents and form) to demonstrate its powers. Like we had before with the examples folder. It would be a good way to verify how modifications on the core behave with existing slides.
What Hubert says.
On 06/22/2012 08:05 AM, Hubert SABLONNIÈRE wrote:
The
template.html
only provides styles needed for the current demo example. So even if I really like Takahashi style presentations DZSlides shouldn't impose it to its users.
OK, but I'm suggesting that there are dependencies between "your style" and the "default style", or at least in how I'm using them. I've been using 3 cascading styles.
_default (in template.html) _your (in template.html) _mine: this cascades on top of _your with some minor stylistic tweaks and customizations.
However, when I grab the latest Takahashi based template with _mine applied, things don't work and all of my old slides (using the new template) don't look right either. You are suggesting I ought not overlay _mine on top of _your, but replace it with a single CSS: _mine+_your that should be more robust against default changes? (I've tried that too, but feared I'd miss out on some of the new features, and it created some bugs as well, see below).
I think DZSlides could provide some really different examples (contents and form) to demonstrate its powers. Like we had before with the examples folder. It would be a good way to verify how modifications on the core behave with existing slides.
Yes, this could be very useful to users and serve as a test suite against future changes to the underlying code.
I explained the multiple examples in more details in #94.
I'm not sure I'm following your explanation in details. Can you try again to explain what's wrong to you?
IMO I can say the different parts of the CSS (core/your) feel a bit wrong. The order and the CSS priorities aren't easy to handle.
Here's and old deck using dzslides from 2011. You can see it uses "../dzslides/2011/class-slides.css" which itself imports the "user customizable" CSS associated with dzslides ("class-slides-pandoc.css") and my tweaks to that ("class-slides-reagle.css"). Everything works fine.
However, when I move to using a more recently version of the template:
This is further complicated as I'm making use of this through pandoc. In any case, perhaps I should not assume that modular CSS is any more likely to grant me forward compatibility. If so, it'd be nice to have version numbers so I know at which versions I need to keep to. Perhaps this would be addressed by #94 though.
I've modified the most recent version's template to include all the most basic slide types I'd want to use: traditional {text, with img floated {left/right}; Takahashi white/black; Takahashi black/white, etc. I'm not sure if there's a version of compatibility we are shooting for, but I do use some cool CSS3 selectors (only child, nth-child) because my browsers support them.
Furthermore, following the conventions (e.g., H1 with child is traditional slide; H1 alone is Takahashi), these slide types can easily be generated using pandoc without recourse to adding HTML with classes into one's markdown. (The one fix that Pandoc needs is not to generate empty H1s. Otherwise, a few tweaks (e.g., the title page) and it's done! :) .)
It's a first go, so I'd love feedback/contributions -- if the latter, I'd be happy to maintain in a fork.
Note for future : try to be future proof in the core CSS...
@reagle About browser compatibility I think for now versions in #19 serve as a reference. We'll update the README.
@reagle I think your fork can be a base for one of the future examples of explained in #94. I'll look at the details soon.
Thx.
My experience in creating rich dzslide types from simple pandoc was complicated by the fact that pandoc doesn't offer id and class attributes in its markdown syntax (which is okay, I also like simplicity) and the fact that CSS selectors select the descendant of an expression -- that is, you can't say, "apply this style to my parent section
element".
This is an issue even for the default template.html
. blockquote
makes it's height 100% to make the slide black, but if it appears in a p
which has a left-margin, you are screwed. It'd be nicer to be able to have the style applied to the section in which a blockquote appears. In my slide types I have to use lots of similar tricks.
I asked at pandoc if it's possible to include in its section
class declarations from its children elements? So instead of: class="slide level1"
it might say `class="slide level1 h2 img"? I imagine the parser might not want to do that (for the same reason, performance, that CSS selectors don't) and the author agreed, no, that's not something he wants to do.
However, with the use of something like jQuery's ":has()" the CSS could be much simpler. Thoughts?
This is related to #20 (documentation), but I was toying with moving to the newer version of dzslides with its implied Takahashi style of slides with large text. One of the things I noted is that an h2 slide looks just like an h1. It'd be nice if each heading served a particular stylistic purpose. Right now it seems like:
Maybe an h2 could be h/v centered, but white text on a pretty blue background? (I thought of this given the beautiful transition of background color in reveal-js afer slide 7.) We could even make use of h{4..6} elements.
Hence it'd be nice to have, and document, some key default slides types.