CSS Image Values and Replaced Content Module Level 4

Anything else that might be useful? Defining the shape of the gradient as elliptical, perhaps?

Placing Color Stops

Conic Gradient Examples

Produce examples. Better yet, strike this section, and intermix some examples into the sections above. Do this for the other two types of gradients as well.

Repeating Gradients: the ''repeating-linear-gradient()'', ''repeating-radial-gradient()'', and ''repeating-conic-gradient()'' notations

Repeating gradient syntax is identical to that of non-repeating gradients:

repeating-linear-gradient(red, blue 20px, red 40px)

repeating-radial-gradient(red, blue 20px, red 40px)

repeating-radial-gradient(circle closest-side at 20px 30px, red, yellow, green 100%, yellow 150%, red 200%)

repeating-conic-gradient(at 20%, white 0deg, white 20deg, red 20deg, red 40deg)

Insert rendering here.

1. Define list as an initially-empty list of premultiplied RGBA colors, and total-length as the distance between first and last color stops.
2. For each adjacent pair of color-stops, define weight as half the distance between the two color-stops, divided by total-length. Add two entries to list, the first obtained by representing the color of the first color-stop in premultiplied sRGBA and scaling all of the components by weight, and the second obtained in the same way with the second color-stop.
3. Sum the entries of list component-wise to produce the average color, and return it.

repeating-linear-gradient(red 0px, white 0px, blue 0px);

repeating-linear-gradient(red 0px, white .1px, blue .2px);

Gradient Color-Stops

		<color-stop-list> =
			[ <> , <>? ]# , <>
		<linear-color-stop> = <> && <>
		<linear-color-hint> = <> | <>
		<color-stop-length> = [ <> | <> ]{1,2}

		<angular-color-stop-list> =
			[ <> , <>? ]# , <>
		<angular-color-stop> = <> && <>?
		<angular-color-hint> = <> | <>
		<color-stop-angle> = [ <> | <> ]{1,2}

		<color-stop> = <> | <>
	

		Plus:
			Sequence:
				N: 
				T: ,
				Choice: 1
					N: 
					Skip:
			T: ,
		N: 
	

This is past the complexity point where it can be easily understood with just prose. Add a diagram illustrating the possibilities, preferably for all three kinds of gradients (to show off the three shapes of gradient lines). The colors in gradients are specified using color stops. A color stop is a combination of a color and one or two positions. (Depending on the type of gradient, that position can be a length, angle, or percentage.) While every color stop conceptually has at least one position, the position can be omitted in the syntax. (It gets automatically filled in by the user agent; see below for details.) Some color stops don't have a color, only a position. A color stop like this is a color interpolation hint, which specifies how the colors of the two color stops on either side should be interpolated in the space between them (by default, they interpolate linearly). There can only be at most one color interpolation hint between any two given normal color stops; using more than that makes the function invalid. Color stops are organized into a color stop list, which is a list of one or more color stops. The first and last color stops in the list must have a color (though their position can be omitted). Color stops are placed on a gradient line, which defines the colors at every point of a gradient. The gradient function defines the shape and length of the gradient line, along with its starting point and ending point. Color stops must be specified in order. Percentages refer to the length of the gradient line between the starting point and ending point, with 0% being at the starting point and 100% being at the ending point. Lengths are measured from the starting point in the direction of the ending point along the gradient line. Angles are measured with 0deg pointing up, and positive angles corresponding to clockwise rotations from there. Color stops are usually placed between the starting point and ending point, but that's not required; the gradient line extends infinitely in both directions, and a color stop can be placed at any position on the gradient line. A color stop with two locations is mostly equivalent to specifying two color stops with the same color, one for each position. However, if the color is omitted, it's treated as a single color stop by step 4 in the clean-up algorithm below. Specifying two locations makes it easier to create solid-color "stripes" in a gradient, without having to repeat the color twice. The position of a color stop can be omitted. This causes the color stop to position itself automatically between the two surrounding stops. If multiple stops in a row lack a position, they space themselves out equally. Similarly, the color of a color stop can be omitted. The causes the color to be automatically computed to halfway between the two surrounding stops, so that the "midpoint" of a transition can be easily adjusted. If multiple stops in a row lack a color, they space themselves out equally in "color space", giving more control over the smoothness of the transition. The following steps must be applied in order to process the list of color stops. After applying these rules, all color stops will have a definite position and color and they will be in ascending order:

