Re: [css3-align] Some questions about justify-self

On Wed, Mar 20, 2013 at 11:30 AM, Christian Biesinger
<cbiesinger@chromium.org> wrote:
> [Resending this now that I'm subscribed, in hopes that I don't need
> list admin approval this time]
>
> Hi all,
>
> I am considering implementing the box alignment spec and just finished
> reading through it. I have some questions:

Cool!  Note that the spec needs a little bit of cleanup and attention,
which we haven't gotten around to yet.  Feel free to ask me or
fantasai any questions you may have as you implement.

> SECTION 3.1 (justify-self)
> - The spec defines a "baseline" value for justify-self. It is not
> clear to me what that means? Is this just for vertical writing modes,
> or am I missing something?

Basically, yes.  Every box is supposed to generate both a horizontal
and vertical baseline, so that it can be baseline-aligned regardless
of the surrounding writing-mode.

> - For stretch - am I reading the description correctly that stretch
> will potentially shrink the element?

Yes.

> - For "true" - this keyword will only make a difference when used with
> center, correct?

No.  'true' is meant to act more like margin-based alignment, where
you're always safe from overflowing off the before/start side.  It
applies to all of the alignment keywords.  For example, if 'end' is
used, and the element is larger than its container, it'll line up with
the 'start' side and extend off the 'end' side instead.

> - The "EXAMPLE 1" would benefit from specifying which justify-self
> value leads to the described behavior, IMO

All of them do - it's just describing how you can combine both margins
and alignment.  It could be written more clearly, definitely.

> SECTION 3.2 (align-self)
> - The possible values differ from the ones in the flexbox spec (head
> vs flex-start, foot vs flex-end), is that intentional?

Yes, Flexbox defines additional values that are
flex-direction-specific, as those are generally more appropriate for
Flexbox than the writing-mode-specific directions.  Once you implement
the Alignment spec, the new values should also be available for
Flexbox.

Note that the head/foot names are still under debate. :/  They're more
traditionally called "before" and "after", but we've been trying to
change them to a better pair.  Any suggestions would be welcome.

> SECTION 4.1 (justify-content)
> - Do "start" and "end" also apply to flexboxes? The text doesn't say
> that they don't, but that feels weird...

Yes.  Why does it seem weird?  They're just the writing-mode-specific
directions, dependent on whether the element is ltr or rtl.  These are
distinct from flex-start and flex-end - a row-reverse flexbox will
have them opposite.

> - The second mention of "end" in the list should be "flex-end"

Ah, indeed.

> - Do left and right mean the same as start and end, assuming LTR content?

Yes.

> - Same baseline question as above. The mention of vertical-align makes
> me think that this is only meant for the align-* properties.

Nope, baselines apply in both directions.  In any given writing-mode,
though, only one of them is used.

> - Requiring the "true" keyword to get true centering does not match
> the current flexbox spec. This is also an issue for align-self.

Yes, this is something that needs to be fixed in the spec.  We need to
amend the grammar so that it allows either a "true" or "safe" keyword.
 If this is omitted, it defaults to whatever the relevant display mode
does - safe for block layout, true for flexbox layout.

> SECTION 4.2 (align-content)
> - To make sure I understand this correctly: "head" and "foot" are
> equivalent if the height of the block is "auto", correct?

Because it shrinkwraps the content, so there's no real distinction
between the two alignments?  Yes.

> - I believe the "end" in the list should be "flex-end"

Yes.

> - In the "space-around" description, the mention of "space-between"
> towards the end should say space-around. What's the value in making
> this value and space-between optional for browsers to implement?

Hm, that's a good question.

> - For "true" - it feels a little weird to me that "foot" doesn't imply
> "true"; wouldn't this surprise authors?

Depends on the display mode.  'true foot' in some contexts will hide
content in an unscrollable area, which is why it's not the default for
block layout.  Flexbox, being more of a UI display mode than a
document one, is usually more okay with this risk.

~TJ

Received on Wednesday, 20 March 2013 18:51:35 UTC