ember-cli-addon-docs: Dealing with css conflicts
The addon I am writing docs for uses a design system that is based on Tachyons. This is causing me problems in a few cases, most notably with the absolute class added to the nav here. The problem is that because I’m importing my css first before the css from this addon my absolute is superseding positioning applied to the nav by the lg:relative class and therefore always positioning the nav absolutely.
I think there might be a way to fix this particular case, but more broadly do you have any advice on how to address this kind of issue?
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 18 (10 by maintainers)
I don’t have time to work on this now, but for anyone who’s motivated here’s what needs to happen:
We need to re-work AddonDocs’ usage of Tailwind to not include Tailwind’s Preflight styles.
These base styles make sites easier & more consistent to work with, but it is possible to use Tailwind’s utilities without them. I believe Adam said the biggest change is that the use of
bordernow needs to be accompanied with a border color and border style. You can read some about that here, as well as other changes Preflight brings along – but note that that link is to 1.0, and AddonDocs currently uses Tailwind v0.Unfortunately right now, AddonDocs uses
ember-cli-tailwindwhich has the preflight directive hardcoded into its modules.css file. So to actually remove preflight, we need to first either (1) add a config option toember-cli-tailwind, or (2) removeember-cli-tailwindaltogether, and wire up our own postcss pipeline withember-cli-postcssthat includestailwindcss. This would also allow us to add purgess to the pipeline, which would be ideal. (This very reason is also why I’m going to deprecate the addon and suggest folks set up a postcss pipeline in their own projects.)Once we exclude Preflight from our Tailwind build, we’ll then need to update our components to make sure things look good without the reset. We could either include a new reset like vanilla normalize, or include the option for no reset, so visual addons like Ember Styleguide can bring their own global styles and be guaranteed of no collisions with styles provided by AddonDocs.
The only other alternative I can think right now would be to expose an option that doesn’t include any css from AddonDocs, for addons that want full control over styling. Those addons could still use AddonDocs’ components as provider/renderless components, so they have things like the version selector in the header and the navigation index in DocsViewer. Then, those addons could style everything on their own.
I originally wanted to add renderless data-provider components for all the data AddonDocs provided, and then rebuild the UI components with those, so others could opt-out of the visual styles AddonDocs provides and still use the data providers. But I never got around to it.
If anyone wants to take this on and needs any help or direction, I am more than happy to provide some guidance!
https://github.com/embermap/ember-cli-tailwind/blob/master/lib/modules.css
Yes - we should probably prefix the Tailwind classes we’re using, perhaps with
ad-so they don’t conflict.I also want to get PurgeCSS in here so we don’t ship a bunch of unused classes.
Gotcha, makes sense.
Sad to see you go! If you find yourself using it again, let us know if you run into issues again.
Looks like some stuff is styled on the html elements which can also cause issues:
Another example:
+1 on this - I’m also using a modified Tachyons system and I’ve been overriding templates to “fix” the class conflicts