Copy from public_webgl mailing list, proposed by Jeff Gilbert from Mozzila

"""
Specifically, the following would generate INVALID_OPERATION:
* SKIP_PIXELS + width > ROW_LENGTH
* SKIP_ROWS + height > IMAGE_HEIGHT

This will:
* Make things cleaner for both implementers and devs
* Remove a source of implementation behavior differences
* Prevent a source of bugs for developers (setting SKIP_PIXELS without
ROW_LENGTH)

If we find a compelling use-case for relaxing this, no content
breakage will occur if we decide to loosen these restrictions later.
"""

"""
Unfettered behavior here, however, not make sense in the context of
the rest of the API.

There are two relevant cases:
* Overlapping rows
* Non-trivial subrects

Overlapping rows:
width>ROW_LENGTH
(The same applies to height>IMAGE_HEIGHT)
Overlapping rows are not tightly defined. As such, well-behaved apps
cannot expect the results of an overlapping row read to be consistent
across implementations. Since it's trivial to change the params into a
non-overlapped row configuration, with no loss of reliable utility, I
propose we restrict this behavior.

Nontrivial subrects:
SKIP_PIXELS+width>(ROW_LENGTH ? ROW_LENGTH : width)
(The same applies for SKIP_ROWS/IMAGE_HEIGHT)
If the goal is simply to offset into the buffer, there are other
entrypoints/API aspects which allow this.
However, there are weird results from using something like
SKIP_PIXEL=10000: Alignment (for the purposes of row striding) is
still based on effective row length alone. (effective row length =
ROW_LENGTH ? ROW_LENGTH : width) Thus `baseOffset + skipBytes +
N*rowStride` will not necessarily be aligned to `baseOffset +
M*ALIGNMENT`, subverting the ALIGNMENT param. (and generally being
suprising!)
Roughly, if `SKIP_PIXELS > ROW_LENGTH-width`, you can just offset the
base pointer via another part of the API, then make a call with
`SKIP_PIXELS <= ROW_LENGTH-width`.
Since there are other ways to handle arbitrary byte skipping, and
eliminating nontrivial subrects is an easy way to ensure expected
behavior, I propose we restrict this behavior.
"""

We need to update the spec, modify existing tests, and implement this behavior.