1. If the first color stop does not have a position, set its position to 0%. If the last color stop does not have a position, set its position to 100%.
2. If a color stop has a position that is less than the specified position of any color stop before it in the list, set its position to be equal to the largest specified position of any color stop before it.
3. If any color stop still does not have a position, then, for each run of adjacent color stops without positions, set their positions so that they are evenly spaced between the preceding and following color stops with positions.
4. If any color stop does not have a color, then, for each run of adjacent color stops without colors, set their colors to be evenly spaced linear interpolations in premultiplied sRGBA space between the preceding and following color stops with colors. Note that a color stop with two positions is still counted as a single color stop by this step, so both positions will be assigned the same color.

This requires us to wait until after layout to do fix-up, because implied-position stops (set by step 3) may depend on stops that need layout information to place, and which may be corrected by step 2. Swapping steps 2 and 3 would let us interpolate color stops purely at computed-value time, which is a nice plus, at the cost of changing behavior from level 3 for some edge cases that triggered fixup. Make sure this is handled well in the serialization rules. At each color stop position, the line is the color of the color stop. Between two color stops, the line's color is interpolated between the colors of the two color stops, with the interpolation taking place in premultiplied RGBA space. By default, this interpolation is linear-- at 25%, 50%, or 75% of the distance between two color stops, the color is a 25%, 50%, or 75% blend of the colors of the two stops. However, if a color interpolation hint was provided between two color stops, the interpolation is non-linear, and controlled by the hint:

1. Determine the location of the hint as a percentage of the distance between the two color stops, denoted as a number between 0 and 1, where 0 indicates the hint is placed right on the first color stop, and 1 indicates the hint is placed right on the second color stop. Let this percentage be H.
2. For any given point between the two color stops, determine the point's location as a percetnage of the distance between the two color stops, in the same way as the previous step. Let this percentage be P.
3. Let C, the color weighting at that point, be equal to PlogH(.5).
4. The color at that point is then a linear blend between the colors of the two color stops, blending (1 - C) of the first stop and C of the second stop.

			1. linear-gradient(red, white 20%, blue)
			   =1=>
			   linear-gradient(red 0%, white 20%, blue 100%)

			2. linear-gradient(red 40%, white, black, blue)
			   =13=>
			   linear-gradient(red 40%, white 60%, black 80%, blue 100%)

			3. linear-gradient(red -50%, white, blue)
			   =13=>
			   linear-gradient(red -50%, white 25%, blue 100%)

			4. linear-gradient(red -50px, white, blue)
			   =13=>
			   linear-gradient(red -50px, white calc(-25px + 50%), blue 100%)

			5. linear-gradient(red 20px, white 0px, blue 40px)
			   =2=>
			   linear-gradient(red 20px, white 20px, blue 40px)

			6. linear-gradient(red, white -50%, black 150%, blue)
			   =12=>
			   linear-gradient(red 0%, white 0%, black 150%, blue 150%)

			7. linear-gradient(red 80px, white 0px, black, blue 100px)
			   =23=>
			   linear-gradient(red 80px, white 80px, black 90px, blue 100px)

			8. linear-gradient(red, 25%, white)
			   =14=>
			   linear-gradient(red 0%, rgb(100%,50%,50%) 25%, white 100%)
		

linear-gradient(90deg, red, transparent, blue)

Sizing Images and Objects in CSS

Object-Sizing Terminology

intrinsic dimensions

The term intrinsic dimensions refers to the set of the intrinsic height, intrinsic width, and intrinsic aspect ratio (the ratio between the width and height), each of which may or may not exist for a given object. These intrinsic dimensions represent a preferred or natural size of the object itself; that is, they are not a function of the context in which the object is used. CSS does not define how the intrinsic dimensions are found in general. Raster images are an example of an object with all three intrinsic dimensions. SVG images designed to scale might have only an intrinsic aspect ratio; SVG images can also be created with only an intrinsic width or height. CSS gradients, defined in this specification, are an example of an object with no intrinsic dimensions at all. Another example of this is embedded documents, such as the <iframe> element in HTML. An object cannot have only two intrinsic dimensions, as any two automatically define the third. If an object (such as an icon) has multiple sizes, then the largest size (by area) is taken as its intrinsic size. If it has multiple aspect ratios at that size, or has multiple aspect ratios and no size, then the aspect ratio closest to the aspect ratio of the default object size is used. Determine this by seeing which aspect ratio produces the largest area when fitting it within the default object size using a contain constraint fit; if multiple sizes tie for the largest area, the wider size is chosen as its intrinsic size.

