Open olivictor opened 8 years ago
Well you can use them with @extend
but that works a bit differently.
@extend
doesn't work very well I'm afraid... I think it would be a nice feature if it's not too hard to maintain.
Do you have a use case in mind?
Sorry about the late answer!
The use case is really to decouple the framework functionality from the class names you have defined. This way you can use BEM for example (or any other naming convention) without any adicional atomic-like classes, leaving only semantic classes that make sense to your application on the html document. That generally makes sense on big applications that require many different components.
Also you can provide modules that we could use separately... suppose I just want to compose some element with the bulma grid behaviour and some other styles. Then this kind of thing would be possible:
@import "bulma/grid";
.some-site-section {
@include grid;
margin-bottom: 20px;
}
I'll keep an eye on the project and create some composable mixins for my projects. I can show you some real use cases then ;)
@jgthms I like the suggestions outlined here, can you please reopen this?
@jgthms I'd love to see this implemented as well. Coming over from Foundation, it was nice to be able to include class names as mixins as means to keep my markup semantic.
Re-opening so we can investigate how this could work.
I'm planning on re-introducing extends in the codebase. I think it would work better than mixins because if you do @include grid;
any time you need the grid, you're gonna end up with a huge CSS with lots of repeated sections.
First, I think we need to define what we mean by semantic HTML - is the goal here being able to turn something like
<div class="section is-half is-primary">
...
</div>
into
<div class="some-section">
</div>
I can see both perspectives of using @include
or @extend
but unsure what the right path here is.
On one hand, @extend
is usable now if you create a class after importing Bulma.
@import 'bulma';
.some-section {
@extend .section, .is-half, .is-primary;
...
}
Assuming that .section
, .is-half
and .is-primary
is never going to get used again in HTML to enforce semantics, then those classes are now considered bloat, hence a need for using mixins and @include
. My problem with this is by enforcing semantic HTML, we just hide styling complexities in CSS, which loses some of the advantages of Bulma for developers who are not into CSS as much.
As such, I'm wondering if it may be worth thinking about going the Bootstrap route where we can make mixins to use for building base classes.
// pseudo code
@import 'bulma/utils/'
.section
@include make-section()
.is-half
@include calculate-size(6/12)
.is-primary
@include set-colors($primary-color, $inverted-color)
This way we have utility mixins that front end devs can use to extend Bulma and have the ability to pick and choose which parts of Bulma they want to use so that they can optimize based on their needs.
Sorry for the long post, would love to see a discussion around this :)
@angelocordon This is what I and much other developers like to use (the bootstrap way). To be true because this is not possible yet, it's holding me back from using Bulma. Working with a CMS is a pain if I have to insert additional classes instead of the "pre-defined" classes, given by the CMS. I'd rather like to semantically extend (@ include) a given class like .headings with bulmas .title. Just an example.
I hope my text is clear. I am not a native English speaker.
@jgthms Was wondering if there was any updates on this feature request?
I'm trying to use the Tile feature and need change the sizes based on the breakpoint. Since Sass doesn't allow extends inside of a mixin, it doesn't seem like there's a clean way to this besides writing the css myself. Unless there's a different way, I'd love to see something like this implemented.
Here's an example of what I'm trying to accomplish below.
.staff {
margin-top: $gap;
flex-flow: wrap;
@extend .tile, .is-ancestor;
.is-parent {
@include tablet {
@incldue tile-size(6)
}
@include desktop {
@incldue tile-size(4)
}
}
}
Here's an example using Foundation that I wrote which illustrates what I'm trying to achieve.
.bios {
@include block-grid(1);
@media #{$medium-up} {
@include block-grid(2);
}
@media #{$large-up} {
@include block-grid(3);
}
@media #{$xlarge-up} {
@include block-grid(4);
}
}
Sass's @extend
-only selectors might fit in well with this approach. Defining Bulma's core classes as placeholder selectors would make it simpler for developers to construct their own semantic selectors using @extend
without the core classes bloating the final CSS file.
(It will obviously be necessary to continue to provide the 'normal' version of Bulma too, but it should be possible to create a build script that extracted each placeholder selector and created a matching 'normal' selector that just extended the placeholder version.)
hey there, recently encountered a use case where I'd need sth like this. I've been trying to provide bulma like styling for https://github.com/CurrySoftware/elm-datepicker and the only available way, due to how the library is built, was to write my own scss
file.
Needless to say, I wanted to do sth like:
.#{$datepicker-ns}day button {
@extend .button.is-white;
}
but it was not possible, compiler was telling me that it couldn't find .button
selector.
Anyway, thumbs up for resolving this issue as there are some use-cases that support it.
While this feature wouldn't be useful for all Bulma users (as mentioned in #1402), it also wouldn't negatively impact any users, and it would open the door to many more developers interested in defining their own class naming system or utilizing component-specific classes in their application.
Bulma seems great but used in a large application there's a very real chance that some other library, framework, or component is going to be either defining or attempting to use some of the same class names that Bulma defines. The results would be undefined behavior depending on the order of stylesheet loading, and one may not realize when this starts happening right away.
Allowing people to use mixins (or extend-only selectors) for Bulma would eliminate this possibility, and then these mixins could be included (or selectors extended) for the actual default Bulma classes so that those including the main Bulma CSS would still use it exactly as they did before. But those wanting to do their own thing could simply include the relevant SASS components from Bulma and include the mixins or extend the extend-only selectors themselves.
+1 for adding mixins. With @extend
you can't do the following:
@include until($desktop) {
@extend .is-size-2;
}
You may not @extend an outer selector from within @media. You may only @extend selectors within the same directive.
I ran into this as well. I'm using reusable HTML components which each have their own styling, instead of sprinkling style-classes all over the place, I prefer to define a top-level class for each component, and then use CSS paths to define the style of the entire component's element tree starting from the root of that component.
I've had some success using simple @extend .is-size-6
, etc, but
@extend .icon
, only to find out that there were some styling inconsistencies because the .button
styling changes depending on nested .icon
classes (using @extend .button
on the button doesn't work in these cases, because it specifically looks for the icon
class on its children).I realise this is probably quite the effort to do this, and given this issue is pinned I'm pretty sure it's past the consideration phase and it now requires contributions to make this happen, but I wanted to put the above use-case here either way, in case it further explains to someone why it would be good to have this.
Sass's
@extend
-only selectors might fit in well with this approach. Defining Bulma's core classes as placeholder selectors would make it simpler for developers to construct their own semantic selectors using@extend
without the core classes bloating the final CSS file.(It will obviously be necessary to continue to provide the 'normal' version of Bulma too, but it should be possible to create a build script that extracted each placeholder selector and created a matching 'normal' selector that just extended the placeholder version.)
This sounds like the best approach to me because theoretically the user would also not have to compile every class that they don't use. In other words, I'll never use col-2
in my project so why should it be in my compiled code?
With placeholder selectors, we can use them as if they were mixins or classes, and the ones that don't get used don't get compiled.
It seems like this wasn't updated for a while and I am wondering if its still something planned for bulma. I am interested in bulma as basement for a css library and currently its tricky to actually extend bulma's rules. Is this still planned? Would you accept merge requests? I am looking forward to any reply :)
Besides this, thanks for the greatest CSS thing out there, keep on going! :)
Recently started using Bulma, and I too was looking for something similar to how Tailwind allows you to use @apply
. It's really nice to be able to tidy up the really long class names on my HTML elements to a single name. e.g.
<!-- Original -->
<div class="is-fullwidth is-fullheight is-flex is-justify-content-center is-align-items-center is-flex-direction-column">
<!-- Desired -->
<div class="my-div">
<style>
.my-div {
@apply is-fullwidth is-fullheight is-flex is-justify-content-center is-align-items-center is-flex-direction-column;
}
</style>
This way we could use any naming convention and compose the elements styles using
@include