Details
Checked <p> tags and made sure that they look as they did before removing the html font-size clamp
Diff Detail
- Repository
- rCOMM Comm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Question
| landing/global.css | ||
|---|---|---|
| 41 ↗ | (On Diff #10400) | It seems like the equation has changed from 0.75rem + 1vw previously, yeah? How was it determined? |
| landing/global.css | ||
|---|---|---|
| 41 ↗ | (On Diff #10400) | Looks like it's half of this line: https://phabricator.ashoat.com/D3434#inline-20247 (Should that diff be connected with this stack in any way?) |
| landing/global.css | ||
|---|---|---|
| 41 ↗ | (On Diff #10399) |  We should make the relative size 1rem. So when a user bumps up, or down their font size it changes enough to make a difference. relative-size Browser default root font size is 16px. This value can be changed by users in their browser settings, usually for accessibility purposes. Positive or negative "rem" values should be included to avoid locking font size to px value and to support user font size preferences. from the about page. |
| landing/global.css | ||
|---|---|---|
| 41 ↗ | (On Diff #10399) |
Not sure I understand? What's the change you're suggesting? I basically read through this: https://css-tricks.com/linearly-scale-font-size-with-css-clamp-based-on-the-viewport/, and it made sense, so I'm trusting it. |
Spoke with Ben, determined that what we have is fine to land but there's still possibly room for improvement. I'll spend some time this weekend properly reading up on all these relative CSS units and their interactions with accessibility settings and whatnot and make any necessary changes.
| landing/global.css | ||
|---|---|---|
| 41 ↗ | (On Diff #10399) | I don't feel that strongly about it. But, in the referenced post the author talks about this exact shortcoming of his approach. I also don't think many of our users are bumping their text and that this matters so much right now. But, could be worth going back to and taking a closer look. |
(Should that diff be connected with this stack in any way?)
They aren't really "dependent" on each other (they could all be landed in whatever order), but I guess I could have flagged that they were part of the same body of work and should have included a link to the webpage with the math for each one.
My previous understanding was that we should use "depends on" when a diff doesn't stand alone (eg one diff introduces a function and another diff uses the function... basically where in the past people would do [1/n] diffs)... but I guess we just want every single diff to link to its parent so the "stack" view shows every step from master to the current diff? It seems a little tedious, but I'll do that going forward.
Yeah, in my opinion it's less about documenting the actual dependencies, and more about laying a path for your reviewer to help them review things in the right order, and so they have somewhere to check if they see something they don't expect, or see something they think might've been addressed in a follow-up.