specified size

The specified size of an object is given by CSS, such as through the 'width' and 'height' or 'background-size' properties. The specified size can be a definite width and height, a set of constraints, or a combination thereof.

concrete object size

The concrete object size is the result of combining an object's intrinsic dimensions and specified size with the default object size of the context it's used in, producing a rectangle with a definite width and height.

default object size

The default object size is a rectangle with a definite height and width used to determine the concrete object size when both the intrinsic dimensions and specified size are missing dimensions.

CSS⇋Object Negotiation

1. When an image or object is specified in a document, such as through a ''url()'' value in a 'background-image' property or a src attribute on an <img> element, CSS queries the object for its intrinsic dimensions.
2. Using the intrinsic dimensions, the specified size, and the default object size for the context the image or object is used in, CSS then computes a concrete object size. (See the following section.) This defines the size and position of the region the object will render in.
3. CSS asks the object to render itself at the concrete object size. CSS does not define how objects render when the concrete object size is different from the object's intrinsic dimensions. The object may adjust itself to match the concrete object size in some way, or even render itself larger or smaller than the concrete object size to satisfy sizing constraints of its own.
4. Unless otherwise specified by CSS, the object is then clipped to the concrete object size.

Concrete Object Size Resolution

Default Sizing Algorithm

• If the specified size is a definite width and height, the concrete object size is given that width and height.
• If the specified size is only a width or height (but not both) then the concrete object size is given that specified width or height. The other dimension is calculated as follows:
  1. If the object has an intrinsic aspect ratio, the missing dimension of the concrete object size is calculated using the intrinsic aspect ratio and the present dimension.
  2. Otherwise, if the missing dimension is present in the object's intrinsic dimensions, the missing dimension is taken from the object's intrinsic dimensions.
  3. Otherwise, the missing dimension of the concrete object size is taken from the default object size.
• If the specified size has no constraints:
  1. If the object has an intrinsic height or width, its size is resolved as if its intrinsic dimensions were given as the specified size.
  2. Otherwise, its size is resolved as a contain constraint against the default object size.

Cover and Contain Constraint Sizing

• A contain constraint is resolved by setting the concrete object size to the largest rectangle that has the object's intrinsic aspect ratio and additionally has neither width nor height larger than the constraint rectangle's width and height, respectively.
• A cover constraint is resolved by setting the concrete object size to the smallest rectangle that has the object's intrinsic aspect ratio and additionally has neither width nor height smaller than the constraint rectangle's width and height, respectively.

Examples of CSS Object Sizing

Sizing Objects: the 'object-fit' property

	Name: object-fit
	Value: fill | contain | cover | none | scale-down
	Initial: fill
	Applies to: replaced elements
	Inherited: no
	Percentages: n/a
	Media: visual
	Computed value: specified value
	Animatable: no
	

fill

The replaced content is sized to fill the element's content box: the object's concrete object size is the element's used width and height.

contain

The replaced content is sized to maintain its aspect ratio while fitting within the element's content box: its concrete object size is resolved as a contain constraint against the element's used width and height.

cover

The replaced content is sized to maintain its aspect ratio while filling the element's entire content box: its concrete object size is resolved as a cover constraint against the element's used width and height.

none

The replaced content is not resized to fit inside the element's content box: determine the object's concrete object size using the default sizing algorithm with no specified size, and a default object size equal to the replaced element's used width and height.

scale-down

Size the content as if ''none'' or ''contain'' were specified, whichever would result in a smaller concrete object size. Note: Both ''none'' and ''contain'' respect the content's intrinsic aspect ratio, so the concept of "smaller" is well-defined.

> parameter on the preserveAspectRatio attribute in [[SVG11]]. Note: Per the object size negotiation algorithm, the concrete object size (or, in this case, the size of the content) does not directly scale the object itself - it is merely passed to the object as information about the size of the visible canvas. How to then draw into that size is up to the image format. In particular, raster images always scale to the given size, while SVG uses the given size as the size of the "SVG Viewport" (a term defined by SVG) and then uses the values of several attributes on the root <svg> element to determine how to draw itself.

