- From: Adam Del Vecchio <adam.delvecchio@go-techo.com>
- Date: Thu, 29 Apr 2010 13:08:13 -0400
- To: "Alex Mogilevsky" <alexmog@microsoft.com>, "www-style@w3.org" <www-style@w3.org>
- Message-Id: <20100429170816.800354461@mx1.go-techo.com>
I disagree. I think possibly (at least some of) the box-* positions could be somehow combined into a single box: property, however I think incorporating them into display would make the display property do too much. However, I think display: flexbox; would have been better then display: box. I understand that I may be completly wrong with the above, I'm only 2 days into the list. Anyway, that's just my $0.02 -- Adam Del Vecchio (Mobile) President - Techo TechnologyOn 29 Apr 2010 9:10 a.m., Alex Mogilevsky <alexmog@microsoft.com> wrote: > -----Original Message----- > From: www-style-request@w3.org [mailto:www-style-request@w3.org] On > Sent: Monday, April 19, 2010 3:44 PM > > On Mon, Apr 19, 2010 at 3:18 PM, L. David Baron <dbaron@dbaron.org> > wrote: > > > 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. I actually don’t like at all the idea of using more display values instead of 'box-direction' and 'box-orient'. I really don't see why this is better. It seems generally harder to understand and it makes the most common cases look less elegant. And it does rely on assumption that 'display-inside' exists, and if that doesn’t happen this becomes really complicated. > >> 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. ^_^ I am still in favor of keeping 'display' values minimal, and having 'direction' and 'orient' separate. > >> 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. I tend to agree with Tab on this one. It actually should be 'before|after|middle'. > Multiple Lines > ============== > > Changed box-lines to box-wrap, to more accurately describe the mechanics > behind it, and to map the values more closely to the white-space property, > which is its closest analog in static flow. > Values are `normal` and `nowrap`, default of `nowrap`. (Not sure about > naming here.) 'box-wrap' is probably better then 'box-lines'. It seems wrong to have a value called 'normal' which is not the default though. It should just be 'box-wrap:nowrap|wrap' (default 'nowrap') > >> 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? 'box-break-before' is intuitive enough I think. It can be 'box-line-break-before' too. Or 'box-wrap-before'. \ > >> 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 think it would make sense to use start/end/before/after in terms of block-progression rather than box orientation. If it was that way, all four would have to apply to both box-align and box-pack, and a change of orientation without a change of alignment would have very different effect from what it does now.
Received on Thursday, 29 April 2010 17:08:54 UTC