IRC log of css on 2012-06-20

Timestamps are in UTC.

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