- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 19 Apr 2010 15:44:02 -0700
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: www-style list <www-style@w3.org>
On Mon, Apr 19, 2010 at 3:18 PM, L. David Baron <dbaron@dbaron.org> wrote: > Sorry for not responding to the various flexbox threads last week; I > was on vacation last week and I'm still catching up. No problem! > On Monday 2010-04-19 14:35 -0700, Tab Atkins Jr. wrote: >> Flex-inline and flex-block are based on the block progression >> direction and the writing-mode, and map to one of the first four >> values. > > It seems clearer to say they're based on the inline progression > direction and the block progression direction. Sure. >> Default is flex-right (equivalent to current draft's >> box-orient:horizontal;box-direction:normal;). > > Shouldn't it be flex-inline to correspond to the current draft? At > least in Gecko's implementation, the direction of box-orient: > horizontal boxes is influenced by both 'direction' and > 'box-direction'. Gah, right. Somehow got mixed up and thought the default was "horizontal" in the current draft. >> Display Order >> ============= >> >> box-direction is dropped for now. It seems to be clearer to specify >> the direction of flow directly in the display value. I don't *think* >> that we've lost anything by this. > > I presume you're also proposing to drop box-orient. Yes. Sorry, I dropped that in my head so long ago I forgot that I needed to call it out. ^_^ >> box-align has its start/end values renamed to before/after. It was >> necessary to change one of these two properties; you can't have start >> and end referring to perpendicular directions. I chose box-align to >> be changed so that the mapping makes the most sense for the default >> values - before/after act like top/bottom by default, and start/end on >> box-pack act like left/right by default, just like they would in a >> page with normal english text. > > I think this might cause more confusion than it fixes. Really? I find it sort of confusing that start/end, which are typically used in the context of text direction, would be used to refer to perpendicular directions here. It's possible that names other than start/end/before/after would be more appropriate, but the layout of a flexbox is generally similar to the layout of text on a line, so that seemed the most natural to me. At the very least, though, I'd want different words for the align and pack directions. >> Added box-clear property, which takes `start` and `end` values. >> box-clear forces a linebreak in a flexbox, regardless of the box-wrap >> value. `start` pushes the element onto a new line, `end` pushes the >> *next* element onto a new line. Ordinary line-wrapping takes place >> after box-clearing happens (that is, first we do all the explicit >> linebreaking caused by box-clear, then, if box-wrap is normal, we >> check if any line is long enough to need wrapping). > > These feel to me much more similar to *-break-before/after than to > clear. I'm a little skeptical of the use of the "clear" name. Yeah, the concepts are similar. It's possible to use a *-break-before/after concept instead. It would just require an appropriate name. line-break-before/after? Using this set of concepts instead of the "clear" concept would allow us to drop the box-wrap property, too. The default value for both properties would just be "never", producing the standard single-line form. You can cause wrapping by setting "auto" on all the children of a flexbox, and "always" to produce explicit breaks. >> What's left >> =========== >> >> There is a pending question concerning what the best directions for >> start/end/before/after to map to is, depending on the display value. >> Currently, here are my thoughts: >> >> right: before is top, start is left >> down: before is left, start is top >> left: before is top, start is right >> up: before is left, start is bottom >> inline: before and start are equivalent to whatever the writing-mode >> says they are >> block: like inline, but before and start are swapped > > I think start/end/before/after should depend on the block and inline > progression directions and not the box direction/orientation. (I'm > thinking of things like margin-start/end/before/after. Are you > thinking about some other use of these names?) No, I'm thinking of the same use of the names. I'd like a physical-direction-agnostic name for the directions, though, to make it simpler to talk about. The current draft just explicitly talks about both horizontal and vertical every time (well, it skips vertical a lot, but it *could* talk about both all the time) and then explicitly talks about what to do when box-direction:reverse is specified. I don't particularly want to invent a *third* set of directional words, though. If using start/end/before/after is too confusing, we can just explicitly lay out every case in the draft, like the current draft does. ~TJ
Received on Monday, 19 April 2010 22:44:55 UTC