[Feature Request] Don't style elements via element name selectors

[4storia]

Here's the problem I'm running into:
I added vuetify to my app because I wanted to start using it for new features. Suddenly, all of my h1 are 112px tall, and my buttons have competing margins and font sizes.

For the most part, vuetify's styles are namespaced by class names (this is good!). However, this is not true for button, h1, h2, etc, as well as a few other lesser-used elements (subheading, for example). It's really irritating to pull in a ui framework and have it break a bunch of unrelated styles in your application. I'd love to be able to pull in vuetify and just start using it for new features, instead of having to go back and audit my entire app for style breakages.

I'd be equally fine if the solution here was to build component styles for single components that could be pulled in individually via something like import 'vuetify/dist/vBtn.min.css' (this is assuming they're all well-namespaced). This would also have the advantage of not having to import tons of theming classes if they aren't needed.

I expect to have to re-style parts of my app to conform with a ui framework, but not being able to choose when and how I get to do that kind of sucks, especially for big applications where being able to upgrade things piecemeal is crucial.

[johnleider]

That is really quite interesting as we do not apply styles to block level elements to my knowledge, especially heading tags, which are controlled by classes. In light of that, going to need some additional information.

[4storia]

Interesting, maybe a regression then? I'm using 0.16.4. You can look at line 4177 of /dist/vuetify.css (sorry, I'm sure theres a more convenient src file I could reference here instead). You can also see this codepen: https://codepen.io/Flare/pen/Yrarpo

[johnleider]

It would appear it is, will fix.

[4storia]

:) dope, thanks. Super impressed with vuetify so far btw, amazing work

[johnleider]

So after thinking on this for awhile, I'd like to open up a dialog. While I do agree that having block level styles applied to elements is annoying when trying to integrate Vuetify into another project that has an existing framework, but it's also part of the reason for it being a framework. If we say, all heading tags now must use an explicit class to change their size, that's a very huge breaking change, for not a lot to be gained.

If your goal was to remove these, you could also simply import a custom stylus set and build your own version that does not contain these block level declarations. I can also see where this may seem like I'm forcing a lot of work on the dev for a change, but I'd argue that supporting integration with other framework is not a priority and should require a niche setup for a niche use-case.

[4storia]

A few things, but first and foremost I'd argue that block styling isn't in the spirit of component design, nor is it an encouraged best practice of vue. In the same way it's considered best practice to use scoped on any component you build, or otherwise namespace your css to prevent bleed, I would expect a ui framework to follow the same rules. If you look at angular material, probably the best implementation of material design, you'll see that you can import the entire framework without affecting any of your existing styles (minus one or two body tag styles). With vue's huge emphasis on components and scoped styles, it seems like a big framework anti-pattern to force global styles on an application.

