search

asciidoctor / asciidoctor-reveal.js

:crystal_ball: A reveal.js converter for Asciidoctor and Asciidoctor.js. Write your slides in AsciiDoc!
http://asciidoctor.org
Other
296 stars 188 forks source link

background image in CSS not possible anymore #226

Closed bcouetil closed 5 years ago

bcouetil commented 6 years ago

First, I want to thank you very much for the good work on Asciidoctor and Asciidoctor-reveal. Using it extensively for both documentation and presentations. Loving it, loving you guys :)

I was on 1.1.3 version and wanted to use the master branch to be able to use plugins. But now the rendering behave deferently and I did not find any way around.

Here is my slides in 1.1.3 : https://bcouetil.gitlab.io/academy/PRES-asciidoc-dark.html

You added this from #16 in HTML : if (slide.getAttribute('data-background-color')) return; var bgColor = getComputedStyle(slide).backgroundColor; if (bgColor !== 'rgba(0, 0, 0, 0)' && bgColor !== 'transparent') { slide.setAttribute('data-background-color', bgColor); slide.style.backgroundColor = 'transparent'; }})

My background image is in CSS, with nothing about style in the .adoc. Now, with new version, the body background is forced to be the same as the slides background.

What do you suggest ?

obilodeau commented 6 years ago

What CSS are you using to set the background image? It looks like it's done with a custom reveal.js theme, is there a place I can look at the source?

Once I know how it's set, I think we can query for it in Javascript and do the background color assignment only if there's no background defined or something like that.

p.s.: Thanks for the kind words :smile:

bcouetil commented 6 years ago

Thank you for the quick answer.

Everything is in reveal-zenika-dark.css, viewable in code inspection.

For the global background : body { background: no-repeat center url(./logo-zenika.png); background-size: 60%; background-color: black; }

For the slide background : .reveal .slides section { background: #222; }

mojavelinux commented 6 years ago

Loving it, loving you guys :)

:heart_eyes:

mojavelinux commented 6 years ago

