Clarify in tutorial that can load global CSS by importing css file

[KyleAMathews]

Also add "CSS FAQ" that covers

• global css
• what is css-in-js and what are some options w/ Gatsby
• ordering issues — how to control e.g. move css/headComponents props around
• CSS modules (naming scheme)
• what else?

[benforshey]

This might be a bit out of scope for this issue, but I'd love to help others understand their choices with typography in CSS. The docs present two ways to customize typography: Webpack file loading and Typography.js.

But I find myself most often just using your Typefaces project—it works really well! It's way more performant than the @font-face declaration, and it doesn't come with the weight of Typography.js. I'd love to put that option in the docs somewhere.

[kildareflare]

@benforshey Thanks for the heads up. I also self hosted mys sites fonts, but did so through this site.
https://google-webfonts-helper.herokuapp.com/fonts
I like the idea of using npm to handle this though :0)

[dustinhorton]

@benforshey

But I find myself most often just using your Typefaces project—it works really well! It's way more performant than the @font-face declaration

It's an awesome project, but it's not "more performant than the @font-face declaration—it leverages it, as all modern webfont tech does : ]

I could do a PR with an example site using Typefaces, but it's implementation in Gatsby isn't anything special: just import a font into your layout file, and then use it in your CSS.

As a sidenote, I couldn't figure out how to implement Typefaces within Storybook within Gatsby, but I haven't spent much time on it either.

[dustinhorton]

@kildareflare Which font are you using from Google Fonts? Chances are, you can already use it via NPM via Typefaces. The list of current supported fonts are @ https://github.com/KyleAMathews/typefaces/tree/master/packages

[kildareflare]

@dustinhorton Yup it is supported, thanks. I only did not use npm as did not realise it was an option. I'll be updating soon.

[benforshey]

It's an awesome project, but it's not "more performant than the @font-face declaration—it leverages it, as all modern webfont tech does : ]

Hmm, I'm puzzled. I personally found using Typefaces over my globally-imported @font-face declarations to drop about 150k off my page weight, with no other changes. I also scored much higher on PageSpeed Insights for prioritizing above-the-fold content.

[benforshey]

So, it's not that I think using Typefaces is magic, but I figured that it was more performant because of code-splitting and bundling...all that good Webpack / Gatsby stuff that happens out of the box. But, admittedly, I'm still learning.

[jquense]

For v1 we should also cover the default postcss plugins included, like cssnext, import, etc

[KyleAMathews]

@benforshey curious why you say typography.js is heavy?

Also are you comparing a non-gatsby project to a gatsby one? Curious how a simple change would lead to 150kb diff. Which is huge for css. Perhaps your other method was pulling in extra stuff.

One nice thing about Gatsby + typefaces is the font-face declarations are inlined which means the browser starts downloading the font files all that much earlier.

[benforshey]

Oh, well, maybe heavy isn’t the right choice of words? I think Typography.js includes modernizer and default styles that I end up overwriting. I usually only use a CSS reset and some basic responsive typography rules. I remember running a PageSpeed Insights test using Typography.js and getting dinged for having a blocking CSS resource.

No, it’s a Gatsby to Gatsby comparison. I’m really curious about my 150k, too, because it seems like my experience is pretty abnormal. Maybe it had something to do with the only Latin glyphs being used in Typefaces fonts (at least I think I saw that in the docs...)? I was including 6-or-so font files in the font-face declarations, with Woff, Woff2, etc.

[benforshey]

By the way, I don’t mean to derail the issue or cause a huge dustup over what I experienced. Maybe I screwed something up in my testing. I’ve screwed up simpler things. :-)

I’m just trying to say that I’d be happy to help write (or at least be glad to see) Typfaces in the docs.

Also, thanks so very much for your work on this stuff—I’m quite literally using it to earn a living. Your work + the community’s contribution is an invaluable resource to me.

[KyleAMathews]

@benforshey coooool! That's what we're all working for!

[benforshey]

@KyleAMathews @dustinhorton If it's helpful to anything, I just reproduced the page size increase that I was talking about. Without @font-face in global CSS and using Typefaces, page size is 642KB. With @font-face declarations in global CSS and without Typefaces, page size is 900KB.

I have a my master branch (Typefaces) and a branch preview (@font-face) set up with Netlify for testing. Maybe there's something else I'm doing that's causing this to happen, but the only difference between the code is the addition of the @font-face and the deletion of the require() statements. Page size was measured by GTMetrix on both branches.

Please let me know if there's anything I can do to help with this. I'd love to chip in somehow.

[dustinhorton]

@benforshey If you want to toss it in a public repo with a branch with & branch without Typefaces, I'd could take a look and try to debug.

