diff options
author | 2021-08-12 20:24:06 +0200 | |
---|---|---|
committer | 2021-08-12 13:24:06 -0500 | |
commit | cbae535cad6790b60affc5391d3cab194701ee65 (patch) | |
tree | 9576a0c1bd390acbf7ef161e34b99160df8b02d5 /docs/src/pages/guides | |
parent | fbbb589d921cae62f42694c3081ebf8378d24a80 (diff) | |
download | astro-cbae535cad6790b60affc5391d3cab194701ee65.tar.gz astro-cbae535cad6790b60affc5391d3cab194701ee65.tar.zst astro-cbae535cad6790b60affc5391d3cab194701ee65.zip |
Fix typos in the docs/ content (#1093)
Co-authored-by: mundry <mundry@users.noreply.github.com>
Diffstat (limited to 'docs/src/pages/guides')
-rw-r--r-- | docs/src/pages/guides/deploy.md | 6 | ||||
-rw-r--r-- | docs/src/pages/guides/rss.md | 2 | ||||
-rw-r--r-- | docs/src/pages/guides/styling.md | 4 |
3 files changed, 6 insertions, 6 deletions
diff --git a/docs/src/pages/guides/deploy.md b/docs/src/pages/guides/deploy.md index de1161945..de8aa69b6 100644 --- a/docs/src/pages/guides/deploy.md +++ b/docs/src/pages/guides/deploy.md @@ -68,15 +68,15 @@ By default, the build output will be placed at `dist/`. You may deploy this `dis ### GitHub Actions -1. In the astro project repo, create `gh-pages` branch then go to Settings > Pages and set to `gh-pages` branch for Github Pages and set directory to `/` (root). +1. In the astro project repo, create `gh-pages` branch then go to Settings > Pages and set to `gh-pages` branch for GitHub Pages and set directory to `/` (root). 2. Set the correct `buildOptions.site` in `astro.config.mjs`. 3. Create the file `.github/workflows/main.yml` and add in the yaml below. Make sure to edit in your own details. -4. In Github go to Settings > Developer settings > Personal Access tokens. Generate a new token with repo permissions. +4. In GitHub go to Settings > Developer settings > Personal Access tokens. Generate a new token with repo permissions. 5. In the astro project repo (not \<YOUR USERNAME\>.github.io) go to Settings > Secrets and add your new personal access token with the name `API_TOKEN_GITHUB`. 6. When you push changes to the astro project repo CI will deploy them to \<YOUR USERNAME\>.github.io for you. ```yaml -# Workflow to build and deploy to your Github Pages repo. +# Workflow to build and deploy to your GitHub Pages repo. # Edit your project details here. # Remember to add API_TOKEN_GITHUB in repo Settings > Secrets as well! diff --git a/docs/src/pages/guides/rss.md b/docs/src/pages/guides/rss.md index d4ac14d5f..3c98db661 100644 --- a/docs/src/pages/guides/rss.md +++ b/docs/src/pages/guides/rss.md @@ -5,7 +5,7 @@ title: RSS Astro supports fast, automatic RSS feed generation for blogs and other content websites. -You can create an RSS feed from any Astro page that uses a `getStaticPaths()` function for routing. Only dynamic routes can use `getStaticPaths()` today (see [Routing](/core-concepts/routing). +You can create an RSS feed from any Astro page that uses a `getStaticPaths()` function for routing. Only dynamic routes can use `getStaticPaths()` today (see [Routing](/core-concepts/routing)). > We hope to make this feature available to all other pages before v1.0. As a workaround, you can convert a static route to a dynamic route that only generates a single page. See [Routing](/core-concepts/routing) for more information about dynamic routes. diff --git a/docs/src/pages/guides/styling.md b/docs/src/pages/guides/styling.md index ed1ebc1f6..bdeb3a22f 100644 --- a/docs/src/pages/guides/styling.md +++ b/docs/src/pages/guides/styling.md @@ -272,7 +272,7 @@ import Button from './Button.astro'; </nav> ``` -This is undesirable because now `<Nav>` and `<Button>` fight over what the final button looks like. Now, whenever you edit one, you'll always have to edit the other, and they are no longer truly isolated as they once were (now coupled by a bidirectional styling dependency). It's easy to see how this pattern only has to repeated a couple times before being afraid that touching any styles _anywhere_ may break styling in a completely different part of the app (queue `peter-griffin-css-blinds.gif`). +This is undesirable because now `<Nav>` and `<Button>` fight over what the final button looks like. Now, whenever you edit one, you'll always have to edit the other, and they are no longer truly isolated as they once were (now coupled by a bidirectional styling dependency). It's easy to see how this pattern only has to be repeated a couple times before being afraid that touching any styles _anywhere_ may break styling in a completely different part of the app (queue `peter-griffin-css-blinds.gif`). Instead, let `<Button>` control its own styles, and try a prop: @@ -303,7 +303,7 @@ Elsewhere, you can use `<Button theme="nav">` to set the type of button it is. T Recently there has been a debate of all-scoped component styles vs utility-only CSS. But we agree with people like Sarah Dayan who ask [why can't we have both][utility-css]? Truth is that while having scoped component styles are great, there are still hundreds of times when the website's coming together when two components just don't line up _quite_ right, and one needs a nudge. Or different text treatment is needed in one component instance. -While the thought of having perfect, pristine components is nice, it's unrealistic. No design system is absoutely perfect, and every design system has inconsistencies. And it's in reconciling these inconsistencies where components can become a mess without utility CSS. Utility CSS is great for adding minor tweaks necessary to get the website out the door. But they also are incomplete on their own—if you've ever tried to manage responsive styles or accessible focus states with utility CSS it can quickly become a mess! **Utility CSS works best in partnership with component (scoped) CSS**. And in order to be as easy as possible to use, Utility CSS should be global (arguably should be your only global CSS, besides maybe reset.css) so you don't have to deal with imports all willy-nilly. +While the thought of having perfect, pristine components is nice, it's unrealistic. No design system is absolutely perfect, and every design system has inconsistencies. And it's in reconciling these inconsistencies where components can become a mess without utility CSS. Utility CSS is great for adding minor tweaks necessary to get the website out the door. But they also are incomplete on their own—if you've ever tried to manage responsive styles or accessible focus states with utility CSS it can quickly become a mess! **Utility CSS works best in partnership with component (scoped) CSS**. And in order to be as easy as possible to use, Utility CSS should be global (arguably should be your only global CSS, besides maybe reset.css) so you don't have to deal with imports all willy-nilly. Some great problems best handled with Utility CSS are: |