Describe the bug
src/styles/_mixins.scss contains a @for loop that generates CSS classes .ellipsis-y-1 … .ellipsis-y-10:
|
@for $i from 1 through 10 { |
This change was introduced into the codebase as a side effect of the CRIS merger (related PR #4956).
sass-resources-loader prepends _mixins.scss to every component SCSS file. A partial that is injected like this must only contain variables, mixins and functions. Due to the addition of CSS classes it also emits real CSS rules, so all ten classes (about 1.6 KB) are compiled into the styles of every component. Angular's emulated view encapsulation then scopes each copy to its own component (.ellipsis-y-1[_ngcontent-…]), so none of these copies is useful outside its own template.
The .ellipsis-y-* classes are only used in metadata-link-view-popover.component.html, which uses ellipsis-y-1 and ellipsis-y-3.
For every rendered component, Angular writes a <style> block into the page, and each of those blocks carries a copy of the ellipsis-y-*classes. On an entity landing page I've found 47 <style> blocks with 470 duplicated rules (~75 KB), out of ~605 KB total HTML.
The JS bundle dist/browser/*.js contains 606 component-scoped copies and dist/server/*.js contains 1,158. Every DSpace client has to download and parse them in the webbrowser.
Expected behavior
Files injected through sass-resources-loader (_variables.scss, _mixins.scss) should not emit any CSS classes. The .ellipsis-y-* rules should exist once, not once per component.
I propose to remove the CSS classes in _mixins.scss and define the two required CSS classes (ellipsis-y-1 and ellipsis-y-3) in the metadata-link-view-popover component. If we later find more use cases of these classes, we can adapt the implementation. Currently, we do not need a global definition of those CSS classes in the DSpace Angular project.
Describe the bug
src/styles/_mixins.scsscontains a@forloop that generates CSS classes.ellipsis-y-1….ellipsis-y-10:dspace-angular/src/styles/_mixins.scss
Line 54 in 2ade1e4
This change was introduced into the codebase as a side effect of the CRIS merger (related PR #4956).
sass-resources-loaderprepends_mixins.scssto every component SCSS file. A partial that is injected like this must only contain variables, mixins and functions. Due to the addition of CSS classes it also emits real CSS rules, so all ten classes (about 1.6 KB) are compiled into the styles of every component. Angular's emulated view encapsulation then scopes each copy to its own component (.ellipsis-y-1[_ngcontent-…]), so none of these copies is useful outside its own template.The
.ellipsis-y-*classes are only used inmetadata-link-view-popover.component.html, which usesellipsis-y-1andellipsis-y-3.For every rendered component, Angular writes a
<style>block into the page, and each of those blocks carries a copy of theellipsis-y-*classes. On an entity landing page I've found 47<style>blocks with 470 duplicated rules (~75 KB), out of ~605 KB total HTML.The JS bundle
dist/browser/*.jscontains 606 component-scoped copies anddist/server/*.jscontains 1,158. Every DSpace client has to download and parse them in the webbrowser.Expected behavior
Files injected through
sass-resources-loader(_variables.scss,_mixins.scss) should not emit any CSS classes. The.ellipsis-y-*rules should exist once, not once per component.I propose to remove the CSS classes in
_mixins.scssand define the two required CSS classes (ellipsis-y-1andellipsis-y-3) in the metadata-link-view-popover component. If we later find more use cases of these classes, we can adapt the implementation. Currently, we do not need a global definition of those CSS classes in the DSpace Angular project.