Relative Layout (em) by jpdevries · Pull Request #3 · Thinkful-Ed/analog-sea

jpdevries · 2016-11-12T12:03:19Z

This is just an example, that demonstrates a pattern of using both em and px units to make for a more relative and responsive layout. It is not necessarily meant to be merged.

Modern browsers support page zooming with pixel units but that isn't the only way a web page can be zoomed. Increasing the font-size using relative units such as em is a universal way to make a page more legible. Aside from browser zoom, this can be done by web components, browser plugins, or user sheets with the following CSS:

html {
  font-size: 200%; /* analogous to font-size: 2em; */
}

The Issue

If px units are used they will not scale along with relative font-size unit of parent elements. In other words, they won't abide to the cascading nature of CSS. This can cause text to flow outside the container and even be hidden.

Screencast (GIF)

The solution

Use relative units in areas the layout should scale. In some cases, use a combination of px and em. For example:

  .signup-form {
    max-width: 10em;
    min-width: 400px; /* make sure it is always at least 400px */
  }

This ensures that the component width scales with the type size while maintaining a minimum of our 400px desired width at 100% zoom.

Use px units in areas you do not want the layout to scale. In this example, px units are used for the padding of the text inputs.

Screencast (GIF)

To test yourself change the font-size on the <HTML> element.

olexpono · 2016-11-12T15:14:47Z

Lots of issues in this approach, "magic" numbers in em, two mobile-esque layouts to keep in mind, inconsistent looks depending on if you zoomed with text size, or zoom. I don't think we should advocate going halfway, you could just set a font size in PX on body and prevent the awkward label zooming when text size is zoomed.

olexpono · 2016-11-12T15:14:47Z

Lots of issues in this approach, "magic" numbers in em, two mobile-esque layouts to keep in mind, inconsistent looks depending on if you zoomed with text size, or zoom. I don't think we should advocate going halfway, you could just set a font size in PX on body and prevent the awkward label zooming when text size is zoomed.

jpdevries · 2016-11-12T15:18:34Z

Well, I think Responsive Design isn't about making sure everything looks "pixel-perfect" it is more about accounting the many variables of the web. If a user sheet increases the font-size the layout should respond to that, not break.

I'm not advocating anything with this PR though. Just pointing at that as is, the labels get blown up because they aren't set declaratively with px. If we are going to stick with px we should consider setting that on the html or body to prevent that from happening.

jpdevries · 2017-04-06T22:42:10Z

@tholex thought you might be interested in WCAG 2.1 1.4.11 which adds a new success criteria for sites to remain accessible without horizontal scrolling when scaled to 400%. 2.1 is still a DRAFT but, as it extends 2.0, it is safe to assume this does not mean only supporting "browser zooming" or default font sizes in browsers but also includes supporting standard user agent sheets and browser plugins which override CSS styles with something like:

html { /* in a user sheet or a11y plugin */
  font-size:400% !important;
}

This success criteria can only be met when using relative units to size type. This is because WCAG 2.0 1.4.4 states users must be able to scale using the user agent, not just "browser zoom" which, by the way, is an action users have to initially perform on each web site they visit.

This means media queries are also best to use relative units, and not pixels, as layout needs to scale without horizontal scroll.

Yes modern browsers "zoom pixels" even though this was not the intent. So many developers misused the units that vendors had to make a breaking change and go against the intent of the CSS spec. And it actually made things worst because there is now no way to declaratively set font sizes anymore. In other words, think about text as illustration or texture, you can't say with absolute certainty "I want this type to be exactly 20px regardless of zoom level" which was the original intent of the specification. We've lost art direction capabilities by forcing modern browsers to reinterpret units.

Further more not all browsers default 1em to 16px (but of course the vast majority do). So you cannot universally assume px units will translate as expected.

Pixels make it easier for developers to think in pixels when authoring the web. Relative units make it easier for people, particular those with accessibility needs, to use and access the web.

Looking forward, do we want to teach in accordance with Web Content Accessibility Guidelines? Do we want to teach students to make things easier on themselves, or their users? And if they have to decide between the two, which is the responsible choice as a (world wide) web professional?

The author's responsibility is to create Web content that does not prevent the user agent from scaling the content effectively. — WCAG 2.0 1.4.4

I'm not trying to get Thinkful to take a stance one way or another on this. I do wonder if we should expose students one way or another to considerations and differences between the two approaches.

