Zoom in breaks list item

[cluelessjoe]

What MDC-Web Version are you using?

I'm using material-components-web version "0.19.0" and @material/list version 0.2.17

What browser(s) is this bug affecting?

Firefox 55.0.3 64 bits for Arch Linux
Your user agent: Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Other HTTP headers
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
COOKIE: ah=fr-fr
UPGRADE-INSECURE-REQUESTS: 1

What OS are you using?

Arch Linux (uname -a : 4.12.8-2-ARCH #1 SMP PREEMPT Fri Aug 18 14:08:02 UTC 2017 x86_64 GNU/Linux)

What are the steps to reproduce the bug?

• Go at the page for list on the Material Components Catalog https://material-components-web.appspot.com/list.html
• Use a small resolution (768x1024)
• Zoom in
  In my case I had a long text in the list item and it behaved the same.

What is the expected behavior?

The height of the list item should increase

What is the actual behavior?

The various lines are overlapping.

Any other information you believe would be useful?

I'm no css/design expert, may be that's a correct behavior, but I find it poor with accessibility reasons (zooming in makes the content unreadable)

[Garbee]

We should probably hide overflow to fix this. As the container shouldn't increase with font size according to the MD team.

[cluelessjoe]

Thanks for the reply :)

I'm a bit surprised though: usually we zoom in because we have a hard time reading. Hiding part of the text is the exact opposite...

[Garbee]

I made the argument to handle everything dynamically. Material Design team disagreed. Here we are. Hiding is the best acceptable solution that aligns to the team's wishes.

[cluelessjoe]

Don't they care about accessibility? Why this position? :(

[Garbee]

It's not that they don't care. It's that changing the font size doesn't mean you want all the components of the page to resize as well. Font size affects font-related things. Not the size of blocks themselves.

[cluelessjoe]

Playing the devil's advocate, you're good at that ;) Strange choice still, contrary to the aim of zooming IMHO. Is it a commonplace choice regarding accessibility to discard content in favor of shapes when zooming in? I never heard/read such thinking (being not an expert though...).

Anyway, I'll try to change the behavior on my side and be done with it. A pity since it casts quite some shadows on the others decisions (are there some other surprising ones?)...

Issue closed on my side, feel free to close when you feel like it.

Thanks for your instructive answers and MDC web!

[lynnmercier]

Adding overflow:hidden is the best short term fix.

@cluelessjoe, if you'd like to submit a PR to fix this, use the mdc-typography-overflow-ellipsis mixin from mdc-theme package.

I made the argument to handle everything dynamically.

To @Garbee point, I've opened up some discussions with our design team around when we are suppose to truncate text, and when we are suppose to dynamically change font size or container size. Obviously handling cases dynamically is trickier, so we need time to prototype different options and review them with our designers. But perhaps we can address some of the usability concerns with future version of MDC Web.

[cluelessjoe]

@lynnjepsen PR done, thanks for the indication
Regarding how to handle zoom in, IMHO it feels logical for the content to be still visible, otherwise it kills the purpose of zooming in the first place (one doesn't zoom to have less text).

[cluelessjoe]

BTW, it came back to me that I spotted this issue first not by zooming but by having long text in the list items. The long text would then be blurred as when zooming.

Maybe long text makes a better case for handling better this issue, because then it's not due to some "rare" user interaction, but can happen anytime provided the length of the text displayed exceeds the available room for it. In case of dynamic content it can happen pretty randomly/frequently.

[Garbee]

My original recommendation, way back before MCW code was even officially started, was to rem most of the px values. This allowed the containers to respectfully resize with the size of the textual content for legibility. While this does introduce some challenges, in most cases it works just fine. As I recall before, the designers decided "Changing the font size doesn't mean you want everything around it to change as well." Or something to that effect.

An example of this can be seen in my original v2 button demo. This has an input you can modify the markup's font size with to see the resizing live.

[cluelessjoe]

BTW, the Web Content Accessibility Guidelines (WCAG) 2.0, which is the legal standard regarding accessibility in the USA states :

1.4.4 Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA)

and in the 1.4.8 Visual Presentation section (level AAA)

Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.

Regarding em/rem, there is 'C14: Using em units for font sizes' technique note which is described like this:

The objective of this technique is to specify text font size in em units so that user agents can scale content effectively. Since the em is a property of the font, it scales as the font changes size. If a font-size is specified for the body element, all other elements inherit that value, unless overridden by a more specific selector.

and is checked this way:

Check that the value of the CSS property that defines the font size is expressed in em units. 

So it actually looks like em are required for level WCAG 2.0 of level AA. So, while not being a lawyer, this looks mandatory in the USA and is mandatory for sure in France when willing to do accessible websites (which is now required by law and enforced at least for state related websites, like the ones for hospitals, cities and administration). Pretty serious stuff in the end IMHO.

[Garbee]

@cluelessjoe C14 doesn't say em's are required for everything. It does however say to make sure font sizes are responsive, which is what is provided.

The zooming up to 200% losslessly is achievable with other methods than simply using rem/em on everything. We need guidance from the MD team here on how this needs to be proceeded with. This is definitely some valuable information to get provided to them though. It helps show the legal regulations around designing for this aspect of user experiences which is an important thing for quite a few industries.