You call it a "niche" to co-exist with other frameworks, but in reality the ability to start a brand new project with a new ui framework is very niche - the real world sees companies and individuals pick up new frameworks for existing applications and slowly phase out the old code. This is a "very huge breaking change" in the sense that it changes how styles are applied to certain elements, but I think the idea that there is "not a lot to be gained" pretty much ignores the vast majority of the userbase, namely companies and individuals who are maintaining existing applications. It is most certainly a breaking change, but I don't necessarily see that as a problem, especially for a pre 1.0 framework. Also, it's a breaking change that is easily resolved for someone already using this framework, because they can just add classes to their existing code, ala something like <h1 class="vuetify"> or <button class="v-primary"> (again, taking inspiration from angular material's mdButton, which compiles down to <button class="md-primary">). It is much harder to pull in and then "undo" specific global styles, especially with the constant threat of future framework upgrades causing more app-wide breakages. Even in the situation where someone created an app from scratch with vuetify, what if in the future you add block styles for a tags - Imagine what a pain the upgrade process looks like for them!

Creating a custom stylus build for this project is a pretty bad answer too - how often do you pull in third party dependencies and then use their build pipelines to patch their code?

As I mentioned above, I think another solution (although less ideal), is that the dist folder ends up looking more like this:

/dist
  vuetify.css
  vuetify.min.css  <-- these two have all the styles
  vBtn.min.css <-- this is just the button styles
  vChip.min.css
  ...

I think that gets close to the same level of flexibility, where developers can import styles for the specific components they want to use, and choose when (or if) to pull in block level styling. This doesn't solve the problem where specific components are currently styled via block selectors (vBtn is an example of this, as it greatly restyles plain button elements), but it IS at least a step towards component design.

Lmk how you feel about all that - apologies for the huge wall of text, but this is a pretty big deal and basically makes or breaks whether I use vuetify at all.

[johnleider]

Jeez, fine, I'll do it :)

…

On Oct 15, 2017 6:33 PM, "Cliff Hess" ***@***.***> wrote: A few things, but first and foremost I'd argue that block styling isn't in the spirit of component design, nor is it an encouraged best practice of vue. In the same way it's considered best practice to use scoped on any component you build, or otherwise namespace your css to prevent bleed, I would expect a ui framework to follow the same rules. If you look at angular material, probably the best implementation of material design, you'll see that you can import the entire framework without affecting any of your existing styles (minus one or two body tag styles). With vue's huge emphasis on components and scoped styles, it seems like a big framework anti-pattern to force global styles on an application. You call it a "niche" to co-exist with other frameworks, but in reality the ability to start a brand new project with a new ui framework is *very* niche - the real world sees companies and individuals pick up new frameworks for existing applications and slowly phase out the old code. This is a "very huge breaking change" in the sense that it changes how styles are applied to certain elements, but I think the idea that there is "not a lot to be gained" pretty much ignores the vast majority of the userbase, namely companies and individuals who are maintaining existing applications. It is most certainly a breaking change, but I don't necessarily see that as a problem, especially for a pre 1.0 framework. Also, it's a breaking change that is easily resolved for someone already using this framework, because they can just add classes to their existing code, ala something like <h1 class="vuetify"> or <button class="v-primary"> (again, taking inspiration from angular material's mdButton, which compiles down to <button class="md-primary">). It is much harder to pull in and then "undo" specific global styles, especially with the constant threat of future framework upgrades causing more app-wide breakages. Even in the situation where someone created an app from scratch with vuetify, what if in the future you add block styles for a tags - Imagine what a pain the upgrade process looks like for them! Creating a custom stylus build for this project is a pretty bad answer too - how often do *you* pull in third party dependencies and then use their build pipelines to patch their code? As I mentioned above, I think another solution (although less ideal), is that the dist folder ends up looking more like this: /dist vuetify.css vuetify.min.css <-- these two have all the styles vBtn.min.css <-- this is just the button styles vChip.min.css ... I think that gets close to the same level of flexibility, where developers can import styles for the specific components they want to use, and choose when (or if) to pull in block level styling. This doesn't solve the problem where specific components are currently styled via block selectors (vBtn is an example of this, as it greatly restyles plain button elements), but it IS at least a step towards component design. Lmk how you feel about all that - apologies for the huge wall of text, but this is a pretty big deal and basically makes or breaks whether I use vuetify at all. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2085 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIpOgpPCMJfLNJAC6XqTQ9cZN46AVxQbks5ssohEgaJpZM4Px5zO> .

[4storia]

MY MAN. Thanks :D

[nkoterba]

Chiming in here as well. Vuetify as a library is great but its handling of styles is having significant impacts on our webapp.

Namely, the inclusion of styles on global document elements (e.g. body, html, main, code, etc) makes some very big assumptions to how we want to style our app.

Here's some examples:

html,
body {
  height: 100%;
  min-height: 100%;
  position: relative;
  width: 100%;
}
html {
  font-size: 14px;
  text-rendering: optimizeLegibility;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  -webkit-tap-highlight-color: rgba(0,0,0,0);
  overflow-x: hidden;
}
body {
  font-family: 'Roboto', sans-serif;
  line-height: 1.5;
}
...
caption {
  font-size: 12px;
  font-weight: 400;
  margin-bottom: 16px;
}
button {
  font-size: 14px;
  font-weight: 500;
  margin-bottom: 16px;
}
ul,
ol {
  padding-left: 24px;
}

I recognize that Vuetify generally expects to be the principal (if not the only) visualization library with styles used in the webapp but this is a stretch assumption to make considering the state of web development today.

I would suggest removing these 'global' styles and instead adding classname styles to specific items that need 'customization' (e.g. button) and trying to generally avoid anything on html and body in general.

[4storia]

Just gonna pop back in here real quick (I know, I know, I'm sorry) and suggest that it might also be worth looking into namespacing some class names too - I noticed things like .title sit in the global namespace (which is the same kind of problem we've been talking about), and also have !important applied to them, which makes it extra hard to override. Because of how heavily vue weights scoped styles for components, I end up using generic class names like .title pretty frequently (which end up getting compiled into rules like .title[data-v-02f41fb8] so they don't bleed elsewhere)

[johnleider]

This has already been completed on https://github.com/vuetifyjs/vuetify/tree/enhancement/theme-part-2 and will be merging into dev here soon.

[asifm]

The link is showing 404 now. https://github.com/vuetifyjs/vuetify/tree/enhancement/theme-part-2

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. Please direct any non-bug questions to our Discord