Since this is such a endlessly debated issue (outside of the WCAG/a11y community at least) I was thinking we could add a Resources section that links to a couple articles that are for relative units and the same number that are against and use it as an example to tell students there are multiple opinions on practices, and as they progress throughout their journey they'll be solidifying their own.

Note: WCAG 2.1 1.4.11 builds on WCAG 2.0 1.4.4 which requires a 200% zoom level for success criteria.

Sufficient techniques

The user agent may satisfy provision one of this checkpoint through a number of mechanisms, including zoom, magnification, and allowing the user to configure a reference size for rendered text (e.g., render text at 36 points unless otherwise specified). For example, for CSS2 [CSS2] user agents, the medium value of the font-size property corresponds to a reference size.

jpdevries · 2017-04-07T23:01:11Z

@tholex I had a chance to discuss this with WCAG authors at CSUN 2017 and confirmed that the success criteria requires more than just the browser zoom. Browser zoom is an action that has to be performed every time you visit a new site. As I learned from low vision users at CSUN 2017, this is a tedious process which is why user agent sheets, which have been part of web standards since CSS 1, are part of the success criteria under the "user agent" umbrella.

Your bolded statement contradicts your links & ignores the VAST majority of user agents

No it doesn't.

Deque University is a leading source on these research topics. Please see:
https://dequeuniversity.com/guide/archive/fireeyes/hc/index-issues/issue-details?i=030401-C&v=5.0

olexpono · 2017-04-07T23:12:59Z

Two things about that link in particular show that it is an outdated view. That issue is about <font> elements, and the page states:

This user guide refers to an older version of FireEyes. For more current information refer to the current FireEyes User Guide.

Basically this page is saying "this used to be an issue." Now, I understand that browser zoom is not supported everywhere, but it's looking like the de-facto way to fix this going forward. All the modern browsers support zooming px values.

This statement is not necessarily true:

Browser zoom is an action that has to be performed every time you visit a new site.

E.g. chrome has no problem setting a default zoom on new pages... and remembers the user setting across domains as you probably know.

jpdevries · 2017-04-07T23:36:25Z

Two things about that link in particular show that it is an outdated view. That issue is about elements, and the page states:

Deque University and WCAG spoke to this at CSUN17 last month. They say relative units 👍 declarative units 👎 even in 2017 and onward.

and remembers the user setting across domains as you probably know.

Certainly that is convenient. User sheets can span across separate browsers and allow significantly more control over how they consume content on the web.

This isn't about taking my word for it. Perhaps we'd benefit from speaking to a daily low vision user about this topic. I could arrange that if you'd like.

jpdevries · 2017-04-07T23:53:00Z

I'm glad you bring up the Chrome settings. There is also a setting to change the font size. This setting will not be respected on type set in px.

if a user sets a preference there (Extra Large for example) it won’t have any effect on text content specified with pixels

Notice the labels are the only thing that scale when I change my browser preference. This is because they default to relative units, like every browser does and always will. (For the most part, with the exception of browser chrome, browser defaults for type are relative.)

So can we at least agree on this? If you are going to set some type in px you should set all type in px. Otherwise it will have unexpected affects on the user.

It would be ridiculous to set all type in pixels and override every browser default. Which brings us back to sticking with relative units and going with, not against the grain, of browser default and AG.

Of course there is an exception here. If you don't want the type to scale, px is appropriate.

This is an example of a user story that fails with font-size set in px:

As a web user, I should be able to update my Font Size preferences in Chrome and have my preference reflected across all type one would expect to scale on the page.

olexpono · 2017-04-10T20:00:39Z

JP, you've argued with me over and over about these two settings for a year and a half, of course I know the font-size setting...

I don't mind the label/p explicit px, I think that any reasonable styleguide would set label and p tags in either px or rem.

It would be ridiculous to set all type in pixels and override every browser default. Which brings us back to sticking with relative units and going with, not against the grain, of browser default and AG.

Not what you mean by this... there are maybe only a dozen browser defaults regarding font sizes, and reset.css already resets them to 1em/100%. Setting them all to px / rem is less than 40 lines of CSS. I agree that consistency in supporting AND not supporting the font-size setting is important for people that use it, since it's probably hard to change that on a per-page basis.

On the whole, I'd be very happy to talk with a low-vision desktop user, I find it highly unlikely that they would use a non-default font-size setting all over the web. Either they use zoom or some other method (OS zoom) to comfortably browse small content. Approving #5 and closing this.

jpdevries · 2017-04-10T22:54:31Z

