From d6b9f74f2e27fdf21313b01a3c87b2000dbccc85 Mon Sep 17 00:00:00 2001
From: Peter Roche <46547072+paroche@users.noreply.github.com>
Date: Thu, 7 Nov 2019 21:54:53 -0700
Subject: [PATCH] Update article.md

"starts to bug..." -> "becomes buggy..."

I am not aware of "bug" being used as a verb in IT, but if it is, this is the first time I recall seeing it, so I would say it's probably not common.

Anyway, using it as a verb kind of bugged me a little.
---
 2-ui/1-document/09-size-and-scroll/article.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/2-ui/1-document/09-size-and-scroll/article.md b/2-ui/1-document/09-size-and-scroll/article.md
index 8b293e19..102f9c58 100644
--- a/2-ui/1-document/09-size-and-scroll/article.md
+++ b/2-ui/1-document/09-size-and-scroll/article.md
@@ -245,7 +245,7 @@ Why should we use geometry properties instead? There are two reasons:
 
     From the CSS standpoint, `width:auto` is perfectly normal, but in JavaScript we need an exact size in `px` that we can use in calculations. So here CSS width is useless.
 
-And there's one more reason: a scrollbar. Sometimes the code that works fine without a scrollbar starts to bug with it, because a scrollbar takes the space from the content in some browsers. So the real width available for the content is *less* than CSS width. And `clientWidth/clientHeight` take that into account.
+And there's one more reason: a scrollbar. Sometimes the code that works fine without a scrollbar becomes buggy with it, because a scrollbar takes the space from the content in some browsers. So the real width available for the content is *less* than CSS width. And `clientWidth/clientHeight` take that into account.
 
 ...But with `getComputedStyle(elem).width` the situation is different. Some browsers (e.g. Chrome) return the real inner width, minus the scrollbar, and some of them (e.g. Firefox) -- CSS width (ignore the scrollbar). Such cross-browser differences is the reason not to use `getComputedStyle`, but rather rely on geometry properties.