Positioning Objects: the 'object-position' property

	Name: object-position
	Value: <>
	Initial: 50% 50%
	Applies to: replaced elements
	Inherited: no
	Percentages: refer to width and height of element itself
	Media: visual
	Computed value: specified value
	Animatable: yes
	Canonical Order: the horizontal component of the <>, followed by the vertical component
	

The 'object-position' property determines the alignment of the replaced element inside its box. The <> value type (which is also used for 'background-position') is defined in [[!CSS3VAL]], and is resolved using the concrete object size as the object area and the content box as the positioning area. Note: Areas of the box not covered by the replaced element will show the element's background.

Image Processing

Overriding Image Resolutions: the 'image-resolution' property

The image resolution is defined as the number of image pixels per unit length, e.g., pixels per inch. Some image formats can record information about the resolution of images. This information can be helpful when determining the actual size of the image in the formatting process. However, the information can also be wrong, in which case it should be ignored. By default, CSS assumes a resolution of one image pixel per CSS ''px'' unit; however, the 'image-resolution' property allows using some other resolution.

	Name: image-resolution
	Value: [ from-image || <> ] && snap?
	Initial: 1dppx
	Applies to: all elements
	Inherited: yes
	Media: visual
	Computed value: as specified, except with <> possibly altered by computed for ''snap'' (see below)
	Animatable: no
	

The ''image-set()'' notation can alter the intrinsic resolution of an image, which ideally would be automatically honored without having to set this property. How should we best address this? Change the initial value to ''auto'', meaning "1dppx, unless CSS says otherwise"? Say that image-resolution has no effect on images whose resolution was set by something else in CSS? Or somehow wordsmithing ''image-set()'' in some way such that it always produces ''1dppx'' images somehow? The 'image-resolution' property specifies the intrinsic resolution of all raster images used in or on the element. It affects both content images (e.g. replaced elements and generated content) and decorative images (such as 'background-image'). The intrinsic resolution of an image is used to determine the image's intrinsic dimensions. Values have the following meanings:

<>

Specifies the intrinsic resolution explicitly. A "dot" in this case corresponds to a single image pixel.

from-image

The image's intrinsic resolution is taken as that specified by the image format. If the image does not specify its own resolution, the explicitly specified resolution is used (if given), else it defaults to ''1dppx''.

snap

If the "snap" keyword is provided, the computed <> (if any) is the specified resolution rounded to the nearest value that would map one image pixel to an integer number of device pixels. If the resolution is taken from the image, then the used intrinsic resolution is the image's native resolution similarly adjusted.

As vector formats such as SVG do not have an intrinsic resolution, this property has no effect on vector images.

Printers tend to have substantially higher resolution than computer monitors; due to this, an image that looks fine on the screen may look pixellated when printed out. The 'image-resolution' property can be used to embed a high-resolution image into the document and maintain an appropriate size, ensuring attractive display both on screen and on paper:

			img.high-res {
				image-resolution: 300dpi;
			}
		

With this set, an image meant to be 5 inches wide at 300dpi will actually display as 5in wide; without this set, the image would display as approximately 15.6in wide since the image is 15000 image pixels across, and by default CSS displays 96 image pixels per inch.

Some image formats can encode the image resolution into the image data. This rule specifies that the UA should use the image resolution found in the image itself, falling back to 1 image pixel per CSS ''px'' unit.

img { image-resolution: from-image }

These rules both specify that the UA should use the image resolution found in the image itself, but if the image has no resolution, the resolution is set to ''300dpi'' instead of the default ''1dppx''.

			img { image-resolution: from-image 300dpi }
			img { image-resolution: 300dpi from-image }
		

Using this rule, the image resolution is set to 300dpi. (The resolution in the image, if any, is ignored.)

img { image-resolution: 300dpi }

This rule, on the other hand, if used when the screen's resolution is 96dpi, would instead render the image at 288dpi (so that 3 image pixels map to 1 device pixel):

img { image-resolution: 300dpi snap; }

The ''snap'' keyword can also be used when the resolution is taken from the image:

img { image-resolution: snap from-image; }

An image declaring itself as 300dpi will, in the situation above, display at 288dpi (3 image pixels per device pixel) whereas an image declaring 72dpi will render at 96dpi (1 image pixel per device pixel).

Orienting an Image on the Page: the 'image-orientation' property

