15:17:39 <RRSAgent> RRSAgent has joined #css
15:17:39 <RRSAgent> logging to http://www.w3.org/2012/06/20-css-irc
15:17:44 <glazou> Zakim, this will be Style
15:17:44 <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 43 minutes
15:17:48 <glazou> RRSAgent, make logs public
15:23:43 <evanli> evanli has joined #css
15:29:36 <glazou> glazou has left #css
15:34:19 <bradk> bradk has joined #css
15:49:37 <glazou> glazou has joined #css
15:54:17 <koji> koji has joined #css
15:55:08 <glazou> koji: see my last tweet cc:ed to you
15:55:39 <glazou> koji: https://twitter.com/glazou/status/215467984704126977
15:56:46 <Zakim> Style_CSS FP()12:00PM has now started
15:56:47 <oyvind> oyvind has joined #css
15:56:53 <Zakim> +plinss
15:57:49 <glazou> Zakim, code?
15:57:49 <Zakim> the conference code is 78953 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), glazou
15:57:56 <Zakim> +??P42
15:58:02 <glazou> Zakim, ??P42 is me
15:58:02 <Zakim> +glazou; got it
15:59:12 <antonp> antonp has joined #css
16:00:10 <florian> florian has joined #css
16:00:25 <Zakim> +[Microsoft]
16:00:28 <arronei> zakim, microsoft has me
16:00:39 <Zakim> +arronei; got it
16:00:44 <Zakim> +??P46
16:00:48 <florian> Zakim, I am ??P46
16:00:48 <Zakim> +florian; got it
16:01:08 <Zakim> + +93550aaaa
16:01:17 <antonp> Zakim, aaaa is me
16:01:18 <Zakim> +[Microsoft.a]
16:01:26 <Zakim> +antonp; got it
16:01:29 <koji> glazou:thx
16:01:31 <smfr> smfr has joined #css
16:01:32 <florian> florian has left #css
16:01:42 <florian> florian has joined #css
16:01:50 <JohnJansen> JohnJansen has joined #css
16:01:59 <Zakim> +??P50
16:02:02 <Zakim> + +1.206.324.aabb
16:02:12 <sylvaing> Zakim, aabb is sylvaing
16:02:12 <Zakim> +sylvaing; got it
16:02:14 <Zakim> + +1.408.636.aacc
16:02:16 <nimbu> nimbu has joined #css
16:02:23 <smfr> Zakim: aacc is me
16:02:32 <smfr> i guess Zakim forgot everyone again
16:02:44 <Zakim> + +1.650.275.aadd
16:02:50 <smfr> Zakim, aacc is me
16:02:52 <Zakim> +smfr; got it
16:02:57 <smfr> Zakim: why you hate colons?
16:03:36 <Zakim> +fantasai
16:03:49 <bradk> zakim, aadd is me
16:03:49 <Zakim> +bradk; got it
16:03:55 <bradk> I think
16:04:08 <Zakim> + +1.415.832.aaee
16:04:30 <krit> zakim, aaee is me
16:04:30 <Zakim> +krit; got it
16:04:32 <JohnJansen> Zakim, Microsoft has JohnJansen
16:04:32 <Zakim> +JohnJansen; got it
16:04:48 <JohnJansen> is the phone working for anyone?
16:05:15 <smfr> JohnJansen: say something
16:05:24 <nimbu> how do I tell zakim i am in same conferencing phone systam as krit
16:05:37 <JohnJansen> so, I guess you didn't hear me :-)
16:05:48 <Zakim> +??P18
16:06:07 <antonp> I'm not really hearing anyone, just tiny bursts of phone activity
16:06:18 <fantasai> zakim, krit has nimub
16:06:18 <Zakim> +nimub; got it
16:06:22 <krit> hober: what does w3c meme say?
16:06:27 <fantasai> zakim, nimub is nimbu
16:06:27 <Zakim> sorry, fantasai, I do not recognize a party named 'nimub'
16:06:32 <fantasai> :/
16:07:12 <fantasai> ScribeNick: fantasai
16:07:18 <fantasai> plinss: additions to agenda?
16:07:27 <fantasai> smfr: transforms and fixed backgrounds
16:07:47 <fantasai> florian: at bottom of agenda, leftovers from f2f, some have been addressed and should be removed
16:08:23 <fantasai> fantasai: an issue on counter style case-sensitivity
16:08:31 <fantasai> Topic: CSS2.1
16:08:38 <fantasai> http://wiki.csswg.org/topics/overflow-formatting-context
16:08:45 <fantasai> plinss: everyone had an action item to review this
16:09:16 <glazou> ROFL
16:09:25 <fantasai> antonp: So, this is an issue about introducing a new term "formatting context" which will cover things like BFC but also be used to cover things like "flexbox FC" and "table FC"
16:09:38 <glazou> #antonp { speech-rate: slower; }
16:09:43 <fantasai> antonp: It came up in the Flexbox spec, because its children are not formatted as blocks
16:09:59 <fantasai> antonp: Realized it would be useful to have a term simply "formatting context"
16:10:21 <fantasai> antonp: would solve problem in specs currently, e.g. for overflow it should apply to a wider class of items than just block formatting contexts
16:10:37 <fantasai> antonp: similar issue with containing block
16:10:50 <fantasai> antonp: answer here is an element that establishes a formatting context, not just a block formatting context
16:10:56 <fantasai> antonp: this also speaks to some bugs we have on 2.1
16:11:14 <fantasai> antonp: related to the fact that currently we have problems with definitions of overflow and containing block because they do forget to handle tables
16:11:26 <fantasai> antonp: These edits would fix those bugs and give us a nice editorial hook for future specs
16:11:43 <fantasai> florian: after reading what was written and listening to what was said, I think the logic makes sense
16:11:58 <fantasai> florian: I don't feel comfortable enought that I know enough details to be sure this all works
16:12:15 <fantasai> florian: I therefore hesitate to vote for it
16:12:57 <fantasai> fantasai: I think these edits are correct (I wrote some of them). Would like to hear from dbaron too though
16:13:14 <fantasai> arronei: I think these changes are fine, but wondering why we're editing 2.1 here
16:14:22 <fantasai> arronei: 2.1 isn't completely clear here, but it's not obviously wrong
16:14:40 <fantasai> arronei: why not just start a CSS3 spec
16:15:02 <fantasai> fantasai: Our current specs depend on 2.1 right now, not on non-existent or early-draft specs
16:15:37 <fantasai> plinss: I'm also concerned about editing 2.1, but also see the problem with not having equivalent text in level 3
16:16:01 <Rossen> Rossen has joined #css
16:16:32 <fantasai> proposal - resolve pending dbaron's approval
16:18:42 <fantasai> Rossen: Is this going to have any changes to the behavior of tables? Or is it just editorial?
16:19:11 <fantasai> antonp: When there was a lot of rewriting of blocks and boxes and things, there were some thing that were broken as part of that
16:19:24 <fantasai> antonp: e.g. overflow used to a pply to tables, but doesn't as a result of that
16:19:41 <fantasai> antonp: basically the edit there is taking the spec back to what it was supposed to be saying
16:19:58 <fantasai> antonp: we can fix those two bugs by being very explicit, and just say exactly which boxes are affected
16:20:09 <fantasai> antonp: but the primary motivation for using this term is that CSS3 specs need to use it
16:20:23 <fantasai> antonp: since it's useful to 2.1 and 3, better to make these edits
16:20:55 <fantasai> Rossen: just concerned about introducing any implementation changes to 2.1
16:21:13 <fantasai> sylvaing: the question is, do we need to change testcases. If yes, then we need to take a closer look at this
16:21:20 <fantasai> sylvaing: If there are testcases, should be part of the proposal
16:21:37 <fantasai> antonp: I believe there are testcases, part of the reason these bugs were filed was because they didn't match the testcases
16:22:14 <sylvaing> bringing the spec in line with the test suite is fine imo
16:22:56 <fantasai> http://test.csswg.org/shepherd/testcase/overflow-applies-to-013/name/overflow/title/table/
16:23:18 <fantasai> RESOLVED: Proposal accepted pending dbaron's review and acceptance
16:23:41 <Zakim> -??P18
16:23:43 <Zakim> +[Microsoft.aa]
16:23:52 <fantasai> Topic: Flexbox
16:23:59 <Rossen> Zakim, [Microsoft.aa] is me
16:23:59 <Zakim> +Rossen; got it
16:24:33 <fantasai> fantasai: First issue is, does the order property have an effect on the z-order/ painting order
16:25:09 <fantasai> fantasai: do you follow document order when painting, or do you follow the order-modified order
16:25:12 <fantasai> alexmog: also tab-order
16:25:15 <fantasai> fantasai: that's a separate question
16:26:07 <fantasai> fantasai sez stuff
16:26:22 <fantasai> smfr: From implementation perspective, would prefer if flex order didn't affect painting order
16:26:44 <fantasai> alexmog: I think these are related, if we make tab-order change, then z-order should also change
16:27:07 <fantasai> alexmog: from accessibility pov, whole point of changing order is that you don't change your tree, you only change little bit in cells, it looks like the order is different
16:27:17 <jet> jet has joined #CSS
16:27:19 <fantasai> alexmog: tab dialogs, one item's bring to front
16:27:24 <fantasai> alexmog: you still read stuff in original source order
16:27:59 <fantasai> smfr: if you have flex order affect painting order, the author puts in z-index, what happens?
16:28:08 <fantasai> smfr: what stacking context are you using to paint the flex items
16:28:51 <fantasai> smfr: can items interleave with flex items
16:29:00 <fantasai> fantasai: z-index still works as usual
16:29:29 <fantasai> fantasai: but if z-index has same number or auto, you use document order
16:29:52 <fantasai> fantasai: question is, does 'order' affect the document order fallback for painting, or do you just you striaght-up document order
16:29:58 <alexmog_> alexmog_ has joined #css
16:30:25 <dbaron> dbaron has joined #css
16:30:37 <glazou> who flushed the toilets?
16:30:47 <fantasai> alexmog: the last time we discussed this, a couple years ago, we concluded at that point that reordering is a major enough change that everything looks as if it really was in a different order, and it makes sense to actually render in this new order
16:30:57 <Zakim> + +1.415.766.aaff
16:31:06 <fantasai> alexmog: nobody could come up with use cases where it's important to preserve source order for painting
16:31:32 <fantasai> alexmog: if there is any overlap of items, if it is ever intentional, painting order that matches order in flexbox would make sense
16:31:49 <miketayl_r> miketayl_r has joined #css
16:32:07 <fantasai> alexmog: IE reorders by order, and it does simplify implementation
16:32:32 <fantasai> fantasai^: IIRC, webkit prefers painting order to be affected; for Mozilla, we can go either way, but I think simplifies our implementation somewhat
16:32:43 <fantasai> smfr: if webkit impl is ok with it, then fine with me
16:32:52 <fantasai> antonp: [...]
16:33:14 <fantasai> antonp: if you make 3-column layout, you probably want each column to be stacking context anyway, would use z-index anyway
16:33:29 <fantasai> florian: I think I'm hearing most people wanting painting order following order
16:33:52 <fantasai> plinss: Yes, though I'm hearing some concerns about tab-order
16:33:53 <miketaylr> miketaylr has joined #css
16:34:12 <fantasai> fantasai would like to tackle that as a separate issue, since it affects other things
16:34:19 <fantasai> Rossen: do we have a similar thing for grid?
16:34:35 <fantasai> alexmog: Discussed in grid, in grid there is no order, everything is explicitly placed into its slot
16:34:43 <fantasai> alexmog: no sequence in grid, so not applicable there
16:35:09 <fantasai> alexmog: if at some point order is universally applicable, then it should be treated same way wherever it's applicable
16:35:18 <fantasai> plinss: proposal is for order to affect painting order. Any objections?
16:35:27 <fantasai> RESOLVED: order affects painting order
16:35:48 <fantasai> http://wiki.csswg.org/topics/css3-flexbox-flexbox-replaced-children
16:36:14 <fantasai> http://www.w3.org/TR/2012/WD-css3-flexbox-20120612/#flex-items
16:36:21 <fantasai> Current spec text goes with Proposal A
16:36:58 <fantasai> fantasai: proposal A can be recast in terms of proposal B at a later point
16:37:11 <fantasai> alexmog: I would prefer to revert to the old wording
16:37:41 <fantasai> alexmog: Someone said it's a problem with replaced elements vs. non-replaced elements having different styling during loading 
16:37:50 <fantasai> alexmog: whatever browser does this cannot pass Acid2
16:38:01 <fantasai> ...
16:38:05 <fantasai> florian: for me that's not the motivation
16:38:17 <fantasai> florian: we're doing this because these elements have the wrong display type
16:38:30 <fantasai> florian: for other things the user can change the display type to whatever they want
16:38:36 <fantasai> florian: Proposal B lets you opt out
16:40:01 <fantasai> fantasai clarifies that Alex is asking for previous WD's behavior
16:40:11 <fantasai> dbaron: what happens if an element is replaced due to CSS3 'content' property?
16:40:21 <fantasai> florian: I like proposal B best
16:40:33 <fantasai> florian: I would not like to be stuck with Proposal A forever
16:40:40 <fantasai> florian: what Alex is saying sounds suboptimal to me but is acceptable
16:41:05 <fantasai> alexmog: I can live with any of those, just seems inconsistent that replaced inline elements have special behavior that's already defined an known
16:41:10 <fantasai> alexmog: and object fallback depends on those
16:41:15 <dbaron> alex (in response to dbaron): the same (follow the rules for whether 'width' and 'height' apply)
16:42:39 <fantasai> fantasai: One complication here is that Mozilla falls back to inline when <img> elements don't load, but some other browsers treat them as inline-block
16:42:55 <fantasai> fantasai: whereas I believe some other impls don't
16:43:00 <fantasai> fantasai: so you'll get different results
16:43:45 <fantasai> antonp: I think it make sense for these elements to have special behavior
16:43:53 <dbaron> I don't see anything in html5 saying img should be anything other than display:inline when there's no resource
16:43:59 <fantasai> plinss: have 3 proposals on table, not hearing consensus 
16:44:10 <fantasai> florian: To me Proposal A is only acceptable because we can later switch to B
16:44:18 <dbaron> same for canvas
16:44:20 <fantasai> florian: To me it doesn't make sense to have A in the list because what I want is B
16:45:25 <fantasai> fantasai: I think I'd like to summarize the situation and resolve when Tab's back
16:45:32 <fantasai> florian: Does anyone disagree that B is better than A
16:45:42 <fantasai> antonp: I think A should be followed by B, but not sure it should be instantly
16:46:25 <fantasai> florian: concerned that we might be stuck with A if it takes too long to do B
16:46:33 <fantasai> fantasai: ...
16:46:38 <fantasai> alexmog: if A or B, would rather do B
16:47:03 <fantasai> alexmog: yet another thing to do would be to treat any element that is a direct child of flexbox as a flex items
16:47:13 <fantasai> alexmog: from all usecase we have, plaintext in flexbox is not a use case
16:47:23 <fantasai> alexmog: just do something to not lose content when it's there
16:47:37 <fantasai> alexmog: could just have any element, e.g. <b> or <i>, be a flex item
16:47:47 <fantasai> alexmog: you'd get weird results if you have formatted text in a flexbox, but that's not a use case
16:48:20 <fantasai> ACTION: fantasai summarize discussion
16:48:20 <trackbot> Created ACTION-476 - Summarize discussion [on Elika Etemad - due 2012-06-27].
16:48:22 <bradk> * { display: flex; }
16:48:46 <fantasai> fantasai^: don't think we'll get stuck with A, B just has A implemented as ua.css rules
16:49:01 <fantasai> fantasai^: Have a bigger problem that might get stuck with flex items returning 'display: block'
16:49:09 <fantasai> fantasai^: and can't change to returning 'display: flex-item'
16:49:15 <fantasai> Topic: Background Attachment and Transforms
16:49:16 <plinss> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17521
16:49:23 <smfr> http://www.w3.org/TR/css3-transforms/
16:49:29 <fantasai> smfr: In CSS transforms spec there's a sentence that says
16:49:36 <fantasai> smfr: [quotes spec]
16:49:56 <fantasai> smfr: and there's a note that this behaves like a porthole -- you see the background through the porthole
16:50:10 <fantasai> smfr: this kindof makes sense for 2D transforms, butfor 3D it's extremely hard to implement
16:50:22 <fantasai> smfr: Making that element behave like a porthole where you see an untransformed background
16:50:40 <smfr> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17521
16:50:44 <fantasai> smfr: one possible amendment to the spec owuld be to say that bg-attach: fixed affected by trasnform treated like scroll
16:51:19 <Zakim> -antonp
16:51:28 <antonp> antonp has left #css
16:51:44 <fantasai> fantasai: Would it make sense to have the fixed background be transformed with the rest of the element? Rather than just ignoring fixedness
16:51:56 <fantasai> florian: would make sense, why would you do that as an author?
16:52:13 <fantasai> smfr: Your suggestion is tricky because how you render that background before applying that transformed
16:52:33 <fantasai> smfr: so, you render the element as if screen-aligned, then transform
16:52:38 <fantasai> smfr: not sure what left/top offset you'd use
16:52:49 <fantasai> smfr: when you scroll page you'll have this shifting of that background
16:53:12 <fantasai> krit: background should transform with the element
16:53:35 <fantasai> smfr: dbaron gave us some history, that bg-attach fixed was only intended for root element.
16:53:50 <fantasai> smfr: sortof crept into applying to other elements
16:54:02 <fantasai> smfr: any other implementers with feedback? IE?
16:54:18 <dbaron> I'm sure Gecko does something, but I don't know what, and it's hard to work out what's hard off the top of my head.
16:54:21 <fantasai> arronei: Not sure, have to look that up and check
16:54:42 <fantasai> florian: I don't know for Opera
16:54:53 <fantasai> smfr: maybe get action items from other vendors to investigate
16:55:06 <fantasai> florian: from our POV, probably too early to tell
16:55:17 <fantasai> sylvaing: pretty sure we don't do porthole thing, but I'll check what we do
16:55:28 <fantasai> krit: are there test files?
16:55:42 <fantasai> ACTION: smfr make a testcase
16:55:42 <trackbot> Created ACTION-477 - Make a testcase [on Simon Fraser - due 2012-06-27].
16:55:46 <fantasai> ACTION: florian ask Opera
16:55:47 <trackbot> Created ACTION-478 - Ask Opera [on Florian Rivoal - due 2012-06-27].
16:55:59 <fantasai> ACTION: dbaron check Gecko wrt bg-attach and transforms
16:56:00 <trackbot> Created ACTION-479 - Check Gecko wrt bg-attach and transforms [on David Baron - due 2012-06-27].
16:56:12 <fantasai> ACTION: sylvaing check bg-attach with transforms
16:56:12 <trackbot> Created ACTION-480 - Check bg-attach with transforms [on Sylvain Galineau - due 2012-06-27].
16:56:22 <fantasai> plinss: should also give some thought to what the right thing to do is 
16:56:42 <fantasai> bradk: Sounds like if the bg was large enough, and coordinates ok, could have something look good
16:56:47 <fantasai> s/something/portal
16:56:58 <fantasai> deferred to next week
16:57:05 <fantasai> Topic: page-break: recto/verso
16:58:32 <fantasai> fantasai summarizes
16:58:49 <fantasai> glazou: These will be easy to understand in Europe
16:58:56 <fantasai> plinss: these are industry standard terms going back ages
16:58:58 <fantasai> http://en.wikipedia.org/wiki/Recto_and_verso
16:59:16 <fantasai> florian: sounds good to me
16:59:28 <fantasai> RESOLVED: add recto/verso values to page-break-before/page-break-after in css3-break
16:59:37 <Zakim> -krit
16:59:39 <Zakim> -glazou
16:59:40 <Zakim> -Rossen
16:59:42 <Zakim> -[Microsoft]
16:59:44 <Zakim> -dbaron
16:59:46 <Zakim> -fantasai
16:59:49 <Zakim> -sylvaing
16:59:50 <Zakim> -smfr
16:59:52 <Zakim> -plinss
16:59:54 <Zakim> -[Microsoft.a]
16:59:57 <Zakim> -bradk
17:00:23 <Zakim> -??P50
17:00:52 <Zakim> -florian
17:00:53 <Zakim> Style_CSS FP()12:00PM has ended
17:00:53 <Zakim> Attendees were plinss, glazou, arronei, florian, +93550aaaa, [Microsoft], antonp, +1.206.324.aabb, sylvaing, +1.408.636.aacc, +1.650.275.aadd, smfr, fantasai, bradk,
17:00:53 <Zakim> ... +1.415.832.aaee, JohnJansen, nimub, Rossen, +1.415.766.aaff, dbaron
17:01:04 <florian> florian has left #css
17:04:15 <smfr> smfr has left #css
17:05:01 <oyvind> oyvind has left #css
17:06:01 <nimbu> nimbu has joined #css
17:16:30 <evanli> evanli has left #css
17:46:57 <fantasai> sylvaing: didn't you have a note you wanted to add to css3-background?
17:47:05 <sylvaing> yes, it's on www-style
17:47:34 <sylvaing> http://lists.w3.org/Archives/Public/www-style/2012Jun/0445.html
17:47:59 <sylvaing> rewordings welcome, I didn't spend much time on it but hopefully the goal is clear
17:48:28 <fantasai> cool, thanks :)
17:49:13 <sylvaing> I can't think of other things myself
17:49:54 <sylvaing> I do want to spend more time reviewing css3-background testcases though
18:08:48 <jacobg> jacobg has joined #css
18:11:07 <krit> krit has joined #css
18:32:53 <jet> jet has joined #CSS
18:52:29 <Zakim> Zakim has left #css
18:56:44 <krit> krit has joined #css
19:08:48 <stearns> stearns has joined #css
19:12:12 <dbaron> dbaron has joined #css
19:13:40 <ksweeney1> ksweeney1 has joined #css
19:25:22 <logbot> logbot has joined #css
19:34:04 <nimbu> nimbu has joined #css
20:09:06 <tantek> tantek has joined #css
20:26:08 <ksweeney> ksweeney has joined #css
20:26:22 <krit> krit has joined #css
20:29:09 <ksweeney> ksweeney has left #css
20:42:18 <tantek> tantek has joined #css
20:47:42 <tantek> tantek has joined #css
21:03:33 <nimbu> nimbu has left #css
21:11:29 <krit> krit has joined #css
21:12:11 <krit1> krit1 has joined #css
21:13:27 <miketayl_r> miketayl_r has joined #css
22:01:45 <jacobg1> jacobg1 has joined #css
22:04:48 <jacobg> jacobg has joined #css
22:06:39 <jacobg> jacobg has left #css
22:51:51 <myakura> myakura has joined #css
22:52:49 <myakura_> myakura_ has joined #css
22:58:46 <stearns> stearns has joined #css
23:42:52 <nimbu> nimbu has joined #css
23:57:19 <myakura> myakura has joined #css
23:57:32 <myakura_> myakura_ has joined #css
23:57:53 <myakura> myakura has joined #css