- From: Greg Houston <gregory.houston@gmail.com>
- Date: Mon, 3 Sep 2012 20:06:37 -0500
- 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? 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