Issue: This property is likely going to be deprecated and its functionality moved to HTML. At minimum, it will likely lose all but its initial value and ''image-orientation/from-image''. If a picture is taken with a camera turned on its side, or a document isn't positioned correctly within a scanner, the resultant image may be "sideways" or even upside-down. The 'image-orientation' property provides a way to apply an "out-of-band" rotation to image source data to correctly orient an image. Note: This property is not intended to specify layout transformations such as arbitrary rotation or flipping the image in the horizontal or vertical direction. (See [[CSS3-2D-TRANSFORMS]] for a feature designed to do that.) It is also not needed to correctly orient an image when printing in landscape versus portrait orientation, as that rotation is done as part of layout. (See [[CSS3PAGE]].) It should only be used to correct incorrectly-oriented images.

	Name: image-orientation
	Value: from-image | <> | [ <>? flip ]
	Initial: 0deg
	Applies to: all elements
	Inherited: yes
	Media: visual
	Computed value: an <>, rounded and normalized (see text), plus optionally a ''flip'' keyword
	Animatable: no
	

This property specifies an orthogonal rotation to be applied to an image before it is laid out. It applies only to content images (e.g. replaced elements and generated content), not decorative images (such as 'background-image'). CSS layout processing applies to the image after rotation. This implies, for example:

• The intrinsic height and width are derived from the rotated rather than the original image dimensions.
• The height (width) property applies to the vertical (horizontal) dimension of the image, after rotation.

Values have the following meanings:

from-image

If the image has an orientation specified in its metadata, such as EXIF, this value computes to the angle that the metadata specifies is necessary to correctly orient the image. If necessary, this angle is then rounded and normalized as described above for an <> value. If there is no orientation specified in its metadata, this value computes to ''0deg''.

<>

Positive values cause the image to be rotated to the right (in a clockwise direction), while negative values cause a rotation to the left. The computed value of the property is calculated by rounding the specified angle to the nearest quarter-turn (90deg, 100grad, .25turn, etc.), rounding away from 0 (that is, 45deg is rounded to 90deg, while -45deg is rounded to -90deg), then moduloing the value by 1 turn (360deg, 400grad, etc.).

<>? flip

Identical to the plain <> case, except that after rotation the image is flipped horizontally. If the <> is omitted, it defaults to ''0deg''. Note: This value is only necessary to represent all 8 possible EXIF orientations that from-image can produce.

The 'image-orientation' property must be applied before any other transformations, such as being specified in the ''image()'' function with an opposite directionality to its context, or using CSS Transforms.

The following example rotates the image 90 degrees clockwise:

			img.ninety     { image-orientation: 90deg }
			...
			<img class="ninety" src=...>
		

The same effect could be achieved with, for example, an angle of -270deg or 450deg.

Determing How To Scale an Image: the 'image-rendering' property

	Name: image-rendering
	Value: auto | crisp-edges | pixelated
	Initial: auto
	Applies to: all elements
	Inherited: yes
	Media: visual
	Computed value: specified value
	Animatable: no
	

The 'image-rendering' property provides a hint to the user-agent about what aspects of an image are most important to preserve when the image is scaled, to aid the user-agent in the choice of an appropriate scaling algorithm. When specified on an element, it applies to all images given in properties for the element, such as background images, list-style images, or the content of replaced elements when they represent an image that must be scaled. The values of the 'image-rendering' property are interpreted as follows:

auto

The image should be scaled with an algorithm that maximizes the appearance of the image. In particular, scaling algorithms that "smooth" colors are acceptable, such as bilinear interpolation. This is intended for images such as photos.

crisp-edges

The image must be scaled with an algorithm that preserves contrast and edges in the image, and which does not smooth colors or introduce blur to the image in the process. This is intended for images such as pixel art.

pixelated

When scaling the image up, the "nearest neighbor" or similar algorithm must be used, so that the image appears to be simply composed of very large pixels. When scaling down, this is the same as auto.

Should we move the current ''auto'' behavior to a well-named keyword (''smooth''?) and just define ''auto'' to be "whatever the UA wants", which is what ''auto'' usually means? 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. 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 auto, and authors must not use them.

Interpolation

This section describes how to interpolate between new value types defined in this specification, for use with modules such as CSS Transitions and CSS Animations. If an algorithm below simply states that two values should be "interpolated" or "transitioned" without further details, then the value should be interpolated as described by the Transitions spec. Otherwise, the algorithm may reference a variable "t" in its detailed description of the interpolation. This is a number which starts at 0% and goes to 100%, and is set to a value that represents the progress through the transition, based on the duration of the transition, the elapsed time, and the timing function in use. For example, with a linear timing function and a 1s duration, after .3s t is equal to 30%.

