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

On Friday 2015-10-02 15:43 -0700, Tab Atkins Jr. wrote:
> 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 "issue" is that this spec is doing things with computed value
definitions that CSS specs haven't done before, in terms of making
the computed value of the initial value have behavior that depends
on other properties.

What we do now is that we internally treat 'auto' as a computed
value for 'align-self', and then have special code to handle inherit
inheriting an auto computed value, and special code for
getComputedStyle.  We handle this incorrectly for transitions (which
doesn't matter yet since we don't transition/animate
non-interpolable properties) and for the obscure case where every
property in the display struct [1] is explicitly 'inherit' (since in
that case we have an optimization that will cause us to miss the
special code I mentioned previously; this is fixable with another
special case).

For 'align-content' and 'align-items', we currently treat 'stretch'
as the initial value (which is correct for flexbox), and likewise
for 'justify-content' we treat 'flex-start' as the initial value
(which is correct for flexbox).  We don't do anything conditioned on
display type since we only support them for flexbox.

I guess we might be able to pile on a bunch of additional hacks to
make all of this work, but it's a significant amount of complexity
and it might not be quite 100% conformant, especially if we add
other interesting features into the mix.

[1] -moz-appearance, -moz-binding, -moz-orient, animation-delay,
    animation-direction, animation-duration, animation-fill-mode,
    animation-iteration-count, animation-name, animation-play-state,
    animation-timing-function, backface-visibility, clear, clip,
    contain, display, float, isolation, mix-blend-mode, opacity,
    overflow-clip-box, overflow-x, overflow-y, page-break-after,
    page-break-before, page-break-inside, perspective,
    perspective-origin, position, resize, scroll-behavior,
    scroll-snap-coordinate, scroll-snap-destination,
    scroll-snap-points-x, scroll-snap-points-y, scroll-snap-type-x,
    scroll-snap-type-y, touch-action, transform, transform-box,
    transform-origin, transform-style, transition-delay,
    transition-duration, transition-property,
    transition-timing-function, and will-change

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

I guess... although this "legacy" behavior might actually be
something developers actually want.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)