W3C home > Mailing lists > Public > www-style@w3.org > September 2012

Re: Responsive CSS3 Transitions

From: Greg Houston <gregory.houston@gmail.com>
Date: Mon, 3 Sep 2012 20:06:37 -0500
Message-ID: <CAOtq01D969c9oGZ5ATKCmQWb9U-AM70ATBGWboUbUn41tajGXg@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: W3C Style <www-style@w3.org>
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?


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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:03 UTC