jeena/en.javascript.info
1
0
Fork 0
Code Issues Pull requests Projects Packages Wiki Activity Actions

Update article.md

Browse source 
"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.
This commit is contained in:
Peter Roche 2019-11-07 21:54:53 -07:00 • committed by GitHub
parent b071f46c60
commit d6b9f74f2e
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

2
2-ui/1-document/09-size-and-scroll/article.md
View file

@ -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.