[css-images-3] Merge crisp-edges and nearest-neighbor, retaining the older crisp-edges name. w3c#6038

Author: tabatkins

css-images-3/Overview.bs

@@ -1688,7 +1688,7 @@ Determining How To Scale an Image: the 'image-rendering' property {#the-image-re
 
 	<pre class='propdef'>
 	Name: image-rendering
-	Value: auto | smooth | high-quality | crisp-edges | pixelated
+	Value: auto | smooth | high-quality | pixelated | crisp-edges
 	Initial: auto
 	Applies to: all elements
 	Inherited: yes
@@ -1743,33 +1743,28 @@ 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 in some cases.
+			but allows minor smoothing instead of awkward distortion when necessary.
 
 			For each axis,
 			independently 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 as for ''nearest-neighbor'',
+			Scale it to this integer-multiple-size as for ''crisp-edges'',
 			then scale it the rest of the way to the target size as for ''smooth''.
 
 			Note: At integer multiples of the natural size,
-			this gives the same results as ''nearest-neighbor''.
+			this gives the same results as ''crisp-edges''.
 			At non-integer multiples, this usually gives better visual results,
 			even for pixel art,
 			but it does incur a performance penalty
 			due to the "two-step" rendering requirement.
 
 		<dt><dfn caniuse="css-crisp-edges">crisp-edges</dfn>
 		<dd>
-			The image must be scaled with an algorithm that preserves contrast and edges in the image,
+			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.
 
-			This <em>may</em> be identical to ''nearest-neighbor'',
-			but UAs may use any algorithm that meets the requirements.
-
-		<dt><dfn>nearest-neighbor</dfn>
-		<dd>
 			The image must be scaled with the "nearest neighbor" algorithm:
 			treating the original image's pixel grid as a literal grid of rectangles,
 			scale those to the desired size,
@@ -1779,56 +1774,81 @@ Determining How To Scale an Image: the 'image-rendering' property {#the-image-re
 			Note: If the new size is not an integer multiple of the original size,
 			the NN 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,
+			might be a pixel thinner or thicker in the scaled image
 			depending on where they appear,
 			etc.
 	</dl>
 
-	This property does not dictate any particular scaling algorithm to be used.
+	Other than ''crisp-edges''
+	and the portion of ''pixelated'' that acts like ''crisp-edges'',
+	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,
 	switch to nearest-neighbor interpolation in high-load situations,
-	and switch to a high-quality scaling algorithm like Lanczos interpolation for static images that aren't moving or changing.
-	Similarly, with 'image-rendering: crisp-edges',
-	a user agent might scale images with nearest-neighbor interpolation by default,
-	and switch to EPX interpolation in low-load situations.
+	and switch to a high-quality scaling algorithm like Lanczos interpolation
+	for static images that aren't moving or changing.
 
 	<div class='example'>
 		For example, given the following small image:
 
 		<figure>
 			<img src="images/pixel-art-small.gif">
-			<figcaption>A small pixel-art image.
+			<figcaption>A small pixel-art image.</figcaption>
 		</figure>
 
 		Scaling it up 3x might look like the following,
 		depending on the value of 'image-rendering':
 
 		<figure>
 			<img src="images/pixel-art-small.gif" width=384>
-			<figcaption>The image scaled with ''image-rendering/auto''</figcaption>
+			<figcaption>The image scaled with ''smooth''</figcaption>
 		</figure>
 
 		<figure>
 			<img src="images/pixel-art-nn.png">
-			<figcaption>The image scaled with ''pixelated''</figcaption>
+			<figcaption>The image scaled with ''pixelated'' or ''crisp-edges''</figcaption>
+		</figure>
+	</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,
+		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>
 		</figure>
 
 		<figure>
-			<img src="images/pixel-art-smooth.png">
-			<figcaption>
-				The image scaled with ''crisp-edges''.<br>
-				<small>(Or it might look like ''nearest-neighbor'',
-				or as another type of pixel-scaling algorithm,
-				depending on the browser.)</small>
-			</figcaption>
+			<img src="images/pixel-art-nn.png" width=320>
+			<figcaption>The image scaled 2.5x with ''pixelated''</figcaption>
 		</figure>
+
+		<figure>
+			<img src="images/pixel-art-nn-2p5.png">
+			<figcaption>The image scaled 2.5x with ''crisp-edges''</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,
+		tho much less blurring than the ''smooth'' scaling gives.
+		Meanwhile, ''crisp-edges'' avoids introducing any blurring at all,
+		at the cost of aliasing artifacts
+		making the "pixels" look irregularly sized.
 	</div>
 
 	This property previously accepted the values ''optimizeSpeed'' and ''optimizeQuality''.
 	These are now deprecated;
 	a user agent must accept them as valid values
-	but must treat them as having the same behavior as ''nearest-neighbor'' and ''smooth'' respectively,
+	but must treat them as having the same behavior as ''crisp-edges'' and ''smooth'' respectively,
 	and authors must not use them.