Setting them all to px / rem is less than 40 lines of CSS.

Sounds like a lot of code just to stop the user agent from doing what it was designed to do – give the user granular control over how they access the web.

I find it highly unlikely that they would use a non-default font-size setting all over the web.

Again, I recently attended the largest accessibility conference in the world, with over 5,000 attendees, and spoke to several low vision users about this 🤦‍♂️

Either they use zoom or some other method (OS zoom) to comfortably browse small content.

Are you speaking on their behalf or is this an assumption of yours?

I spoke with Rob Dodson of the Chrome team about this. He said:

I'm going to bug the team to see if we have stats data on how many folks use that browser zooming option for mobile chrome
the argument I recently read against it is based on the assumption that most folks would tell the OS to zoom
but I'd love to have some actual data

Note: When Rob refers to OS settings that is still considered the user agent

So hopefully they can provide some analytics. I think if you reach out to the community you'll find that users expect user agent font size settings to be respected. That's historically why those settings exists and why browsers default to relative units for content.

jpdevries · 2017-04-11T00:05:04Z

I mentioned perhaps we should instruct students to read a few opposing articles on units. This one makes some excellent points:
https://nicolas-hoizey.com/2016/03/people-don-t-change-the-default-16px-font-size-in-their-browser.html#fn:everyone

the default font size is not always displayed at 16px. On Opera Mini it is 13px. Kindle 26px.
the founding principles of the world wide web expect inclusiveness and going with the grain of the user agent, not against it
(as I mentioned) bad developer habits have caused browsers to change behavior for the worst

Responsive Design isn't just about viewport width. It is also about responding to the user agent settings such as font size as well.

The user needs to be able to resize the text to 200% of its size anywhere on the page, without the text being cut off or overlapping other text. The font size should be defined in relative units, such as percentages, em or rem.

https://www.w3.org/WAI/tutorials/page-structure/styling/

jpdevries · 2017-04-14T08:20:30Z

I reached out to the working group for clarification and was directed to this explanation of success criteria for 1.4.4. Hoping this clears things up for us.
https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html

The intent of this Success Criterion is to ensure that visually rendered text, including text-based controls can be scaled successfully so that it can be read directly by people with mild visual disabilities, without requiring the use of assistive technology such as a screen magnifier. Users may benefit from scaling all content on the Web page, but text is most critical.

Browser zoom is effectively a screen magnifier (although it only magnifies the viewport).

The scaling of content is primarily a user agent responsibility. User agents that satisfy UAAG 1.0 Checkpoint 4.1 allow users to configure text scale. The author's responsibility is to create Web content that does not prevent the user agent from scaling the content effectively. Authors may satisfy this Success Criterion by verifying that content does not interfere with user agent support for resizing text, including text-based controls, or by providing direct support for resizing text

Declarative units still interfere with the support for resizing text regardless of the fact that modern browsers scale px when zooming now.

Germany has the most strict accessibility laws I'm aware of. I've confirmed with an accessibility expert there that relative units should be used to satisfy 1.4.4.

Regarding @tholex assumption:

Either they use zoom or some other method (OS zoom) to comfortably browse small content

Horizontal scrolling and panning (think mobile) is not a comfortable browsing or reading experience. Just try it yourself or reference this study.

Comments

Conversation

jpdevries commented Nov 12, 2016

The Issue

The solution

Uh oh!

olexpono commented Nov 12, 2016

Uh oh!

olexpono commented Nov 12, 2016

Uh oh!

jpdevries commented Nov 12, 2016

Uh oh!

jpdevries commented Apr 6, 2017

See Also

Uh oh!

olexpono commented Apr 7, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Sufficient techniques

Uh oh!

jpdevries commented Apr 7, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

olexpono commented Apr 7, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jpdevries commented Apr 7, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jpdevries commented Apr 7, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

olexpono commented Apr 10, 2017

Uh oh!

jpdevries commented Apr 10, 2017

Uh oh!

jpdevries commented Apr 11, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jpdevries commented Apr 14, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

See Also

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

olexpono commented Apr 7, 2017 •

edited

Loading

jpdevries commented Apr 7, 2017 •

edited

Loading

olexpono commented Apr 7, 2017 •

edited

Loading

jpdevries commented Apr 7, 2017 •

edited

Loading

jpdevries commented Apr 7, 2017 •

edited

Loading

jpdevries commented Apr 11, 2017 •

edited

Loading

jpdevries commented Apr 14, 2017 •

edited

Loading