15:23:16 <RRSAgent> RRSAgent has joined #css
15:23:16 <RRSAgent> logging to http://www.w3.org/2012/07/25-css-irc
15:23:23 <glazou> Zakim, this will be Style
15:23:23 <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 37 minutes
15:23:28 <glazou> RRSAgent, make logs public
15:32:10 <jet> jet has joined #CSS
15:33:26 <arno> arno has joined #css
15:36:17 <glenn> glenn has joined #css
15:43:08 <krit> krit has joined #css
15:55:16 <Bert> Bert has joined #css
15:56:40 <Zakim> Style_CSS FP()12:00PM has now started
15:56:47 <Zakim> +??P16
15:56:47 <acebal> acebal has joined #css
15:56:56 <glazou> Zakim, ??P16 is me
15:56:56 <Zakim> +glazou; got it
15:57:10 <acebal> acebal has left #css
15:57:35 <florian> florian has joined #css
15:58:21 <CesarAcebal> CesarAcebal has joined #css
15:58:26 <Zakim> +??P22
15:58:44 <glenn> zakim, ??P22 is me
15:58:44 <Zakim> +glenn; got it
15:59:25 <TabAtkins_> TabAtkins_ has joined #css
15:59:30 <Zakim> +plinss
15:59:49 <antonp> antonp has joined #css
15:59:52 <Zakim> +florian
16:00:30 <Zakim> + +1.206.675.aaaa
16:00:37 <stearns> zakim, aaaa is me
16:00:37 <Zakim> +stearns; got it
16:00:51 <Zakim> +tabatkins_
16:00:52 <Zakim> +SteveZ
16:01:00 <Zakim> +[Apple]
16:01:05 <hober> Zakim, Apple has me
16:01:05 <Zakim> +hober; got it
16:01:11 <Zakim> +antonp
16:01:21 <Zakim> +??P15
16:02:10 <glazou> Extra Agenda item : sunday at TPAC
16:02:24 <smfr> smfr has joined #css
16:02:42 <Zakim> +Bert
16:02:52 <Zakim> +smfr
16:03:15 <glazou> regrets: dbaron, sylvaing, rbetts, kattie
16:03:50 <Zakim> +CesarAcebal
16:04:14 <smfr> can someone /topic?
16:05:16 <SteveZ> SteveZ has joined #css
16:05:50 <Zakim> +fantasai
16:05:53 <florian> ScribeNick: florian
16:06:00 <krit> I'll join on topic 2
16:06:06 <florian> Topic: f2f
16:06:08 <glazou> http://wiki.csswg.org/planning/sandiego-2012#participants
16:06:15 <glazou> http://wiki.csswg.org/planning/sandiego-2012#agenda
16:06:27 <florian> glazou: please register yourselfves and add agenda items on the wiki
16:06:44 <florian> glazou: also, what about sunday on tpac
16:07:04 <Zakim> +[Microsoft]
16:07:04 <florian> stevez: w3c can't pay for sunday, budget is 2000 euros
16:07:05 <arronei> zakim, microsoft has me
16:07:06 <Zakim> +arronei; got it
16:07:37 <florian> steveZ: Adobe is willing to pay for 1/4
16:07:44 <florian> SteveZ: who else?
16:08:02 <florian> tab: I'll check, we may be able to contribute
16:08:18 <florian> SteveZ: maybe microsoft could join too?
16:08:28 <florian> ???: I'll talk to sylvain
16:08:42 <arronei> s/???/arronei
16:09:01 <florian> fantasai: I'll check
16:09:09 <florian> florian: I'll check too
16:09:16 <florian> Stevez: Apple?
16:09:48 <florian> glazou: how about  cattering
16:09:59 <florian> Bert: budget included coffee and lunch
16:10:05 <hober> hober: I'll ask
16:11:03 <fantasai> organizations will donate to W3C, W3C will reserve the room
16:11:23 <florian> Topic: flexbox
16:11:33 <TabAtkins_> http://wiki.csswg.org/topics/flex-abspos-placeholders
16:12:27 <florian> tabAtkins: what happens when a flex items gets absolutely positioned
16:12:58 <florian> tabAtkins: current spec says we get a place holder, which interacts normally with the rest of flex elements
16:13:14 <florian> ... noticeable when using space between, etc
16:13:24 <florian> ... may  we could do the same as tables
16:13:36 <florian> ... there are several options, check the wiki
16:13:53 <Zakim> +??P43
16:13:53 <logbot> logbot has joined #css
16:14:14 <glazou> who just joined ?
16:14:28 <florian> ... the simple proposal is proposal A
16:14:43 <florian> fantasai: implementers don't like proposal B
16:14:54 <florian> fantasai: and intially didn't like C either
16:15:15 <florian> ... because it impacts layout of the content of the flexbo
16:15:17 <florian> x
16:15:18 <fantasai> s/and initially/initial commenter/
16:15:21 <jarek> jarek has joined #css
16:15:53 <florian> fantasai: and that's normally not what placeholders do
16:16:48 <fantasai> florian: There was someone mentioning [something about transforms].
16:17:01 <florian> tabAtkins: I'm for A
16:17:26 <florian> ... this is simplest
16:17:51 <florian> ... we have alternative proposals, but they're more complex, and there's no clear use case
16:18:06 <florian> fantasai: A or E (variant of C)
16:18:14 <florian> tab: E is too complex
16:18:32 <florian> florian: didn't morten propose a variant of B
16:18:46 <florian> fantasai: that 's D
16:18:58 <florian> tabAtkins: also a bit complex, not obvious use cases
16:19:20 <florian> SteveZ: what's important is that abspos items don't cause spacing differences
16:19:28 <florian> tab: that's everything but C
16:20:26 <fantasai> fantasai: Morten responds that E is better than A or B
16:20:35 <fantasai> fantasai: He doesn't like A because "it sounds like a bug report"
16:20:46 <drublic> drublic has joined #css
16:21:05 <fantasai> fantasai: i.e. the author would expect the static position to be somewhat accurate
16:21:18 <fantasai> fantasai: it might be more useful for vertical flexboxes rather than horizontal ones
16:21:49 <glazou> Regrets: ChrisL
16:22:52 <fantasai> fantasai: you can abspos something to the side, and have the main content flow down, e.g.
16:23:01 <fantasai> fantasai: Morten listed C > D/E > B > A
16:23:02 <florian> florian/fantasai: morten wants D or E
16:23:13 <fantasai> szilles: This isn't an implementer issue
16:23:32 <fantasai> szilles: The way I understand it is that the main-axis position may be useful to someone
16:24:05 <fantasai> TabAtkins_: That would be option C, because others are arbitrary
16:25:01 <fantasai> discussion of other cases that are complicated, e.g. bidi
16:25:31 <fantasai> szilles: Your (Tab) position is that coming up with something that handles the static position is complicated and hard to implement so why bother.
16:25:42 <fantasai> TabAtkins_: yes
16:25:55 <fantasai> anton: I think there's an author expectation that static position works, simply because it always has until now
16:26:10 <fantasai> anton: We have to choose between two aims here.
16:26:14 <fantasai> anton: Don't like placeholders
16:26:15 <Rossen> Rossen has joined #css
16:26:19 <fantasai> anton: but also want static position to work
16:26:25 <fantasai> anton: they are both expectations that people have
16:26:47 <fantasai> Rossen: I agree with Anton, and to me static position makes a lot of sense when you're talking about document layout and attaching things to the flow
16:26:53 <fantasai> Rossen: For app layout, static position is meaningless
16:26:58 <fantasai> Rossen: not used anywhere
16:27:05 <fantasai> Rossen: If you want something to stick to any particular position
16:27:20 <fantasai> Rossen: Would most likely include it as part of the item itself, so would tag along with item
16:27:38 <fantasai> Rossen: So don't see what we would bring to the users, to implement static position
16:27:47 <fantasai> Rossen: For implementation, easier to do origin of the flexbox
16:28:15 <fantasai> Rossen: Haven't seen any compelling use cases for it
16:30:09 <fantasai> fantasai explains a lot about Mozilla's implementation of frame lists
16:31:49 <fantasai> fantasai: So A and E would be equally difficult.
16:32:02 <Zakim> + +1.206.675.aabb
16:32:21 <fantasai> TabAtkins_: A is easiest from a spec perspective, even if it's not easiest by implementation
16:32:31 <Zakim> -tabatkins_
16:32:34 <fantasai> florian: spec authors are last on the priority list
16:32:58 <fantasai> anton: Nobody's said anything about any of them being impossible to implement
16:33:19 <SteveZ> fantasai: points out that it is necessary to keep the position of abspos items in the document because that affects paint order
16:33:45 <fantasai> Rossen: Even from our POV, implementing one vs other (A vs other) would have some better perf characteristics during content updates, but that's about it
16:33:54 <fantasai> Rossen: computing either position is not a problem
16:34:00 <fantasai> Rossen: Not very difficult to implement
16:34:08 <fantasai> glazou: I'm with Anton, author expectation is quite important
16:34:21 <fantasai> glazou: We are doing things in CSS these days that were quoted as "impossible" by browsers earlier
16:34:28 <krit> Zakim, aabb is TabAtkins_
16:34:29 <Zakim> +TabAtkins_; got it
16:34:32 <fantasai> glazou: complexity of implementation is an argument, but not the ultimate one
16:34:34 <Zakim> +[Microsoft.a]
16:34:38 <Zakim> -??P43
16:34:40 <Bert> (With regions, grid templates, and flexboxes, the list of elements to justify may have little relation to the source tree. It's a list in some overlaid structure, a "shadow tree" (not necessarily even a tree).)
16:34:41 <fantasai> glazou: Readability of spec and expectation of authors seems more important.
16:35:01 <Rossen> Zakim, [Microsoft.a] is me
16:35:01 <Zakim> +Rossen; got it
16:35:06 <fantasai> TabAtkins_: Unless we apply a bunch of properties to placeholders, in non-complex cases the static position will be completely arbitrary
16:35:19 <fantasai> TabAtkins_: Placeholder just goes to order of zero, then that will have no relation to order author intends there
16:35:40 <fantasai> TabAtkins_: people seem to be very reluctant to apply properties to placeholders
16:35:51 <fantasai> Florian: Have we talked enough that we can straw poll?
16:36:02 <fantasai> szilles: Would like to make one comment. 
16:36:26 <fantasai> szilles: If you pick D then the positioning of abspos under ordering is completely arbitrary.
16:36:52 <fantasai> s/is/is not/
16:37:02 <fantasai> szilles: gets glued to next flex item
16:37:12 <fantasai> Anton: It's slightly arbitrary, but static position is always slightly arbitrary
16:37:18 <fantasai> szilles: It's at least predictable
16:37:30 <fantasai> glazou: Let's try doing a straw poll
16:37:34 <fantasai> glazou: We have 5 options A-E
16:37:36 <glazou> Zakim, who is here?
16:37:36 <Zakim> On the phone I see glazou, glenn, plinss, florian, stearns, SteveZ, [Apple], antonp, ??P15, Bert, smfr, CesarAcebal, fantasai, [Microsoft], TabAtkins_, Rossen
16:37:39 <Zakim> [Apple] has hober
16:37:39 <Zakim> [Microsoft] has arronei
16:37:39 <Zakim> On IRC I see Rossen, logbot, SteveZ, smfr, antonp, TabAtkins_, CesarAcebal, florian, Bert, krit, glenn, arno, jet, RRSAgent, Zakim, glazou, shepazu, ChrisL, Ms2ger, florianr,
16:37:42 <Zakim> ... arronei, jwir3, dglazkov, gsnedders, stearns, trackbot, alexmog, vhardy, sylvaing_away, heycam, shans, CSSWG_LogBot, paul___irish, krijnhuman, hober, fantasai, plinss, Hixie
16:38:16 <fantasai> Straw Poll
16:38:37 <fantasai> fantasai: I think B, D, and E are different ways of expressing the same thing
16:38:43 <fantasai> glenn: abstain
16:38:45 <fantasai> plinss: abstain
16:38:48 <fantasai> Florian: C or E
16:38:58 <fantasai> szilles: B, then A
16:39:03 <fantasai> s/B/D
16:39:13 <fantasai> hober: abstain
16:39:16 <fantasai> anton: D, then A
16:39:23 <Bert> Bert: A or D
16:39:31 <fantasai> smfr: abstain
16:39:40 <fantasai> césar: abstain
16:39:42 <fantasai> fantasai: not C
16:39:50 <fantasai> arron: abstain
16:39:54 <fantasai> tab: A or C
16:39:58 <fantasai> rossen: abstain
16:40:11 <fantasai> * missed a few abstentions there
16:40:15 <fantasai> glazou: poll is not very conclusive
16:40:47 <fantasai> szilles: All answers, except one or two Cs, were advocating no traceable effect of using abspos
16:41:06 <glazou> my poll was not minuted : wanted A then D but going to abstain
16:41:50 <fantasai> ROssen: I strongly support that
16:42:07 <fantasai> RESOLVED: placeholders have no impact on surrounding flex layout
16:43:59 <fantasai> fantasai: I think B, D, and E are roughly the same, they're trying to accomplish the same thing but expressed differently
16:44:18 <fantasai> fantasai: only might be different in edge cases, which we could discuss
16:44:48 <fantasai> fantasai: edge cases are
16:45:01 <fantasai> fantasai: a) between flex items, glued to next or previous
16:45:23 <fantasai> fantasai: b) if it's at a wrap point, does it wrap with the next, or wrap with the previous
16:45:28 <fantasai> Anton: I would vote next in both cases
16:46:01 <fantasai> TabAtkins_: given both are completly scrambled up by order, it's completely arbitrary
16:46:12 <fantasai> fantasai: this is after reordering 
16:46:30 <fantasai> fantasai: c) if no flex items, where does it go
16:46:53 <fantasai> Rossen: Should go exactly where the first flex item would have gone
16:47:16 <fantasai> Rossen: If trying to keep as close as possible to flow layout
16:47:35 <fantasai> Rossen: In flow layout, is it with the next or previous item? Does it stick to wrapping or not?
16:47:54 <fantasai> Rossen: Use those rules
16:48:05 <SteveZ> +1 for Rossen's reasoning
16:48:21 <fantasai> Rivoal: I'm ok with that reasoning, and if everybody agrees, we can resolve and that and have the editors go off and spec that, whichever it is
16:48:35 <fantasai> Rossen: Shouldn't something like this go in the positioning spec?
16:48:55 <drublic> drublic has joined #css
16:48:56 <fantasai> Anton: In normal layout, says "position as if it were not floated and position was static"
16:49:13 <fantasai> Rossen: Would hope that all static positions be put into css3-positioning
16:49:29 <fantasai> TabAtkins_: Would prefer not t have this be undefined right now
16:49:57 <fantasai> fantasai: I think we want to define it here
16:50:46 <fantasai> Straw Poll A vs. Rossen's Principles
16:51:09 <fantasai> Rossen's Principles are, do the same thing you'd do in normal flow layout
16:51:32 <fantasai> Rossen: Either going with precise position, or origin
16:51:37 <fantasai> Rossen: For grid, we take the origin of the current cell
16:51:43 <fantasai> Rossen: In grid, you can have static auto position
16:51:54 <fantasai> Rossen: but you can define grid column and grid row, which will put you in a particular grid cell
16:52:00 <fantasai> Rossen: you get something better than origin of the grid
16:52:05 <fantasai> Rossen: But it's still origin of the cell
16:52:16 <fantasai> Rossen: Now if you have 5 items in that cell, we won't do anything better than 0 0
16:52:29 <fantasai> fantasai: items in the same cell stack on top of each other anyways
16:53:02 <fantasai> Florian: This gives me another argument against A. More likely to wind up with things on top of each other if you're not careful
16:53:17 <fantasai> TabAtkins_: That's the definition of abspos
16:53:18 <fantasai> glazou: A
16:53:28 <fantasai> plinss: abstain
16:53:31 <fantasai> glenn: abstain
16:53:39 <fantasai> Florian: Rossen
16:53:47 <fantasai> Alan: Rossen
16:53:59 <fantasai> szilles: Rossen
16:54:04 <fantasai> hober: abstain
16:54:06 <fantasai> Anton: Rossen
16:54:10 <fantasai> Bert: abstain
16:54:14 <fantasai> smfr: abstain
16:54:18 <fantasai> César: abstain
16:54:22 <fantasai> fantasai: abstain
16:54:24 <fantasai> Arron: Rossen
16:54:26 <fantasai> Tab: A
16:54:39 <fantasai> Rossen: Rossen
16:54:46 <fantasai> Consensus on Rossen
16:54:59 <fantasai> Florian: Can we let the editors now figure this out?
16:55:37 <fantasai> RESOLVED: Abspos static position defined according to Rossen's principles above
16:55:56 <glazou> yes
16:55:59 <glazou> sorry krit
16:56:04 <krit> glazou: :)
16:56:41 <fantasai> fantasai: Question is, does 'order' affect the absolutely-positioned child, either wrt painting order or wrt static position
16:56:54 <fantasai> Florian: If we went with A, I'd say no, but given we're not going with A, I think 'order' is usefl.
16:57:12 <fantasai> TabAtkins_: The issue is, we literally do nothing for placeholders in any thing else
16:57:25 <fantasai> TabAtkins_: e.g. we don't honor 'float' or 'clear' when computing static positions
16:57:31 <fantasai> No strong opinions
16:57:37 <fantasai> szilles: I would go for not honoring it
16:57:50 <fantasai> szilles: Best way to keep things consistent
16:57:53 <TabAtkins_> Note that *not* ordering it makes "Rossen's principles" much less coherent.
16:57:55 <fantasai> Florian: I can go with that
16:58:16 <ChrisL> I have some changes in fonts too, but did not put the right class on the changed bit
16:58:33 <ChrisL> sorry w/c
16:58:56 <fantasai> RESOLVED: 'order' does not apply to abspos children of a flexbox, placeholders have all initia/inherited values for poperties
16:59:41 <fantasai> fantasai: At TPAC resolved to change 'order' to <integer>, but Tab forgot to edit this in.
16:59:58 <fantasai> TabAtkins_: Question is do we reverse the resolution or edit it in
17:00:19 <fantasai> szilles: When do two numbers equal each other?
17:01:26 <fantasai> RESOLVED: Fix issue 22
17:02:56 <fantasai> That's all the issues
17:03:11 <Zakim> -glenn
17:03:13 <Zakim> -[Apple]
17:03:13 <Zakim> -smfr
17:03:13 <fantasai> Editors to edit all the issues, post text for review, and decide on CR next week
17:03:14 <Zakim> -[Microsoft]
17:03:14 <Zakim> -stearns
17:03:15 <Zakim> -Rossen
17:03:15 <Zakim> -glazou
17:03:16 <Zakim> -Bert
17:03:18 <Zakim> -SteveZ
17:03:20 <Zakim> -CesarAcebal
17:03:22 <Zakim> -plinss
17:03:24 <Zakim> -antonp
17:03:28 <Zakim> -fantasai
17:03:42 <Zakim> -TabAtkins_
17:04:04 <arno> arno has joined #css
17:04:44 <arno1> arno1 has joined #css
17:05:30 <Zakim> -??P15
17:05:40 <antonp> antonp has left #css
17:06:42 <Zakim> -florian
17:06:44 <Zakim> Style_CSS FP()12:00PM has ended
17:06:44 <Zakim> Attendees were glazou, glenn, plinss, florian, +1.206.675.aaaa, stearns, tabatkins_, SteveZ, hober, antonp, Bert, smfr, CesarAcebal, fantasai, arronei, +1.206.675.aabb,
17:06:44 <Zakim> ... [Microsoft], Rossen
17:07:19 <krit> krit has left #css
17:13:57 <fantasai> TabAtkins_: So, running tests now...
17:14:07 <TabAtkins_> Tests?
17:14:14 <fantasai> TabAtkins_: On behavior of abspos
17:14:19 <TabAtkins_> Oh.
17:14:33 <fantasai> TabAtkins_: Chrome has a weird line-breaking bug, but Opera and Mozilla place the abspos at the edge of the preceding item
17:14:43 <fantasai> when it occurs at a line break
17:14:48 <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%20%20div%20{%20width%3A%203em%3B%20border%3A%20solid%3B%20}%0A%20%20span%20{%20border%3A%20solid%20blue%3B%20position%3A%20absolute%3B%20}%0A%3C%2Fstyle%3E%0A%3Cdiv%3E%0A%E4%B8%80%E4%BA%8C%E4%B8%89%3Cspan%3E%3C%2Fspan%3E%E5%9B%9B%0A%3C%2Fdiv%3E
17:16:46 <fantasai> All three browsers place the box with the next character rather than the previous in the presence of letter-spacing
17:17:15 <fantasai> I can't trigger justification on any of them, though
17:17:20 <fantasai> so I can't test justification directly
17:20:43 <fantasai> So, thinking about how to spec this...
17:22:00 <CesarAcebal> CesarAcebal has joined #css
17:22:56 <fantasai> I think we could just say that each abspos child of a flex container is wrapped in an anonymous flex item (or consecutive sequences of them are wrapped in an anonymous flex item) just like the spec used to say
17:23:05 <fantasai> and then define how they don't impact justification
17:27:13 <TabAtkins_> I think I'd prefer to have them be placeholder items, at order 0.  We run step 0 of the layout algo, then attach each to the preceding non-placeholder item, then ignore them completely for the rest of the algo.
17:27:37 <fantasai> Then we have to deal with alignment
17:27:52 <fantasai> I'd rather have the anonwrapper be effectively the placeholder, and have everything else fall out from that
17:27:56 <fantasai> it's also closer to the old spec
17:28:12 <TabAtkins_> Hm? We don't have to worrya bout alignment at all.
17:28:31 <TabAtkins_> Because we ignore them during the alignment phase, since that's "the rest of the algo".
17:29:03 <TabAtkins_> We just attach them to the main-end cross-start side of the preceding item.
17:30:57 <TabAtkins_> Ugh, this is just going to be such a dumb idea.  People are imagining some sophisticated and desirable handling that won't exist.
17:33:08 <fantasai> if the preceding item is smaller than the cross-size of the line?
17:33:29 <fantasai> you don't want to attach it to the margin-box corner
17:33:42 <fantasai> you want it's main-axis position, but the cross-start edge of the line box
17:33:43 <fantasai> maybe
17:33:50 <fantasai> Then there's align-items
17:33:55 <fantasai> and how that impacts the placeholders
17:34:19 <TabAtkins_> Nothing should affect any of it.
17:34:45 <fantasai> text-align affects placeholders
17:35:38 <TabAtkins_> I don't want to try and translate every quirk of abspos text handling into flexbox.
17:37:38 <leaverou> leaverou has joined #css
17:38:37 <fantasai> reminds me, this all needs to be defined for block alignment as well...
17:38:43 <fantasai> >_<
17:39:59 <Ms2ger> Yay, defining stuff
17:40:11 <fantasai> no, no yay. static position sucks
17:40:12 <fantasai> :(
17:40:25 <TabAtkins_> And yet you voted to make it more complicated!
17:40:31 <fantasai> I voted not C
17:40:53 <TabAtkins_> And then abstained. ;_;
17:41:07 <fantasai> yep, because authors > spec editors
17:41:28 <TabAtkins_> Well, duh.  I voted A because the other options aren't actually better for authors either.
17:41:46 <fantasai> I think that's the case for row flexboxes
17:41:55 <fantasai> I think it doesn't actually matter much for wrapping flexboxes
17:42:12 <fantasai> but for column flexboxes I'm not so sure
17:42:12 <TabAtkins_> This option, since it doesn't transfer order to the placeholder and doesn't do a lot of other more sophisticated things, won't match author expectations in many cases.
17:43:08 <TabAtkins_> I actually think it's impossible to match author expectations well.  I'm with Rossen's earlier argument that, for app layout, static position is meaningless and arbitrary.
17:43:24 <TabAtkins_> I'm confused as to why he seemingly switched sides. :/
17:43:30 <fantasai> I think we'll see flexbox used for non-app layouts
17:43:48 <fantasai> catalogs, for instance, aren't apps ^_^
17:44:12 <TabAtkins_> I doubt you can come up with a reasonable use-case for static position in a flexbox used for catalogs.
17:44:40 <fantasai> yeah, probably
17:46:29 <TabAtkins_> Like I said, I think that people voted Rossen with an expectation in their head of paragraph-style layout, where static position does have some useful properties.
17:46:56 <TabAtkins_> I think static position is most useful for a few kinds of positioning hacks that should be solved by more powerful abspos.
17:49:09 <TabAtkins_> Basically, I think the committee decision resulted in a shitty half-decision that won't actually do anything very useful.  Some people will find ways to use it, and this will be used as justification for further spreading complicated static position to future specs.
17:49:41 <fantasai> I think it's good we resolved on not C :)
17:50:10 <jet> jet has joined #CSS
17:50:23 <TabAtkins_> Yeah, I'm fine with that, I don't care.  It was *a* simple, consistent treatment, but not the best.
17:52:19 <TabAtkins_> A is simple.  The others are less simple, and are consistent in particular ways, but inconsistent in others.
17:58:44 <fantasai> 		The <a href="http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width">hypothetical box</a> used to calculate the <i>static position</i> [[!CSS21]]
17:58:47 <fantasai> 		of an absolutely-positioned <i>flex item</i> corresponds to
17:58:50 <fantasai> 		that of an anonymous empty flex item
17:58:52 <fantasai> 		whose main-axis position coincides with the main-start edge of the subsequent real flex item
17:58:56 <fantasai> 		and, being hypothetical, has no effect on flex layout.
17:59:00 <fantasai> 		If there is no subsequent real flex item,
17:59:02 <fantasai> 		the hypothetical box's main-axis position is the main-end edge of the previous flex item,
17:59:06 <fantasai> 		else the main-start edge of the flex container.
18:00:08 <TabAtkins_> I see no need to explicitly talk about the hypothetical box.
18:00:20 <fantasai> Those are the terms CSS2.1 uses to define static position
18:00:30 <fantasai> and it makes it easy to write the spec prose here.
18:00:36 <fantasai> Unless you have a better proposal?
18:00:46 <TabAtkins_> Just define the static position directly.
18:01:00 <fantasai> No, not going to. Don't want to deal with bidi
18:01:15 <fantasai> It gets complicated, basically, when you involve bidi.
18:01:17 <TabAtkins_> Wait, what?  There's no bidi involved.  There's no text here, just flex items.
18:01:29 <fantasai> 'direction' affects which corner of the hypothetical box you pick
18:01:44 <fantasai> So will, eventually, 'writing-mode'.
18:02:04 <fantasai> By defining the hypothetical box, and letting that define the static position, we don't have to deal with that here.
18:02:42 <TabAtkins_> On the other hand, we have to deal with alignment and sizing.  You can't just say "has no effect on layout" when you're relying on an actual box to be created with a size and whatnot.
18:03:12 <fantasai> The size is zero, because it's anonymous and empty
18:13:55 <ksweeney> ksweeney has joined #css
18:14:49 <ksweeney> ksweeney has left #css
18:31:38 <TabAtkins_> No, by default the size of an anonymous item is 'stretch'.
18:40:48 <arno> arno has joined #css
18:43:05 <Zakim> Zakim has left #css