Sweetalert2: Customizable styles

[projct1]

Will be nice if i can full customize styles with scss variables 😄
Parameters like swal2-title, swal2-spacer, swal2-input, etc. By styles i mean margin, size etc.
Now, swal-modal totally stands out from common site styling.

[offenseindepth]

It would be great if we could define the top margin/vertical position of the modal. Is there any intention to have this implemented soon? Is there a possible workaround to get by in the meantime? Thanks and great work!

[limonte]

How about introducing defaultStyling parameter which receives an object, e.g.:

swal.setDefauls({
  defaultStyling: {
    title: <true|false>,
    content: <true|false>,
    input: <true|false>,
    spacer: <true|false>,
    buttons: <true|false>,
  }
})

Default is true for all, if user wants to switch off default styling for some elements of the modal, s/he needs to set corresponding setting to false.

After adding defaultStyling parameter, buttonsStyling will be deprecated (with console.warning message) and removed in the next major release.

Thoughts?

[projct1]

@limonte Yea, and for disable all styling mayby allow to set defaultStyling: false for disable all default styling?

[toverux]

I'm totally in favor of deprecating the old styling-related options and move them to a sub-object! Will also make the docs simpler and reduce the clutter in the options.

[birjolaxew]

Would there be a point in having the styling toggleable in our configuration object, instead of in our stylesheet? The styles we currently have in our config object are styles that might differ from alert to alert, and I don't really see the use case for disabling default styles for a single alert.

I'd suggest adding variables to sweetalert2.scss which allows people to disable various parts of our styling when they compile the stylesheet, and then add instructions for compiling it to the documentation.

[mrchimp]

I would much prefer to configure this in my SCSS. All that would be required would be to change e.g.

$success:  #a5dc86;

to

$swal-success:  #a5dc86 !default;

Then I can just set those variables in my variables file and then include sweetalert2.scss or it can be compiled as it would currently.

If this sounds good, I'm happy to make a pull request.

[toverux]

Yeah, I must admit that I would prefer a solution that is closer from CSS than allowing only a limited, opinionated subset of JavaScript options (that's not very web friendly).
I'd be happy to see a PR that increases the reusability of our SCSS, even if we keep the JavaScript options for now, to keep backward compatibility.

In the future, we should investigate a new, cleaner way to customize Swal. Anyone here has already played with PostCSS? It looks promising and maybe that will augment interop with consumers that use another preprocessor than Sass.

[dobromir-hristov]

Yeah for starters the scss variables should be overridable with !default. A good approach is to have a seperate file with all the variables that is included in the main one. That way you can see a well documented list of variables, that if you define before your inclusion of the sweetalert scss they are overriden and you are good to go.
Also like the way that they are now, if I decide to include the scss into my build, the variables will override my own if not included as a last file.

[limonte]

Here we go: https://github.com/limonte/sweetalert2/blob/master/src/colors.scss

Colors are available starting from v6.5.2

[dobromir-hristov]

Zurb's Foundation has a black and white variables and allot of the times these are not exactly pure white and black. Maybe add a !default to those as well ? Just in case.
Great work on the variables.

[limonte]

Thanks a lot for your feedback @dobromir-hristov !

• Should we add !default to $transparent as well?
• Should swal2- prefix be added to $black, $white and $transparent

[mrchimp]

I would say yes and yes.

On Sun, 2 Apr 2017, 10:25 Limon Monte, [e-mail] wrote:

Thanks a lot for you feedback @dobromir-hristov
https://github.com/dobromir-hristov !

• Should we add !default to $transparent as well?
• Should swal2- prefix be added to $black, $white and $transparent

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/limonte/sweetalert2/issues/410#issuecomment-290975001,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAI_rS1mqnr2bbdJkdXswU2BVgN6Oh1Nks5rr2mAgaJpZM4Ljkg4
.

[dobromir-hristov]

@limonte Yeah. Its a good practice to prefix all your variables. If a user would like to override them easily with his own he could do

$swal2-black: $black // Lets say we have $black defined already.

before the inclusion of the swal styles.

[limonte]

Done: https://github.com/limonte/sweetalert2/blob/master/src/colors.scss

[mattbrunetti]

Awesome! I installed this package just in time.

We have to theme swal2 to match our Twitter Bootstrap themes (our app actually has multiple themes). This feature will make doing so much easier and error-proof.

All I have to do (besides setting the classes to apply to the buttons) is set the swal2 sass variables using the bootstrap sass variables.

@limonte Are you interested in adding the bootstrapColors.scss file into this project, since likely so many people use this package with bootstrap?

[projct1]

Yea, now i totally overwrite (crutch) all swal styles for bootstrap 4, and have to set default settings:

swal.setDefaults({
    buttonsStyling: false,
    confirmButtonClass: 'btn btn-success w-25 mr-05',
    cancelButtonClass: 'btn btn-secondary w-25 ml-05'
});

[mattbrunetti]

We're using Bootstrap 3 since Bootstrap 4 isn't officially released yet.

I guess if support for Bootstrap variables was added we'd want support for versions 3 and 4.

I would gladly open a PR to add support for version 3

[limonte]

@mattbrunetti Great! Please do so, I will gladly review and merge the Bootstrap 3 support.

[AlexSwensen]

we don't use bootstrap by default, and i don't think this should be dependant upon using bootstrap.
I have had to set custom spacing and sizing for both the header text, description text, and button sizes & spacing, as well as overall padding around the modal. Currently i am having to override existing SWAL2 styling, and i have to manually compare and update with every release.

I feel that Most of these should be broken out as variables (as has been done with colors) to make this process simpler.

[mattbrunetti]

@AlexSwensen The proposal, which I wasn't all too clear about, was to provide an extra scss file that you can @import after your bootstrap variables are set and before you @import sweetalert2.scss, optionally, if you are using bootstrap. So the styles wouldn't depend on bootstrap, just add a bit of extra support for those who use it with bootstrap.

[AlexSwensen]

@mattbrunetti ah, that makes a lot more sense. 👍

[cr101]

@mattbrunetti Bootstrap 4 Beta is 91% complete. It would be great to have support for Bootstrap 4 as well.

[limonte]

I guess this issue could be closed.

There are already a lot of SASS variables: https://github.com/sweetalert2/sweetalert2/blob/master/src/variables.scss

Feel free to request variables you missing for your projects.

[craigs100]

Why not just have the ability to switch off the built-in styling all together and provide your own stylesheet/styles? I added this to a project but apparently it's not "on brand" and changing it appears to be too complex a job so having to ditch it unfortunately :( Also would like the JS and CSS files separate so I can decide when and where to load and possibly modify them. Any chance of a sensible download or have I missed the point? Sorry if this sounds mean spirited but just trying to get a job done. I like the idea, just needs some work on the delivery. Many people don't use SASS/LESS and would be very happy with a CSS file. K.I.S.S. ;)

