mail archive www-style.w3.org
(List home) (Recent threads) (197 other W3C lists)
Subscription Options
- RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
- Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe (we seem to have lost it) address with "subscribe" in the subject line.
- Moderate traffic list: up to 30 messages per day
- This list contains about 20,554 messages, beginning Mar 2011
- 54 messages added yesterday
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no
[css3-linebox] (edge case) negative outer size and line layout
Ad
The spec has a imprecise informative note: # Note that items with zero main size will never start a line unless # they're the very first items in the flex container, or they're # preceded by a forced break. The "collect as many" line will collect # them onto the end of the previous line even if the last non-zero # item exactly "filled up" the line. because when the last non-zero item overflows the line, the next item with zero main size will start next line. This is demonstrable[1] in Chrome 22. I think it's fine to leave the paragraph as it is (it's informative anyway), but it would be nice if css3-linebox specs this simple algorithm* because in inline layout browser are not currently interoperable in this edge situation (again, see [1], for 'inline-block's with negative outer size). A similar edge situation is for flex items with negative outer cross-size. The current spec determines the cross-size of a flex line with: # (single line flex container) # # Otherwise, for each flex line: # # - Collect all the flex items whose inline-axis is parallel to the # main-axis, whose ‘align-self’ is ‘baseline’, and whose # cross-axis margins are both non-‘auto’. Find the largest of the # distances between each item's baseline and its hypothetical outer # cross-start edge, and the largest of the distances between each # item's baseline and its hypothetical outer cross-end edge, and # sum these two values. # # - Among all the items not collected by the previous step, find the # largest outer hypothetical cross size. # # - The used cross-size of the flex line is the larger of the numbers # found in the previous two steps. The spec should mention whether and when these calculations are clamped at 0. If we want to spec Chrome 22's behavior, from testcases like data:text/html,<!DOCTYPE html><div style="width: 40px; border: yellow 20px solid; display: flex; -webkit-flex-flow: wrap;"><span style="width: 60px; background: blue; height: 20px; -webkit-flex: none;"></span><span style="width: 20px; height: 20px; background: red; margin-top: -40px"></span></div> and data:text/html,<!DOCTYPE html><div style="width: 40px; border: yellow 20px solid; display: -webkit-flex; -webkit-flex-flow: wrap;"><span style="width: 60px; background: blue; height: 20px; -webkit-flex: none;"></span><span style="width: 20px; height: 20px; background: red; margin-top: -40px; -webkit-align-self: baseline;">g</span></div> , it seems that what would be needed is | - Collect all the flex items whose inline-axis is parallel to the | main-axis, whose ‘align-self’ is ‘baseline’, and whose | cross-axis margins are both non-‘auto’. Find the largest of the | distances between each item's baseline and its hypothetical outer | cross-start edge (or zero when all hypothetical outer cross-start | edges are below the baseline), and the largest of the distances | between each item's baseline and its hypothetical outer cross-end | edge (or zero when all hypothetical outer cross-end | edges are above the baseline), and sum these two values. | | - Among all the items not collected by the previous step, find the | largest outer hypothetical cross size, clamped at 0. Otherwise, I don't particularly think negative cross-size for flex lines are terrible. We don't have line boxes with negative cross-size because there are struts for 'line-height', which stands for "minimum cross-size", but we don't have such a thing for flex lines so I don't think the consistency is in favor of any side. I suggest we do whatever would result in less code in browsers. * Namely, this prose: # Otherwise, starting from the first uncollected item, collect as # many consecutive flex items as will fit or until a forced break is # encountered (but collect at least one) into the flex container's # inner main size into a flex line... # # For this step, the size of a flex item is its outer hypothetical # main size. [1] http://lists.w3.org/Archives/Public/www-archi... (feel free to use it for other purposes because all browsers have bugs in this demo here and there...) Cheers, Kenny
On Fri, Aug 3, 2012 at 2:47 AM, Kang-Hao (Kenny) Lu wrote: > The spec has a imprecise informative note: > > # Note that items with zero main size will never start a line unless > # they're the very first items in the flex container, or they're > # preceded by a forced break. The "collect as many" line will collect > # them onto the end of the previous line even if the last non-zero > # item exactly "filled up" the line. > > because when the last non-zero item overflows the line, the next item > with zero main size will start next line. This is demonstrable[1] in > Chrome 22.That's a good point. The note is actually wrong. I'll correct it.> I think it's fine to leave the paragraph as it is (it's informative > anyway), but it would be nice if css3-linebox specs this simple > algorithm* because in inline layout browser are not currently > interoperable in this edge situation (again, see [1], for > 'inline-block's with negative outer size).Yes, it would be useful to have a generic algorithm for this, so we don't have to redefine it every time.> A similar edge situation is for flex items with negative outer > cross-size. The current spec determines the cross-size of a flex line with: > > # (single line flex container) > # > # Otherwise, for each flex line: > # > # - Collect all the flex items whose inline-axis is parallel to the > # main-axis, whose ‘align-self’ is ‘baseline’, and whose > # cross-axis margins are both non-‘auto’. Find the largest of the > # distances between each item's baseline and its hypothetical outer > # cross-start edge, and the largest of the distances between each > # item's baseline and its hypothetical outer cross-end edge, and > # sum these two values. > # > # - Among all the items not collected by the previous step, find the > # largest outer hypothetical cross size. > # > # - The used cross-size of the flex line is the larger of the numbers > # found in the previous two steps. > > The spec should mention whether and when these calculations are clamped > at 0. If we want to spec Chrome 22's behavior, from testcases like > > data:text/html,<!DOCTYPE html><div style="width: 40px; border: yellow > 20px solid; display: flex; -webkit-flex-flow: wrap;"><span style="width: > 60px; background: blue; height: 20px; -webkit-flex: none;"></span><span > style="width: 20px; height: 20px; background: red; margin-top: > -40px"></span></div> > > and > > data:text/html,<!DOCTYPE html><div style="width: 40px; border: yellow > 20px solid; display: -webkit-flex; -webkit-flex-flow: wrap;"><span > style="width: 60px; background: blue; height: 20px; -webkit-flex: > none;"></span><span style="width: 20px; height: 20px; background: red; > margin-top: -40px; -webkit-align-self: baseline;">g</span></div> > > , it seems that what would be needed is > > | - Collect all the flex items whose inline-axis is parallel to the > | main-axis, whose ‘align-self’ is ‘baseline’, and whose > | cross-axis margins are both non-‘auto’. Find the largest of the > | distances between each item's baseline and its hypothetical outer > | cross-start edge (or zero when all hypothetical outer cross-start > | edges are below the baseline), and the largest of the distances > | between each item's baseline and its hypothetical outer cross-end > | edge (or zero when all hypothetical outer cross-end > | edges are above the baseline), and sum these two values. > | > | - Among all the items not collected by the previous step, find the > | largest outer hypothetical cross size, clamped at 0. > > Otherwise, I don't particularly think negative cross-size for flex lines > are terrible. We don't have line boxes with negative cross-size because > there are struts for 'line-height', which stands for "minimum > cross-size", but we don't have such a thing for flex lines so I don't > think the consistency is in favor of any side. > > I suggest we do whatever would result in less code in browsers.Ah, I didn't consider that boxes can have a negative outer size. Silly me. Yes, clamping at zero is the most sensical behavior here. ~TJ
On Fri, Aug 3, 2012 at 8:08 AM, Tab Atkins Jr. wrote:
> On Fri, Aug 3, 2012 at 2:47 AM, Kang-Hao (Kenny) Lu
> wrote:
>> The spec has a imprecise informative note:
>>
>> # Note that items with zero main size will never start a line unless
>> # they're the very first items in the flex container, or they're
>> # preceded by a forced break. The "collect as many" line will collect
>> # them onto the end of the previous line even if the last non-zero
>> # item exactly "filled up" the line.
>>
>> because when the last non-zero item overflows the line, the next item
>> with zero main size will start next line. This is demonstrable[1] in
>> Chrome 22.
>
> That's a good point. The note is actually wrong. I'll correct it.
>
>> I think it's fine to leave the paragraph as it is (it's informative
>> anyway), but it would be nice if css3-linebox specs this simple
>> algorithm* because in inline layout browser are not currently
>> interoperable in this edge situation (again, see [1], for
>> 'inline-block's with negative outer size).
>
> Yes, it would be useful to have a generic algorithm for this, so we
> don't have to redefine it every time.
>
>> A similar edge situation is for flex items with negative outer
>> cross-size. The current spec determines the cross-size of a flex line with:
>>
>> # (single line flex container)
>> #
>> # Otherwise, for each flex line:
>> #
>> # - Collect all the flex items whose inline-axis is parallel to the
>> # main-axis, whose ‘align-self’ is ‘baseline’, and whose
>> # cross-axis margins are both non-‘auto’. Find the largest of the
>> # distances between each item's baseline and its hypothetical outer
>> # cross-start edge, and the largest of the distances between each
>> # item's baseline and its hypothetical outer cross-end edge, and
>> # sum these two values.
>> #
>> # - Among all the items not collected by the previous step, find the
>> # largest outer hypothetical cross size.
>> #
>> # - The used cross-size of the flex line is the larger of the numbers
>> # found in the previous two steps.
>>
>> The spec should mention whether and when these calculations are clamped
>> at 0. If we want to spec Chrome 22's behavior, from testcases like
>>
>> data:text/html,<!DOCTYPE html><div style="width: 40px; border: yellow
>> 20px solid; display: flex; -webkit-flex-flow: wrap;"><span style="width:
>> 60px; background: blue; height: 20px; -webkit-flex: none;"></span><span
>> style="width: 20px; height: 20px; background: red; margin-top:
>> -40px"></span></div>
>>
>> and
>>
>> data:text/html,<!DOCTYPE html><div style="width: 40px; border: yellow
>> 20px solid; display: -webkit-flex; -webkit-flex-flow: wrap;"><span
>> style="width: 60px; background: blue; height: 20px; -webkit-flex:
>> none;"></span><span style="width: 20px; height: 20px; background: red;
>> margin-top: -40px; -webkit-align-self: baseline;">g</span></div>
>>
>> , it seems that what would be needed is
>>
>> | - Collect all the flex items whose inline-axis is parallel to the
>> | main-axis, whose ‘align-self’ is ‘baseline’, and whose
>> | cross-axis margins are both non-‘auto’. Find the largest of the
>> | distances between each item's baseline and its hypothetical outer
>> | cross-start edge (or zero when all hypothetical outer cross-start
>> | edges are below the baseline), and the largest of the distances
>> | between each item's baseline and its hypothetical outer cross-end
>> | edge (or zero when all hypothetical outer cross-end
>> | edges are above the baseline), and sum these two values.
>> |
>> | - Among all the items not collected by the previous step, find the
>> | largest outer hypothetical cross size, clamped at 0.
>>
>> Otherwise, I don't particularly think negative cross-size for flex lines
>> are terrible. We don't have line boxes with negative cross-size because
>> there are struts for 'line-height', which stands for "minimum
>> cross-size", but we don't have such a thing for flex lines so I don't
>> think the consistency is in favor of any side.
>>
>> I suggest we do whatever would result in less code in browsers.
>
> Ah, I didn't consider that boxes can have a negative outer size.
> Silly me. Yes, clamping at zero is the most sensical behavior here.Woo, long overdue fixes! Fixed the note and made flex lines clamp
their cross size at 0.
~TJ