- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 26 Jan 2012 16:35:31 -0800
- To: Alex Mogilevsky <alexmog@microsoft.com>
- Cc: Daniel Holbert <dholbert@mozilla.com>, "www-style@w3.org" <www-style@w3.org>
On Thu, Jan 26, 2012 at 4:31 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote: > ± From: Daniel Holbert [mailto:dholbert@mozilla.com] > ± Sent: Thursday, January 26, 2012 11:59 AM > ± > ± What should "auto" compute to for elements that *aren't* inside of a > ± flexbox? (in which case there is no flexbox to derive the "flexbox's > ± ‘flex-align’" from) > > It seems it is again an issue with trying to arrive to final effective value at style cascading as opposed to interpreting the values in layout. > > Sorry if I don't fully understand the meaning of the word "computes", It means the computed value. > but in my understanding "flex-item-align:auto" has to behave as follows > > 1) When applied to any element, the value is stored as 'auto' > 2) When queried from the element (flexbox item or not), the value is returned as 'auto' > 3) Flexbox layout, at cross-axis alignment stage > a) retrieves 'flex-item-align' property from each flexbox item > b) if it is not 'auto', that is the item's alignment > c) if it is 'auto', alignment type set in flexbox's 'flex-align' property is used. > > Or are there any other expectations? Or something else I don't get? If you ask for the specified value (via the OM APIs that let you query el.style or examine the stylesheet directly), you'll get back 'auto'. If you call getComputedValue(el).flexItemAlign, though, you'll get the flexbox's 'flex-align' value, because it's already resolved the computed value. This is standard behavior for these sorts of properties. ~TJ
Received on Friday, 27 January 2012 00:36:18 UTC