[zenflow]

Why not just have the ability to switch off the built-in styling all together and provide your own stylesheet/styles?

@craigs This needs to be documented, but it is already possible. Just require/import 'sweetalert2/dist/sweetalert2' instead of 'sweetalert2'.. those modules are the same except one injects the default css and one does not.

[zenflow]

Also would like the JS and CSS files separate so I can decide when and where to load and possibly modify them.

The dist folder also contains the styles as a plain css file

[craigs100]

Thanks for your replies. I don't see a /dist/ directory anywhere. All I see is a Git repo for devs to build their own, or two CDN's that just pull down a combined JS and CSS file. No zip or CDN of the basic js and css files which is what you'd expect as a web dev/user.

[dobromir-hristov]

Waw... Use npm.. :D

[zenflow]

@craigs100 compiled files are typically not checked into source-control, i.e. Git. They are in the package published on npm though, so you get them when you npm install sweetalert2.. You can also find them on unpkg.com which serves all the files from all the packages on the npm registry.. see the index for this package.. https://unpkg.com/sweetalert2/

[craigs100]

Thanks for the links to the files but that's the problem. What's wrong with a simple zip file to download rather than insist people have to install npm, node, gulp, grunt, bower or whatever just get get hold of it? Thanks, but I've just built my own. It was easier in the end and will be more flexible in the future. K.I.S.S. ;)

[zenflow]

What's wrong with a simple zip file to download rather than insist people have to install npm, node, gulp, grunt, bower or whatever just get get hold of it?

@craigs100 This particular project has gone out of our way to provide every possible way of accessing the package, so what you say is possible with sweetalert2.. https://github.com/sweetalert2/sweetalert2/archive/v7.19.2.zip .. Every release is available like this.

But FWIW, for more serious projects I would recommend getting used to package managers (e.g. npm) and bundlers (e.g. webpack, browserify), since (1) they make it much easier to upgrade versions and (2) this way every library you try to use will work. It is more complex to start out, but it's more powerful and makes things simpler and easier in the long-run.

[craigs100]

Thanks for the heads up. I didn't realise what I needed was just in the /dist/ directory. Web development has got vastly over complicated in the last 5 or 6 of the 21 years I've been doing it professionally. The maxim "Keep It Simple Stupid" seems to have been lost. Let's hope it returns soon so people can concentrate on building fantastic sites rather than wasting time on the scaffolding. Good luck with your efforts and thank you.

[limonte]

<offtopic>
How it feels to learn JavaScript in 2016
</offtopic>

@craigs100 Regarding to your initial request

Why not just have the ability to switch off the built-in styling all together and provide your own stylesheet/styles? I added this to a project but apparently it's not "on brand" and changing it appears to be too complex a job so having to ditch it unfortunately :(

We're working on theming https://github.com/sweetalert2/sweetalert2-themes/pull/1

There will be clean or minimalistic (name to be decided) theme in the near future. There will be just functional CSS styles an no fancy stuff at all. On top of that theme, users will be able to add their own styles/theme easily without the need to override/reset current styling.