- From: David Singer <singer@apple.com>
- Date: Mon, 29 Nov 2010 16:27:07 -0800
- To: Tab Atkins Jr. <jackalmage@gmail.com>
- Cc: www-style list <www-style@w3.org>
On Nov 29, 2010, at 14:34 , Tab Atkins Jr. wrote: > On Mon, Nov 29, 2010 at 11:50 AM, David Singer <singer@apple.com> wrote: >> On Nov 23, 2010, at 13:14 , Tab Atkins Jr. wrote: >>> The latter may be sufficient to pronounce this "not a problem", but >>> the extra function is just kind of gratuitous, especially if you're >>> already using one of the color functions - "image(rgba(0,0,0,.5))" >>> looks uglier than necessary. >>> >> >> shouldn't anything that claims to be making an image (like image() here) be able to provide all its characteristics, including its dimensions? Isn't this one of the ways an image constructor differs from a color constructor? > > Images don't always have dimensions. They can have any, all, or none > of an intrinsic width, height, or aspect-ratio. And that's okay. > Gradients don't have any dimensions, and SVG can have any of the valid > combinations. > > Imo, colors most naturally convert into a dimensionless image. I think a gradient has to have dimensions, or we don't know what we're grading over. So I think it's fine to say that something has intrinsic dimensions, or is dimensioned to fit into something else, and indeed the gradient discussions have had a lot on how you determine the end-points (and the effective side-extension perpendicular to the gradient), which are the dimensions. But I think we would have a problem if we say "size this doofer to fit its contents" and the contents in turn say "size me to fit my container" :-). David Singer Multimedia and Software Standards, Apple Inc.
Received on Tuesday, 30 November 2010 00:27:40 UTC