Re: Responsive CSS3 Transitions

On Mon, Sep 3, 2012 at 2:12 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Sun, Sep 2, 2012 at 11:37 PM, Greg Houston <gregory.houston@gmail.com> wrote:
>> 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.

That works.

>> 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?

http://greghoustondesign.com/sandbox/background-size/

>> 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.

That's disappointing. I'll have to give this some more thought and
maybe reply again, though I think some sort of intelligent
background-bleed might be helpful for some use cases or even allowing
the designer to control the rounding.

.container:nth-child(even) { width: 50% roundUp; }
.container:nth-child(odd) { width: 50% roundDown; }

Actually that works a lot better than my background-bleed idea. I
could fix my turn transition so it worked flawlessly if I had control
over the rounding.

Received on Tuesday, 4 September 2012 01:07:06 UTC