revert: docs: Fix import order for GitLab CSS bundle
This reverts merge request !1258 (merged)
@ealcantara and I have discussed the changes that have been going on in GitLab UI's visual integration test setup recently.
Most notably:
- "Include GitLab CSS bundle" checkbox doesn't follow resources' order of that of gitlab.com
- docs: Fix import order for GitLab CSS bundle
- visual_gitlab_integration fails to detect inconsistencies
- chore(ci): Fix CSS order in storyshots
We're thankful for the effort that has been put into documenting and/or fixing those issues. However, we feel like those fixes aren't fully addressing the main issue, which is that we're currently unable to consistently reproduce GitLab's styles order in GitLab UI.
!1258 (merged), which we're reverting here, changed the way our custom decorator includes GitLab's CSS in Storybook by appending it to the end of the <head> element, overwriting a behavior that we knew wasn't perfect, but was intended as we wanted to include application.css between Bootstrap's and GitLab UI's CSS: !805 (comment 223937360)
At the time, we agreed to proceed with this initial solution, but we felt (and still feel) like a better option would be to compile a specific CSS bundle in GitLab that would not contain GitLab UI's styles, so that we could properly replicate the styles inclusion chain:
- Bootstrap
- Gitlab UI
- GitLab
Instead of:
- Bootstrap
- GitLab UI
- GitLab
- GitLab UI
At this point, we think that we should take a step back to find a more robust solution by exploring the idea of a dedicated CSS bundle, rather than tweaking the current imperfect setup.
This means reverting !1258 (merged) and putting !1280 (merged) on hold.
These visual integration issues are interlaced with another higher-level problem which is that GitLab UI's components are too sensitive to CSS leaks. We feel like this is a result of our current way of styling components with component-specific stylesheets. We went with this approach because we wanted a way of providing reusable styles for HAML components, but we should assess the current situation and try to answer some questions:
- Is this approach actually valuable for HAML components? Are those component styles actually used in HAML? To what extent?
- Does this approach present any risk for HAML components? Currently, changes can happen in GitLab UI components' markup or styles without ever taking into account their HAML equivalents. It is quite possible for a
@gitlab/uirelease to break some HAML components and we don't have any automated way of preventing this atm. - Can/should we transition to a less CSS leaks-prone solution, which would most likely also mean dropping support for HAML components? Should we consider switching back to a utility class approach, which should be better at preventing CSS leaks, and would limit CSS growth in GitLab UI? This could be done in conjunction with Vue Loader's scoped styles to override underlying components styles when needed.
This MR is not the best place to discuss such big changes, we're considering opening an RFC, and we might need to discuss a bit further synchronously (in a gitlab-ui-wg call for example).