Bear with me, this issue looks long because I am trying to be as specific and accurate as possible as we look for the solution. 🌻
This issue comes from our user testing round 1: navigation. When using browser zoom, content within a web page generally needs to reflow so that it fits within the smaller window. For the most part, participants using browser zoom when completing tasks were able to access all content successfully without the browser relying on horizontal scrollbars or some other mediating element. This part is great! Code cells similarly do not rely on horizontal scrollbars, but that's only because they cut off the code cell's content altogether. This prevented participants from completing tasks; this part is the problem.
This seems to be an issue of the code cell containers (the area denoted by the border) being responsive, while the content is not. To be more accurate, the text within the code cell does scale font size following browser zoom (as it should), but the text does not respond to the width of zoomed browser viewport. To summarize:
The good news: code text gets bigger and readable for those who need it.
The bad news: the big code text overflows and cannot be visually accessed where it cuts off.
@isabela-pf note: I am discussing code cells because that is the only case we observed issues with during the test. I suspect this behavior will extend to all cells that are labelled with what seem to be input classes like jp-InputArea and jp-Cell-inputAreathat have Jupyter-specific rendering classes rather than the jp-RenderedHTMLCommon, jp-RenderedMarkdown, and jp-MarkdownOutputclasses that I believe follow non-Jupyter-specific specifications like CommonMark. Or maybe it's the data-type designation of inline instead of text/markdown. I haven't investigated this yet, but I wanted to point it out because it's possible that this will either be an issue we run into again or that our fixes may impact other areas of the rendered notebook we don't anticipate.
A code cell at 200% browser zoom (Firefox)
A code cell at 400% browser zoom (Firefox)
A code cell at 100% browser zoom, but 326 pixel viewport (Firefox)
For context, WCAG reflow guidelines (same link as above) say we need to account for 400% zoom/320 CSS pixels without using horizontal scrollbars. Chrome and Firefox browsers currently support up to 500% zoom (writing from personal experience here, I'm looking for the changelog on this).
Possible solutions
At the root, the solution is to have all content properly reflow so it appears on-screen. In an ideal (and WCAG-compliant) world, the solution will not use horizontal scrollbars.
In terms of implementation, I think several design and code questions remain. I'm going to let this discussion happen below to save this already long issue.
I know that reflowing lines of code can have unique challenges of its own since character count and line numbers are meaningful information. I do not know if there is any code formatting happening at some point of the notebook conversion or rendering, so that may be worth checking as well. This could be part of the problem and solution. @tonyfast has talked to me about this on different projects with related problems.
Acceptance criteria
This issue can be closed when we
Merge a PR that fixes code cells to reflow without hiding content to the desired upstream repo
Tasks to complete
[ ] Investigate the code source of the proper and failing reflow in cells throughout the rendered notebook
[ ] Do competitive analysis of code reflow behaviors in other code-centric interfaces (this probably will include other Jupyter references and beyond)
[ ] Propose proof-of-concept visual designs and critique when we have better knowledge of the technical constraints, iterate as needed
[ ] Reach agreement about what fix we want to pursue and where those changes need to be made
Problem and context
Bear with me, this issue looks long because I am trying to be as specific and accurate as possible as we look for the solution. 🌻
This issue comes from our user testing round 1: navigation. When using browser zoom, content within a web page generally needs to reflow so that it fits within the smaller window. For the most part, participants using browser zoom when completing tasks were able to access all content successfully without the browser relying on horizontal scrollbars or some other mediating element. This part is great! Code cells similarly do not rely on horizontal scrollbars, but that's only because they cut off the code cell's content altogether. This prevented participants from completing tasks; this part is the problem.
This seems to be an issue of the code cell containers (the area denoted by the border) being responsive, while the content is not. To be more accurate, the text within the code cell does scale font size following browser zoom (as it should), but the text does not respond to the width of zoomed browser viewport. To summarize:
@isabela-pf note: I am discussing code cells because that is the only case we observed issues with during the test. I suspect this behavior will extend to all cells that are labelled with what seem to be input classes like
jp-InputAreaandjp-Cell-inputAreathat have Jupyter-specific rendering classes rather than thejp-RenderedHTMLCommon,jp-RenderedMarkdown, andjp-MarkdownOutputclasses that I believe follow non-Jupyter-specific specifications like CommonMark. Or maybe it's thedata-typedesignation ofinlineinstead oftext/markdown. I haven't investigated this yet, but I wanted to point it out because it's possible that this will either be an issue we run into again or that our fixes may impact other areas of the rendered notebook we don't anticipate.A code cell at 200% browser zoom (Firefox)
A code cell at 400% browser zoom (Firefox)
A code cell at 100% browser zoom, but 326 pixel viewport (Firefox)
For context, WCAG reflow guidelines (same link as above) say we need to account for 400% zoom/320 CSS pixels without using horizontal scrollbars. Chrome and Firefox browsers currently support up to 500% zoom (writing from personal experience here, I'm looking for the changelog on this).
Possible solutions
At the root, the solution is to have all content properly reflow so it appears on-screen. In an ideal (and WCAG-compliant) world, the solution will not use horizontal scrollbars.
In terms of implementation, I think several design and code questions remain. I'm going to let this discussion happen below to save this already long issue.
I know that reflowing lines of code can have unique challenges of its own since character count and line numbers are meaningful information. I do not know if there is any code formatting happening at some point of the notebook conversion or rendering, so that may be worth checking as well. This could be part of the problem and solution. @tonyfast has talked to me about this on different projects with related problems.
Acceptance criteria
This issue can be closed when we
Tasks to complete