swagger-api / swagger-api/swagger-ui

Compensate Operation content in lower resolution sizes

Open
#8,940 9 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

cat: a11y cat: browser specific cat: style & presentation cat: user experience Good first issue type: enhancement
Dominant language
JavaScript
Stars
29k
Forks
9.3k
Avg merge
2d 23h
Merged PRs (30d)
25

Description

This can be reproduced both in SwaggerEditor (v4) and Swagger Editor (v5). The preview that is located in the right-hand side (where SwaggerUI displays) is fully collapsible without any limits. The components tries to compensate, but after some threshold they will stop making visual sense.

This is not really specific to SwaggerUI. If we take for example React Material Design components, these reference components will too collapse until they stop making sense.

What we can do is to use Material Design Specification and say that our minimal supported break-point is 360dp/px. We will make CSS changes and make sure that Operations and other visual components renders properly on that break-point. Second remediation can be setting the minimum width of the preview pane in the editors (but not sure this is warranted).

Under threshold of 360dp/px what is displayed is no longer guaranteed.

Work on this can be done progressively, layering changes on top of previous changes:

  • Amend CSS of expand level 0
  • Amend CSS of expand level 1
    ….. repeat to level n ….

Currently SwaggerUI has some notion of minimal supported break-point and some components tries to compensate.

image

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

Reproduce the collapse behavior in the Swagger Editor preview using the linked SwaggerEditor v4 and Swagger Editor v5 examples, then inspect the SwaggerUI preview components and their existing responsive CSS. Apply the responsive changes progressively from expand level 0 through deeper levels, and consider the 360dp/px breakpoint the issue proposes as the point where Operations and related components should remain visually usable.

Written by the indexing model from the issue text.

Assessment

Tech stack
css, javascript
Domain
frontend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.