[rdela]

Hi all I would be happy to take a crack at updating the tutorial and/or adding any new examples.

I import a css file in https://github.com/gatsbyjs/gatsby/tree/master/examples/using-redirects and could pull that out into a wider css example with other uses or separate them into distinct css examples or update existing ones. I am going to try to commit another example using all the netlify redirection options soon as well, using-redirects-netlify maybe?

So no biggie to add a couple more examples or tweak tutorial in the same pass.

[benforshey]

@dustinhorton Thanks! I just made a new gatsby-starter-default and put it into a public repo.

The master branch is set up with font-face declarations and locally-served font-files (woff2 & woff). The typefaces branch is set up with no font-face declarations and the typefaces installed through npm. A quick gatsby build showed a 1MB difference between the public folders.

[rdela]

@benforshey the difference is because your are measuring public font files end up in node_modules in typefaces branch because they are installed through npm. Look in node_modules/[typeface-russo-one,typeface-source-sans-pro] post-build. Unlike master, where those directories will not be there because they end up in public like you wrote.

[rdela]

@benforshey oh nevermind I see what you meant they do get moved to static on build in both cases

[rdela]

@benforshey That said, here are my results building both branches, only 8.909 kB difference in public sizes, not 1MB.

5,555,886 bytes // typefaces = 5,555,886 bytes
5,564,795 bytes // master = 5,564,795 bytes
5,564,795 bytes - 5,555,886 bytes = 8,909 bytes
8,909 bytes to KB = 8.909 kB
8.909 kB to MB = 0.008909 MB

[rdela]

@benforshey Also only the master branch served the fonts correctly once built and serving locally, the typefaces branch never displayed the headline font Russo for sure, hard to tell on Source Sans because I have it installed locallly. Did not try to debug any further so not sure why.

[benforshey]

Also only the master branch served the fonts correctly once built and serving locally, the typefaces branch never displayed the headline font Russo for sure

@rdela Ah, sorry about that. I forgot the require() statements in the layouts file, but never noticed because I did have the font files installed locally on my system. I pushed the fix to the typefaces branch.

Once I fixed that, I couldn't get gatsby serve to display the fonts on the typefaces branch because of CORS (this may just be my problem): Access to Font at 'http://0.0.0.0:8000/static/russo-one-latin-400.93e70648.woff2' from origin 'http://localhost:8000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8000' is therefore not allowed access.

I ran gatsby build, and served the files from that directory (using serve) to verify that they were displaying correctly. I even deleted my local font files just to be sure. It worked as expected.

That said, here are my results building both branches, only 8.909 kB difference in public sizes, not 1MB.

I suspect that is just because I didn't actually require the files. Once I fixed that, my file sizes between branches were still relatively significant. Here are my processes and results:

master

$du -h public
8.0K    public/page-2 
944K    public/static 
8.0K    public/404 
5.4M    public 

typefaces

$du -h public
8.0K    public/page-2
452K    public/static
8.0K    public/404
4.9M    public/

So the difference in the two static folders, which in my tests only contain the font files, is 492K. So, I don't know why, or if I'm doing something wrong...but that's what I've got.

[rdela]

@benforshey CORS problem related to #2960 I think, thanks for updating branch, when we get CORS 0.0.0.0/localhost issue resolved I will update my clone and we can resume font-face testing and trying to figure out why you are seeing such a big discrepancy. I will du -h as well to make sure we are using same steps.

[monsieurnebo]

I'm self-hosting fonts and getting the same error as @benforshey when testing my project on the local network.

gatsby develop -p 8080 is working fine.

gatsby develop -p 8080 --host 0.0.0.0 is making gatsby available on the local network, but fires the following errors:

index.js:2369 Uncaught Error: The error you provided does not contain a stack trace.
    at parseError (index.js:2369)
    at getStackFrames (index.js:2262)
    at crashWithFrames (index.js:1926)
    at index.js:1944
    at rejectionHandler (index.js:2040)

