Breakdown Stylesheets into Logical Parts
In order to assure better maintainability and better cooperation for contributors, it would be good to breakdown current stylesheet source horizon.less into multiple files based on Horizon's logical parts. Main file (horizon.less) would only include partials and actual styling should happen only in those partials. With this approach we assure that we easier find styling for particular section and if somebody will be dealing only with that section (e.g. instances) he will not have to change one big robust file, but just its related part. Suggested structure will be specified on whiteboard later on.
Blueprint information
- Status:
- Complete
- Approver:
- Matthias Runge
- Priority:
- Low
- Drafter:
- Jaromir Coufal
- Direction:
- Approved
- Assignee:
- Maxime Vidori
- Definition:
- Approved
- Series goal:
- Accepted for liberty
- Implementation:
-
Implemented
- Milestone target:
-
8.0.0
- Started by
- Jaromir Coufal
- Completed by
- David Lyle
Related branches
Related bugs
Sprints
Whiteboard
[jcoufal]
Structure proposal:
-------
[layouts]
| _shell.less
| _navigation.less
| _modal.less
| _detail.less
[responsive]
| _instances_
| ...
[vars]
| _mixins.less
| _vars.less
| _vars_colors.less
...
... (etc.)
...
_overview.less
_instances.less
_instances_
_instances_
_instances_
_volumes.less
...
... (etc.)
...
_responsive.less
dashboard.less
login.less
-------
Basic idea is to have top level stylesheets, each representing one layout (dashboard.less and login.less). That top-level stylesheet includes all related top-level partials in following sequence:
* vars, mixins, resets
* layouts
* sections (like _overview.less, _instances.less, etc.)
* responsives
Each section in the UI needs to have one top-level partial which represents it. For example:
* _instances.less
= top-level partial, including styling for top-level view (view for menu item Instances) and includes all related sub-partials
* _instances_
= sub-partials are defining views which you can access from the main view (and is related to the view). So, from instances, you can get modal for creating instance, editing instance or instance detail.
Any questions, concerns or suggestions are very welcome.
***
[mvidori]
I started this one, css code is pretty messy, lots of work in propects
I first created this architecture,
[admin]
_defaults.less
_domains.less
_flavors.less
...
[layout]
_alert.less
_detail.less
_form.less
_table.less
...
[project]
_access_
_containers.less
...
[settings]
_change_
_user_
[vars]
_mixins.less
_type.less
_utils.less
_vars.less
_vars_colors.less
dashboard.less
login.less
horizon.less
layout files are full of code but admin, project and settings are pretty empty. I will try to tidy a bit for a first commit.
***
[jcoufal 2013-09-05]
Hey Max, thanks for taking care about this BP. The whiteboard was created before Bootstrap v3 and our upgrade to v3 will affect the file structure. I would just comment with some enhancement proposals, and @jtomasek is going to write more about integration with Bootstrap v3.
[layouts] and [vars] sounds good to me as folders. In [layouts] I would keep global page layouts (or some page subparts related to the page layout - no tables or forms).
Then _tables.less, _forms.less, _buttons.less and similar components (which are globally used) I would move to [components]. Note that we are going to base as much as possible on bootstrap and in components we are going to override and/or enhance bootstrap bits.
Then I don't think we need the separation for [admin] and [project], because they have very similar elements (e.g. instances, volumes, etc) and furthermore there is intention to enhance the IA and then this breakdown will not respect it. I would suggest to keep these in one folder for now, e.g. [specific], which would include _instances.less for example. As you mentioned, in [specific], there would be only view specific things and we need to be very sure, that things which are in specific can't be globally used, so that they belong only to that specific view and not to components.
Otherwise it sounds good to me. I hope you two guys (you and @jtomasek) won't have much conflicts in the code.
***
[jtomasek]
Related to this is my work on updating to Bootstrap 3. (https:/
openstack_
openstack_
- here are all files that we need to override bootstrap styling, the structure here strictly resembles to bootstrap less files naming. So if we need to override variables, we create variables.less here and import the bootstrap variables file at the beginning of it. Then folder also includes bootstrap.less that looks like this:
@bootstrap-
// Core variables and mixins
@import "variables.less";
@import "@{bootstrap-
// Reset
@import "@{bootstrap-
@import "@{bootstrap-
// Core CSS
@import "@{bootstrap-
@import "@{bootstrap-
@import "@{bootstrap-
...
in the horizon.less I then include this bootstrap.less file.
The names I pick might not resemble exactly to your desired structure, jcoufal will definitely comment on that. Important thing is that we base on overriding the bootstrap components and we strictly keep up with bootstrap.less file organization and naming.
[hayashi]
mvidori, let me ask a question, incidentally. I also tried to divide the horizon. less for my internal project, then I encountered a problem.
I tried to divide horizon.less like this.
horizon.less
|_navi.less
|_main.less
...
But it seems the less compiler watch only horizon.less, so if I change
navi.less or main.less, re-compile doesn't occur unless I change
horizon.less. Did you encounter same issue?
[mvidori]
I use my own dev environment, to develop on less, in order to avoid this kind of trouble ;). It is a normal behaviour, in _stylesheet.html you can see that only horizon.less is watched by the compress tag, if you modify any other file it would not be compiled unless horizon.less is modified.
[hayashi]
Thanks for reply. Oh, it was same as me. This is not convenient and cause confusion for developers who will update less files. They have to update something horizon.less to reflect other files's change.
Are there any way to avoid this issue? When I use Grunt or lessc, this kind of issue doesn't happen, when change the imported file, compile will be occurred.
Gerrit topic: https:/
Addressed by: https:/
Breakdown Stylesheets into Logical Parts
Addressed by: https:/
Use the bootstrap mixins and fix table_cell_action
Addressed by: https:/
Breakdown Stylesheets into Logical Parts
Gerrit topic: https:/
Addressed by: https:/
Refactoring of Horizon navigation
Addressed by: https:/
Add a centralized palette to Horizon
Addressed by: https:/
Split workflows and wizards in dedicated files
Gerrit topic: https:/
Addressed by: https:/
Breakdown CSS: split out the resource browser
Addressed by: https:/
Breakdown forms in a dedicated file
Addressed by: https:/
Breakdown CSS: split out the topologies styles
Addressed by: https:/
Breakdown CSS: pull variables from accordion nav
Addressed by: https:/
Breakdown CSS: pull varaibles from horizon charts
Addressed by: https:/
Lint-based cleanup of 2 scss files
Addressed by: https:/
Breakdown CSS: split styling for table inline edits
Gerrit topic: https:/
Gerrit topic: https:/
Addressed by: https:/
Fix broken network topology css
[david-lyle 2014.08.26] Moving milestone to Kilo
Addressed by: https:/
Restyled topbar to resemble UX guidelines
Gerrit topic: https:/
Addressed by: https:/
Reorganized scss imports
Addressed by: https:/
Move variables from accordion nav to _variables.scss
Addressed by: https:/
WIP - Custom Horizon Theme
Work Items
Dependency tree
* Blueprints in grey have been implemented.
