Syntax for image-pattern support in CSS
james.graham at oracle.com
Fri Aug 31 18:52:47 PDT 2012
Where is the origin for the repeating case?
The internal object takes either proportional values - which are also
implicitly relative to the location of the shape - or it takes absolute
values - which need to be adjusted to match the location of any given shape.
So, you can define the repeating version as anchored at 0,0,imgw,imgh
but that means that it has a fixed location relative to the origin of
the local coordinate system, not relative to the shape's location. If
you translate the shape then it will carry the tiling along with it, but
if you move the location of the shape, then it will slide across the
tiling (like watching cartoons of chameleons walking over a patterned
It seems that perhaps for ImagePattern we should have both "truly
proportional" and "shape location relative"?
where any of x,y,w,h can be percentages.
Tiling from transform origin would be "(uri)" or "(uri,0,0)"
Tiling from shape corner would be "(uri,0%,0%)"
Tiling from shape center would be "(uri,50%,50%)"
Tiling with transform-relative positioning would be "(uri,10,10,100,100)"
Tiling with shape-relative positioning and fixed size would be
Tiling with complete proportional semantics would be "(uri,10%,10%,50%,50%)"
Unfortunately, the fx.scene.ImagePattern API object would need an
overhaul to support any of this (though it doesn't necessarily have to
support everything that CSS supports, but it would be nice), as would
the internal support which currently only offers "all 4 values
TX-relative" or "all 4 values shape-bounds-relative" support.
Is that overkill?
On 8/31/12 3:36 PM, Richard Bair wrote:
> Never mind me, it has been a long day :-). Of course the repeating-image-pattern function solves my problem. So I will simply do:
> In the case of image-pattern, the uri-string is mandatory, and we default to 0%, 0%, 100%, 100%, true (just like the constructor). You can just specify the numbers and not bother with the boolean if you want. You only have to specify the boolean if you need to specify the numbers and have it not be proportional.
> For the tiling case, just use repeating-image-pattern and be happy.
> Seems great.
> On Aug 31, 2012, at 3:25 PM, Richard Bair wrote:
>> Sounds good, I am updating the parser. It does irritate me that proportional is true by default, just because it means that the tiling case (probably the most common case) requires the long form. I wouldn't want the inconsistency from CSS to constructors though. What bothers me is that giving the anchor meaning is kind of unnecessary most of the time, because all you want to do is have the image at its intrinsic width/height tiled. But you have to hard code sizes in this call in CSS, don't you?
>> As far percent, I agree that would be nicer than 0-1. However, I'm not sure how to make it sensible with that final boolean. I could just say that 0% == 0, and 100% == 1. The final boolean could be optional since it defaults to true. You have to specify the long form if you want it to tile. Irritating, but not the end of the world.
>> On Aug 31, 2012, at 6:15 AM, David Grieve wrote:
>>> Instead of url, I'd prefer both be image-pattern, since ImagePattern has a ctor taking just the image. Syntax would be
>>> which, as you mention, maps 1-1 onto ImagePattern. The problem here, though, is how to get tiling without knowing the size of the image since the ImagePattern default is stretch. You propose a url syntax. Will people be confused by this? I suggest a function
>>> which gets you the repeat. This is unambiguous and follows what W3C does for gradients (e.g., repeating-radial-gradient).
>>> On Aug 30, 2012, at 9:20 PM, Richard Bair wrote:
>>>> Anywhere a Paint is allowed:
>>>> image-pattern('region/test20x20.png', 0, 0, 1, 1, true);
>>>> The syntax is exactly the same as our ImagePattern class. I rather chose the rgb() style function rather than linear, radial gradient style named parameters both because it was less work and less syntax to define, and because there aren't many params and I thought I'd just map directly to the class. I could have tried giving percentage based value support (percent of what? The image, the dest?) but I decided to just stick with plain numbers. Most of the time people will either just use the url version and get tiling for free, or they will use the image-pattern version and get it stretched (as I've done here). Or they can do whatever with the image-pattern version.
>>>> What do you think?
>>>> (I'm attacking this issue right now, incidentally, because I'm working on numerous Region performance and behavior issues, and in my travels I noticed some very useful rendering modes are not supported currently with respect to images, so I thought I would round it all out while I was in the code).
>>> David Grieve | Principal Member of Technical Staff
>>> Mobile: +16033121013
>>> Oracle Java Client UI and Tools
>>> Durham, NH 03824
>>> <green-for-email-sig_0.gif> Oracle is committed to developing practices and products that help protect the environment
More information about the openjfx-dev