- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 8 Oct 2015 15:55:02 -0700
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: www-style list <www-style@w3.org>
On Thu, Oct 8, 2015 at 1:53 PM, L. David Baron <dbaron@dbaron.org> wrote: > 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. You missed my point. Flexbox has had this exact behavior for years. Has it always been troublesome? It sounds like, from your further comments that I'm snipping, it has been. I just want to make sure that I actually understand the issue here, and that it's not something new and unique to the Alignment spec that I'm not seeing. ~TJ
Received on Thursday, 8 October 2015 22:55:49 UTC