W3C home > Mailing lists > Public > www-style@w3.org > August 2009

Re: Mirror as background property

From: James Elmore <James.Elmore@cox.net>
Date: Sat, 29 Aug 2009 13:40:06 -0700
Message-Id: <727D2BEE-173D-4199-BB48-B25000156A16@cox.net>
Cc: CSS <www-style@w3.org>
To: Tab Atkins Jr. <jackalmage@gmail.com>

On Aug 29, 2009, at 11:07 AM, Tab Atkins Jr. wrote:

> I've given this topic some more thought, and come up with two primary
> use-cases for this feature, plus a possible interesting hack (that
> should probably be addressed elsewhere, but would work with this).
> These use-cases have led me to a concrete proposal that I think
> introduces the minimal amount of complexity while remaining very
> useful.
> Use Case 1 - Symmetrical Gradients
> ----------------------------------
> In my linear-gradient proposal it became necessary to allow authors to
> mix unit types when specifying color-stops, particularly mixing
> lengths and percentages.  However, this also required adding rules to
> resolve positioning/ordering conflicts, and these rules make it
> difficult/impossible to ensure that a gradient intended to b
> left-right or top-bottom symmetrical remains so.  For example, the
> value "linear-gradient(left, blue 0, aqua 20px, white 20%, white 80%,
> aqua calc(100% - 20px), blue 100%)" produces a symmetrical image as
> long as the box is at least 100px wide, but as soon as it drops below
> that width things go wonky - for example, if the box is 80px wide the
> first aqua wins over the first white, and both sit at 20px, while the
> second white wins over the second aqua, and both sit at 64px (rather
> than 60px, which would be symmetrical).
> A mirror feature would allow you to guarantee that your gradient
> remains symmetrical at all sizes by just flipping whatever appears on
> the left half onto the right half.  Tangentially, it would also make
> symmetrical gradients much simpler to specify - you could write the
> above as just "linear-gradient(left, blue, aqua 20px, white 20%)" and
> let the mirroring take care of the right half completely.
> Use Case 2 - Top/Bottom or Left/Right Symmetrical Flair
> -------------------------------------------------------
> When creating a page like a blog post or similar, it's fairly common
> to have some short, wide image 'framing' the top.  This might be a
> fleur-de-lis, vines, or just stylized curves.  This is easily done
> just by specifying it as a background and a bit of padding-top to keep
> the text away.  However, it may also be desirable to have the image
> vertically flipped and present at the bottom of the article, enclosing
> the text.  Currently this is only possible by using a wrapper element
> to hold the additional background, but in the future we'll be able to
> rely on multiple-backgrounds or border-image to style this properly.
> However, neither of these are ideal.  Border-image is overly complex
> for such a simple case, and multiple backgrounds just suck in general
> (they're the least bad solution to the general problem) and require
> you to create and manage two separate images.
> A mirror feature would make this trivial.  Specify a single
> background, mirror it, and apply proper padding to top and bottom.
> This would work similarly for a symmetrical left/right image flanking
> an article.
> Maybe Use Case? - Turn a gradient into an arrow
> -----------------------------------------------
> Using an angle gradient and mirroring it can produce an interesting
> 'arrow' effect pointing in any direction.  Ideally this would be
> produced by a diamond gradient, either in SVG or specified as some
> variant of radial-gradient, but this would be a fairly easy way to
> produce the effect.
> Actual Proposal
> ===============
> I propose a new background-* property, background-mirror, which takes
> the values "mirror-left", "mirror-right", "mirror-top",
> "mirror-bottom", and "no-mirror".  It defaults to "no-mirror", and
> will be set to that value if unspecified in the background shorthand
> property.

Three comments:

     First, does "mirror-left" mirror FROM the left half onto the  
right or does it mirror from the right half ONTO the left. Similarly  
with right, top, and bottom. This can be resolved with a simple rule,  
but how can users remember it simply? (I still have trouble  
remembering that wind blows FROM the wind direction, so perhaps I am  
a bad example.)

     Second, since the name of the property is 'background-mirror'  
why not name the values 'left,' 'right,' 'top,' and 'bottom'? That  
allows the use of 'none' for the default state, which seems cleaner  
to me.

     Third, does the property allow multiple values? If not, how can  
a user convert a 45degree linear gradient into a diamond gradient? I  
would think mirroring right, then bottom, or whatever. Is this  
possible? I think it should be.

> The effect of this property is to divide the *box* (not the image) in
> half either vertically (mirror-left and mirror-right) or horizontally
> (mirror-top and mirror-bottom), then take the entire image in the
> specified half of the current background layer and mirror it to the
> other side.  So, for example, specifying mirror-left will split the
> box vertically down the center, take the entire background layer on
> the left half, and mirror it onto the right half.  "no-mirror" applies
> no mirroring.

How would a user perform mirroring if the reflection point were not  
at the center of the box? (Either top-to-bottom or left-to-right?)  
One of the use cases presented in the gradient discussion was  
mirroring, then tiling, to make a smooth background. Would it be  
necessary to insert a transparent box (<div>?) and size it, then tile  
that? And, since the box is in the foreground, how can it be  

I like the idea of this property, but would like to see more  
control / flexibility in its use.

> In the rendering chain for backgrounds, this property is applied last,
> after the background is sized, positioned, repeated, and otherwise
> specified.

Why not apply it before repetition, but after sizing and positioning?  
That handles some of the problems mentioned above? (Of course, you  
probably already have a very good reason which I have not considered.)

> Thoughts?
> ~TJ

Received on Saturday, 29 August 2009 20:40:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:38 UTC