- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 4 Jun 2010 09:39:49 -0700
- To: Andrew Fedoniouk <news@terrainformatica.com>
- Cc: Brad Kemper <brad.kemper@gmail.com>, Zack Weinberg <zweinberg@mozilla.com>, www-style@w3.org
On Thu, Jun 3, 2010 at 9:35 PM, Andrew Fedoniouk <news@terrainformatica.com> wrote: >>> Seems like my question was not clear enough. >>> Let me put it this way: >>> >>> <div width:1000px padding-left:1fx >>> box-sizing:border-box *flow:vertical*> >>> <div #A width:calc(700px + 1fx) /> >>> <div #B width:2fx /> >>> </div> >>> >>> What would be the width of div#A ? >>> (#B there is just for illustration). >> >> It's 700px, by the exact same logic in the previous version of this >> problem. (#B is 0px wide.) >> >> It would be more useful if you could explain precisely which part of >> my explanation wasn't useful. There's something about this case that >> you don't get, and my explanations aren't helping, so I'd like to know >> why, just in case it's something I'm fundamentally missing. >> > > I lost you here completely, sorry. > > Once again. You say that here: > > <div width:1000px padding-left:1fx > box-sizing:border-box flow:vertical> > <div #A width:calc(700px + 1fx) /> > <div #B width:2fx /> > </div> > > div#A will get width 700px and > div#B will be 0px wide, correct? > > And what will be the width of content-box of outer > div then? Please note that it is box-sizing:border-box. > > Either both div#A and div#B should have zero widths > (if content box width == 0) > or both of them should have 700px > (if content box width == 700px). Oh! I'm so sorry, I didn't notice that you'd switched to a vertical flow. In that case, both boxes are 700px wide, as is the content area of the parent. That's specified in 6.2.1.2. >>> Ok, but it is still a problem even if you will fix that. >>> >>> Reading definition of the "preflex length": >>> >>> "The preflex size of a flexible length is the greater of the flexible >>> length's minimum and preferred sizes." >>> >>> E.g. for two collapsed margins you say that this margin >>> is using max(fixed-length, preferred-length). >> >> Where are you seeing that? I never say anything like that anywhere in >> my algorithm, nor in the more informal description of margin >> collapsing in section 4; it's quite incorrect. > > Here "4. Flexibility". > <quote> > If one margin is "calc(20px + 1fl)" (a length with a flexibility of 1 and a > preferred size of 20px) and the other is "max(50px, 2fl)" (a length with a > flexibility of 2 and a minimum size of 50px), the collapsed margin > would have a flexibility of 2, a minimum size of 50px, and a > preferred size of 20px. > </quote> > > As far as I understand all this 50px of yours will go to the preflex > length as it is "minimum size of 50px". Ah, okay. The issue was the you said "fixed-length" when you meant "min length". I say something very specific about fixed lengths that is *not* what you described, so I was reading it differently. > Or there is something wrong in your definition or in my understanding > of it. > Is width:max(50px, 2fl) an equivalent of width:2fl, min-width:50px ? Yes, it is exactly equivalent. >>> This test is also about interpretation of "flexible length's minimum" >>> "preferred length" and "preflex length" that you use. >> >> There is no interpretation necessary. All of those terms are >> precisely defined. (If you find an ambiguity, let me know.) >> > > These test's tell me better what you have in mind > than your text for some reasons. This is probably not > about your text per se but rather about CSS you use > e.g. fonts and line spacing. I have no "Droid" fonts here > and so it falls back to arial with that dense line spacing. > And content area is fixed so I cannot make lines shorter... Use a browser with a proper Inspector so you can change that stuff yourself. ^_^ (What browser are you using? The Droid fonts are linked in via @font-face rules from the Google CDN - you don't actually need them to be on your computer.) >>> So by default width of element content is not its >>> preferred width. Probably it is better then to use >>> something like "base width" rather than "preferred width"? >>> >>> In tables for example, preferred width of a column is >>> a content width of cells in it. >> >> That's tables. This is flexbox. You can *make* the preferred width >> be the width of the content - either use "width: calc(fit-content + >> 1fl);" or (proposed, not yet in the draft) use "width: 1fla;". Both >> of these create a flexible width with flexibility 1 and preferred size >> of the content's width. It's just not the default way to do it. > > You use term "fit-content" (in your document too) that is not > defined anywhere yet. > > What exactly is that "fit-content"? Yeah, it hasn't quite been defined anywhere, but it *should* be - I believe dbaron's got it on his plate for the future. It's the "intrinsic" width. The actual definition builds on the definitions for min-content and max-content, like so: min-content: The width of the longest line if you take every possible linebreak opportunity. max-content: The width of the longest line if you don't take any non-forced linebreak opportunities. fit-content: max(min-content, min(max-content, available width)) Though, I suspect I have to define what the "available width" is for a flexbox at various stages. > E.g. for this paragraph: > <p>100px-word 200px-word</p> > > Options are: > a) 200px - (so called min-intrinsic width) > b) 300px + space width (so called max-intrinsic width) 300px + space. >> You complained about the fact that the current flexbox draft makes >> preferred width always equal to the width of the contents. Why are >> you now unhappy with the opposite? > > Umm... I do not remember myself complaining about something like that. It was in a much earlier email, when you were initially still very confused about additive flexes. The dislike may have been solely a result of you not yet understanding it, though. >>>>> f) >>>>> <div width:1000px flow:horizontal > >>>>> <div width:calc(500px + 1fx) >some-500px-wide-text</div> >>>>> <div width:calc(700px + 1fx) >some-700px-wide-text</div> >>>>> </div> >>>> >>>> Free space is -200px. This gets split evenly and added to the >>>> preferred width of each. The first child ends up as 400px wide, the >>>> second child as 600px wide. The contents of both overflow. >>> >>> So your vision of display:box tends to follow >>> display:block rules rather than BFC blocks like display:table-cell. >>> Seems like your point of view is different from what Gecko/XUL >>> is using. >> >> It might be different from XUL, I dunno. It's not different from the >> current flexbox draft, which would act in the exact same way. That >> is, given this markup: >> >> <div width:1000px display:box> >> <div width:500px box-flex:1>some-500px-wide-text</div> >> <div width:700px box-flex:1>some-700px-wide-text</div> >> </div> >> >> The current flexbox draft would do the exact same thing that my >> proposal does - the children would be shrunk to 400px and 600px wide, >> respectively, and their contents would overflow. > > Try this then: > > <!DOCTYPE html> > <html> > <head> > <title>Mozilla FlexBox</title> > <style> > body { font:10pt verdana; } > div { min-height:10px; } > span { border-top:2px dashed black; display:inline-block; } > #box1 { display:-moz-box; width:1000px; -moz-box-orient:horizontal; } > #box2 { -moz-box-flex: 1.0; width:500px; background:gold;} > #box3 { -moz-box-flex: 1.0; width:700px; background:red;} > #ruler100 { width: 100px; border-bottom:3px solid green; margin-top:1px;} > #ruler200 { width: 200px; border-bottom:3px solid green; margin-top:1px;} > #ruler300 { width: 300px; border-bottom:3px solid green; margin-top:1px;} > </style> > </head> > <body> > <div id="box1"> > <div id="box2"><span style="width:500px"></span></div> > <div id="box3"><span style="width:700px"></span></div> > </div> > <div id="ruler100" >100px</div> > <div id="ruler200" >200px</div> > <div id="ruler300" >300px</div> > </body> > </html> > > Either Mozilla does not follow their specification or their > spec is wrong or your interpretation of their spec is not correct. Ah, you're right. One of those is true. We'd have to ask Moz to see which one. > All existing flex implementations use display:table-cell > for flex blocks (that makes real sense) and yours is not > for some reasons. Probably that shift of paradigm is the main > source of my problems to get your spec right. > > The idea behind of display:table-cell and flexible block is that > they establish BFC. It means that that e.g. floats inside are > seen in full and not overdrawn by neighbors/siblings. > The main idea and purpose of position:static > mode is to ensure that content can be seen in full. > So there is no loss of information for the human as > on the page here: > http://www.terrainformatica.com/w3/w3-front-page.png I'll think on this. It wouldn't be big change. ~TJ
Received on Friday, 4 June 2010 16:40:52 UTC