Skip to content
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

[Gatsby Docs Update] Sidebar + article layout updates #10735

Merged

Conversation

joecritch
Copy link
Contributor

@joecritch joecritch commented Sep 18, 2017

This supersedes #10707

what are the changes?:

  • Adds media queries and JS to make sidebar collapse/expand from a
    sticky bottom bar on small screen sizes
  • tweaks to colour contrast (checked using aXe) and some html attributes
  • centralised article layout for large desktops
  • created a carousel-like overflow for the marketing columns on mobile.
  • moved 'Edit this page' to the bottom, as part of the new centralised layout.
  • offset note and code blocks out of the grid, so there text lines up. (this was previously an issue with CodeMirror, but i think we're good now?)

why make these changes?

  • improved accessibility score
  • improved readability on large desktop
  • improved use of screen space on mobile

test plan

  • manual testing

**what is the change?:**
- Adds media queries and JS to make sidebar collapse/expand from a
  sticky bottom bar on small screen sizes
- Many TODOs still open! This is just an initial version.

**why make this change?:**
Moving closer to Joe's fantastic design. :)

**test plan:**
Manual testing - Flarnie will insert a gif

**issue:**
Various items under the `Sidebar Component` on this checklist;
https://github.com/bvaughn/react/wiki/Gatsby-check-list
**what is the change?:**
We skim the items in the 'defaultActiveSection' to find the currently
active one, and display it's title in the sticky responsive bottom
navbar.

Before I had just plugged in the section title as a placeholder.

**why make this change?:**
It's better this way. One step closer to Joe's shiny new design. :)

**test plan:**
Manually tested (Flarnie will insert a screenshot)

**issue:**
Sidebar items on this checklist;
https://github.com/bvaughn/react/wiki/Gatsby-check-list
@reactjs-bot
Copy link

reactjs-bot commented Sep 18, 2017

Deploy preview ready!

Built with commit 4f1839e

https://deploy-preview-10735--reactjs.netlify.com

@joecritch joecritch force-pushed the gatsbyDocsUpdateTypographyAndArticleLayout branch 2 times, most recently from 5729ebb to 28f8881 Compare September 18, 2017 14:28
Copy link
Contributor

@bvaughn bvaughn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI's failing b'c of formatting issues. 😄

Mind running yarn prettier-all (in the root of the project) to fix them up?

@joecritch joecritch force-pushed the gatsbyDocsUpdateTypographyAndArticleLayout branch from 28f8881 to 4f1839e Compare September 18, 2017 15:22
@joecritch joecritch force-pushed the gatsbyDocsUpdateTypographyAndArticleLayout branch from 4f1839e to 63d9f83 Compare September 19, 2017 12:34
@joecritch joecritch changed the title [Gatsby Docs Update] Typography and article layout tweaks [Gatsby Docs Update] Sidebar + article layout updates Sep 19, 2017
@joecritch joecritch force-pushed the gatsbyDocsUpdateTypographyAndArticleLayout branch 2 times, most recently from 16eeca3 to 0472658 Compare September 19, 2017 14:37
@joecritch joecritch force-pushed the gatsbyDocsUpdateTypographyAndArticleLayout branch from 0472658 to 89c8d69 Compare September 19, 2017 14:38
maxWidth: isFooter ? 800 : 1260,
paddingLeft: isFooter ? 0 : 20,
paddingRight: isFooter ? 0 : 20,
},
Copy link
Contributor

@bvaughn bvaughn Sep 19, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe rather than passing in isFooter we could support additional custom CSS? (Since only one instance of Container would have the footer CSS).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good shout, feels nicer to compose. Changed :)

@@ -55,7 +55,7 @@ const Header = ({location}) => (
width: 'calc(100% / 6)',
}}
to="/">
<img src={logoSvg} alt="React" height="20" />
<img src={logoSvg} alt="" height="20" />
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why'd the "alt" get removed? Accident?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

aXe was picking it up that it was a duplicate of the title; which is apparently an anti-pattern. Empty alt tags are used for presentational img tags, so I think we're good 👍

Copy link
Contributor

