Making better use of <h2> and documenting default style

[reagle]

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:

• h1: is horizontally/vertically centered (no room for content)
• h2: identical to 1
• h3: is a more traditional header at the top of a slide, permitting content.
• blockquote: is white text on a black background
• figure/img/caption: is full slide and superimposed on top of the image

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.

[hsablonniere]

@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.

[paulrouget]

What Hubert says.

[reagle]

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.

[hsablonniere]

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.

[reagle]

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:

1. if I use the same "user customizable" CSS from 2011, the text size is OK, but some features are broken (i.e., no incremental, text isn't centered, kitten isn't offset and I can't see the figure caption.)
2. If I use the new template.html and use my old slide content to it, they don't fit on the slide anymore as someone changed the underlying style of the template to the Takahashi method.

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.

[reagle]

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.

[reagle]

OK, now maintained in a fork.

[hsablonniere]

Note for future : try to be future proof in the core CSS...

[hsablonniere]

@reagle About browser compatibility I think for now versions in #19 serve as a reference. We'll update the README.

[hsablonniere]

@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.

[reagle]

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?