Experiment with re-ordering / moving scss import statements #3

New Issue

adrinux · 2021-11-05T10:44:22Z

adrinux commented

2021-11-05 10:44:22 +00:00

Per @dpschen comment on #954

The @import "colors"; should be removed here and instead added in global.scss below the bulma imports.
Probably also below the theme and components overwrites, but I'm not 100% sure about that.

Reason: the colors.scss produces now CSS output (the :root rules) — it was compiled to nothing before.
Since it's prefixed to every components rendered CSS this would result in a lot of code duplication in the end.
Probably not a big issue with gzip but still unnecessary.

Maybe we should rename it (maybe custom-properties.scss ?) and move it out of this folder (the name variables stood for 'SCSS variables') so that we don't mix contexts, since all the other files inside are imported by this _index.scss.

May allow removal of a lot of !important in the colors.scss.

Per @dpschen comment on #954 > The @import "colors"; should be removed here and instead added in global.scss below the bulma imports. > Probably also below the theme and components overwrites, but I'm not 100% sure about that. > > Reason: the colors.scss produces now CSS output (the :root rules) — it was compiled to nothing before. > Since it's prefixed to every components rendered CSS this would result in a lot of code duplication in the end. > Probably not a big issue with gzip but still unnecessary. > > Maybe we should rename it (maybe custom-properties.scss ?) and move it out of this folder (the name variables stood for 'SCSS variables') so that we don't mix contexts, since all the other files inside are imported by this _index.scss. > May allow removal of a lot of !important in the colors.scss.

adrinux referenced this issue from vikunja/frontend

2021-11-05 10:45:59 +00:00

Migrate to bulma-css-variables and introduce dark mode #954

dpschen referenced this issue from vikunja/frontend

2021-11-07 14:34:15 +00:00

Migrate to bulma-css-variables and introduce dark mode #954

adrinux commented

2021-11-08 22:01:45 +00:00

@dpschen Moved colors import in 0e93ddf4b5

No apparent visual difference.

Should shadows.scss and variables.scss also be moved?

And why does devtools show so many css variables appended to each inline stylesheet? I have no clue how this works...

@dpschen Moved colors import in https://kolaente.dev/adrinux/frontend/commit/0e93ddf4b559df76a643c0395d41e8714104affb No apparent visual difference. Should shadows.scss and variables.scss also be moved? And why does devtools show so many css variables appended to each inline stylesheet? I have no clue how this works...

dpschen commented

2021-11-10 20:31:15 +00:00

I created a branch based on the bulma-css-variables branch and changed the stuff.
Not sure how to createa pull request here though. Here you can see the diff:

https://kolaente.dev/adrinux/frontend/compare/bulma-css-variables...dpschen/frontend:feature/reorder-scss-imports

I created a branch based on the `bulma-css-variables` branch and changed the stuff. Not sure how to createa pull request here though. Here you can see the diff: https://kolaente.dev/adrinux/frontend/compare/bulma-css-variables...dpschen/frontend:feature/reorder-scss-imports

adrinux commented

2021-11-11 11:34:04 +00:00

I was able to create a pull request and merge. Closing.

adrinux closed this issue

2021-11-11 11:34:04 +00:00

dpschen commented

2021-11-11 12:29:43 +00:00

I was able to create a pull request and merge. Closing.

Nice 👍
Did you see the comments where I explain how the prefixed scss gets loaded?
Are those understandable and did you understand now generally how that system works?