192.168.1.126/:1 Uncaught (in promise) DOMException: Only secure origins are allowed (see: https://goo.gl/Y0ZkNV).

Access to Font at 'http://0.0.0.0:8080/static/Roboto-Regular.5d4aeb4e.woff2' from origin 'http://192.168.1.126:8080' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://192.168.1.126:8080' is therefore not allowed access.

@rdela My packages are up-to-date. Is there any fix for this?

[KyleAMathews]

@monsieurnebo upgrade to the latest. @m-allanson wrote a PR to fix your problem in #3299

[monsieurnebo]

@KyleAMathews I just tested gatsby develop -p 8080 --host 0.0.0.0 with this PR, and I still encounter the same CORS issue :/

[rdela]

@monsieurnebo You should not need 0.0.0.0 non-routable meta-address anymore. localhost works for single machine dev, for local network testing, have you tried:
gatsby develop -p 8080 --host 192.168.1.126 (using your error message from earlier)
…where 192.168.1.126 is your actual local IP?

gatsby develop -p 8080 --host [machineName].local
is the better option now I think for local network testing

-H is short for --host and both of these work for me and site is available at either address whether I run
gatsby develop -H [myLocalIP] -p 8080
or
gatsby develop -H [machineName].local -p 8080

more background: #2960 (comment) & later comments and references on that issue.
In an offshoot of that issue, some people fixed their issues specifying localhost like gatsby develop --host localhost but I am under the impression this is no longer necessary and equivalent to gatsby develop. If this does fix your issue you probably should update gatsby and/or gatsby-cli. See #2983 (comment) & later comments and references on that PR, and #2983 (comment)

[rdela]

Wait there seems to be an incompatibility between current gatsby-cli and previous versions of Gatsby, found a site where I cannot get local network testing up. Investigating and will update here.

updated above and below

[rdela]

Got this working without updating Gatsby. Think firewall or router was blocking something that made local network testing impossible.

Only error I have is Only secure origins are allowed one covered in linked issues, present in both [myLocalIP] and [machineName].local versions, but not localhost, which makes sense given the Chrome docs linked in other issues.

[rdela]

127.0.0.1 also immune from Only secure origins are allowed error…

[rdela]

#2983 (comment)

On the Chrome errors, expanded shortlink:
Chromium‎ > ‎Chromium Security‎ > ‎Prefer Secure Origins For Powerful New Features

“Secure origins” are origins that match at least one of the following (scheme, host, port) patterns: 
(https, *, *)
(wss, *, *)
(*, localhost, *)
(*, 127/8, *)
(*, ::1/128, *)
(file, *, —)
(chrome-extension, *, —) 
This list may be incomplete, and may need to be changed. Please discuss! 

A bug to define “secure transport” in Blink/Chromium: https://code.google.com/p/chromium/issues/detail?id=362214

For example, Chrome is going to make Service Workers available only to secure origins, because it provides the origin with a new, higher degree of control over a user's interactions with the origin over an extended period of time, and because it gives the origin some control over the user's device as a background task.

Consider the damage that could occur if a user downloaded a service worker script that had been tampered with because they got it over a MITM’d or spoofed cafe wifi connection. What should have been a nice offline document editor could be turned into a long-lived spambot, or maybe even a surveillance bot. If the script can only run when delivered via authenticated, integrity-protected transport like HTTPS, that particular risk is significantly mitigated.

…and indeed setting gatsby develop --host localhost and using http://localhost:8000 makes the errors go away, as does gatsby develop --host 127.0.0.1 and using http://127.0.0.1:8000/

[m-allanson]

#1975 should provide a fix for the Only secure origins issue. Using https means you could set any hostname and have Chrome still treat it as secure.

[rdela]

Nice thanks @m-allanson @pwener let me know if I can help out

[monsieurnebo]

I updated to the latest and tested to use my real IP address as the following:

gatsby develop -p 8080 --host 192.168.3.222

It fixes the CORS errors, but not these two:

Uncaught Error: The error you provided does not contain a stack trace.
    at parseError (index.js:2369)
    at getStackFrames (index.js:2262)
    at crashWithFrames (index.js:1926)
    at index.js:1944
    at rejectionHandler (index.js:2040)
parseError @ index.js:2369
getStackFrames @ index.js:2262
crashWithFrames @ index.js:1926
(anonymous) @ index.js:1944
rejectionHandler @ index.js:2040

192.168.3.222/:1 Uncaught (in promise) DOMException: Only secure origins are allowed (see: https://goo.gl/Y0ZkNV).

That only shows up when accessing to the project from something else than localhost.

---

Either way, we're using a npm command to start the local server, and we cannot hardcode the IP address so ... so I'm still trying to enable a 0.0.0.0 access.

[madeleineostoja]

👍 for documenting global CSS as a first-class citizen. I'm coming to Gatsby from a web components background and am all-in on CSS variables for global styles rather than typography.js style approaches, using CSS modules / styled components just for encapsulating component styles, as a replacement for shadow dom.

Re: typography - I'd also echo including more standards-based approaches to performant type in docs, rather than leading with typography.js. Maybe even brief mentions of stuff like the font loading API / font-display:swap and subsetting.

[KyleAMathews]

Due to the high volume of issues, we're closing out older ones without recent activity. Please open a new issue if you need help!