- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 13 Feb 2012 18:29:57 +0100
- To: "www-style@w3.org" <www-style@w3.org>
Flexbox
-------
- Discussed switching 'flex()' notation back to a 'flex' property
- Discussed using margins for alignment in place of or in conjunction
with flex-item-align
CSS3 Line Layout
----------------
Steve Zilles presented a proposal for the scoping of the CSS3 Line Layout
module (which needs significant rewriting since the previous publication).
Scope would include
- line processing model
- defining line layout from 2.1 with more precision
- choosing baselines to use for alignment
- line grid proposal from Kyoto F2F
- possibly other stuff
====== Full minutes below ======
Flexbox
-------
Scribe: fantasai
Tab: We have a few issues that are not big or controversial, just
Alex and I disagree.
<alexmog> http://wiki.csswg.org/spec/css3-flexbox#open-issues
Tab: Two open issues: 18 and 19, and a third one raised by fantasai
Tab: Issue 18
Tab: Right now, in current flexbox as written, auto margins resolve to zero
Tab: if you want to align things, you use flex-pack or flex-align
Tab: In my old proposal auto margins flexed
Tab: Alex prefers having margins flex in cross axis
Tab: And alignment property is fallback
Tab: If both are auto, center it. If one is auto, align to other side
Alex: flex-item-align is somewhat redundant with aligning with margins
Alex: Most things that can be done with alignment can be done with
flexible margins
Tab: Right. I dropped that idea because of baseline alignment
Alex: If choice is between margin alignment and a separate property,
separate property is better because it easier to understand,
and it does support baseline alignment, which margins wouldn't
Alex: The concern I have for not doing margin alignment is that in
situations where margin alignment works, it is already a
well-understood way to align things.
Alex: if you take normal block flow and change to vertical flexbox,
you will get the same behavior: won't get surprises
Alex: There is also not really any contradiction in using margins
Alex: Flexbox can insist that auto margins resolve to zero, but it
doesn't have to.
Alex: So if both flexbox code and margin code, no special code added,
it will just work.
Alex: Setting auto margins to zero seems artificial: no good reason
to do it.
Tab: So, auto margins being flexible or zero.
fantasai: Note that zero is the default, so you have to explicitly ask
for auto to get the flex behavior.
dbaron: I tend to prefer flexible, though I think auto is confusing a
keyword
fantasai: I prefer flex over zero as well
Alex: There was another option that we briefly discussed, that centering
and aligning things using flexbox alignment properties does true
center and does start-end alignment regardless of overflow
Alex: overflow will still be end alignment
Alex: Margin alignment however should be do what margins do in normal
flow: If overflow happens, margin: auto should not result in true
centering, should just set those margins to zero and apply
whatever alignment
Tab: Basically, use auto-resolution rules from block
Alex: I kindof like that approach even though we have three ways to
align an item. They're all consistent. Margins are consistent
with margins everywhere, and box properties consistent with each
other, and there are no conflicts in flexbox algorithm.
Tab: So we have 2 people for flexible auto margins. Anybody think auto
margins should resolve to zero?
Rossen: Why do you want them to be zero?
Tab: Simpler, don't have another way of doing alignment.
Tab: It's not problematic, it's just an extra thing.
dbaron: Is there an existing mechanism that acts on the item individually?
Tab: flex-item-align property
dbaron: I guess I'd lean towards making auto margins zero.
Bert: This looks a lot like vertical-align, so why not use vertical align?
Tab: The name is confusing.
Alex: There is more to it including grid consistency.
Bert: This is specific to flex, but in grid we also have alignment.
Bert: And then we have table alignment.
Bert: If they all use different properties, it might be too much.
fantasai: flex-item-align exists because of baseline alignment, right? ...
I think we can get away with not having a separate property.
fantasai: need to think about it
Alex: baseline alignment per item isn't particularly useful
Alex: You can set flex-align to baseline, and then use margins to change
anything you want not baseline-aligned
Tab: You can't mix stretch and baseline then
... some confusing discussion ...
Alex: I think the situation of some items being baseline-aligned and
others being stretched is kindof rare.
Alex: So if that's the only reason to have an extra property, it's not
worth it.
* fantasai agrees with Alex
Tab: If we use margins for alignment, still have issue of consistency
with blocks vs. true centering
fantasai: If you have flex-align, you can do true centering. Just can't
mix it with baseline.
Tab: But I want that for [toolbar example?]
fantasai: I think the three of us should get in a room and figure it out.
Tab: Response so far seems to indicate that group has no opinion.
Tab: Next topic. Flex function
Tab: Right now you set flex() on either 'width' or 'height'.
Tab: This has the downside that flex() is only valid width or height,
depending on orientation of the flexbox.
Alex: Before I would start describing why flex() is bad, I would say
that it doesn't have to be a function to begin with.
Tab: Getting to that.
Tab: If you, for whatever reason, change the orientation, you have to
switch which property you set it on.
Alex: And you have to store it on both properties.
Tab: Alex instead suggests a separate property that indicates the flex
in whichever dimension is appropriate
Alex: I would be fine with either flex property with same value, or flex
property that just gives flexibility and use width/height as
preferred size
fantasai: Ahhh, I can see that there's a problem either way you go there.
fantasai: If you want preferred width as zero, because you want just flex,
then you don't want that stored in 'width' because when you
remove flexibility you get something nonsensical
fantasai: But if you set preferred width to your actual preferred width,
then you do want that stored in 'width' because when you remove
flexibility you want to get that size.
Alex: Other problem with flex function is you can't set flex separately
from width or height.
Alex: Seems to be a completely reasonable thing to do
Alex: Everywhere else this would have been a separate property
Alex: Hard to work with the functional notation.
Alex: And you cannot cascade flex separately from preferred size
Alex: And animations would be really difficult to apply to flex function
fantasai: animate from flex 1 to flex 2?
Tab: No problem. But animating from no flex to flex is a problem. But a
separate issue than this.
Alex: my preferred solution would be to have a flex property with three
values. Fine with having preferred size there.
Alex: For implementation it is redundant.
fantasai: But then you don't get your separate cascading.
Alex: Have sub-properties.
fantasai: I don't think positive and negative flex need to cascade separately.
Do you?
Tab: No...
fantasai: I think they should stay one property. If the issue is ease of OM
access, that's a separate issue that we need to solve globally.
fantasai: I think the only thing you need is one property with positive and
negative flex and a switch for using 'width'/'height' as preferred
size or using zero.
nobody else seem to care
discussion of stabilizing spec
Alex: fantasai's condition for moving to LC was that dbaron reviews and
approves the spec
dbaron: Would prefer if feature design would stabilize before moving to LC
Alex: These issues are coming up as a result of me implementing the spec.
Bert: Have a question.
Bert: Flex seems very similar to fr unit in Grid. Can't you use one or the
other?
Tab: I think grid is planning to move to flex()
Tab: Can't use fr unit because we need a triplet for flex: preferred size,
positive flex, and negative flex.
Tab: fr unit only provides one of those.
Alex: We had that as a unit at some point in Flexbox
Tab: But replaced it with e.g. flex(1)
Tab: So Grid was planning to move to flex() function. But we no longer have
a flex() function anymore.
Alex: Would be weird to remove fr in favor of flex()
Tab: Primary need of flex() function was to establish minimum for flexing
Tab: For grid. You needed a minimum size for columns. But you have the
minmax() function
Alex: ...
Tab: Using just the fr unit is too weak, because I want to say this column
is ... with minmax() a lot of function of flex() is subsumed
Tab: So fr unit is okay. probably don't need flex function there.
Bert: Does the flex property apply to tables, too? To <col> element for example?
fantasai: what happened to the multi-length unit for tables? I remember
it was implemented, because I wrote tests for it.
dbaron: I removed it at some point.
dbaron: What the spec said it was supposed to do was same as percentages
Tab: When someone defines table layout, we can figure it out at that point.
[discussion of how undefined table layout is]
Tab: Anyone else have any comments on flexbox?
fantasai: Process is, the three of us get to the point where we can't find
any more issues. Then we give it to dbaron. If he can't find any
issues, then we go to LC.
Bert: Are you replacing flex() with one or two properties?
Alex: Only one. Because there's only flex in one dimension.
Bert: What about grid?
Alex: ...
Bert: I'm specifically thinking about andrew fedoniouk made
Bert: He did grid and flex together, and came up with a 2D flex model
Tab: You can do a flex grid. But it's not the same thing as the grid layout
module that we're talking about.
Alex: Flexbox has a lot of details not applicable to grid.
fantasai: Should think about 2D flexible layout, if we do that we'd need
flex in 2 dimensions.
Tab: Can you link to Andrew's model?
<Bert> -> http://www.terrainformatica.com/w3/flex-layout/flex-layout.htm
documentation of Andrew Fedoniouk's grid/flex combo (see last
para of section 3.5)
fantasai: Anton and I were suggesting that instead of calling the container
a "flexbox" and the children "flexbox items", we should call the
the boxes that actually flex "flexboxes" and call the container a
"flex container" to be consistent with how we use terminology
elsewhere, like blocks and block containers.
fantasai: To make the 'display' value consistent with this, we suggest
"display: flex" and "display: inline-flex"
Anton: I'm not won over by 'display: flex', but can't think of anything better.
dbaron: I think making display:flex make something a flexbox container is
confusing
Alex: This is the first I hear about this, so let's discuss this first.
* sylvaing renaming -> www-bikeshed mailing list
Line Module
-----------
Steve posts slides
"CSS Line Module Processing Model"
Steve: Sent a message to the mailing list
<dbaron> http://lists.w3.org/Archives/Public/www-style/2012Feb/0238.html
Steve: Basically talking about a processing model for line module
Steve: At November F2F we agreed jdaggett and I would edit Line module
Steve: And to incorporate line grid material into it
Steve: Because line module talks about alignment
Steve: To begin that process, wanted to get agreement on what the processing
model is for the line module
Steve: Then have a slide about next steps.
Steve: So this is not quite the model I put out in the message to the
list because dbaron looked at it and commented, so I tried to
incorporate dbaron's comments.
Steve: Basically, what happens is that with one small exception, you can
largely do line breaking and justification prior to doing alignment
Steve: It's presumed that's what the Text module is describing.
Steve: This is describing alignment within that.
Steve: So once I've got a line, then I have to adjust each component of
the line relative to its parent
Steve: based on alignment points, leading, and other things don't want
to get into.
Steve: Having done that, then compute height of line, size of line box.
Steve: Two ways of taking that line box and putting it on to the current
flow in the block direction.
Steve: If there is no line grid, no alignment to the line grid, then we
just stack the top of the new line box at bottom of previous.
Steve: Relatively straightforward.
Steve: If there is a line grid, then some baseline in the line box is
aligned to some baseline in the line grid.
howcome thinks the word 'table' in there is confusing
Steve: After I define the line height, I might have things that collide
with floats.
Alan: That will require you to recalculate the width
dbaron: If you're laying out lines within a space like this
*draws two lines denoting sides of containing block*
dbaron: If you have floats like this
*draws narrow float and fat float below it*
dbaron: If the height of the line or its position winds up with the
bottom of the line here, you're fine.
dbaron: But if the bottom of the line ends up here
*draws line adjacent to fat float*
then you have to shorten the line and redo line breaking
dbaron: We should stick to rule that once you shorten it, you don't
lengthen it again.
dbaron draws "this is some <big>TEXT</big>"
dbaron draws "this is some" onto the line, and "TEXT" onto a next line.
dbaron: It would fit horizontally, but it would make the line tall
enough to intersect the fat float, which would make it no
longer fit.
http://lists.w3.org/Archives/Public/www-archive/2012Feb/att-0012/dsc03591-dbaron-drawing-on-linebox.jpg
dbaron: Not sure we define what happens in this case.
<Bert> (Re the <big>TEXT</big> example: You might instead make an
earlier line a little longer or shorter.)
"Baseline Tables"
Steve: It basically notes that you have different alignment points
for different scripts. Latin typically alphabetically. Some
northern Indic scripts to hanging baseline. Ideographic to
ideographic baseline, which is usually the text-after-edge
Steve: So the current vertical-align property doesn't really deal
with that, so one of the other tasks the line module took
was to come up with a reasonable set of properties that give
you control over vertical-align, allowing for different
baseline tables.
Steve: Few complications to it. In particular, there's a notion
called 'dominant baseline', e.g. if you put Latin text in
Japanese document, the dominant baseline would be ideographic.
But Chinese text in English document, dominant baseline is
alphabetic.
Steve: Matters because baseline tables are different by font
Steve: The last complication is that I define what alignment is for
a given font size and dominant baseline, but there are certain
baseliens you can align to that don't come from the font.
Steve: text-top and text-bottom, which come from leading,
Steve: and bottom and top, which are even messier.
Steve: algorithm in 2.1
Steve: Collection of alignment points I have to deal with, some computed
as a result of laying out the lines.
howcome: Statement of different baselines having different baseline
tables doesn't make sense to me.
some explanation of baseline tables
most fonts have one baseline table
but some fonts have multiple baseline tables: you choose a different
one depending on your dominant baseline
howcome: CSS shouldn't have to say what the dominant script is
Steve: there are defaults, and it is automatically specified
jdaggett: That's a detail we don't need to depend on right now.
howcome: If we have to deal with it we have to deal with multiple baselines.
howcome: we use the term 'baseline' in vertical-align, but don't specify
which one.
fantasai explains dominant baselines and how they're used for alignment
See http://www.w3.org/TR/css3-writing-modes/#baseline-alignment
dbaron: based on what Steve was saying, this is what I imagine is an example
dbaron: You were talking about different sets of baseline tables, I was
imagining perhaps Chinese text within English aligning different
from English text within Chinese.
dbaron: Here, ideographic baseline matches alphabetic, because alphabetic
is dominant
dbaron: Whereas here the Latin is centered between the top and bottom of
the ideographic characters because Chinese is dominant and you
want to fit everything within the embox
Steve: That's somewhat exaggerated, but yes.
http://lists.w3.org/Archives/Public/www-archive/2012Feb/att-0012/dsc03592-dbaron-drawing-on-multiple-baseline-tables.jpg
howcome: I'd like to add my use case
howcome: In a multicol element...
Steve: Haven't gotten to line grids yet.
Steve: So that's what baseline tables are about.
Steve: Concerns I have --
Steve: determining top and bottom of baselines. It is in 2.1 except 2.1
is underspecified intentionally
Steve: I see as a goal of this effort is trying to come up with a reasonable
definition, because if we don't, we will never be able to do the
line grid
jdaggett: It would be good to interact with type design community to [...]
to get a consistent platform. Right now we cannot, for a given
font, which of several different metrics are given, we currently
specified one or the other because there's disagreement about
which one should be used.
ChrisL: Platforms disagree on which set of metrics to use.
Steve: Ascenders and descenders are an example
Steve: Last point is, it's been noted that good typography doesn't put
half-leading at the top of the box.
fantasai: or the bottom, if there's a border or anything you can see
jdaggett: So having some way of being able to say you'd like that behavior
seems desirable
fantasai: This is complicated by the fact that two paragraphs after each
other, if you turn off half leading at the top (and/or bottom)
you will have not enough space between the two
dbaron explains this situation further
dbaron: It's in the minutes from the Kyoto meeting.
<dbaron> Basically, that CSS lacks a distinction between blocks that
establish frames and blocks that just have line breaks
<dbaron> and we need the interline spacing at block boundaries for things
that aren't frames (with the half-leading at the edges of each
of the blocks)
<dbaron> but that when we're in a block that happens to be at the edge
of a frame we don't want that interline spacing
Steve: So, I treat that as a goal.
Florian: I think we should deal with the more critical things first.
Steve: That's why I treat it as a goal.
Steve: Okay, line grids
Steve: This example is taken from the line grid spec
Steve: Points out what the key goal of the line grid spec is
Steve: If you have, as seen in this multicol, you'd like to ensure that
the body text lines up across the columns.
Steve: So you could get interrupted by a figure
Steve: or text in a different size
Steve: But it should resynchronize at the next point
jdaggett: We're using line grids in a couple different contexts.
jdaggett: In this case seems you're really arguing for line boxes are
spaced at integral...
howcome: It's a discrete unit.
jdaggett: There's a concept of aligning this thing with other thing.
jdaggett: Multi-column case is different, because you want integral amount
of space.
Alan: In the multicol case it's still a grid, it's just something achievable
if you can control the other line heights (points at images, headings)
chrisL: The heading, e.g. , is not snapped to the grid.
Steve: Key thing is within the line grid spec, talks about a constant rhythm.
jdaggett: There are cases where the metrics of the font will tell you that
the line box has grown
jdaggett: Want to achieve where things like subscripts leaking out of the
line box but not colliding with anything don't interrupt the rhythm
Steve: Similarly to my topics of concern of alignment, some concerns for line
grid
Steve: Idea is that for a container, typically a page, I would define a
current font font-size and line-height, and that would determine
spacing used for that container
Steve: Question is, to what do I align in that?
Steve: I need a table of baselines for each of the slots that I needed
Steve: I can have for example columns where the left column is in English,
right column is in Hindi
Steve: They want to align up to the rhythm, but the alignment points are
different for each of them
fantasai notes this is already covered by line-grid proposal
...
Florian: Are you discussing what fantasai proposed in Kyoto? something
else? the problem space? how that proposal fits into the problem
space?
Steve: Hopefully.
Steve: So, I left this as a question...
Steve: Can I always just align the dominant baseline in the line, because
all other lines are aligned to dominant baseline
Steve: That depends on computing dominant baseline in the line, which you
can't do today
Steve: Then, if I go back, if I look at these headings and images (image
taken from line-grid)
Steve: If there are chunks that don't align to grid, but want to placed
within an integral number of line units
Steve: Question is what do I do with the extra space?
Steve: Could top bottom or center it
Steve: Bert pointed out TeX has a nice feature called glue, similar to
flex, which can determine space left above/below
Steve: So certain analogy to flex
howcome: Makes sense, but simple alignment seems like a good idea.
discussion of aligning blocks inside integral number of lines
Steve: Last point is issue of top-line leading, you might want to define
an offset of the line grid from the top of the container
Steve: So in general, might want to say 'line grid starts here"
Steve: Shift the line grid, though grid is infinite in either direction
Steve: proposed plan
Steve: We have a draft that is seriously out of date
Steve: First step is to take what's there and
Steve: a) update to current template
Steve: b) drop things that are out-of-scope
Steve: e.g. defer drop-caps
ChrisL: If you can do integral number of line grid units, you've solved
quite a bit of the drop-caps problem
Steve: Next thing is redo the introduction based on the processing model
I just outlined
Steve: Then implement resolution of moving the Line Grid description
into this spec
Steve: And then have something to discuss at Hamburg F2F.
discussion of publishing strategy
Steve explains that he tried to send the presentation to the mailing list
twice and failed, and that's why it's not there.
Florian: I'm happy this is being worked on.
[ discussion of slide format conversion and avoiding [?] ]
ChrisL: SVG 1 already has the concept of aligning baselines, and it's a
little handwavy. If we can point to this in SVG2 that would be
preferable.
dbaron: speaking of SVG and other formats
dbaron: I'm going to attempt to describe what happened, and Chris will
correct me where I'm wrong
dbaron: I think XSL1.0 took the CSS vertical-align property and turned
it into a shorthand for 3-4 other properties
dbaron: SVG then took a subset of those properties, but didn't reflect
vertical-align as a shorthand
dbaron: I think what we want to wind up with is vertical-align as a shorthand.
ChrisL: That's correct except XSL didn't really have shorthands. It had
a way of expanding a property into traits, which is not quite
the same as our shorthand.
dbaron: If we introduce these properties back from svg, would prefer not
to have multiple properties with same set of values not shorthand
of each other
dbaron: beware there's a bit of hornets nest with some of these properties
dbaron: we'll probably talk about it again in the future.
<glenn> see http://www.w3.org/TR/2006/REC-xsl11-20061205/#shortexpan
for more info on XSL shorthands
Alan: On the www-style mailing list, there were an argument that went over
and over again about what a line box is
Alan: One person said that box that contains glyphs but not the half-leading,
and other ...
dbaron: Sure this isn't about inline box? Because if this is about line box,
these people had no idea what they were talking about
Alan: What's a line box?
Steve: A box that ocntains the line. Complex rules that define its top and
bottom.
ChrisL: do glyphs always fit in line box?
No.
smfr: ever a gap between line boxes?
No (except for floats and clearance)
<dbaron> My previous research into the messy set of properties that might
be a shorthand is https://bugzilla.mozilla.org/show_bug.cgi?id=308338#c21
and my opinion on the way to proceed is
https://bugzilla.mozilla.org/show_bug.cgi?id=308338#c28
ChrisL: Does clearance realign to line-grid?
fantasai: My conclusion from last time I looked was that vertical-align
should not be a shorthand.
fantasai: vertical-align: baseline should use dominant baseline
<glenn> believes vertical-align should be a shorthand
fantasai: Most cases can just use the dominant-baseline of the parent
to choose the appropriate alignment baseline.
dbaron: We might not want dominant-baseline to be part of vertical-align,
but if we have alignment-shift and alignment-?, those should
probably be part of vertical-align
dbaron: I think alignment-adjust and baseline-shift should definitely be
subproperties of a vertical-align shorthand if they're included.
I don't have a strong opinion on whether dominant-baseline should
be in the vertical-align shorthand.
Bert: What happened with vertical aligning of image?
SteveZ: At minimum, we'll add top, bottom, center, and we'll consider
adding glue/flex.
<br duration="calc(15 * 60s)" />
Received on Monday, 13 February 2012 17:30:31 UTC