@bvaughn bvaughn Sep 19, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

aXe was picking it up that it was a duplicate of the title; which is apparently an anti-pattern

I have never heard this. Interesting. So it's best to explicitly specify an empty alt attribute vs none at all in this case?

Upon further consideration, I think images used as links should have alt text describing the destination of the link, not the image itself. So maybe this one should say something like, "React home page"? Oh, I see what you're saying now.

width: 1,
margin: -1,
padding: 0,
border: 0,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not display: none ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Due to the lack of alt attribute (see the other comment), we still want the site title to be read if the crawler is using mobile

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha. This is gross. 😛 But I think your logic is reasonable. The grossness is just browser stuff. 😁

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I might look into changing the markup slightly after this is merged to avoid this if you don't oppose it.

[media.between('large', 'xlargeSmaller')]: {
paddingRight: 280,
},
[media.between('xlargeSmaller', 'belowSidebarFixed')]: {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I care for the newly-added media constants. The API was kind of built to make sense with sizes but the new strings are kind of more arbitrary. This query particular is pretty confusing. 😁 What does it mean to be between xlargerSmaller and belowSidebarFixed?

www/src/theme.js Outdated
xlargeSmaller: {min: 1100, max: 1339},
belowSidebarFixed: {min: 740, max: 1559}, // Used for "between()"
sidebarFixed: {min: 1560, max: Infinity},
sidebarFixedNarrowFooter: {min: 1560, max: 2000},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think these constants make sense, (paricularly xlargeSmaller 😁 ), with the way the sizes were designed. If we need these new sizes, then I think we should pick a few hard-coded media query values rather than try to make them work within the media methods.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See my latest commit. I've not removed them entirely, as I think it's good to have all width constraints in one central place, but I've made it more obvious about what they're actually doing. And was able to remove belowSidebarFixed due to the new "excludeLarge" on the between function 👍

render() {
const {defaultActiveSection, location} = this.props;
console.log('the defaultActiveSection is ;', defaultActiveSection);
console.log('this.props are ', this.props);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These probably weren't intended to be left in ^

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed :)

@@ -140,8 +131,9 @@ const CreateLink = (location, section, item) => {
} else {
return (
<Link
css={[linkCss, isItemActive(location, item) && activeLinkCss]}
css={[linkCss, isActive && activeLinkCss]}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isActive change is good 👍 Thanks

www/src/theme.js Outdated
@@ -24,33 +24,30 @@ const colors = {
darker: '#20232a', // really dark blue
brand: '#61dafb', // electric blue
brandLight: '#bbeffd',
brandOnWhite: '#10819b',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit brandDark ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this was actually an artefact, so now removed :)

www/src/theme.js Outdated
text: '#1a1a1a', // very dark grey / black substitute
subtle: '#777', // light grey for text
subtle: '#6d6d6d', // light grey for text
subtleOnDark: '#999',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: subtleDark ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think subtleOnDark is nicely verbose in this instance, showing it's for use on dark backgrounds. Would you agree?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure that's okay 😄 Feel free to ignore "nit" comments

www/src/theme.js Outdated
between(smallKey: Size, largeKey: Size) {
if (SIZES[largeKey].max === Infinity) {
between(smallKey: Size, largeKey: Size, excludeLarge: Boolean = false) {
if (SIZES[largeKey].max === Infinity && !excludeLarge) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this conditional correct? Or did you mean to have an || instead of an &&?

Calling between(small, large, true) would create a media query with max-width even if the max size was Infinity. When would we want that?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it was logically correct, but it wasn't nice to read. excludeLarge is an exception because you're not concerned about the max property. So I've refactored it — 5e4dda9

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still confused. Isn't a max-width of Infinity the same as no max-width at all?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah... I see now that you're using ${SIZES[largeKey].min} below. Hm.

@bvaughn bvaughn merged commit bd0f28d into facebook:gatsby Sep 19, 2017
@bvaughn
Copy link
Contributor

bvaughn commented Sep 19, 2017

Let's follow-up on the other PR comments later. Merging for now to help get the Netlify build working. 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants