Vuetify: [feature request] Add specific vuetify prefix to classes declarations

Created on 1 Sep 2017 · 17Comments · Source: vuetifyjs/vuetify

Adding Vuetify in an existing project causes glitches because css are not well scoped.
Classes like .warning, .info or .title are really common and they shouldn't collide.

One easy solution could be to prefix all Vuetify classes with an unique string like vtf-

Epic enhancement

Source

ghost

❤18

Most helpful comment

It's something actively being worked on. The first set will be in 1.1

On Sat, Mar 24, 2018, 11:36 AM Tor Arne Vestbø notifications@github.com
wrote:

Is there an up to date guide on how to work around this with Vuetify
1.0.10? I'd like to use Vuetify with a-la-carte components, and have those
components I import not pollute the global CSS styles, affecting nothing
but their own component's style. Is this possible through editing of e.g.
the stylus rules, or some webpack plugin/module? Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/vuetifyjs/vuetify/issues/1561#issuecomment-375898540,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIpOgkngM5mkkxb5Y2X9lo1ADu2EENKnks5thmfjgaJpZM4PKNLJ
.

johnleider on 24 Mar 2018

👍5 🎉3 🚀1

All 17 comments

That would be awesome, for now I have to replace my integrated Vuetify component with a vanilla JS/CSS plugin since I am not able to fix all the layout glitches I get when I include the Vuetify styles :(

smxsm on 27 Sep 2017

Remove @extend in Stylus code use function instead see #1902
Only two files :)

And the final user can use Stylus supports block-level import for isolate Vuetify style

.vtf
    @import 'path/to/node_modules/vuetify/src/stylus/main.styl'

Zeph33 on 12 Oct 2017

After discussion with the community, backers and team, we have decided that while this will be done to a degree, it will not be done for v1.0. There are many colliding opinions on what should and should not be scoped for ease of use and also specificity. With 1.0 being a large release in itself, a change like this should be better reserved for when we have a better handle of the exact use-cases we plan to support and those that we do not.

We will continue to evaluate the best possible way to integrate this task within the framework.

johnleider on 22 Nov 2017

👍2 👎1

@johnleider too bad, and now that the Stylus stuff was refactored in 0.17.0 the workaround by @Zeph33 doesn't work anymore .... and if I try to integrate a current 0.17.5. Vuetify app in my shop, it looks like this:

Instead of this:

So, it looks like Vuetify is totally unusable for "integration" in other frameworks/layouts and only usable standalone in its current state I think ... :(

smxsm on 16 Dec 2017

👍4

We integrated Vuetify into an web-application with existing CSS which is still in use. To prevent cross-side effects like those described by @smxsm we use postcss-parent-selector to add a parent selector ".vuetify" to each style declaration comming from vuetify.
That works nice for us but in a few cases produces errors because of increased selector specificity.

But maybe this is a valid/quick workaround for you aswell. At least for the time vuetify doesn't do it by itself :)

julkuh on 16 Dec 2017

Hi @julkuh thanks for the tip with postcss ... mind sharing your config? I am using the advanced webpack config and although the vue-loader already seems to support postcss I'm having a hard time to find the right place to add the parent-selector plugin :)

smxsm on 16 Dec 2017

@julkuh nevermind, figured it out... at least it adds my prefix now :) And it looks goooood, the layout isn't broken anymore 👍 I owe you a beer or two! :)
For anybody interested, here is the part I've added in my utils.js which configures the CSS loaders (first do a "yarn add postcss-loader" and "yarn add postcss-parent-selector"):

exports.cssLoaders = function (options) {
  options = options || {}

  var cssLoader = {
    loader: 'css-loader',
    options: {
      minimize: process.env.NODE_ENV === 'production',
      sourceMap: options.sourceMap
    }
  }
  // smx_sm -  added postcss loader with plugins
  var postCssLoader = {
    loader: 'postcss-loader',
    options: {
      ident: 'postcss',
      sourceMap: true,
      plugins: (loader) => [
        require('autoprefixer')(),
        require('cssnano')(),
        require('postcss-parent-selector')({selector: '.vuetify_wrapper'})
      ]
    }
  }

  // generate loader string to be used with extract text plugin
  function generateLoaders (loader, loaderOptions) {
    var loaders = [cssLoader, postCssLoader]
    if (loader) {
      loaders.push({
        loader: loader + '-loader',
        options: Object.assign({}, loaderOptions, {
          sourceMap: options.sourceMap
        })
      })
    }
    ...

smxsm on 16 Dec 2017

👍1

Oh no, now the "select option offset" problem is back :( https://github.com/vuetifyjs/vuetify/issues/1490
With the parent-selector in place, the option values are in the top left corner, if I add the "data-app" attribute and the "application" class to my outer body element as suggested in that issue:

If I do not add the attribute and class to the outer div, the values have an offset ...

If I also add my parent-selector to the outer div, too, I'm getting other side effects again ...

$('div.page-wrap').addClass("application application--light vuetify_wrapper");

The problem seems to be that the option values are not placed inside the wrapping vue/vuetify app element, but somewhere up in the main body content, so the styles with parent-selector don't apply for them.

<!-- OUTER BODY DIV -->
<div class="page-wrap application application--light" data-app="true">
...
    <div class="card">
        <div class="list_tile ..." ...> <!-- SELECT OPTIONS SOMEWHERE HERE -->
    </div>
   ....
    <!-- HERE COMES MY "parent-selector" WRAPPER DIV -->
   <div class="vuetify_wrapper">
       <!-- NOW THE VUE(TIFY) APP -->
       <div data-app="true" class="application theme--light" id="app" light=""> 
       </div>
   </div>
   ...

Are you using v-selects, too, @julkuh ? Any solution? :) The only dirty workaround I see is to add extra styles (without the "parent selector") for the ".list_type ..." classes related to v-select and its options to get them the correct positions and layout ... or to try to exclude all v-select related styles from the parent-selector .... :(

smxsm on 17 Dec 2017

Ok, that dirty workaround basically works...

I have duplicated the related styles for the v-select and removed the parent selector for those ... kinda hacky, but it "works" for now ;)

smxsm on 17 Dec 2017

👍1

Maybe the nicest fix for this would be not prefixing / scoping vuetify itself, but transforming vuetify's styles into a "standalone CSS framework". To me the single largest downside to vuetify is I can't (easily) use the same styles in other parts of my website (unless I dig into the .styl files, of course, but real documentation would be, well, much nicer)...

Take for example bootstrap-vue: since it extends bootstrap, it provides us with consistent styling between the Vue parts of the website and the content-only parts, as well as well-documented class names for all UI features.

Consider also buefy's approach: it's built around bulma and it takes things one step futher: there are no components that would be nothing but style wrappers. Its components either provide vue-driven behaviour, or you are directed to bulma's documentation otherwise. I personally find that beautiful, but that's a matter of taste. Either way, it provides standalone, documented stylesheets and that's important for a hybrid app.

Vuetify on the other hand seems to be built with the mindset "single-page-app or nothing".

We evaluated these (and more) for the project we are currently kickstarting at work. It's a hybrid website, and there's no way around it. So as far as vuetify goes, we like it, we love it, it's amazing, but we will probably have to choose one of the contenders because of this one reason. And that's, well, sad.

@johnleider: what do you think? Would you consider taking the framework in this direction?

xlotlu on 22 Dec 2017

👍2

Unfortunately you can not meet everyone's needs. If we remove the styles from the individual components, you will not be able to reduce the css size with a-la-carte, and people will be upset about that. There is one thing in common between your 2 exampled projects, they are based off of something else. They do not have to focus on the styling portion (maybe not bulma) of the application, and instead are able to create this abstracted experience that you are referencing.

johnleider on 23 Dec 2017

👎1 👍1

But there would be no need to disconnect the styles from the individual components. Even if you were to separate the styles in a different package, you would pull it in as a dependency, and continue require()ing the .styls as usual.

I quoted "standalone CSS framework" as I was only thinking of making it easy to use its classes directly, so it gets hybrid-app friendly. All this would take is to:

document the class names,
cover all the usual use-cases of a CSS framework (i'm really not sure if there's anything left, you seem to have covered most angles),
and maybe scope stuff locally to where it applies, e.g. .alert--warning, .btn--warning etc. instead of .warning.

This would make it entirely redundant for users of Vuetify to use another "official" CSS framework. Hybrid-app friendly, single source of truth, definitely lower overall css size, win-win for everybody.

Splitting the styles into a separate product would be the icing on the cake, but it's entirely unnecessary. If someone would want to use the CSS standalone without the Vue machinery, they could do that right now anyway, with a-la-carte as a bonus.

Happy holidays. :)

xlotlu on 23 Dec 2017

👍5

Is there an up to date guide on how to work around this with Vuetify 1.0.10? I'd like to use Vuetify with a-la-carte components, and have those components I import not pollute the global CSS styles, affecting nothing but their own component's style. Is this possible through editing of e.g. the stylus rules, or some webpack plugin/module? Thanks!

torarnv on 24 Mar 2018

It's something actively being worked on. The first set will be in 1.1

On Sat, Mar 24, 2018, 11:36 AM Tor Arne Vestbø notifications@github.com
wrote:

Is there an up to date guide on how to work around this with Vuetify
1.0.10? I'd like to use Vuetify with a-la-carte components, and have those
components I import not pollute the global CSS styles, affecting nothing
but their own component's style. Is this possible through editing of e.g.
the stylus rules, or some webpack plugin/module? Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/vuetifyjs/vuetify/issues/1561#issuecomment-375898540,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIpOgkngM5mkkxb5Y2X9lo1ADu2EENKnks5thmfjgaJpZM4PKNLJ
.