Relative CSS in parent folder are now added with an absolute path

[cderv]

Here is an example. Note that no matter which way to generate the html (make at the root or use the knit button of RStudio), the line 10 of 01_about/presentation.html has the absolute path there. Thanks @yihui
example.zip

Originally posted by @daijiang in #29 (comment)

[cderv]

Here is the directory structure:

> fs::dir_tree()
.
+-- 01_about
|   +-- libs
|   |   +-- header-attrs
|   |   |   \-- header-attrs.js
|   |   \-- remark-css
|   |       +-- default-fonts.css
|   |       \-- default.css
|   +-- presentation.html
|   \-- presentation.Rmd
+-- example.Rproj
+-- Makefile
\-- style.css

@yihui, do we support in html_document() using a resource file that is stored in a parent folder, so not below the root of the Rmd file folder ?

I think it was working before because we did not mess much with the provided css path. However, now that we have added support for SASS in html_document_base(), we have a treatment to normalize relatively to output_dir.
See https://github.com/cderv/rmarkdown/blob/bc936f75d44d34b60c4fc90cd76304d22b524be6/R/html_document_base.R#L110

if (!xfun::is_web_path(f)) f <- normalized_relative_to(output_dir, f)
  args <- c(args, "--css", pandoc_path_arg(f, backslash = FALSE))
}

I think normalized_relative_to() is there to make sure an absolute path in f will be made relative before being included as a resource. However, this will result in transforming an absolute path something like ../style.css`

In the example above, this is what is called:

# output_dir is ".", the root folder of the Rmd file
# f is the css file path provided
normalized_relative_to(".", "../styles.css")
# > [1] "C:/Users/chris/Documents/DEV_OTHER/ISSUES/xaringan-29/example/styles.css"

Filepath handling become quite complicated at some point. I am always referencing to fs package and it seems it gets the correct result in this case

# ran in debug mode in place of 'normalized_relative_to'
> fs::path_rel(f, output_dir)
../style.css

It seems it handles relative path using also parent folder with ...

We can classify this as a regression. It was introduced in the first place for sass support because sass() will return an absolute path, so we make it relative again. See https://github.com/cderv/rmarkdown/blame/48cc87b9e87518da18e340c019ca6b8efcbfb320/R/html_document_base.R#L109

An easy fix would be to move the line 109 inside the if() to make it run only when .sass or .scss is used. I am not sure if we need this for .css file provided in css argument.

     # Process css files as Pandoc argument if not already been processed by bslib
     for (f in css) {
       if (grepl("\\.s[ac]ss$", f)) {
         if (!xfun::loadable("sass")) {
           stop2("Using `.sass` or `.scss` file in `css` argument requires tass package.")
         }
         f <- sass::sass(
           sass::sass_file(f),
           # write output file to `lib_dir/sass-{sass:::sass_hash()}{[basena)}`
           output = sass_output_template(
             basename = xfun::sans_ext(basename(f)),
             tmpdir = lib_dir
           ),
           options = sass::sass_options(output_style = "compressed")
         )
+        f <- normalized_relative_to(output_dir, f)
       }
-      # do not normalize web path
-      if (!xfun::is_web_path(f)) f <- normalized_relative_to(output_dir, f)
       args <- c(args, "--css", pandoc_path_arg(f, backslash = FALSE))
     }

It seems like the way to restore previous behavior.

But, I am still unsure how well we support resources in parent folder than the Rmd or HTML file. I know that there is a render_supporting_files() to copy resources in a place known and relative to the html I believe.

However, it seems quite common for presentations to store them all in a unique folder with shared resources, so it seems important to support this correctly.

[daijiang]

Thanks @cderv for the quick response! It would be great to support relative path here. Currently, I just manually replaced the absolute path to relative path once the html file was generated.

[yihui]

@cderv We should support relative paths that point to parent folders.

xfun::relative_path() can also deal with ../style.css. I feel rmarkdown:::normalized_relative_to() needs some improvements but I'm not sure how risky it is to touch it or replace it with xfun::relative_path().

That said, the fix you proposed seems to be simple enough and can restore the previous behavior (which is desirable), so I'll apply this fix. Thanks!

[yihui]

Please try the development version of rmarkdown via

remotes::install_github('rstudio/rmarkdown')

[daijiang]

It works well so far, thanks for the help!!

[cderv]

I feel rmarkdown:::normalized_relative_to() needs some improvements but I'm not sure how risky it is to touch it or replace it with xfun::relative_path().

I already hesitated once in the past to change it, but felt the same: not sure how risky it was because they are slightly different.

That said, the fix you proposed seems to be simple enough and can restore the previous behavior (which is desirable), so I'll apply this fix. Thanks!

Thanks for the committing fix while I was gone!

@daijiang

It works well so far, thanks for the help!!

Thanks a lot for confirming that this fixes it !