I had not considered the case where the canvas has a different background color from the slides (since that's not how I make my slides).

In order to support this, I think we'd need to designate a role to control whether the color from the slide gets propagated to the canvas. One possibility is to designate the "layer" role as a way to disable this behavior. Another possibility, which would be more compatible with existing presentations, is to disable this behavior by default and only activate it if the "canvas" role is present. In other words:

[.red.canvas]
== Slide Title

Then the logic in the JavaScript would be:

if (!slide.classList.contains('canvas')) return;

(Another possibility is to use an AsciiDoc option instead of a role, though it would ultimately have to set an attribute in the HTML that the JavaScript can check).

If you see another solution, please propose it.

obilodeau commented 6 years ago

I've played in my head with several alternatives, trying to avoid the additional role but they all come with a global attribute toggle (either to disable the behavior by default or enable it) which I think we need to avoid here...

Your canvas role is what should surprise our users the least. In addition to canvas I would support background too this way it would become even more coherent with the work we did with backgrounding images.

Then you could also say:

[.red.background]
== Slide Title

which makes it pretty clear even for non-HTML/javascript terminology aware people.

@bcouetil, any comments before I proceed with the change?

bcouetil commented 6 years ago

I really like the way that, by default, you don't override the/my CSS. But anyhow, any solution would fly for me, except having to add a role on each slide on each presentation :)

bcouetil commented 6 years ago

I had not considered the case where the canvas has a different background color from the slides (since that's not how I make my slides).

I understand that this is not common, but this enables us as a compagny to put any background or parallax image, staying perfectly readable, regardless of the content and the slide theme : https://bcouetil.gitlab.io/academy/PRES-asciidoc-dark-parallax.html

mojavelinux commented 6 years ago

I wasn't suggesting that your way was wrong. There's no right or wrong. I was just pointing out why I had not considered it.

mojavelinux commented 6 years ago

Your canvas role is what should surprise our users the least. In addition to canvas I would support background too this way it would become even more coherent with the work we did with backgrounding images.

I'd be fine with the background alias for consistency.

I think requiring the background/canvas role makes the most sense.

obilodeau commented 6 years ago

I understand that this is not common, but this enables us as a compagny to put any background or parallax image, staying perfectly readable, regardless of the content and the slide theme

Well, it's not really regardless of the slide theme since it is specified in your slide theme (for a global background) or in your AsciiDoc file (for a parallax). Unless I don't understand how you achieved it.

Don't get me wrong, I'm proceeding with the change we discussed. I just want to make it clear: you do provide a modified slide theme in order to achieve the slide deck you linked. However, you, elegantly, provide it without forking reveal.js' source. Something I need to achieve for my own organization...

bcouetil commented 5 years ago

I know guys, just wanted to clarify my intentions ! And sorry, by saying "regardless of the slide theme", I wanted to say "of what's inside the foreground rectangle" (sorry, I'm french and a backend dev, so expressing myself in this field is not easy :sweat_smile:).

However, you, elegantly, provide it without forking reveal.js' source. Something I need to achieve for my own organization...

:smile:

That is indeed a first and solid step toward an organization-ready asciidoc-reveal example. Here are other things that would improve it :

Any input on these ?

mojavelinux commented 5 years ago

Define a footer text & image : did not find anything out of the box in this project, #53 seems unfinished

You might want to reply on that thread to see if there have been any updates the haven't been reported.

mojavelinux commented 5 years ago

sorry, I'm french and a backend dev, so expressing myself in this field is not easy

You are doing great!

mojavelinux commented 5 years ago

Customize highlight.js : configuration works fine for html5 backend but does not seem to work for reveal

Could you clarify in what way you are customizing it? And how are you doing it with the html5 converter. I'm sure we can replicate that functionality once we understand.

bcouetil commented 5 years ago

Sure. I'm using the maven plugin, see here : https://bcouetil.gitlab.io/academy/BP-asciidoc.html#generation-using-maven

Basically, I use configuration/sourceHighlighter, attributes/highlightjsdir and attributes/highlightjs-theme with html5 (and a downloaded highlight.js folder), and I did not find any combination working with reveal backend.

Showing my full-asciidoc cheat-sheets site to Dan Allen himself is a dream come true :heart_eyes: :flushed:

mojavelinux commented 5 years ago

Showing my full-asciidoc cheat-sheets site to Dan Allen himself is a dream come true

:heart_eyes: You are too kind.

mojavelinux commented 5 years ago

I use configuration/sourceHighlighter, attributes/highlightjsdir and attributes/highlightjs-theme with html5 (and a downloaded highlight.js folder), and I did not find any combination working with reveal backend.

Ah, yes, the highlight.js integration is slightly different in the reveal.js converter. Since Reveal.js has native integration with highlight.js, it actually handles the highlight.js installation. All the converter does is allow the theme to be overridden using highlightjs-theme. If you want to be able to provide a custom installation, we'll need to track that in a separate issue.

You can find the logic for how highlight.js is integrated in the following template: https://github.com/asciidoctor/asciidoctor-reveal.js/blob/master/templates/document.html.slim

obilodeau commented 5 years ago

A fix is on its way to be integrated: #229

bcouetil commented 5 years ago

Cool !

You can find the logic for how highlight.js is integrated in the following template: https://github.com/asciidoctor/asciidoctor-reveal.js/blob/master/templates/document.html.slim

Thank you, I then understood what was wrong, and it now works out of the box ! with this configuration : <source-highlighter>highlightjs</source-highlighter> <highlightjs-theme>highlight/styles/gruvbox-dark.min.css</highlightjs-theme>

BTW, I used the Syntax Quick Reference as a base to test my themes in all formats, especially in reveal. Here are the results.

It took me some time, I did this from scratch, and since there is no asciidoc/reveal live example (or not referenced in documentation), maybe we could host it somewhere to showcase ? (with obvious but easy changes, like images).

obilodeau commented 5 years ago

BTW, I used the Syntax Quick Reference as a base to test my themes in all formats, especially in reveal. Here are the results.

There's a ton of spread out examples in examples/ directory but I agree, there's nothing like what you shared here. I'll open a task about it.

mojavelinux commented 5 years ago

Thanks @obilodeau!

Very cool, @bcouetil!

obilodeau commented 5 years ago

Fix is in master, will be part of our next release. Closing issue. Feel free to re-open if you deem it necessary.

bcouetil commented 5 years ago

Tested it, thanks !