Fix typos

README.md

@@ -744,13 +744,13 @@ view model =
 
 `Html.Events.onClick ButtonClicked` is also easy to diff. `ButtonClicked` is just a value, so it can be compared, to know if the event listener needs to change.
 
-`Html.Events.onInput GotSearchInput` then? `GotSearchInput` is a _function._ Function cannot be compared in general. But this happens to be the _same function reference_ every time. So we can check for `===` reference equality in JavaScript to know if the event listener needs to change.
+`Html.Events.onInput GotSearchInput` then? `GotSearchInput` is a _function._ Functions cannot be compared in general. But this happens to be the _same function reference_ every time. So we can check for `===` reference equality in JavaScript to know if the event listener needs to change.
 
 `Html.Events.onInput (GotCommentInput i)` is problematic, though. It returns a _new_ function every time due to the partial application. (A lambda function would also be a _new_ function every time.) We simply can’t know when it changes, so the event listener needs to change every time.
 
 (And, on the lowest level, an event handler is just a pair of an event name and a _decoder_ (that results in a message). So when the original elm/virtual-dom compares your event handlers, it actually has to compare _decoders._ elm/json contains a hidden `_Json_equality` only for this reason. My fork does not need that function.)
 
-Then we need to introduce `Html.map` to the mix as well. The original elm/virtual-dom assigns `domNode.elm_event_node_ref = eventNode`, where `eventNode` is an object with a clever system of references, where different layers of `Html.map` can mutate chains of objects that eventually results in that when an event is triggered, all mapping functions can be applied. This system is pretty difficult to grasp, and can only be fully understood for a couple of seconds at a time. It also hides the infamous `Html.map` bug. All in all, this system avoid (at least theoretically), updating event listeners on every render. It also avoid having to recurse into lazy virtual nodes when they haven’t changed.
+Then we need to introduce `Html.map` to the mix as well. The original elm/virtual-dom assigns `domNode.elm_event_node_ref = eventNode`, where `eventNode` is an object with a clever system of references, where different layers of `Html.map` can mutate chains of objects that eventually results in that when an event is triggered, all mapping functions can be applied. This system is pretty difficult to grasp, and can only be fully understood for a couple of seconds at a time. It also hides the infamous `Html.map` bug. All in all, this system avoids (at least theoretically) updating event listeners on every render. It also avoids having to recurse into lazy virtual nodes when they haven’t changed.
 
 My fork takes a much simpler approach. As mentioned in the “New DOM node pairing algorithm” section, my fork needs to recurse into _all_ virtual DOM nodes anyway, even into lazy nodes. And the diffing of event decoders often doesn’t work anyway, due to passing extra data in messages (that feels pretty common). So my fork simply updates all event listeners every render.
 
@@ -865,7 +865,7 @@ I explain those points more in the [properties-vs-attributes.md](https://github.
 
 My fork of elm/browser is a mixed bag of small changes. I intend to make separate pull requests for each thing.
 
-- In my fork of elm/virtual-dom, I made the “virtualize” function complete, making it work i practice. One aspect of virtualization that could _not_ be solved in elm/virtual-dom on its own, was the bug where `<a>` elements didn’t get their click listener attached during virtualization, making them do full page reloads instead of being routed by Elm. This had to be fixed in _both_ the virtual-dom package, _and_ the browser package. This is the change in my fork that is the most related to the virtual-dom changes.
+- In my fork of elm/virtual-dom, I made the “virtualize” function complete, making it work in practice. One aspect of virtualization that could _not_ be solved in elm/virtual-dom on its own, was the bug where `<a>` elements didn’t get their click listener attached during virtualization, making them do full page reloads instead of being routed by Elm. This had to be fixed in _both_ the virtual-dom package, _and_ the browser package. This is the change in my fork that is the most related to the virtual-dom changes.
 
 - elm/browser is in charge of the Elm debugger. The debugger code has a bug where it passes `document` instead of `document.body` to the “virtualize” function, for the debugger window. Previously, that didn’t matter at all and happened to work anyway. With my fork of elm/virtual-dom, that caused the debugger window to be a blank page. I’ve fixed that (adding `.body`), but I also added compatibility for that bug in my virtual-dom fork, so it can be used without my elm/browser fork without breaking the debugger. Basically, I added `if (node === document) { node = document.body; }` as a workaround. So this change isn’t _technically_ needed, but it’s nice fixing problems “in the right place” too.