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

Thanks for the response. See comments inline.

On Wed, Mar 20, 2013 at 11:50 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Wed, Mar 20, 2013 at 11:30 AM, Christian Biesinger
> <cbiesinger@chromium.org> wrote:
>> 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.

Ah. OK, that makes sense. Looking at the code, that shouldn't be too
hard to implement, I think.

>> - 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.

True, I realized that in my question below :)

>> - 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.

OK, I'll have to think more about that example. By the way, speaking
of margins, how does stretch interact with margins? Does it
effectively set the margins to zero, or does it only stretch such that
there's space for them? I assume it's the latter but I'm not sure.

>> 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.

Oh I see. I think I didn't fully understand how start/end work with
flexbox before, hence also my confusion in the question below.

> 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.

Maybe top and bottom?

>> 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.

Right, I didn't fully understand that's how they worked. Would it make
sense to add a non-normative paragraph to the spec that basically says
what you just said?

>> - 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.

Would it make sense to mention that in the spec too, or is that
obvious to people with more familiarity with CSS?

>> - 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.

That would be good. Having a "safe" keyword for flexbox would actually
have been useful for me a few times.

>> - 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.

Ah, hm. I forgot that this would make it unscrollable. Only a problem
if overflow is not visible... but I guess that makes sense.

-christian

Received on Wednesday, 20 March 2013 20:09:23 UTC