On Sun, Oct 18, 2009 at 5:57 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
> I wasn't sure I understood ROC's idea, but it looks to me as though he is
> saying that "image-opacity()", for instance, would be an image value
> type,[1] alongside "url()" and proposals such as "linear-gradient". If so,
> then I see a couple more problems with it:
>
That's correct, although I'm not sure you've understood it...
4) You wouldn't be able to do "image-opacity()" and "image-rect()", for
> instance, on the same image.
>
Sure you would:
background-image: image-opacity(image-rect(url(foo.png), 0, 0, 100, 100),
0.3);
Functions are even more composable than individual properties, because you
can compose them to arbitrary depth, if need be.
5) It seem that you wouldn't be able to apply the effect to other image
> value types, such as the proposed "linear-gradient", "radial-gradient",
> sprites, or using 'image()' for fallbacks. Or at least not without making
> the notation extremely complex and hard to read (by a human, I mean), and
> kind of painful to animate (by a typist).
>
Sure you would:
background-image: image-opacity(linear-gradient(...), 0.3);
etc
Hard to read? Maybe, and maybe the syntax could be improved a little bit,
for example by moving the image to be the last parameter of these functions.
However, this function notation has been immensely popular in mathematics
and programming languages.
"But CSS isn't a programming language!" I hear you say. I say, when you want
to combine features in complicated ways, you're creating a programming
language whether you want to or not, and if you stop pretending it's not a
programming language and apply programming language design principles,
you'll get much better results.
Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]