Fix typo on line 273, change move to moved.

src/documents/abbreviations/syntax/index.html.md

@@ -270,7 +270,7 @@ In second example the `<b>` element is placed _inside_ `<a>` element. And that
 
 	<p>Click <a href="">here</a> to continue</p>
 
-In this example, to write `Click here to continue` inside `<p>` element we have explicitly move down the tree with `>` operator after `p`, but in case of `a` element we don’t have to, since we need `<a>` element with `here` word only, without changing parent context.
+In this example, to write `Click here to continue` inside `<p>` element we have explicitly moved down the tree with `>` operator after `p`, but in case of `a` element we don’t have to, since we need `<a>` element with `here` word only, without changing parent context.
 
 For comparison, here’s the same abbreviation written without child `>` operator:
 
@@ -317,4 +317,4 @@ run: emmet.expand_abbreviation
 This is why Emmet needs some indicators (like spaces) where it should stop parsing to not expand anything that you don’t need. If you’re still thinking that such formatting is required for complex abbreviations to make them more readable:
 
 * Abbreviations are not a template language, they don’t have to be “readable”, they have to be “quickly expandable and removable”.
-* You don’t really need to write complex abbreviations. Stop thinking that “typing” is the slowest process in web-development. You’ll quickly find out that constructing a single complex abbreviation is much slower and error-prone than constructing and typing a few short ones.
+* You don’t really need to write complex abbreviations. Stop thinking that “typing” is the slowest process in web-development. You’ll quickly find out that constructing a single complex abbreviation is much slower and error-prone than constructing and typing a few short ones.