Interpolating <>

All images can be interpolated, though some special types of images (like some gradients) have their own special interpolation rules. In general terms, images are interpolated by scaling them to the size of the start image and cross-fading the two while they transition to the size of the end image. In specific terms, at each point in the interpolation the image is equal to cross-fade( (100% - t) start image, end image).

Special-case interpolating to/from no image, like "background-image: url(foo);" to "background-image: none;".

Interpolating cross-fade()

If both the starting and ending images are cross-fade()s which differ only by by their <>, they must be interpolated by interpolating their <>. Otherwise, they must be interpolated as generic <>s.

Interpolating <>

This section needs review and improvement. In particular, I believe the handling of linear-gradient() is incomplete - I think we want to specifically interpolate the "length" of the gradient line (the distance between 0% and 100%) between the starting and ending positions explicitly, so it doesn't grow and then shrink over a single animation. Gradient images can be interpolated directly in CSS transitions and animations, smoothly animating from one gradient to another. There are only a few restrictions on what gradients are allowed to be interpolated:

1. Both the starting and ending gradient must be expressed with the same function. (For example, you can transition from a ''linear-gradient()'' to a ''linear-gradient()'', but not from a ''linear-gradient()'' to a ''radial-gradient()'' or a ''repeating-linear-gradient()''.)
2. Both the starting and ending gradient must have the same number of <>s. Note that one can pad a gradient with additional <>s placed atop each other, if necessary to make two gradients have the same number of <>s.) For this purpose, all repeating gradients are considered to have "infinite" color stops, and thus all repeating gradients match in this respect.

If the two gradients satisfy both of those constraints, they must be interpolated as described below. If not, they must be interpolated as a generic <>.

1. Convert both the start and end gradients to their explicit forms:

   For linear gradients:

   • If the direction is specified as an <>, it is already in its explicit form.
   • Otherwise, change its direction to an <> in [''0deg'',''360deg'') that would produce an equivalent rendering. If both the start and end gradients had their direction specified with keywords, and the absolute difference between the angles their directions mapped to is greater than 180deg, add 360deg to the direction of the gradient with the smaller angle. This ensures that a transition from, for example, "to left" (270deg) to "to top" (0deg) rotates the gradient a quarter-turn clockwise, as expected, rather than rotating three-quarters of a turn counter-clockwise.

   For radial gradients:

   • If the size is specified as two <>s or <>s, it is already in its explicit form.
   • Otherwise, the size must be changed to a pair of <>s that would produce an equivalent ending-shape. If the <> was specified as ''circle'', change it to ''ellipse''.

2. Interpolate each component and color-stop of the gradients independently. For linear gradients, the only component is the angle. For radial gradients, the components are the horizontal and vertical position of the center and the horizontal and vertical axis lengths.
3. To interpolate a color-stop, first match each color-stop in the start gradient to the corresponding color-stop at the same index in the end gradient. For repeating gradients, the first specified color-stop in the start and end gradients are considered to be at the same index, and all other color-stops following and preceding are indexed appropriately, repeating and shifting each gradient's list of color-stops as needed. Then, for each pair of color-stops, interpolate the position and color independently.

Serialization

This section describes the serialization of all new properties and value types introduced in this specification, for the purpose of interfacing with the CSS Object Model [[CSSOM]]. To serialize any function defined in this module, serialize it per its individual grammar, in the order its grammar is written in, omitting components when possible without changing the meaning, joining space-separated tokens with a single space, and following each serialized comma with a single space. For ''cross-fade()'', always serialize the <>.

For example, a gradient specified as:

Linear-Gradient( to bottom, red 0%,yellow,black 100px)

must serialize as:

linear-gradient(red, yellow, black 100px)

Changes since Images 3

• added ''x'' unit (or rather, put in an issue about adding it as a general alias for ''dppx'')
• restored the ltr/rtl keywords in image(), but in a different place
• added ''image-set()''
• re-added ''element()''
• re-added ''cross-fade()''
  • changed the syntax a bit to allow interesting things
• added issue for focus-moving to ''radial-gradient()''
• added ''conic-gradient()''
• added two-position syntax for color-stops
• allowed the color to be omitted from color-stops
• loosened the syntax for color-stops to allow color/length in either order
• added ''image-orientation:from-image''
• re-added 'image-rendering'
• added interpolation section
• added serialization section