Re: [css4-images] First draft of css4-images, feedback requested

> Perhaps we could move the annotations to the front of the function,
> and then let the image alternatives trail off the end?  Actually, this
> sounds like a pretty good idea.

So, you mean that instead of something like image("arrow.png" ltr,
"arrow.gif" ltr), it would be image(ltr "arrow.png", "arrow.gif")? That
sounds good to me.

(BTW, as far as I can see, the grammar given in the current doc does not
seem to include ltr/rtl.)

On Tue, Aug 7, 2012 at 11:29 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Tue, Aug 7, 2012 at 8:06 AM, Aharon (Vladimir) Lanin
> <aharon@google.com> wrote:
> > Regarding ltr/rtl, here are the comments from Kenny Lu and Andrew
> Fedoniouk
> > that caused the feature to be bumped to level 4. I guess this needs to be
> > discussed.
>
> Thanks for re-collecting them!
>
> > On Sat, Mar 10, 2012 at 3:34 PM, Kang-Hao (Kenny) Lu
> > <kennyluck@csail.mit.edu> wrote:
> >> I don't think there is a use case for specifying
> >> different modes (non-flipping, ltr, rtl) for different images in the
> >> fallback chain. The fact that the syntax allows this seems to indicate
> >> that this syntax is suboptimal, although I don't have better suggestion
> >> at the moment.
>
> Yeah, this is true.  Right now, you'd have to indicate the
> directionality on every url.  This is *theoretically* of use, but
> since the common case is intended to be just providing alternative
> versions of the same image, it's obviously non-optimal to force this.
>
> Perhaps we could move the annotations to the front of the function,
> and then let the image alternatives trail off the end?  Actually, this
> sounds like a pretty good idea.
>
> >> By the way, this draws analogy with @dir in HTML which might
> >> be the reason of this confusion because in HTML @dir defaults to ltr (in
> >> some sense) while the default is "non-flipping" here.
>
> I don't think this is a particularly huge issue.  Yeah, most text is
> inherently directional, but people are used to images being
> non-directional.
>
> > On Sat, Mar 10, 2012 at 3:54 PM, Andrew Fedoniouk
> > <news@terrainformatica.com> wrote:
> >> If so then "annotate an image with a directionality" phrase
> >> is misleading.
> >>
> >> For me annotation means act of assignment of some attribute.
> >> But not the act of transforming image pixels (flipped as you mentioned).
> >>
> >> In any case image transformations (filters of any kind) should be a
> >> subject of some other mechanism I think. There are many other
> >> things that AFAIR were already requested for images.
> >>
> >> Something like
> >> background-image-transformation: brightness(0.7) flip-x;
> >> background-image-transformation: flip-y;
> >> background-image-transformation: rotate(90deg);
> >> background-image-transformation: transparent(rgb(255,255,0));
> >> background-image-transformation: shadow(1,1,2px);
> >> etc.
> >>
> >> Such filters actually could be a part of the image() thing:
> >>
> >> image( a.png flip-x-if(rtl) )
> >> image( b.png flip-x-if(ltr) )
> >> image( c.png rotate-if(ttb,90deg) )
> >> image( d.png brightness(0.7) flip-x-if(rtl) )
> >>
> >> etc.
> >>
> >> I mean if we've started speaking about image transformations then
> >> we should use use syntax that is extendable.
>
> I would like to give some thought to an @image at-rule that gives us a
> nice, extensible way to do things like this, but I don't think it's
> required just for image directionality.
>
> ~TJ
>