Css grid Boilerplate - progressive enhancement for browsers that don't support grid

[chaotic-stump]

• I have read Chapter's contributing guidelines.
• My pull request has a descriptive title (not a vague title like Update README.md).
• My pull request targets the master branch of Chapter.

Related to #144

I added a @supports not tag so browsers that don't have CSSgrid will still render the mobile view (which will be built out first anyway). This allows for support of the ~%8 of browsers that don't use grid without much adjustment at all.

This is a rough draft so I'm pretty open to suggestions. The mockups aren't out yet so I tried to follow the patterns I have seen in discussion.

[ThomasRoest]

I would recommend following the example from the official repo for creating a layout component: https://github.com/zeit/next.js/tree/canary/examples/layout-component

also, I don't think we need a sidebar right now? Just add it later when needed

[chaotic-stump]

Thanks for the recommendation, I haven't used Nuxt before, (or styled-components for that matter) so it's a lot of new territory for me. I figured something like Layout would happen once a router was added. I left the sidebar for illustrative purposes to quickly check grid support. I figure any of it can be taken out if not needed.

If that time is now, let me know and I'll take the sidebar out.

[ThomasRoest]

you should remove this one because it conflicts with the imported layout

[ThomasRoest]

this needs a type, try something like this

interface IProps {
  children: React.ReactNode;
}

const Layout = ({ children }: IProps) => {
  return (
    <Site>
      <Header />
      <Sidebar />
      {children}
      <Footer />
    </Site>
  );
};

export default Layout;

[nik-john]

@SeanRParker Could you point me to where we committed to using CSS Grid at all? From what I understand, we have material UI and its built in CssBaseline provides Browser reset CSS. And material UI uses flexbox under the hood. Therefore, if I understand correctly, we wouldn't need to use @support not for CSS Grid (maybe for FlexBox though).

PS: I don't see where we agreed to use Material UI either, but looks like that ship has sailed. So we'd better get overboard. If you could port the components you have created to Material UI, I can merge them in

[GeniaT]

@nik-john

I don't see where we agreed to use Material UI either, but looks like that ship has sailed.

It wasn't agreed specifically on Material UI but See Quincy's comment

[vaibhavsingh97]

@nik-john @GeniaT This PR: #154, is merged 2 days ago, it happened very quickly.

I don't see where we agreed to use Material UI either, but looks like that ship has sailed

Yes, we haven't concluded to use any particular framework, but @vkWeb should have wait before merge, and wait for community to approve but looks like by @QuincyLarson comment he concluded that we will use Material UI as it was used in earlier projects. Still, if you guys have another opinion on UI framework, we can revert that PR and can raise PR which whole community agrees.

[vkWeb]

Yes, we haven't concluded to use any particular framework, but @vkWeb should have wait before merge, and wait for community to approve but looks like by @QuincyLarson comment he concluded that we will use Material UI as it was used in earlier projects. Still, if you guys have another opinion on UI framework, we can revert that PR and can raise PR which whole community agrees.

@vaibhavsingh97 I'm sorry for the quick merge. Next time, I'll definitely wait for more approvals. 😞

Actually Quincy's comment made me think that we can go with material UI so I merged it as is. And I think it's fine too. I am open to ideas for any other framework but I would personally recommend that we start working on MVP features rather than getting too much involved in the libs discussion.

[chaotic-stump]

If it isn't much additional work, I am in favor of supporting more browsers. But only if it isn't much more work.
For the sake of expediency, I am now recommending we just focus on Chrome, Firefox, and Safari for our MVP. This will cover 80% of desktop and mobile users.

Based on Quincy's remarks in #144 I figured this was a natural direction to go for the highest level of support with minimal lift.

@nik-john Sorry for confusion on my end, this is the first I've really submitted to open source projects and I thought Pull Requests were recommendations that maintainers could then choose to merge in or not.

I haven't really worked with Material-UI, but does CssBaseline add grid support to minor browsers? At first glance, it looks like a reset and not a progressive enhancement for browsers that can't do CSSgrid.

With this approach we can use CSSgrid (for larger layouts) and Flexbox (laying out content with those layouts) in tandem. This direction allows for using baked in CSS while not leaving anyone behind, since we're going mobile first anyway.

Also, if we're going with Material UI, I'd recommend cutting out the middle man and clean up the codebase by only importing parts we need (like buttons, inputs etc) and not any layout modules.

*edit: with this approach it doesn't matter which UI library we use, so long as we can tree shake it.

[chaotic-stump]

@nik-john I just realized what you meant by the framework grid being built in flexbox.

There’s pros and cons to either approach with a fairly similar result.

[nik-john]

@SeanRParker

I haven't really worked with Material-UI, but does CssBaseline add grid support to minor browsers? At first glance, it looks like a reset and not a progressive enhancement for browsers that can't do CSSgrid.

You're right - CssBaseline is merely a reset. My point is that we don't need to provide Grid support because we won't be using it (at the moment, at least). Material UI provides a grid system out of the box using FlexBox and therefore we won't need to use Grid (considering grid still has no support on Opera like you've noted). So, adding a polyfill will only mean unused code.

@nik-john Sorry for confusion on my end, this is the first I've really submitted to open source projects and I thought Pull Requests were recommendations that maintainers could then choose to merge in or not.

Thank you for your contribution - I see that you've been very active in the community - I hope that you'll provide a lot more in the coming days.

At the moment, this looks like something we won't need, so I'm closing the PR. But when the time comes, please feel free to reopen it

[chaotic-stump]

Sounds good