Re: Responsive CSS3 Transitions

On Sun, Sep 2, 2012 at 11:37 PM, Greg Houston <gregory.houston@gmail.com> wrote:
> Last night I was modifying Joe Lambert's Flux Slider to be responsive.
> I ran into three issues I think could be related to in order to make
> this sort of work faster and have better results.
> http://greghoustondesign.com/sandbox/flux-slider/demo_transition_gallery.html
>
> 1. There doesn't seem to be a simple, elegant way to make a div keep
> its aspect ratio when resized. Being able to set the width of an
> element as a percentage of its height or set its height as a
> percentage of its width would be great, and particularly so if all it
> required was a simple short-hand:

We can't really do this the "direct" method of allowing you to set
height with a width unit, or vice versa, due to cyclic dependency
issues.  However, I have a draft for an aspect-ratio property at
<http://www.xanthir.com/blog/b4810> that will hopefully find its way
into a draft soonish.


> 2. If you slice up a div into smaller divs and add the same background
> to each slice as the parent and reposition that background
> appropriately, each background will still be the correct size to
> rebuild the original image from the slices. That is, unless you have
> resized the original container div and set the background-size to
> something like "auto 100%". That new background-size in pixels will
> not propagate down to the children, and so each child element now
> requires additional math to set the size of the background in relation
> to the size of the slice. It would be helpful if there was a CSS
> toggle that would make the exact size of the parent background
> propagate to the children.

I don't understand the problem you're outlining.  Can you link to a
concrete example?


> 3. I don't have a clear sense of what would be a good solution for
> this next issue, but its the most problematic that I ran into, and
> I've yet to come up with a workaround. It relates to halving the width
> or height of an element that doesn't have an even height or width. If
> you put two "halves" together where the whole dimension is an odd
> number there will generally be a 1px slice that is missing. The
> different UAs seem to relate to rounding differently

Unfortunately, we can't really specify rounding to any great
precision, for several reasons.

For one, different browsers use different amounts of precision in
their rendering.  Until recently, for example, Chrome was
whole-pixel-based.  (We briefly flirted with using floating point
values, but eventually settled on using 1/60th of a pixel, like
Firefox.)

For two, the details of how to round "well" are quite complicated.  If
you specify something naive like "<.5, round down, >=.5, round up",
you'll do badly when people try to do things like put 7 equal-sized
divs next to each other.  As well, for aesthetic reasons, browsers
typically try hard to keep borders on an element the same width, even
if they would fall on different rounding boundaries using the "normal"
algorithm for element sizes.

We're trying to solve this mostly by making new layout modes that are
friendly to smart rounding (like Flexbox), but there are still
fundamental limitations to trying to do pixel-perfect designs.  The
correct solution is to simply not do things that rely on pixel-perfect
positioning, unless you can manually ensure that all the sizes are
whole pixels and thus won't trigger any rounding at all.

~TJ

Received on Monday, 3 September 2012 19:13:33 UTC