- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Thu, 15 Oct 2015 23:25:17 -0700
- To: Florian Rivoal <florian@rivoal.net>
- Cc: Jihye Hong <jh.hong@lge.com>, www-style@w3.org
Sent from my iPad On Oct 15, 2015, at 10:21 PM, Florian Rivoal <florian@rivoal.net> wrote: >> >> On 16 Oct 2015, at 07:51, Brad Kemper <brad.kemper@gmail.com> wrote: >> >> >> >> >> Brad Kemper >> >> On Oct 15, 2015, at 12:59 AM, Jihye Hong <jh.hong@lge.com> wrote: >> >>>> On Oct 9, 2015, at 10:44 AM, Brad Kemper <brad.kemper@gmail.com> wrote: >>>> >>>> What I suggested was: don't make 'polar' a separate value of 'position'. >>> Instead, let >>>> 'polar-angle' and 'polar-distance' combine with positions absolute, fixed, >>> and relative, >>>> in the same way that left, right, top, and bottom do. The effects of left, >>> right, top, bottom, >>>> polar-angle, and polar-distance would be cumulative, so if you wanted a >>> horizontal or vertical >>>> offset, you would usually use 'top' and 'left' for that. >>> >>> We also had considered about the method similar to your suggestion. >>> But, I'm not sure that the coordination system is decided by the >>> polar-related properties not by the position: polar. >> >> I'm suggesting it could be. >> >>> When using position: polar, we clearly know that the element is positioned >>> based on the center point of the containing block. >> >> I guess what I am suggesting is that if the value of 'polar-distance' is anything other than 'auto', then the element is positioned based on the center point of the containing block. > > If I am following you correctly, if polar-distance is anything other than auto on an absolutely (or fixed) positioned element, then it is positioned from the center of the containing block. But if it is on a relatively positioned element, then it would be from where the center of the element would have been if statically positioned (or equivalently relatively positioned with top/left/bottom/right left to their initial value). Yes. Good point. > And on a statically positioned element, it does nothing (just like top/right/bottom/left). > > Right? Right. > That makes sense to me with polar-distance as a length, Great! > but I seems that percentage polar distances would only makes sense when used with absolutely/fixed positioned element, not with relative, so we'd probably have to make them the same as 0 in that case. Which is probably fine. Or did you mean something else? Hmm. I hadn't given that much thought. I would expect it to be consistent with top, right, bottom, left, which apparently use percentages the same way as absolutely positioning, as a percentage of the containing block (although I've never personally needed to use rel-pos that way). So I guess I'd measure what the polar-distance would be if it was abs-pos, and then move it that much. But that's more of a "purity" consideration than a practical one, from where I stand. Otherwise I don't feel strongly about it yet. >> (Alternative proposal: if the value of 'polar-angle' is anything other than 'auto', then the element is positioned based on the center point of the containing block.) > > Makes more sense to me with polar-distance than with polar-angle. Yes, it feels a little more natural to me that way too. >> So it is still being determined by a value, but on a different property than what the draft says. >> >> Or... introduce 'center' as another property, so that 'center: 50%' would center an element. > > That sounds more confusing, and not obviously more useful. Does it? OK. Well, it would be useful in general to be able to abs-pos center an element, or even just position an element anywhere by the center of the element, instead of by the edges. And even to have 'center' be a shorthand for 'center-x' and 'center-y' (or logical equivalent). So this is really a whole other thing, but if we had it, then it would fit nice with the idea of then applying 'polar-*' measurements (and maybe trbl measurements too) from that point without further need for a way to measure coordinates from the center. I realize this would expand the scope of what this spec is trying to accomplish. But I think it would be pretty useful beyond round displays in a way that still works well with round displays.
Received on Friday, 16 October 2015 06:28:28 UTC