Cocoa coordinates start at the bottom left; content ➞ contents to be consistent with Views code.

docs/ui/views/overview.md

 # Views Overview
 
 This document is an overview of Views concepts, terminology, and architecture.
 The target audience is engineers using or working on Views.
 
 ## General Things
 
 Points in this document are written as `(x,y)`, and rectangles are written as
 `[(x,y) wxh]`. For example, the rectangle `[(100,100) 50x20]` contains the point
 `(130,110)`.
 
 Views uses a coordinate system with `(0,0)` at the top-left, with increasing
 x-coordinates moving rightwards and increasing y-coordinates moving downwards.
 This is the same as the Windows and GTK coordinate systems, but *different from*
-the Cocoa coordinate system, which has `(0,0)` at the bottom-right. Coordinates
+the Cocoa coordinate system, which has `(0,0)` at the bottom-left. Coordinates

[Elly Fong-Jones, 2017/05/22 14:53:42]

ooops! thanks for noticing & fixing :)

 in this document use the Views coordinate system.
 
 Views generally *take ownership* of objects passed to them even via raw
 pointers, although there are some exceptions, such as delegates.
 
 ## Views
 
 A **View** is a UI element, similar to an HTML DOM element. Each View occupies a
 rectangle, called its **bounds**, which is expressed in the coordinate system of
 its parent View. Views may have child Views, which are laid out according to the
@@ skipping 71 matching lines @@
 
 ## Widgets
 
 Views need an underlying canvas to paint onto. This has to be supplied by the
 operating system, usually by creating a native drawing surface of some kind.
 Views calls these **widgets**. A Widget is the bridge between a tree of Views
 and a native window of some sort, which Views calls a **native widget**. Each
 Widget has a **root view**, which is a special subclass of View that helps with
 this bridging; the root view in turn has a single child view, called the
 Widget's **contents view**, which fills the entire root view. All other Views
-inside a given Widget are children of that Widget's content view.
+inside a given Widget are children of that Widget's contents view.
 
 Widgets have many responsibilities, including but not limited to:
 
 1. Keyboard focus management, via [FocusManager]
 2. Window resizing/minimization/maximization
 3. Window shaping, for non-rectangular windows
 4. Input event routing
 
 For more details, see [widget.h].
 
 ### Client and Non-Client Views
 
-The content view of most Widgets is a **Non-Client View**, which is either a
+The contents view of most Widgets is a **Non-Client View**, which is either a
 [NonClientView] or one of its descendants. The Non-Client View has two children,
 which are the **Non-Client Frame View** (a [NonClientFrameView]) and the
 **Client View** (a [ClientView]). The non-client frame view is responsible for
 painting window decorations, the Widget's border, the shadow, and so on; the
 client view is responsible for painting the Widget's contents. The area the
 client view occupies is sometimes referred to as the Widget's "client area". The
 non-client frame view may be swapped out as the system theme changes without
 affecting the client view.
 
 ## Dialogs
 
 A commonly-used type of client view is a **dialog client view**, which has a
-**content view**, optional buttons on the lower-right, and an optional extra
+**contents view**, optional buttons on the lower-right, and an optional extra
 view on the lower-left. Dialogs are usually created by subclassing
 [DialogDelegate] or [DialogDelegateView] and then calling
-`DialogDelegate::CreateDialogWidget`. The dialog's content view fills the entire
-top part of the widget's client view, and the bottom part is taken over by the
-dialog's buttons and extra view.
+`DialogDelegate::CreateDialogWidget`. The dialog's contents view fills the
+entire top part of the widget's client view, and the bottom part is taken over
+by the dialog's buttons and extra view.
 
 ## Bubbles
 
 A common type of dialog is a **bubble**, which is a dialog that is anchored to a
 parent View and moves as the parent View moves. Bubbles are usually created by
 subclassing [BubbleDialogDelegateView] and then calling
 `BubbleDialogDelegateView::CreateBubble`. Bubbles can have a title, which is
 drawn alongside the window controls as part of the Bubble's Widget's
 NonClientFrameView.
 
 [BoxLayout]: https://cs.chromium.org/chromium/src/ui/views/layout/box_layout.h
 [BubbleDialogDelegateView]: https://cs.chromium.org/chromium/src/ui/views/bubble/bubble_dialog_delegate.h
 [ClientView]: https://cs.chromium.org/chromium/src/ui/views/window/client_view.h
 [DialogDelegate]: https://cs.chromium.org/chromium/src/ui/views/window/dialog_delegate.h
 [DialogDelegateView]: https://cs.chromium.org/chromium/src/ui/views/window/dialog_delegate.h
 [FillLayout]: https://cs.chromium.org/chromium/src/ui/views/layout/fill_layout.h
 [FocusManager]: https://cs.chromium.org/chromium/src/ui/views/focus/focus_manager.h
 [GridLayout]: https://cs.chromium.org/chromium/src/ui/views/layout/grid_layout.h
 
 [NonClientView]: https://cs.chromium.org/chromium/src/ui/views/window/non_client_view.h
 [NonClientFrameView]: https://cs.chromium.org/chromium/src/ui/views/window/non_client_view.h
 [background.h]: https://cs.chromium.org/chromium/src/ui/views/background.h
 [border.h]: https://cs.chromium.org/chromium/src/ui/views/border.h
 [canvas.h]: https://cs.chromium.org/chromium/src/ui/gfx/canvas.h
 [view.h]: https://cs.chromium.org/chromium/src/ui/views/view.h
 [widget.h]: https://cs.chromium.org/chromium/src/ui/views/widget/widget.h