Copyediting/proofreading (#128)

Author: arihant2math

src/architecture/canvas.md

@@ -53,10 +53,10 @@ flowchart TB
 
 As part of the HTML event loop, the script thread runs a task (parsing, script evaluating, callbacks, events, ...) and after that it [performs a microtask checkpoint](https://html.spec.whatwg.org/multipage/#perform-a-microtask-checkpoint) that drains the microtasks queue.
 In the [window event loop](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model:window-event-loop-3) we queue a global task to [update the rendering](https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering) if there is a [rendering opportunity](https://html.spec.whatwg.org/multipage/webappapis.html#rendering-opportunity) (usually driven by compositor based on hardware refresh rate).
-In Servo we do not actually queue a task, but instead we [run `update the rendering` after any IPC messages in the ScriptThread](https://github.com/servo/servo/blob/d970584332a3761009f672f975bfffa917513b85/components/script/script_thread.rs#L1418) and then [perform a microtask checkpoint too](https://github.com/servo/servo/blob/d970584332a3761009f672f975bfffa917513b85/components/script/script_thread.rs#L1371) as the event loop would have done after a task is completed.
+In Servo, we do not actually queue a task, but instead we [run `update the rendering` after any IPC messages in the ScriptThread](https://github.com/servo/servo/blob/d970584332a3761009f672f975bfffa917513b85/components/script/script_thread.rs#L1418) and then [perform a microtask checkpoint too](https://github.com/servo/servo/blob/d970584332a3761009f672f975bfffa917513b85/components/script/script_thread.rs#L1371) as the event loop would have done after a task is completed.
 [Update the rendering](https://github.com/servo/servo/blob/d970584332a3761009f672f975bfffa917513b85/components/script/script_thread.rs#L1201) does various resize, scroll and animations steps (which also includes performing a microtask checkpoint to resolve outstanding promises) and then [run the animation frame callbacks](https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#run-the-animation-frame-callbacks) (callbacks added with [`requestAnimationFrame`](https://developer.mozilla.org/en-US/docs/Web/API/Window/requestAnimationFrame)).
 At this point draw commands are issued to painters to create a new frame of animation.
-Finally we trigger reflow (layout), which first updates the rendering of canvases (by flushing dirty canvases) and animated images, then traverses the DOM and its styles, builds a `DisplayList`, and sends that to WebRender for rendering.
+Finally, we trigger reflow (layout), which first updates the rendering of canvases (by flushing dirty canvases) and animated images, then traverses the DOM and its styles, builds a `DisplayList`, and sends that to WebRender for rendering.
 
 When canvas context creation is requested (`canvas.getContext('2d')`), the script thread blocks on the painter thread as it initializes and creates a new WebRender image (`CreateImage`), finally sending the associated `ImageKey` back to script.
 

src/architecture/concurrency-and-parallelism.md

@@ -34,15 +34,15 @@ Here are some ways that we take advantage of both:
   Decoding multiple images in parallel is straightforward.
 * _Decoding of other resources_.
   This is probably less important than image decoding, but anything that needs to be loaded by a page can be done in parallel, e.g. parsing entire style sheets or decoding videos.
-* _GC JS concurrent with layout_ - Under most any design with concurrent JS and layout, JS is going to be waiting to query layout sometimes, perhaps often.
+* _GC JS concurrent with layout_ - Under almost any design with concurrent JS and layout, JS is going to be waiting to query layout sometimes, perhaps often.
   This will be the most opportune time to run the GC.
 
 For information on the design of WebXR see the [in-tree documentation](./webxr.md).
 
 ## Challenges
 
 * _Parallel-hostile libraries_.
-  Some third-party libraries we need don't play well in multi-threaded environments.
+  Some third-party libraries we need don't play well in multithreaded environments.
   Fonts in particular have been difficult.
   Even if libraries are technically thread-safe, often thread safety is achieved through a library-wide mutex lock, harming our opportunities for parallelism.
 * _Too many threads_.

src/architecture/further-reading.md

@@ -4,13 +4,13 @@
 
 ## References
 
-Important research and accumulated knowledge about browser implementation, parallel layout, etc:
+Important research and accumulated knowledge about browser implementation, parallel layout, etc.:
 
 * [How Browsers Work](http://ehsan.github.io/how-browsers-work/#1) - basic explanation of the common design of modern web browsers by long-time Gecko engineer Ehsan Akhgari
 * [More how browsers work](http://taligarsiel.com/Projects/howbrowserswork1.htm) article that is dated, but has many more details
 * [Webkit overview](https://web.archive.org/web/20150804185551/https://www.webkit.org/coding/technical-articles.html)
 * [Fast and parallel web page layout (2010)](https://lmeyerov.github.io/projects/pbrowser/pubfiles/paper.pdf) - Leo Meyerovich's influential parallel selectors, layout, and fonts.
-  It advocates seperating parallel selectors from parallel cascade to improve memory usage.
+  It advocates separating parallel selectors from parallel cascade to improve memory usage.
   See also the [2013 paper for automating layout](https://lmeyerov.github.io/projects/pbrowser/pubfiles/synthesizer2012.pdf) and the [2009 paper that touches on speculative lexing/parsing](http://lmeyerov.github.io/projects/pbrowser/hotpar09/paper.pdf).
 * [Servo layout on mozilla wiki](https://wiki.mozilla.org/Servo/StyleUpdateOnDOMChange)
 * [Robert O'Callahan's mega-presentation](http://robert.ocallahan.org/2012/04/korea.html) - Lots of information about browsers

src/architecture/microtasks.md

@@ -3,8 +3,8 @@
 # Microtasks
 
 According the HTML spec, a microtask is: "a colloquial way of referring to a task that was created via the queue a microtask algorithm"([source](https://html.spec.whatwg.org/multipage/#microtask-queue)).
-Each [event-loop](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop)--meaning window, worker, or worklet--has it's own microtask queue.
-The tasks queued on it are run as part of the [perform a microtask checkpoint](https://html.spec.whatwg.org/multipage/#perform-a-microtask-checkpoint) algorithm, which is called into from various places, the main one being [after running a task](https://html.spec.whatwg.org/multipage/#event-loop-processing-model:perform-a-microtask-checkpoint) from an task queue that isn't the microtask queue, and each call to this algorithm drains the microtask queue--running all tasks that have been enqueued up to that point([without re-entrancy](https://html.spec.whatwg.org/multipage/#performing-a-microtask-checkpoint)).
+Each [event-loop](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop)--meaning window, worker, or worklet--has its own microtask queue.
+The tasks queued on it are run as part of the [perform a microtask checkpoint](https://html.spec.whatwg.org/multipage/#perform-a-microtask-checkpoint) algorithm, which is called into from various places, the main one being [after running a task](https://html.spec.whatwg.org/multipage/#event-loop-processing-model:perform-a-microtask-checkpoint) from a task queue that isn't the microtask queue, and each call to this algorithm drains the microtask queue--running all tasks that have been enqueued up to that point([without re-entrancy](https://html.spec.whatwg.org/multipage/#performing-a-microtask-checkpoint)).
 
 ## The microtask queue in Servo
 
@@ -18,7 +18,7 @@ Dedicated workers [use a child runtime](https://github.com/servo/servo/blob/4357
 A task can be enqueued on the microtask queue from both Rust, and from the JS engine.
 
 - From JS: the JS engine will call into [`enqueue_promise_job`](https://github.com/servo/servo/blob/7eac599aa1d6bcf8858c51d90763373f0dd5f289/components/script/script_runtime.rs#L196) whenever it needs to queue a microtask to call into promise handlers.
-  This callback mechanism is setup [once per runtime](https://github.com/servo/servo/blob/7eac599aa1d6bcf8858c51d90763373f0dd5f289/components/script/script_runtime.rs#L520).
+  This callback mechanism is set up [once per runtime](https://github.com/servo/servo/blob/7eac599aa1d6bcf8858c51d90763373f0dd5f289/components/script/script_runtime.rs#L520).
   This means that resolving a promise, either [from Rust](https://github.com/servo/servo/blob/7eac599aa1d6bcf8858c51d90763373f0dd5f289/components/script/dom/promise.rs#L173) or from JS, will result in this callback being called into, and a microtask being enqueued.
   Strictly speaking, the microtask is [still enqueued from Rust](https://github.com/servo/servo/blob/7eac599aa1d6bcf8858c51d90763373f0dd5f289/components/script/script_runtime.rs#L222).
 - From Rust, there are various places from which microtask are explicitly enqueued by "native" Rust:

src/architecture/web_api.md

@@ -21,13 +21,13 @@
    - Add an appropriate member to the struct(s) added at 4.
    - If this requires defining other structs or enums, these should derive `JSTraceable` and `MallocSizeOf`([example](https://github.com/servo/servo/pull/34844/commits/7d73370b0c41a1b00f4b25b7e1b8bf9b67430708#diff-2e7f6e100fdbd73318de2dda9b3d3883700be9ebfd028d4412a207e93cb02892R53)).
    - All `JSTraceable` structs added above that contain members that must be rooted because they are either [JS values](https://github.com/servo/mozjs/blob/87cabf4e9ddf9fafe19713a3d6bc8c5e6105544c/mozjs/src/gc/collections.rs#L94) or [DOM objects](https://github.com/servo/servo/blob/9887ad369d65eb362db21c778ae5f00aad74db6c/components/script/dom/bindings/root.rs#L5) should be marked with `#[cfg_attr(crown, crown::unrooted_must_root_lint::must_root)]`. [Example](https://github.com/gterzian/servo/blob/b7688fe916d105ae9023cd2429068f16ecba3574/components/script/dom/readablestreamdefaultcontroller.rs#L120), where the lint is needed due to the presence of a `JSVal`.
-   - If such a struct is assigned to a variable, `impl js::gc::Rootable` for the and use `rooted!` to root the variable([example](https://github.com/servo/servo/pull/34844/commits/94867eec21e06d59c5479bdaa92ef422bc7b21f9)).
+   - If such a struct is assigned to a variable, `impl js::gc::Rootable` for the struct and use `rooted!` to root the variable([example](https://github.com/servo/servo/pull/34844/commits/94867eec21e06d59c5479bdaa92ef422bc7b21f9)).
    - All of this can be changed later, so simply use your best judgement at this stage. 
    - Add methods for [construction](https://github.com/servo/servo/blob/4a5ff01e060293721d10289ec56dbd4c58a0969e/components/script/dom/mod.rs#L91)(not to be confused with a `Constructor` that is part of the Web API). 
    - [Example result](https://github.com/servo/servo/pull/34844/commits/7d73370b0c41a1b00f4b25b7e1b8bf9b67430708).
 
 ### Part 2: Writing a First Draft
-1. For each methods of the bindings trait referred to at 3 in Part 1:
+1. For each method of the bindings trait referred to at 3 in Part 1:
    - In general, follow the structure of the spec: if a method calls into another named algorithm, implement that named algorithm as a separate private method of your struct, that the trait methods calls into. If you later realize this private method can be used from other structs, make it `pub(crate)`. 
    - For each algorithm step in the spec:
        - Copy the line from the spec. 

src/contributing.md

@@ -16,7 +16,7 @@ This is to prevent duplicated efforts from contributors on the same issue.
 Sending the message "@servo-highfive assign me" will assign the issue to you.
 
 Head over to [Servo Starters](https://starters.servo.org/) to find good tasks to start with.
-If you find any unfamiliar words or jargon, please check the [the glossary](old/glossary.md) first.
+If you find any unfamiliar words or jargon, please check [the glossary](old/glossary.md) first.
 If there's no matching entry, please make a pull request to add one with the content `TODO` so we can correct that!
 
 See [Hacking on Servo](hacking/mach.md) for more information on how to start working on Servo.
@@ -35,7 +35,7 @@ Contributions should adhere to the [style guide](style-guide.md).
 - Commits should be accompanied by a [Developer Certificate of Origin](http://developercertificate.org) sign-off, which indicates that you (and your employer if applicable) agree to be bound by the terms of the [project license](https://github.com/servo/servo/blob/main/LICENSE).
   In git, this is the `-s` option to `git commit`.
 
-- If your patch is not getting reviewed or you need a specific person to review it, you can @-reply a reviewer asking for a review in the pull request or a comment, or you can ask for a review in [the Servo chat](https://servo.zulipchat.com/).
+- If your patch is not getting reviewed, or you need a specific person to review it, you can @-reply a reviewer asking for a review in the pull request or a comment, or you can ask for a review in [the Servo chat](https://servo.zulipchat.com/).
 
 - Add tests relevant to the fixed bug or new feature.
   For a DOM change this will usually be a web platform test; for layout, a reftest.

src/hacking/building-and-running-on-wsl.md

@@ -7,7 +7,7 @@ To run non-headless servo shell on WSL, you will most likely need to be on Windo
 Servo can be built on WSL as if you are building on any other Linux distribution.
 
 1. Setup WSL v2.  See [Microsoft's guidelines for setting up GUI apps in WSL](https://learn.microsoft.com/en-us/windows/wsl/tutorials/gui-apps).
-2. Setup the environment depending on the WSL distribution that you are using (e.g. Ubuntu, OpenSuse, etc)
+2. Set up the environment depending on the WSL distribution that you are using (e.g. Ubuntu, OpenSuse, etc.)
 3. Build
 
 ## Running

src/hacking/building-for-android.md

@@ -26,7 +26,7 @@ ANDROID_NDK_ROOT="/path/to/ndk"
 PATH=$PATH:$ANDROID_SDK/platform-tools
 ```
 
-NOTE: If you are using Nix, you don't need to install the tools or setup the ANDROID_* environment variables manually.
+NOTE: If you are using Nix, you don't need to install the tools or set up the ANDROID_* environment variables manually.
 Simply enable the Android build support running:
 ```
 export SERVO_ANDROID_BUILD=1
@@ -160,7 +160,7 @@ You will be able to catch your breakpoints during execution.
 
 ## x86 build
 
-To build a x86 version, follow the above instructions, but replace `--android` with `--target=i686-linux-android`.
+To build an x86 version, follow the above instructions, but replace `--android` with `--target=i686-linux-android`.
 The x86 emulator will need to support GLES v3 (use AVS from Android Studio v3+).
 
 ## WebVR support

src/hacking/building-for-openharmony.md

@@ -19,7 +19,7 @@ The minimum version of SDK that Servo currently supports is v5.0.2 (API-14).
 #### Downloading via DevEco Studio
 
 [DevEco Studio] is an IDE for developing applications for HarmonyOS NEXT and OpenHarmony.
-It supports Windows and MacOS.
+It supports Windows and macOS.
 You can manage installed OpenHarmony SDKs by clicking File->Settings and selecting "OpenHarmony SDK".
 After setting a suitable installation path, you can select the components you want to install for each available API version.
 DevEco Studio will automatically download and install the components for you.
@@ -80,7 +80,7 @@ care to install the hvigor version matching the requirements of your project.
    For HarmonyOS NEXT Node 18 is shipped. Ensure that the `node` binary is in PATH.
 2. Install Java using the recommended installation method for your OS.
    The build steps are known to work with OpenJDK v17, v21 and v23.
-   On MacOS, if you install Homebrew's [OpenJDK formula], the following additional command may need to be run after the installation:
+   On macOS, if you install Homebrew's [OpenJDK formula], the following additional command may need to be run after the installation:
    ```
    # For the system Java wrappers to find this JDK, symlink it with
    sudo ln -sfn $HOMEBREW_PREFIX/opt/openjdk/libexec/openjdk.jdk /Library/Java/JavaVirtualMachines/openjdk.jdk

src/hacking/debugging-on-openharmony.md

@@ -50,7 +50,7 @@ Whether log statements are visible depends on multiple conditions:
 2. The runtime `log` global filter per module filters set in servoshell. Since environment variables aren't an
   option to customize the log level, `servoshell` has the `--log-filter` option on ohos targets, which allows
   customizing the log filter of the `log` crate.
-  By default servoshell sets a log filter which hides log statements from many crates, so you likely will need to
+  By default, servoshell sets a log filter which hides log statements from many crates, so you likely will need to
   set a custom log-filter if you aren't seeing the logs from the crate you are debugging.
 3. The `hilog` base log filter. `hdc shell hilog --base-level=<log_level>`. Can be combined with `--domain` and `--tag`
   options to customize **which logs are saved**.