W3C home > Mailing lists > Public > www-style@w3.org > October 2015

Re: [css-align] implementability of computed value rules for align/justify-self/items

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 2 Oct 2015 15:43:07 -0700
Message-ID: <CAAWBYDDKyNn_xf4mVRVCcn989LKFEniyFQM5k5Ba8giwYoq7tw@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: www-style list <www-style@w3.org>
On Fri, Sep 11, 2015 at 3:48 PM, L. David Baron <dbaron@dbaron.org> wrote:
> This email is a result of discussion from
> https://bugzilla.mozilla.org/show_bug.cgi?id=1176782#c21 .
>
> I'm really not sure how we'd implement the magic computed value
> rules for align-items, justify-items, align-self, and justify-self
> in Gecko.  Having the initial value of a property produce different
> computed values depending on other properties (all of which could
> also be produced from other values) defeats the key memory usage and
> speed optimizations in our style computation code, since we're no
> longer able to share computation results for non-inherited
> properties between different elements with the same specified
> values.
>
> For the values other than 'legacy', I could implement something
> that's mostly indistinguishable by storing 'auto' as the internal
> computed value, adding code to compute the "real" computed value for
> use by getComputedStyle and our internal users, adding code to fix
> things up when explicit 'inherit' is used, and adding code to fix
> things up for starting of transitions, but there are probably other
> cases I've missed, where we'd end up being nonconformant.

We're... not sure what the issue here is. The Flexbox spec has
computed align-self on the parent's align-items for years with its
"auto" value; are you currently non-conformant for Flexbox? Or is
adding a computed value depend on 'position' a dealbreaker here? Even
display depends on 'position', so we didn't think this would be a
problem.

> The 'legacy' value on justify-items is even worse, though, since it
> makes justify-items essentially be a half-inherited and
> half-non-inherited property, even for the initial value.  I would
> really rather have this legacy alignment behavior be part of an
> inherited property.  (I think I'd be ok if the 'auto' value of
> 'justify-items' took its value from a non-'auto' value of an
> inherited 'legacy-justify-items' and then fell back to the current
> 'auto' rules if 'legacy-justify-items' was 'auto'.  I think that's
> no worse than what we do for the values other than 'legacy'.  (Or
> 'legacy-justify-items' could be part of 'text-align'.)
>
> I'm not sure I worked out the implications of these various
> possibilities correctly, though.

We only added "legacy" because it seemed like a nice bonus to finally
address how <center>/<div align=left|right|center> worked.  We'd
rather not introduce *yet another* alignment property just to handle
this weird legacy case. If our approach is problematic, we'd rather
just drop it and continue to let UAs handle those tags in their own
ideosyncratic ways, as they do today.  Does that sound okay?

~TJ and fantasai
Received on Friday, 2 October 2015 22:43:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:57 UTC