I know it's a bit unintuitive that every component basically has its own "scope" but that's just how scss in vue works (I'm not talking about the scoped attribute here but about the fact that the SCSS of every component gets compiled like its a new file)

> I was able to create a pull request and merge. Closing. Nice 👍 Did you see the comments where I explain how the prefixed scss gets loaded? Are those understandable and did you understand now generally how that system works? I know it's a bit unintuitive that every component basically has its own "scope" but that's just how scss in vue works (I'm not talking about the `scoped` attribute here but about the fact that the SCSS of every component gets compiled like its a new file)

adrinux commented

2021-11-11 12:51:55 +00:00

Saw and read those comments. What I don't get is the 'why?', other than that scss needs to be compiled.

But prefixing every component implies that there is no longer any global css? That these 'global' css variables are all sent to the browser for every component?

This is what I'm seeing in FF dev tools anyway - which my reflect the dev tools presentation more than what is actually happening :)

Saw and read those comments. What I don't get is the 'why?', other than that scss needs to be compiled. But prefixing every component implies that there is no longer any global css? That these 'global' css variables are all sent to the browser for every component? This is what I'm seeing in FF dev tools anyway - which my reflect the dev tools presentation more than what is actually happening :)

dpschen commented

2021-11-11 14:26:49 +00:00

I'll try to explain. Maybe also interesting for you @konrad.

(1) SASS

When you add lang="scss" in a component style what happens is that the style block runs through SASS. Basically it's this for every component (pseudocode):

$PARAGRAPH_STYLE = "src/components/Paragraph.vue?vue&type=style&scoped&lang=scss"
sass $PARAGRAPH_STYLE

If there is an include inside the files get included like normally in SASS.

Depending on how the components are bundled the styles might be combined again later.
But if you e.g. import styles in router view components and load them dynamically the styles stay separated.

In order to have access to the SCSS variables and mixins we need to import them in every component style. So basically we could write this:

<!-- above the other component stuff -->

<style lang="scss" scoped>
// this is a new import syntax from SASS that provides the math tools
@use "sass:math";

@import "${pathSrc}/styles/variables";`

// [...] rest of styles
</style>

Because that's annoying to repeat all the time we use an option additionalData in the SCSS processor in the vite.config.js to prefix that code in every component.

(2) Vues scoped styles

But prefixing every component implies that there is no longer any global css? That these 'global' css variables are all sent to the browser for every component?

When CSS is loaded it's global in general. As of now there are only limited possibilites to make CSS scoped (e.g. iframes or — i think – shadow DOM). There are currently some discussions to change that but it's still in flux.

To emulate scoped CSS vue has this scoped attribute for component styles. What this does is:

You wrote in the template <p> => It adds data attributes to the component elements e.g. <p data-v-03e60f2a>
You wrote p { /* [...] */ } in the components scoped styles:
the elements are references via in CSS by p[data-v-03e60f2a] { /* [...] */ }

So basically it increases to specifity automatically for you so that the change of a selector collision is almost zero. So when you use the same tag selector p in a different component vue will use a different data id.

All of this is independent of custom properties or SCSS.

(3) Global styles

Because we want some styles to be global and not scoped we still have one file global.scss. It is not scoped and is included just once in the App.vue, so it will always get loaded just once.

Our definitions of custom properties in the root styles are included in the global.scss. So they should not be duplicated anymore for every component.

This is what I'm seeing in FF dev tools anyway - which my reflect the dev tools presentation more than what is actually happening :)

In theory my pull request should have solved the duplication.

I also found this explanation in the vue-loader: https://github.com/vuejs/vue-loader#how-it-works

I think vue-loader is not used in Vite but the mechanics are similar.

@konrad:
Maybe this is something that should go in the documentation?

I'll try to explain. Maybe also interesting for you @konrad. ## (1) SASS When you add `lang="scss"` in a component style what happens is that the style block runs through SASS. Basically it's this for every component (pseudocode): ```sh $PARAGRAPH_STYLE = "src/components/Paragraph.vue?vue&type=style&scoped&lang=scss" sass $PARAGRAPH_STYLE ``` If there is an include inside the files get included like normally in SASS. Depending on how the components are bundled the styles might be combined again later. But if you e.g. import styles in router view components and load them dynamically the styles stay separated. In order to have access to the SCSS variables and mixins we need to import them in every component style. So basically we could write this: ```vue  <style lang="scss" scoped> // this is a new import syntax from SASS that provides the math tools @use "sass:math"; @import "${pathSrc}/styles/variables";` // [...] rest of styles </style> ``` Because that's annoying to repeat all the time we use an option `additionalData` in the SCSS processor in the `vite.config.js` to prefix that code in every component. ## (2) Vues scoped styles > But prefixing every component implies that there is no longer any global css? That these 'global' css variables are all sent to the browser for every component? When CSS is loaded it's global in general. As of now there are only limited possibilites to make CSS scoped (e.g. iframes or — i think – shadow DOM). There are currently some discussions to change that but it's still in flux. To emulate scoped CSS vue has this `scoped` attribute for component styles. What this does is: - You wrote in the template `<p>` => It adds data attributes to the component elements e.g. `<p data-v-03e60f2a>` - You wrote `p { /* [...] */ }` in the components scoped styles: the elements are references via in CSS by `p[data-v-03e60f2a] { /* [...] */ }` So basically it increases to specifity automatically for you so that the change of a selector collision is almost zero. So when you use the same tag selector `p` in a different component vue will use a different data id. All of this is independent of custom properties or SCSS. ## (3) Global styles Because we want some styles to be global and not scoped we still have one file `global.scss`. It is _not_ scoped and is included just once in the `App.vue`, so it will always get loaded just once. Our definitions of custom properties in the root styles are included in the `global.scss`. So they should not be duplicated anymore for every component. > This is what I'm seeing in FF dev tools anyway - which my reflect the dev tools presentation more than what is actually happening :) In theory my pull request should have solved the duplication. ----- I also found this explanation in the vue-loader: https://github.com/vuejs/vue-loader#how-it-works I think vue-loader is not used in Vite but the mechanics are similar. ----- @konrad: Maybe this is something that should go in the documentation?

adrinux commented

2021-11-11 15:21:22 +00:00

Thanks for the explanation, things are a bit clearer now.

In theory my pull request should have solved the duplication.

I think it has, with the exception of bulma utilities

/* Bulma Utilities */
[data-v-bfe5252a]:root {
  --input-color: var(--text-strong, #363636);
  --input-background-color: var(--scheme-main, white);
  --input-border-color: var(--border, #dbdbdb);
  --input-height: var(--control-height, 2.5em);
  --input-shadow-color: rgba(var(--scheme-invert-rgb, 10, 10, 10), 0.05);
  --input-shadow: inset 0 0.0625em 0.125em rgba(var(--scheme-invert-rgb, 10, 10, 10), 0.05);
  --input-placeholder-color: rgba(54, 54, 54, 0.3);
  --input-hover-color: var(--text-strong, #363636);
  --input-hover-border-color: var(--border-hover, #b5b5b5);
  --input-focus-color: var(--text-strong, #363636);
  --input-focus-border-color: var(--link, #485fc7);
  --input-focus-box-shadow-size: 0 0 0 0.125em;
  --input-focus-box-shadow-color-hsla: hsla(var(--link-h), var(--link-s), var(--link-l), 0.25);
  --input-focus-box-shadow-color: var(--input-focus-box-shadow-color-hsla, rgba(72, 95, 199, 0.25));
  --input-disabled-color: var(--text-light, #7a7a7a);
  --input-disabled-background-color: var(--background, whitesmoke);
  --input-disabled-border-color: var(--background, whitesmoke);
  --input-disabled-placeholder-color: rgba(122, 122, 122, 0.3);
  --input-arrow: var(--link, #485fc7);
  --input-icon-color: var(--border, #dbdbdb);
  --input-icon-active-color: var(--text, #4a4a4a);
  --input-radius: var(--radius, 4px);
}

Which explains why I had to resort to using !important when overriding --input-placeholder-color today.

Thanks for the explanation, things are a bit clearer now. > In theory my pull request should have solved the duplication. I think it has, with the exception of bulma utilities ```scss /* Bulma Utilities */ [data-v-bfe5252a]:root { --input-color: var(--text-strong, #363636); --input-background-color: var(--scheme-main, white); --input-border-color: var(--border, #dbdbdb); --input-height: var(--control-height, 2.5em); --input-shadow-color: rgba(var(--scheme-invert-rgb, 10, 10, 10), 0.05); --input-shadow: inset 0 0.0625em 0.125em rgba(var(--scheme-invert-rgb, 10, 10, 10), 0.05); --input-placeholder-color: rgba(54, 54, 54, 0.3); --input-hover-color: var(--text-strong, #363636); --input-hover-border-color: var(--border-hover, #b5b5b5); --input-focus-color: var(--text-strong, #363636); --input-focus-border-color: var(--link, #485fc7); --input-focus-box-shadow-size: 0 0 0 0.125em; --input-focus-box-shadow-color-hsla: hsla(var(--link-h), var(--link-s), var(--link-l), 0.25); --input-focus-box-shadow-color: var(--input-focus-box-shadow-color-hsla, rgba(72, 95, 199, 0.25)); --input-disabled-color: var(--text-light, #7a7a7a); --input-disabled-background-color: var(--background, whitesmoke); --input-disabled-border-color: var(--background, whitesmoke); --input-disabled-placeholder-color: rgba(122, 122, 122, 0.3); --input-arrow: var(--link, #485fc7); --input-icon-color: var(--border, #dbdbdb); --input-icon-active-color: var(--text, #4a4a4a); --input-radius: var(--radius, 4px); } ``` Which explains why I had to resort to using !important when overriding --input-placeholder-color today.

dpschen commented

2021-11-11 17:41:50 +00:00

I think it has, with the exception of bulma utilities

Which explains why I had to resort to using !important when overriding --input-placeholder-color today.

That looks indeed wrong.
Tricky situation because variables that are defined there are mixed with SCSS that will produce a rendered output.

> I think it has, with the exception of bulma utilities > Which explains why I had to resort to using !important when overriding --input-placeholder-color today. That looks indeed wrong. Tricky situation because variables that are defined there are mixed with SCSS that will produce a rendered output.

konrad commented

2021-11-13 14:46:00 +00:00

Maybe this is something that should go in the documentation?

Probably a good idea yes. There's not really anything about the frontend there yet. Do you want to send a PR?

> Maybe this is something that should go in the documentation? Probably a good idea yes. There's not really anything about the frontend there yet. Do you want to send a PR?

dpschen commented

2021-11-13 18:56:26 +00:00

Thanks for the explanation, things are a bit clearer now.

In theory my pull request should have solved the duplication.

I think it has, with the exception of bulma utilities

/* Bulma Utilities */
[data-v-bfe5252a]:root {
  --input-color: var(--text-strong, #363636);
  --input-background-color: var(--scheme-main, white);
  --input-border-color: var(--border, #dbdbdb);
  --input-height: var(--control-height, 2.5em);
  --input-shadow-color: rgba(var(--scheme-invert-rgb, 10, 10, 10), 0.05);
  --input-shadow: inset 0 0.0625em 0.125em rgba(var(--scheme-invert-rgb, 10, 10, 10), 0.05);
  --input-placeholder-color: rgba(54, 54, 54, 0.3);
  --input-hover-color: var(--text-strong, #363636);
  --input-hover-border-color: var(--border-hover, #b5b5b5);
  --input-focus-color: var(--text-strong, #363636);
  --input-focus-border-color: var(--link, #485fc7);
  --input-focus-box-shadow-size: 0 0 0 0.125em;
  --input-focus-box-shadow-color-hsla: hsla(var(--link-h), var(--link-s), var(--link-l), 0.25);
  --input-focus-box-shadow-color: var(--input-focus-box-shadow-color-hsla, rgba(72, 95, 199, 0.25));
  --input-disabled-color: var(--text-light, #7a7a7a);
  --input-disabled-background-color: var(--background, whitesmoke);
  --input-disabled-border-color: var(--background, whitesmoke);
  --input-disabled-placeholder-color: rgba(122, 122, 122, 0.3);
  --input-arrow: var(--link, #485fc7);
  --input-icon-color: var(--border, #dbdbdb);
  --input-icon-active-color: var(--text, #4a4a4a);
  --input-radius: var(--radius, 4px);
}

Which explains why I had to resort to using !important when overriding --input-placeholder-color today.

@adrinux:

I uploaded a fix for this:
https://kolaente.dev/dpschen/frontend/src/branch/feature/fix-duplicate-root-styles
8aba56a37b

> Thanks for the explanation, things are a bit clearer now. > > > In theory my pull request should have solved the duplication. > > I think it has, with the exception of bulma utilities > > ```scss > /* Bulma Utilities */ > [data-v-bfe5252a]:root { > --input-color: var(--text-strong, #363636); > --input-background-color: var(--scheme-main, white); > --input-border-color: var(--border, #dbdbdb); > --input-height: var(--control-height, 2.5em); > --input-shadow-color: rgba(var(--scheme-invert-rgb, 10, 10, 10), 0.05); > --input-shadow: inset 0 0.0625em 0.125em rgba(var(--scheme-invert-rgb, 10, 10, 10), 0.05); > --input-placeholder-color: rgba(54, 54, 54, 0.3); > --input-hover-color: var(--text-strong, #363636); > --input-hover-border-color: var(--border-hover, #b5b5b5); > --input-focus-color: var(--text-strong, #363636); > --input-focus-border-color: var(--link, #485fc7); > --input-focus-box-shadow-size: 0 0 0 0.125em; > --input-focus-box-shadow-color-hsla: hsla(var(--link-h), var(--link-s), var(--link-l), 0.25); > --input-focus-box-shadow-color: var(--input-focus-box-shadow-color-hsla, rgba(72, 95, 199, 0.25)); > --input-disabled-color: var(--text-light, #7a7a7a); > --input-disabled-background-color: var(--background, whitesmoke); > --input-disabled-border-color: var(--background, whitesmoke); > --input-disabled-placeholder-color: rgba(122, 122, 122, 0.3); > --input-arrow: var(--link, #485fc7); > --input-icon-color: var(--border, #dbdbdb); > --input-icon-active-color: var(--text, #4a4a4a); > --input-radius: var(--radius, 4px); > } > ``` > > Which explains why I had to resort to using !important when overriding --input-placeholder-color today. @adrinux: I uploaded a fix for this: https://kolaente.dev/dpschen/frontend/src/branch/feature/fix-duplicate-root-styles https://kolaente.dev/dpschen/frontend/commit/8aba56a37b2e34403bd6beeed1e7c7dfc30cf2a5

dpschen referenced this issue

2021-11-13 18:58:49 +00:00

Improve documentation of frontend styles #6

dpschen referenced this issue from vikunja/frontend

2021-11-13 19:01:22 +00:00

Improve documentation of frontend styles #1862

Sign in to join this conversation.