Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

changing highlight.js theme results in plain white text #11

Open
jberkus opened this issue Jan 20, 2016 · 7 comments
Open

changing highlight.js theme results in plain white text #11

jberkus opened this issue Jan 20, 2016 · 7 comments
Labels

Comments

@jberkus
Copy link

jberkus commented Jan 20, 2016

If I use the --hightlight-theme switch, it results in plain white text on a black background regardless of which theme I choose. This is with the "Night" slide theme.

@jberkus
Copy link
Author

jberkus commented Jan 20, 2016

Note that, if I swap out the contents of zenburn.css in the prez file tree, the highlighting changes. So there's an issue picking up the highlight.js theme somewhere.

@Delapouite Delapouite added the bug label Jan 20, 2016
@jberkus
Copy link
Author

jberkus commented Jan 21, 2016

More: it looks like zenburn.css is getting copied to build/ regardless of which Highlight style is chosen, which is probably the cause of the issue.

@Delapouite
Copy link
Member

Thanks for your input Josh.

Here's my first conclusion about what could be happening here.

If I go to an empty directory and run the following command :

prez --init --theme=night --highlight-theme=molokai

The generated index.html file in the build directory will have the correct stylesheets included.

But then, if I want to see my newly generated prez in my browser I run :

prez --serve

The issue here, before serving the slideshow it builds again. But this time, this second build step has the theme and highlight-theme options back to default.

So the current way to get the expected result is to run :

prez --serve --theme=night --highlight-theme=molokai

Which means that you need to provide again and again the same options each time you want to serve the prez. Most of the time this line is written in a npm run serve command, so it's ok.

But I guess it can also be counter-intuitive. Maybe --serve should just display the content of the build directory without doing a build before.

What's your opinion on this @naholyr ?

@jberkus
Copy link
Author

jberkus commented Jan 22, 2016

It also breaks the other way. That is, if you didn't init with the highlight theme, then if you serve with the highlight theme it doesn't work. Which means that once you've init'd a Prez directory, you can't change the highlight theme.

@naholyr
Copy link
Member

naholyr commented Jan 22, 2016

It's strange I thought the highlight theme was like other themes and that all available stylesheets were copied, and made available at serve-time. It's definitely a flaw, I'll have a look at what is the easiest solution to have a consistent behavior:

  • not being able to change stylesheet at serve-time, but then at least not having to specify it again and again (in reality, we always put this in npm scripts and didn't realize it could be a PITA)
  • being able to change stylesheet at serve-time (anyway I'd really like to make it happen)
  • both? maybe we could simply put build options in a some file and read defaults from there when serving, so it can be modified later

@jberkus
Copy link
Author

jberkus commented Jan 25, 2016

I'd prefer it to be at serve-time rather than init time if I had to make a choice. I'll often go through testing several different highlighting schemes after the slides are written.

Both, of course, would be better.

In my installation, when I tried to change the highlight theme at serve time, zenburn.css is still the file which is copied regardless of the theme chosen.

@noraj
Copy link
Contributor

noraj commented Jul 27, 2016

That do the same when you use the f keyboard shortcut to go in fullscreen mode.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants