-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Documentation unreadable in Chrome #15648
Comments
cc @Arhell |
@cefn The only thing I found is a very long title I use chrome to |
Can you send me a screenshot of the MeshConfig and ProxyConfig tables, then? Here are screenshots. The fact this table is too wide for the viewport makes this reference documentation unusable in my opinion (for my browser config). Take the ProxyConfig table. There is a whole invisible 'Requirements' column and no control to get to it. https://istio.io/latest/docs/reference/config/istio.mesh.v1alpha1/#ProxyConfig |
That's right, that's how it should work, there is a scroll bar for the table at the bottom, you should understand that everything depends on the content. |
If you are interested, I checked the same content at https://getbootstrap.com/docs/5.3/content/tables/#always-responsive in their tables, and there is a similar solution with scrolling. |
@cefn Thanks for the report. I'm not sure we can do much more without a fundamental change to how we present this data (e.g. not having a TOC on the right). I know we've had to do this to stop line breaking as arhell pointed out above. Do you see the scrollbar at the bottom of the table? |
CSS allows the designer to determine the width and sharing strategy for different 'cells'. Here, the However, minimum width of the content section is already an optional design conceit and must have corresponding decisions about information layout or shouldn't be adopted. At the very least it could be fixed for wider screens by either introducing a wide-screen breakpoint or setting the default desktop breakpoint higher (1200 is reasonable these days) or ensuring that minwidth for the desktop breakpoint is determined by percentage not pixels. Then at least the typical display devices for software professionals can consume the information. If you want to see how absurd the minwidth design conceit is, given the consequences for the core purpose of this page, consider this screenshot on my main monitor. Claiming there is no way for the text to fit horizontally in the screen is false. For this use case, the designer needs to reconsider the minwidth behaviour, which settles to approximately 900 pixels on my 3440 pixel viewport.
Not in any real-world scenario, such as the ProxyConfig. Looking at any particular row (in the original view where you can see the name of it) you can then scroll several screen-heights to see the horizontal scrollbar, then scroll it horizontally, and when you scroll back vertically you can see the description, but no identifier, making it impossible to use as per the very first screenshot in this thread. I genuinely struggle to understand how this is considered to be usable or a good idea, maybe it's different in my browser or something but have you tried to read a As per my original report, fixing it for my viewport involves setting a single CSS property so I disagree with the claim ' I'm not sure we can do much more without a fundamental change to how we present this data'. The question is simply whether the individual involved in making the CSS design decisions is willing to reconsider their choices and identify a solution in the face of user experience testing. |
the individual involved in making the CSS design decisions
As with so many open source projects, we don't really have one of those.
The site was created about eight years ago, and reskinned about four years
ago. None of the people involved are still around.
We have a couple of occasional volunteers, including Arhell, who will tweak
styles, but we don't have any regular contributor who knows CSS at the
level you are talking at.
That said, I am an individual with the ability to accept changes. If you're
able to submit one, or give enough guidance to someone else that they can
make one, i will very happily shepherd it through!
|
Thanks for the offer and it's of course a very reasonable position for an open source project to take. I am the user population's worst nightmare when it comes to styling and formatting (I have no aesthetic sense whatever as my colleagues would attest). For now I have found a workaround, since if I make my viewport SMALLER than 1200 pixels the table seems to get the expected treatment (although the |
I assume that resizing to that width removed the page table of contents on the right? |
Is this the right place to submit this?
Bug Description
The layout of tabular data within e.g. https://istio.io/latest/docs/reference/config/istio.mesh.v1alpha1/#ProxyConfig prevents reading it. The fixed width is narrower than the contained table even on a very wide screen. Zooming in and out delivers no benefit since it consistently zooms all scaling, including both the fixed width and the font size.
A workaround on my Chrome was to open the inspector and edit the style for
.docs.container
to be2000px
Version
Additional Information
No response
The text was updated successfully, but these errors were encountered: