Closed nimo23 closed 7 years ago
I understand the idea, but most people only use a single css framework. I guess you could import the sass files you want, and wrap that inside a new class, and use &-
to namespace.
Or you could use CSS modules.
But renaming everything would bring a lot of noise, and I believe most users don't want that noise.
I understand the idea, but most people only use a single css framework. I guess you could import the sass files you want, and wrap that inside a new class, and use &- to namespace.
Could you expand on this. I'm not sure to understand what you meant.
Alternatively, would you be open to a PR adding prefixes as an optional variables? Something as dumb than
$prefix: 'my-prefix-'
.#{$prefix}input
color: red
I agree that it's rather ugly but I've not done Sass since a long time, so maybe this is achievable in a prettier way.
@jgthms I currently using prismjs
for code highlighting and it is creating classes like number
, tag
, etc which conflicts and results like below. If prefixing by default isn't an option, would appreciate if you consider giving an optional variable to set for those users in need.
Not Namespacing CSS-Libraries is a Anti-Pattern. It is better to namespace by default. .bulma-card is better than .card, especially when using such common names..
@nimo23 I too agree on this. But both Bulma
& PrismJS
libraries already adapted in large and I'm not sure how adding prefix
to its would impact those. Seems PrismJS
also suffering this same issue.
Reopening the issue as I feel all of you make good points.
I will consider adding $prefix
as @Florian-R suggested, and default it to an empty string:
$prefix: "" !default
@jgthms I'm pretty busy ATM, but I'll try to send you a PR for this when I can, unless someone beat me to it.
No worries. I'm refactoring a lot of code. I'll add the prefix later.
I submitted a PR for this. Does it take long to get it reviewed?
@hgezim Did you run $ npm run deploy
as documented in PR template?
@yoostk, I did but css/bulma.css
got some weird changes.
Nothing should change in the deployed css file. $prefix
is set to blank by default.
Here's the diff:
diff --git a/css/bulma.css b/css/bulma.css
index 6703f21..4bd5a0b 100644
--- a/css/bulma.css
+++ b/css/bulma.css
@@ -3222,7 +3222,6 @@ a.box:active {
.level-left {
-webkit-box-align: center;
-ms-flex-align: center;
- -ms-grid-row-align: center;
align-items: center;
-webkit-box-pack: start;
-ms-flex-pack: start;
@@ -3246,7 +3245,6 @@ a.box:active {
.level-right {
-webkit-box-align: center;
-ms-flex-align: center;
- -ms-grid-row-align: center;
align-items: center;
-webkit-box-pack: end;
-ms-flex-pack: end;
@@ -3264,7 +3262,6 @@ a.box:active {
.level {
-webkit-box-align: center;
-ms-flex-align: center;
- -ms-grid-row-align: center;
align-items: center;
-webkit-box-pack: justify;
-ms-flex-pack: justify;
@@ -3817,7 +3814,6 @@ a.box:active {
top: 0;
-webkit-box-align: center;
-ms-flex-align: center;
- -ms-grid-row-align: center;
align-items: center;
display: none;
-webkit-box-pack: center;
@@ -4030,7 +4026,6 @@ a.nav-item.is-tab.is-active {
.nav-right {
-webkit-box-align: stretch;
-ms-flex-align: stretch;
- -ms-grid-row-align: stretch;
align-items: stretch;
-ms-flex-preferred-size: 0;
flex-basis: 0;
@@ -5617,7 +5612,6 @@ label.panel-block:hover {
.columns.is-vcentered {
-webkit-box-align: center;
-ms-flex-align: center;
- -ms-grid-row-align: center;
align-items: center;
}
@@ -5640,7 +5634,6 @@ label.panel-block:hover {
.tile {
-webkit-box-align: stretch;
-ms-flex-align: stretch;
- -ms-grid-row-align: stretch;
align-items: stretch;
display: block;
-ms-flex-preferred-size: 0;
Because the same change can be seen in b2440df07b69b59c95de25479006f509555caefb, the update to 0.3.1 (the commit pushed after your PR), I guess that's a normal behavior.
There's still a conflict even though I did a git pull
from master and then rebased with master from my branch.
It might be better to wait for the maintainer's response 🤔
most people only use a single css framework
That is exactly what I want every time I start a project. However whenever I deal with a project that survives longer than a year, I get frustrated when all the the sexy looking names are taken by a framework
Nowadays one of my biggest concerns is finding easy to cherry-pick frameworks and having total control on non prefixed selectors
CSS Modules are great, but not the best solution. They are only good for cleaning the global namespace
While prototyping or applying minor modifications, I love having quick/dirty non prefixed selectors.
In any case I do not like the "choose your own prefix" approach. I do believe it is far more valuable having two releases: one with and one without prefixes. That way we could get hard stats/data on what people want. Although I fear that what people initially desire/want is very different to what they need in long term projects
I'd love a way to prefix bulma and generate a custom build just like jquery-ui used to to way back in the day. That way the core of bulma stays clean for new projects with only one CSS framework but can create a custom build with bulma restricted to a single container class.
In my case I want to create a site plugin that inserts a chat to any existing webpage. And will love to have bulma in the chat but not outside of it. Hope this helps a little
In my opinion, the right way to prefix css classes, should you need to, is during the build process. I don't think it is right for Bulma to prefix all classes with something like bulma-
, it is ugly and non portable in my opinion.
you are correct, by default, prefixin all its ugly and has several disadvantages. I just posted an example of an online builder, in that way the core is intact and could create a custom scoped build for any purposes, This might actually can be my next weekend project. I just did a PoC using stylus:
const stylus = require('stylus')
const request = require('request')
request.get(
'https://cdnjs.cloudflare.com/ajax/libs/bulma/0.6.1/css/bulma.css',
(err, data, body) => {
if (err) throw err
const styl = `
.pwnChat{
${body}
}
`
stylus(styl).render((errStylus, css) => {
console.log(css)
})
}
)
This outputs something like this:
Personally I think scopes are the way to go. :)
I don't intend to use multiple CSS frameworks, but not prefixing Bulma means one must know ALL Bulma styles before using Bulma. Right now I'm starting using Bulma for a new project and I have Bulma styling applied to elements that I don't want Bulma styling applied to, simply because of the class I used.
Even once you know all styles, you still always have to be careful when you use them.
IMHO it's far cleaner and more portable to just stick a "b-" at the front of all styles. Then you don't need to use silly classes for things in a project just to avoid summoning Bulma.
And I'd hate to try integrating Bulma with an already-established project, like some poor souls here seem to need to do. Surely all projects already have classes like "title", "hero", "card", "button", etc.
I mention this because I really like Bulma, and I put off using it for a long time due to the lack of prefixing, but I'm giving it a go again now. But it would be so much nicer without these surprise styles popping up.
@jazoom looks like @hgezim did a great job adding prefixes to Bulma. I have the same issue. Any real word project has a long history and has a lot of libraries. I'm considering to get rid of Bulma due to lack of namespace feature.
+1 Please consider name-spacing.
I'll beat the dead horse one more time:
Imagine you're trying to convince your team why this is the best framework to pick for our next project and propose to implement the grid system on a module in an existing project as a PoC.
The existing grid uses a .container
class multiple times at diff levels. The end.
It's impossible to implement without side effects.
At least providing an option would be nice, you don't have to make the namespacing required.
My team would like to switch to Bulma
from Bootstrap
v2.3.2
but the conflicts + the work it's going to take to manually isolate all Bootstrap
has kept that dead in the water for a month or more now.
Wanted to use Bulma for a WP plugin today but I couldn't because any site that activates the plugin will for sure have CSS conflicts. +1 for this feature!
Shame this wasn't implemented by now, it's not always a case of "you start a project with a framework and keep it for the rest of it's life". Imagine the case of older projects done with Bootstrap where the dev team would like to switch to Bulma for some new screens, without having to rewrite the entire application. I'd say a prefix var and 2 lines in the documentation should go far on this one.
Still waiting for this implementation ...
I went with Pure because of this issue :-/
We want to use bulma on a lot of our washington post apps but we can't do this unless you guys support prefix due to legacy conflicts.
Guys, I wrap imports within a .bulma { }
, and it works for me.
Based on https://github.com/jgthms/bulma-start/blob/master/_sass/main.scss My main.scss looks like this:
@charset "utf-8";
// Customization
// You can easily customize Bulma with your own variables.
// Just uncomment the following block to see the result.
// 1. Import the initial variables
@import "../../node_modules/bulma/sass/utilities/initial-variables";
@import "../../node_modules/bulma/sass/utilities/functions";
@import "../../node_modules/bulma/sass/base/minireset";
// 2. Set your own initial variables
// Add pink and its invert
$teal: hsl(10, 70%, 61%);
$teal-invert: findColorInvert($teal);
$lightbrown: hsl(43, 27%, 82%);
$lightbrown-invert: findColorInvert($lightbrown);
// Update the sans-serif font family
$family-sans-serif: "Helvetica", "Arial", sans-serif;
// 3. Set the derived variables
// Use the new pink as the primary color
$primary: $teal;
$primary-invert: $teal-invert;
$link: $lightbrown;
$dropdown-content-arrow: $teal;
$button-background-color: $lightbrown;
$section-padding: 0.9rem 0.8rem;//DEFAULT 3rem 1.5rem
@import "../../node_modules/bulma/sass/utilities/_all.sass";
//@import "../../node_modules/bulma/sass/utilities/derived-variables.sass";
$addColors: (
"teal":($teal, $teal-invert),
"lightbrown": ($lightbrown, $lightbrown-invert)
);
$colors: map-merge($colors, $addColors);
.bulma {
@import "../../node_modules/bulma/sass/base/generic";
// 4. Import the rest of Bulma
@import "../../node_modules/bulma/bulma";
@import "formoverride.sass";
//bulma extensions
@import '../../node_modules/bulma-quickview/dist/bulma-quickview.sass';
@import 'bulma.extensions.tooltip';
.dropdown,
.dropdown .dropdown-trigger,
.dropdown .dropdown-trigger button {
display: flex;
flex: auto;
}
.dropdown .dropdown-trigger button {
justify-content: space-between;
}
@import '../../node_modules/bulma-calendar/src/sass/index.sass';
}
I tried Bulma today and I'm convinced of its features, but it's useless without namespace.
Example
The following selector ".delete, .modal-close" for the modal prohibits the use of the class "delete" for any other element.
It's an aberration! How can we know risky selectors or integrate Bulma into an existing application?
@jgthms I don't understand your message :
But the main thing is that namespacing should not be solved this way, but through components, or CSS modules.
I am not sure if it's trivial to others, but it took me some time to figure it out.
To set up a scope for bulma, say 'myscope', I did the following:
npm install -g less
bulma-myscope.less
', in the same folder as the bulma css file.myscope {
@import (less) url('bulma.css');
}
lessc bulma-myscope.less > bulma-myscope.css
.myscope html => html .myscope .myscope body => body .myscope
then import the bulma-myscope.css
in your HTML (and remove bulma.css
)
in the HTML, for the HTML elements that need the bulma, do the following
<!-- has bulma styles -->
<div class='myscope'>
<div class='columns'>
<div class='column is-8'></div>
<div class='column is-4'></div>
</div>
</div>
<!-- no bulma styles -->
<div class='columns'>
<div class='column is-8'></div>
<div class='column is-4'></div>
</div>
Hi, I'm using bulma with wordpress and the generatepress theme. The "container" class, the theme uses it in the customizer, that is, the styles are in line. I need to rename "container" class in bulma. I'm a noob. Thanks
@walty8 this works beautifully. Thank you.
I found a way to add custom prefix to all Bulma class selectors using PostCSS and postcss-prefixer.
An example webpack configuration is here.
@jgthms I currently using
prismjs
for code highlighting and it is creating classes likenumber
,tag
, etc which conflicts and results like below. If prefixing by default isn't an option, would appreciate if you consider giving an optional variable to set for those users in need.
I have the same problem.
Please take notice that Salesforce's Lightning Design System understands the need for automatic CSS scoping, and offers a download tool for prefixing. It seems trivial to add a $prefix variable that Bulma will account for.
https://tools.lightningdesignsystem.com/css-customizer https://www.lightningdesignsystem.com/downloads/
I understand the idea, but most people only use a single css framework
This misses the point. I'm building web components with Bulma, which requires end-users to import compiled CSS - the majority of which are Bulma semantics. End-users should not be expected to accept a complete clobbering of native tags like H1, H2, input, etc, etc. Moreover, how would a large scale application slowly integrate Bulma styles while deprecating another library? They can't.
Please provide prefixing, or accept the PRs of which there are numerous. Thanks.
Eventually we were able to solve this issue with a few lines of regex. Here are two rules that we apply to the codebase to prefix all Bulma classes, variables and mixins with bulma-
:
/\.((?!bulma)[a-z]+(?:-[0-9a-z]+)*)(?!\w*"\n)/.bulma-$1/g
/\$((?!bulma)[a-z]+[^\s]*)/$bulma-$1/g
/\=([a-z\-0-9]+)/=bulma-$1/g
/\+([a-z\-0-9]+)/+bulma-$1/g
You might need to do some small fixes afterwards, as obviously these regexes are not 100 % accurate (but very close). There are a few global styles in base/generic.sass
and base/minireset.sass
, so if you want to make sure Bulma doesn't touch any global CSS you should remove those from the imports.
I've created a simple NPM builder for bulma.css (v0.8.2) with a custom class namespace:
https://github.com/creativesuspects/bulma-custom https://github.com/creativesuspects/bulma-custom/blob/master/all/bulma.prefixed.css https://github.com/creativesuspects/bulma-custom/blob/master/all/bulma.prefixed.min.css
The package also includes a custom builder that allows you to only include the elements and components you need. I have only done some simple tests, but I haven't encountered any issues so far. I've also included the Checkradio extension in the custom build and that also works.
I think this issue is still very relevant.
Because of this "no prefix" design choice, we have to choose Vuetify over Bulma at this current project im working on. Which is kinda sad because i really like Bulma and the other design choices Bulma brings.
The $prefix: "" !default
solution does not in my opinion feel like a big sacrifice to solve a ton of problems for example legacy heavy projects in need of an upgrade.
oh man... Day one of installing Bulma in an existing project and this is a real sticky problem.
EDIT . . . gulp solution below.
For anyone else, here's how to add a prefix to Bulma classes using postcss in gulp.
I've also added an ignore for the modifiers, eg:
<a class="bu-button is-primary">
rather than
<a class="bu-button bu-is-primary">
/* Compile scss files */
function scssTask() {
var processes = [
// Add bu- to start of all classes
// Ignore Bulma modifiers "is-"
prefixer({
prefix: 'bu-',
ignore: [/is-/],
}),
];
return (
gulp
.src( input.location )
.pipe(sass())
.pipe(postcss(processes))
.pipe(gulp.dest( output.location ))
);
}
@robhadfield whitch npm package are you using ? where the above prefixer()
function from ? thanks. same issue for me.
@lgh06 yes, that's the one - good luck! :)
There was a little remaining from what @robhadfield shared to piece together so I shared a complete postcss-prefixer for bulma solution using gulp here: bulma-prefixer. If you are just wanting the compiled css file with the prefixed classes, that should get you closer.
There's more too... here's the full (I think) list of all the other modifiers...
ignore: [
/is-/, // Modifiers
/has-/,
/are-/,
/pt-/, // Padding helper classes
/pr-/,
/pb-/,
/pl-/,
/mt-/, // Margin helper classes
/mr-/,
/mb-/,
/ml-/,
]
If you're using Vue Cli it's very easy to add postcss-prefixer. Vue comes with PostCSS support, all you need to do is add the postcss-prefixer to your project: npm install -D postcss-prefixer
and a postcss.config.js
file to your root with the following:
module.exports = {
plugins: [
require('postcss-prefixer')({
prefix: 'bu-',
ignore: [
/is-/, // Modifiers
/has-/,
/are-/,
/pt-/, // Padding helper classes
/pr-/,
/pb-/,
/pl-/,
/mt-/, // Margin helper classes
/mr-/,
/mb-/,
/ml-/,
],
}),
],
};
I used the ignore list from @robhadfield above. I'm also using this with the latest version of Vue 3 + typescript that's being used for a Wordpress plugin. Was getting frustrated with style clashes ... this solved the issues.
An option to namespace the css would have been nice. Currently I am using postcss-prefixer to namespace the classes. For anyone who is still looking for a way through it, I have added the code to the following repository. https://github.com/itsiprikshit/custom-bulma I hope this helps.
CSS modules is not a standard anymore, CSS scoping is. Namespacing the CSS is still much preferable for any generic library, even with CSS scoping. I work on a project whose maintainer had to prefix all our classes even when having scoping because there could be clashing against things like container
or menu
. This may be a dealbreaker for many people.
Please namespace all your classes with the prefix "bulma-" or "b-", because there are a lot of conflicts when using other css frameworks as well. For example, common css-class names such as .card, .panel etc are in conflict. So please namespace all the classes with "b-" ("b-card", "b-panel", etc.).
Thanks.