W3C home > Mailing lists > Public > www-style@w3.org > March 2013

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 20 Mar 2013 16:03:51 -0700
Message-ID: <CAAWBYDC3yTmDV1=+q9igftzxEii7FqtpDZB2x_nak=wfVM-Q1Q@mail.gmail.com>
To: Christian Biesinger <cbiesinger@chromium.org>
Cc: www-style list <www-style@w3.org>, Ojan Vafai <ojan@chromium.org>
On Wed, Mar 20, 2013 at 1:08 PM, Christian Biesinger
<cbiesinger@chromium.org> wrote:
> 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 guidance, check out the Flexbox Baselines section
<http://dev.w3.org/csswg/css3-flexbox/#flex-baselines>, which is very
precise and explains how to handle cases when there's no appropriate
baseline in a particular direction.

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

Urf, I see we haven't defined "stretch" at all actually.

"stretch" should act the same way it does in Flexbox - if 'height' is
"auto", it sets the height such that the margin box exactly fills the
available space (treating auto margins as zero, unless they've already
been resolved).  If 'height' isn't auto, is does nothing, and acts
like 'start'.

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

Nope, they can't be explicitly directional, because they're
writing-mode specific.  That axis will be horizontal in Japanese.

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

The idea is that hopefully the logical directions will become common
enough that people understand that automatically.  ^_^  But I'll see
what I can do.


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

Nah, it's somewhat non-obvious.  It should be called out.

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

Yup, definitely.

~TJ
Received on Wednesday, 20 March 2013 23:04:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:07 GMT