gatsby-background-image: Some utility class names are not escaped which breaks

Related-ish to https://github.com/timhagn/gatsby-background-image/issues/40

Description

When using some Tailwind classes such as w-1/4, the package reuses them as is instead of escaping them which generates invalid CSS:

// Expected
.main-image.w-1\/4:before,

// Generated
.main-image.w-1/4:before,

Expected result

The generated selectors apply to my element

Actual result

The generated selectors do not apply to my element


I linked #40 because when I learned how the package works underneath I was very surprised, and it took me some time to track why things would break as soon as I’d add a class name. I don’t think it was such a good idea to remove unique IDs for the background images, using the classes on them just seems extremely error prone as you trust the consumer of the package to give unique class names to each image which… is the opposite of what a class is for.

Why not simply add an id prop since that’s a unique HTML attribute and make it mandatory? Then you could just target #foobar which would be guaranteed to target this element specifically, would that solve the issue? I don’t believe relying on user class names is very future proof, that or the documentation needs to be much clearer on the constraint around class names being unique. 😕

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 18 (10 by maintainers)

Most upvoted comments

Hi @tomnightingalegithub / Tom & @Anahkiasen!

Finally (though not promised ; ), I came round at having a closer look at this.

As it seems to me that the default characters of Tailwind CSS that have to be escaped are : and / unless you are using plugins for it, I put in a few hours and added an escapeClassNames() function for the pseudo-Elements as well as a specialChars plugin option.

With those it was now possible to use Tailwind classes on BackgroundImage (I didn’t try plugins, though % ). More Information in the README at Tailwind CSS and suchlike Frameworks.

Published in v0.8.8, would you be so kind as to test it and close this issue should it solve the initial problem?

Best,

Tim.

Seems to work perfectly on 0.8.11 👍

Sorry yeah I still need to check this again, will try to give it a quick look this weekend