swagger-api / swagger-api/swagger-ui

Standardize CSS patterns

Open
#4,460 3 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

cat: customization cat: style & presentation type: enhancement
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, Markdown would have an accompanying _markdown.scss stylesheet
  • Namespace each component's styles under a standardized class: for example, all the rules in _markdown.scss would be contained within .Markdown, .MarkdownComponent, or something similar
    • Bonus points: contain these styles within a specific component, so that a p style for a parent component wouldn't affect p elements in that component's children
  • 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.