swagger-api / swagger-api/swagger-ui
Standardize CSS patterns
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 29k
- Forks
- 9.3k
- Avg merge
- 2d 23h
- Merged PRs (30d)
- 25
Description
Swagger-UI's stylesheets are adequate overall, but there are several corners where we have CSS patchwork.
Bringing more consistency, safety, and clarity to this part of the project will bring about the following:
- Contributors will be able to more readily understand how to make changes to the project's styles
- Users will be able to reason about custom styles more easily
- User-written selectors for custom styles will be less likely to break, as naming will be less arbitrary
- End-to-end tests will be easier to comprehend
Current Behavior
My current pain points:
- class names and inheritance are inconsistent
- one-off classes and libraries are used (I've committed this sin, see our use of Tachyons)
- wide-reaching styles cut across concerns in an unpredictable way.
Possible Solution
- Classify stylesheets and existing styles into two types: those that affect global styles (a specific element, a class, anything that cross-cuts component concerns), and those that are bound to a specific component
- Organize stylesheets so that each component has its own file: for example,
Markdownwould have an accompanying_markdown.scssstylesheet - Namespace each component's styles under a standardized class: for example, all the rules in
_markdown.scsswould be contained within.Markdown,.MarkdownComponent, or something similar- Bonus points: contain these styles within a specific component, so that a
pstyle for a parent component wouldn't affectpelements in that component's children
- Bonus points: contain these styles within a specific component, so that a
- Agree on, refactor to, and document a CSS naming methodology
- We use BEM in many places, so that's the path of least resistance.
Context
I wrote this ticket so I could spin my thoughts about #4458 into an actionable item.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the existing CSS and SCSS stylesheets, including the proposed _markdown.scss component stylesheet example. Identify global versus component-bound styles and compare current naming with BEM usage. Done means the stylesheet organization, component namespaces, and naming methodology are agreed, refactored, and documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- css, scss
- Domain
- frontend
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100