Blueprint: Feature request: Include CSS file which doesn't contain non-pt-prefixed styles

[sceutre]

We have a largish single page application, and we're evaluating and really like blueprintjs. Nice job!

However, if we include the CSS file as is, our page gets subtly messed up. This is because of rules like the following in _typography.scss

ol,
ul {
  margin: $pt-grid-size 0;
  padding-left: $pt-grid-size * 4;
}

We use ul in various places in our UI and changing the margin results in elements laid out incorrectly. Other things I see in _typography.scss make me feel we need to completely regress all our screens after adding your library which makes quite a barrier to adoption.

It would be nice if, in addition to blueprint.css, you could also generate and distribute blueprint-noconflict.css and blueprint-globalstyles.css (or whatever names) and then we could feel safe including noconflict and manually pull any styles from globalstyles we wished to apply.

[llorca]

@giladgray Any thoughts?

[adidahiya]

Removing those styles might subtly break various things in our core components, but I suppose this is something that's worth looking into -- I wouldn't want to ship a separate "noconflict" stylesheet, but rather remove as many global styles as possible from the core stylesheet.

For now, you have a few options:

• load something like a blueprint-patch.css file after blueprint and before your application styles to reset global typography to what you want
• import the .scss files directly and build your own blueprint (see https://github.com/palantir/blueprint/issues/123)
• utilize the .pt-no-style modifier for ol, ul where you need it

[sceutre]

FWIW I found using webpack, postcss, and cssbyebye you can remove any rules in any CSS file you include without having to modify any sources. If you don't mind playing around with webpack configs (not always the most fun) it's a pretty clean way to customize the css you pull in.

var autoprefixer = require('autoprefixer');
var cssbyebye = require('css-byebye');
var ExtractTextPlugin = require("extract-text-webpack-plugin");

...

var cssbyebyeOpts = {
   rulesToRemove: ['html', /^h/, 'ol', 'ul', 'p', /^pre/, 'small' ], // etc. regexes
   map: false
};

...

module: {
 loaders: [
    {test: /\.scss$/, loader: ExtractTextPlugin.extract("file?name=[name].err", "css!postcss!sass")},
    {test: /\.css$/, exclude: /blueprint\.css$/, loader: ExtractTextPlugin.extract("file?name=[name].err", "css!postcss")},
    {test: /blueprint\.css$/, loader: ExtractTextPlugin.extract("file?name=[name].err", "css!postcss?strip")},

...

postcss: function (arg) {
   if (arg && arg.query && arg.query.indexOf("strip") >= 0) {
      return [autoprefixer({browsers: ['> 1%']}), cssbyebye(cssbyebyeOpts)];
   }
   return [autoprefixer({browsers: ['> 1%']})];
}

[pawsong]

Is there any plan to remove default global css in next 2.0 version? Global css sometimes causes conflict with other css library or frameworks.

[giladgray]

@pawsong there is not such a plan. if you can point out specific global rules that cause you pain then we can look into those, but we're not planning to do away with our CSS stylesheet at any point.

[pawsong]

I been thinking changing default line-height and font-size might have potential conflict with other css. Just my 2 cents!

https://github.com/palantir/blueprint/blob/5e6310d8579c271b2cf70e6c5d82d39174903a11/packages/core/src/_typography.scss#L26

https://github.com/palantir/blueprint/blob/77eac90e60252dc66d594cd12b9e73dec4c86966/packages/core/src/common/_mixins.scss#L35

[giladgray]

so we have global styles for the following elements (conveniently all in _typography.scss):

• [ ] html
• [ ] a
• [ ] small
• [x] h1-h6
• [x] body
• [x] blockquote
• [x] code
• [x] hr
• [x] ol
• [x] p
• [x] pre
• [x] ul

I would argue that global styles for the a and html/body tags should remain as they're simple and ensure the tag appears consistent with blueprint.

Other global styles will be easy to move behind a CSS class. I will also ensure that .pt-running-text styles nested tags directly so it can be used on a block of Markdown-rendered HTML (which rarely have added class names).