[css-images-3] Bring prose more in line with original spec text, + editorial clean-up. w3c#6038

Author: fantasai

css-images-3/Overview.bs

@@ -1751,14 +1751,15 @@ Determining How To Scale an Image: the 'image-rendering' property {#the-image-re
 		<dt><dfn>pixelated</dfn>
 		<dd>
 
-			The image is scaled in a way that preserves the pixelated nature of the original as much as possible,
-			but allows minor smoothing instead of awkward distortion when necessary.
+			The image is scaled in a way that preserves
+			the pixelation of the original as much as possible,
+			but allows minor smoothing as necessary to avoid distorting the image
+			when the target size is not a clean multiple of the original.
 
-			For each axis,
-			independently determine the integer multiple of its natural size
+			For each axis independently,
+			first determine the integer multiple of its natural size
 			that puts it closest to the target size
 			and is greater than zero.
-
 			Scale it to this integer-multiple-size using [=nearest neighbor=],
 			then scale it the rest of the way to the target size as for ''smooth''.
 
@@ -1773,62 +1774,30 @@ Determining How To Scale an Image: the 'image-rendering' property {#the-image-re
 		<dd>
 
 			The image is scaled in a way that preserves contrast and edges,
-			and which does not smooth colors or introduce blur to the image in the process.
-
-			The image <em>may</em> be scaled using [=nearest neighbor=],
-			but may instead be scaled with a UA-defined algorithm.
-			The only requirement is that the algorithm must not blur edges
-			or blend colors from the source image;
-			but it can, for example,
-			intelligently detect diagonal or curved lines
+			and which avoids smoothing colors or introducing blur to the image in the process.
+			This is intended for images such as line drawings.
+
+			The image <em>may</em> be scaled using [=nearest neighbor=]
+			or any other UA-chosen algorithm
+			that does not blur edges or blend colors from the source image.
+			It can, however, detect diagonal or curved lines
 			and render them as such
-			rather than as jagged-looking "giant pixels".
+			(rather than as jagged-looking “giant pixels”).
 
 			Note: If the new size is not an integer multiple of the original size,
-			the NN algorithm can introduce significant “aliasing” bugs;
+			the [=nearest neighbor=] algorithm can introduce significant “aliasing” bugs;
 			lines that were the same thickness in the original image
 			might be a pixel thinner or thicker in the scaled image
 			depending on where they appear,
 			etc.
-			For most purposes, ''pixelated'' will produce a more suitable rendering.
+			For most purposes,
+			''pixelated'' will produce a more suitable rendering than [=nearest neighbor=].
 	</dl>
 
-	<div algorithm>
-
-		The <dfn>nearest neighbor</dfn> (or NN) image scaling algorithm
-		treats the source image's pixels as literal rectangles of color
-		on the source canvas,
-		then colors each destination pixel
-		by choosing one point in the pixel's area
-		(usually either the center or top-left)
-		and using the color of the corresponding point
-		on the source canvas.
-
-		<div class=note>
-
-			When the destination image's size is an integer multiple of the source,
-			this results in "big pixels",
-			as if you'd merely "zoomed in" to the source image.
-			When it's a non-integer multiple,
-			it still produces crisp pixels
-			entirely out of source-image colors
-			(no blending or blurring),
-			but can produce "aliasing bugs"
-			where the "pixel grid" can appear somewhat irregular.
-
-			For example, using NN to scale up an image by x2.5
-			will result in each pixel of the source image
-			being used for two or three pixels of the destination image,
-			in an alternating fashion.
-			Scaling an image down to x0.5
-			will "skip" every second pixel in the source image.
-		</div>
-	</div>
-
-	Other than parts of ''crisp-edges'' and ''pixelated'',
+	Other than the first step of ''pixelated'',
 	this property does not dictate any particular scaling algorithm to be used.
 	For example, with ''image-rendering: auto'',
-	a user agent might scale images with bilinear interpolation by default,
+	a user agent could scale images with bilinear interpolation by default,
 	switch to nearest-neighbor interpolation in high-load situations,
 	and switch to a higher-quality scaling algorithm like Lanczos interpolation
 	for static images that aren't moving or changing.
@@ -1846,30 +1815,65 @@ Determining How To Scale an Image: the 'image-rendering' property {#the-image-re
 
 		<figure>
 			<img src="images/pixel-art-small.gif" width=384>
-			<figcaption>The image scaled with ''smooth''</figcaption>
+			<figcaption>The image scaled 3x with ''smooth''</figcaption>
 		</figure>
 
 		<figure>
 			<img src="images/pixel-art-nn.png">
-			<figcaption>The image scaled with ''pixelated'' or ''crisp-edges''</figcaption>
+			<figcaption>The image scaled 3x with ''pixelated''</figcaption>
 		</figure>
+
+		<figure>
+			<img src="images/pixel-art-smooth.png">
+			<figcaption>
+				The image scaled 3x with ''crisp-edges''
+				interpreted with an edge-preserving algorithm.
+				<br>
+				(Interpreting as [=nearest neighbor=] would give
+				the same results as ''pixelated'' in this case.)
+			</figcaption>
+	</div>
+
+	<div algorithm>
+		The <dfn>nearest neighbor</dfn> (or NN) image scaling algorithm
+		treats the source image's pixels as literal rectangles of color
+		on the source canvas,
+		then colors each destination pixel
+		by choosing one point in the pixel's area
+		(usually either the center or top-left)
+		and using the color of the corresponding point
+		on the source canvas.
+
+		<div class=note>
+			When the target size is an integer multiple of the source,
+			this results in “big pixels”,
+			as if you'd merely zoomed in on the source image.
+			When the target size is a non-integer multiple,
+			it still produces crisp pixels
+			entirely out of source-image colors
+			(no blending or blurring),
+			but can produce aliasing quirks
+			where the “pixel grid” can appear somewhat irregular.
+
+			For example, using [=nearest neighbor=] to scale up an image by 2.5x
+			will result in each pixel of the source image
+			being used for two or three pixels of the destination image,
+			in an alternating fashion,
+			while scaling an image down to 0.5x
+			will skip every second pixel in the source image.
+		</div>
 	</div>
 
 	<div class='example'>
-		At the 3x scaling as in the preceding example,
-		''pixelated'' and ''crisp-edges'' give identical results.
-		At scale ratios in-between integer multiples,
+		At 3x scaling as in the preceding example,
+		both ''pixelated'' and pure [=nearest neighbor=] give identical results.
+		At scale ratios between integer multiples,
 		however,
 		they'll act differently:
 
 		<figure>
 			<img src="images/pixel-art-small.gif">
-			<figcaption>The same small pixel-art image as before.</figcaption>
-		</figure>
-
-		<figure>
-			<img src="images/pixel-art-small.gif" width=320>
-			<figcaption>The image scaled 2.5x with ''smooth''</figcaption>
+			<figcaption>The same small pixel-art image as before</figcaption>
 		</figure>
 
 		<figure>
@@ -1879,15 +1883,18 @@ Determining How To Scale an Image: the 'image-rendering' property {#the-image-re
 
 		<figure>
 			<img src="images/pixel-art-nn-2p5.png">
-			<figcaption>The image scaled 2.5x with ''crisp-edges''</figcaption>
+			<figcaption>
+				The image scaled 2.5x with ''crisp-edges''
+				interpreted as [=nearest neighbor=]
+			</figcaption>
 		</figure>
 
 		The ''pixelated'' version maintains the overall <em>look</em> of simply scaling the pixels up,
 		at the cost of <em>slight</em> blurring,
 		though much less blurring than the ''smooth'' scaling gives.
-		Meanwhile, ''crisp-edges'' avoids introducing any blurring at all,
+		Meanwhile, [=nearest neighbor=] avoids introducing any blurring at all,
 		at the cost of aliasing artifacts
-		making the "pixels" look irregularly sized.
+		making the “pixels” look irregularly sized.
 	</div>
 
 	This property previously accepted the values ''optimizeSpeed'' and ''optimizeQuality''.