/irc-logs / w3c / #css / 2012-05-10 / end

Options:

# Session Start: Thu May 10 00:00:00 2012
# Session Ident: #css
# [00:15] * plinss is now known as plinss_away
# [00:41] * Quits: tabatkins__ (qw3birc@128.30.52.28) (Ping timeout)
# [00:49] * Joins: jdaggett (jdaggett@87.174.195.114)
# [00:50] * Quits: jdaggett (jdaggett@87.174.195.114) (Connection reset by peer)
# [00:55] * Quits: nimbu (Adium@192.150.10.200) (Quit: Leaving.)
# [01:11] * Quits: glenn (gadams@88.71.76.2) (Client exited)
# [01:31] * Quits: paul_irish (paul___iri@205.186.165.150) (Ping timeout)
# [01:33] * Joins: paul___irish (paul___iri@205.186.165.150)
# [01:40] * Quits: alexmog_ (qw3birc@128.30.52.28) (Ping timeout)
# [02:09] * Joins: arronei_ (Arron@24.17.123.244)
# [02:46] * Quits: arronei_ (Arron@24.17.123.244) (Quit: arronei_)
# [03:19] * Joins: shan (qw3birc@128.30.52.28)
# [03:20] * Quits: shan (qw3birc@128.30.52.28) (Quit: Page closed)
# [03:22] * Quits: tantek (tantek@159.63.23.38) (Quit: tantek)
# [03:36] * miketaylrawaylol is now known as miketaylr
# [03:46] * Quits: dstorey (Adium@144.189.101.1) (Quit: Leaving.)
# [04:20] * Joins: dstorey (Adium@67.180.84.179)
# [04:28] * Joins: tantek (tantek@67.103.42.57)
# [04:43] * Joins: bradk (bradk@166.205.138.217)
# [04:50] * Joins: arronei_ (Arron@24.17.123.244)
# [04:50] * Quits: arronei_ (Arron@24.17.123.244) (Quit: arronei_)
# [04:53] * Quits: bradk (bradk@166.205.138.217) (Quit: Signing Off. Buh-bye. )
# [04:53] * Joins: arno (arno@85.182.252.4)
# [04:53] * Quits: arno (arno@85.182.252.4) (Client exited)
# [04:58] * Joins: arno (arno@85.182.252.4)
# [05:02] * miketaylr is now known as miketaylrawaylol
# [05:08] * Quits: tantek (tantek@67.103.42.57) (Quit: tantek)
# [05:43] * Joins: nimbu (Adium@67.169.39.98)
# [05:46] * miketaylrawaylol is now known as miketaylr
# [06:08] * Quits: nimbu (Adium@67.169.39.98) (Quit: Leaving.)
# [06:10] * Joins: tantek (tantek@50.1.62.23)
# [06:28] * Joins: nimbu (Adium@67.169.39.98)
# [07:10] * Joins: glenn (gadams@88.71.76.2)
# [07:27] * Joins: arronei_ (Arron@24.17.123.244)
# [07:40] * Quits: kennyluck (kennyluck@114.43.121.173) (Ping timeout)
# [07:42] * Joins: kennyluck (kennyluck@114.43.117.100)
# [07:42] * Joins: myakura (myakura@221.171.5.98)
# [07:48] * Quits: kennyluck (kennyluck@114.43.117.100) (Client exited)
# [07:50] * Joins: kennyluck (kennyluck@114.43.117.100)
# [07:58] * Quits: glenn (gadams@88.71.76.2) (Client exited)
# [08:12] * Quits: arno (arno@85.182.252.4) (Quit: Leaving.)
# [08:19] * Quits: nimbu (Adium@67.169.39.98) (Quit: Leaving.)
# [08:45] * Joins: alexmog_ (qw3birc@128.30.52.28)
# [08:59] * Joins: florianr (florianr@193.105.139.140)
# [08:59] * Parts: florianr (florianr@193.105.139.140)
# [08:59] * Joins: florianr (florianr@193.105.139.140)
# [09:04] * Joins: jdaggett (jdaggett@193.105.139.140)
# [09:04] * Quits: myakura (myakura@221.171.5.98) (Client exited)
# [09:04] * sylvaing_away is now known as sylvaing
# [09:06] * Joins: dholbert (dholbert@98.248.36.12)
# [09:08] * Joins: alexmog2 (qw3birc@128.30.52.28)
# [09:10] * Joins: Liam (liam@128.30.52.169)
# [09:12] * Quits: miketaylr (miketaylr@70.112.101.224) (Quit: Leaving...)
# [09:12] * Joins: dbaron (dbaron@193.105.139.140)
# [09:19] <dbaron> trackbot, start meeting
# [09:20] * trackbot is preparing a teleconference
# [09:20] <trackbot> RRSAgent, make logs member
# [09:20] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [09:20] <RRSAgent> I have made the request, trackbot
# [09:20] <trackbot> Zakim, this will be Style_CSS FP
# [09:20] <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
# [09:20] <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
# [09:20] <trackbot> Date: 10 May 2012
# [09:20] * plinss_away is now known as plinss
# [09:20] <dbaron> RRSAgent, make logs public
# [09:20] <RRSAgent> I have made the request, dbaron
# [09:20] <dbaron> Zakim, room for 5?
# [09:20] <Zakim> ok, dbaron; conference Team_(css)07:12Z scheduled with code 26631 (CONF1) for 60 minutes until 0812Z
# [09:20] * Joins: glazou (glazou@193.105.139.140)
# [09:20] <Zakim> Team_(css)07:12Z has now started
# [09:20] <glazou> RRSAgent, make logs public
# [09:20] <RRSAgent> I have made the request, glazou
# [09:20] <Zakim> + +49.403.063.68.aaaa
# [09:20] <dbaron> Zakim, aaaa is Meeting_Room
# [09:20] <Zakim> +Meeting_Room; got it
# [09:21] <plinss> zakim, room for 5?
# [09:21] <Zakim> plinss, an adhoc conference was scheduled here less than 2 minutes ago
# [09:21] <dholbert> what's the bridge phone number?
# [09:21] <dbaron> Zakim, code?
# [09:21] <Zakim> the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), dbaron
# [09:21] <dbaron> dholbert, ^
# [09:21] <dholbert> dbaron, thanks
# [09:21] * Joins: arno (arno@193.105.139.140)
# [09:22] <dbaron> ScribeNick: dbaron
# [09:22] <dbaron> Topic: flexbox
# [09:22] * Joins: vhardy_ (vhardy@193.105.139.140)
# [09:23] <Zakim> + +1.831.334.aabb
# [09:23] <dbaron> Present: Jet Villegas, Bert Bos, Liam Quin, Koji Ishii, Peter Linss, Florian Rivoal, Daniel Glazman, Steve Zilles, Sylvain Galineau, Shane Stevens, Tab Atkins, Elika Etemad, Alan Stearns, Dirk Schultze, Arno Guidol, Edward O'Connor, David Baron, John Daggett, Glenn Adams, Alex Danilo, Vincent Hardy
# [09:23] <dbaron> Zakim, aabb is dholbert
# [09:23] <Zakim> +dholbert; got it
# [09:23] * Joins: jet (jet@193.105.139.140)
# [09:23] * Joins: glenn (gadams@193.105.139.140)
# [09:23] <Zakim> + +1.206.923.aacc
# [09:23] <dbaron> Zakim, aacc is alexmog
# [09:23] <Zakim> +alexmog; got it
# [09:24] <dbaron> Present: Jet Villegas, Bert Bos, Liam Quin, Koji Ishii, Peter Linss, Florian Rivoal, Daniel Glazman, Rik Cabanier, Steve Zilles, Sylvain Galineau, Shane Stevens, Tab Atkins, Elika Etemad, Alan Stearns, Dirk Schultze, Arno Guidol, Edward O'Connor, David Baron, John Daggett, Glenn Adams, Alex Danilo, Vincent Hardy
# [09:24] <fantasai> http://wiki.csswg.org/spec/css3-flexbox
# [09:24] * Joins: krit (krit@192.150.10.201)
# [09:25] <dbaron> fantasai: I broke this up into topics.
# [09:25] * Joins: kojiishi_ (kojiishi@193.105.139.140)
# [09:25] <dbaron> fantasai: First topic is box construction for flexboxes.
# [09:25] <dbaron> fantasai: First issue is whether pre white-space is preserved or ignored between elements.
# [09:26] <dbaron> fantasai: Similar to issue with tables: do we do wrapping for preserved whitespace between cells?
# [09:26] <dbaron> fantasai: Wasn't too much of a conclusion from www-style thread.
# [09:26] * Joins: shanestephens (shanesteph@193.105.139.140)
# [09:26] <dbaron> tab: Brad said he might have wanted to preserve whitespace; then I explained how that was kind of crazy.
# [09:27] <dbaron> tab: I think we should do what tables do: if there's significant preserved whitespace, then it's wrapped in an inline and wrapped in a cell.
# [09:27] <dbaron> fantasai: No, it goes away.
# [09:27] <dbaron> tab: Oh, right, tables always drop the whitespace.
# [09:27] <fantasai> http://www.w3.org/TR/CSS21/tables.html#anonymous-boxes
# [09:27] <dbaron> tab: Kenny says a stretch of whitespace should never generate an anonymous flexbox item, and this is consistent w/ how tables work.
# [09:28] <dbaron> (quoting www-style/2012Mar/0521.html)
# [09:28] <fantasai> http://www.w3.org/mid/4F6ACDF3.1030706@mozilla.com
# [09:28] <alexmog_> sounds fine
# [09:28] <dbaron> tab: So if nobody objects to dropping ws that occurs between items...?
# [09:29] <dbaron> dholbert: So dropping ws between items is a little different from what spec now says: only drop if it's all whitespace, but follow normal rules at the edges of flexbox items if they're not all whitespace.
# [09:29] <dbaron> tab: Yeah, that's what the spec currently recommends.
# [09:29] <fantasai> "If a box B is an anonymous inline containing only white space, and is between two immediate siblings each of which is either an internal table box or a 'table-caption' box then B is treated as if it had 'display: none'. "
# [09:30] <fantasai> -- CSS2.1
# [09:30] <dbaron> RESOLVED: Don't change the spec: keep the rule that we don't create anonymous flexbox items that are only whitespace.
# [09:30] * Joins: AlexD (qw3birc@128.30.52.28)
# [09:30] * Joins: SteveZ (chatzilla@193.105.139.140)
# [09:30] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012May/0250.html
# [09:30] <dbaron> fantasai: Next issue is magic behavior of display:inline elements
# [09:30] <dbaron> fantasai: Spec now says anonymous flex item is wrapped around non-atomic inline content.
# [09:30] <dbaron> tab: replaced elements don't get wrapped
# [09:31] <dbaron> fantasai: so you can have an element that is display:inline that becomes a flexbox item on its own because it's replaced
# [09:31] <dbaron> fantasai: Advantage is that the parent of a bunch of buttons or images is a flexbox, all children are individual items.
# [09:31] <dbaron> fantasai: Disadvantage is that you can't tell from computed values whether something will be a replaced element. (e.g., img, object)
# [09:32] <dbaron> fantasai: This has an impact on "can we compute various values?", e.g., a display-outside property computing to flexbox-item. Can't do that if it depends on if you loaded content.
# [09:33] <dbaron> fantasai: Other problem is on the usability side: with a bunch of images, if the images don't load, you end up with one big item instead
# [09:33] <dbaron> SteveZ: Since the intent was a replaced item, and it didn't load for some reason -- why not have it just keep behaving like a replaced item and have the fallback be text?
# [09:33] <dbaron> Zakim, who is noisy?
# [09:33] <vhardy_> Zakim, who is noisy?
# [09:34] <Zakim> dbaron, listening for 10 seconds I heard sound from the following: Meeting_Room (100%), alexmog (9%)
# [09:34] * kennyluck lol
# [09:34] <dbaron> fantasai: Experience reader should get is that you get the fallback content and not notice there's something missing.
# [09:34] <Zakim> vhardy_, listening for 15 seconds I heard sound from the following: Meeting_Room (97%)
# [09:34] <dbaron> Florian: I think it should only depend on what the display value is.
# [09:34] <dbaron> SteveZ: If I'm doing fallbacks for a11y, I'd like the buttons to still be there.
# [09:34] <dbaron> Tab: But by default buttons are display:inline
# [09:35] <dbaron> Tab: We should have made a bunch of these things display:inline-block by default in the HTML style sheet, but didn't.
# [09:35] * fantasai actually disagrees on that point
# [09:35] <dbaron> Tab: I don't think replaced-ness is a thing we can look at.
# [09:35] <dbaron> q+
# [09:35] * Zakim sees dbaron on the speaker queue
# [09:36] <alexmog_> q+
# [09:36] * Zakim sees dbaron, alexmog_ on the speaker queue
# [09:36] <dbaron> Tab: Making it stay an atomic inline means that in some of the fallback cases, you won't get text wrapping across lines (e.g., of alt text).
# [09:36] <glazou> Zakim, ack dbaron
# [09:36] <Zakim> I see alexmog_ on the speaker queue
# [09:36] <fantasai> dbaron: I guess I'm not that worried about dependency on replacedness from technical perspective
# [09:36] <fantasai> dbaron: more worried about weirdness of .. difference in behavior btw having an image in the middle of some text
# [09:37] <fantasai> dbaron: vs. an inline in the middle of some text
# [09:37] <fantasai> Tab: if you're trying to guess, like we are right now
# [09:37] <fantasai> Tab: if you had a flexbox with 3 items: text, image, text, you get 3 flexbox items
# [09:37] <fantasai> Tab: if we're not smart about it, then you get one item
# [09:37] <fantasai> Tab: But then if you fill the flexbox with buttons or images, they won't flex
# [09:38] <fantasai> Tab: If you fill the flexbox with text directly, that's not really a good use case
# [09:38] <glazou> Zakim, ack alexmog
# [09:38] <Zakim> I see no one on the speaker queue
# [09:38] <dbaron> Alex: I'd like to get back to reason for this rule.
# [09:38] <dbaron> Alex: We have this rule because buttons (e.g.) not being flexbox items is a really big problem.
# [09:38] <dbaron> Alex: Whatever happens to ... inlines, should ... for anonymous flexbox items.
# [09:39] <dbaron> Alex: We're trying to do something reasonable for ... markup so people won't lose content.
# [09:39] <dbaron> Alex: We're not going to optimize for ... in flexbox.
# [09:39] <dbaron> Alex: We're trying to come up with a reasonable rule that makes controls flexbox items and not be too special.
# [09:40] <dbaron> fantasai: So the basic problem Alex describes is that when an author puts a flexbox around a bunch of buttons or images, they expect those things to flex.
# [09:40] <dbaron> fantasai: So the goal of this magic behavior for replaced elements is to deal with that surprise.
# [09:40] <dbaron> Alex: ... compromise that we got.
# [09:40] <dbaron> Alex: Anything with display:inline-block ... not ... value of properties... including images and controls. These should be flexbox items.
# [09:40] <dbaron> tab: Still reasonable for images and buttons to work as they do now.
# [09:41] <dbaron> fantasai: I think the behavior is reasonable, except in the case where the element is no longer replaced.
# [09:41] <dbaron> tab: So we want to track replacedness.
# [09:41] <dbaron> fantasai: No, we should track whether the author expected it to be replaced.
# [09:41] <dbaron> fantasai: That's a lot of magic.
# [09:41] <dbaron> q+
# [09:41] * Zakim sees dbaron on the speaker queue
# [09:41] <dbaron> SteveZ: It's what the user had expected.
# [09:42] <glazou> Zakim, ack dbaron
# [09:42] <Zakim> I see no one on the speaker queue
# [09:42] <fantasai> dbaron: I think I'm a little worried about that sort of magic in the case that maybe certain specs like HTML get extended
# [09:42] <fantasai> dbaron: in such a way that a lot of elements could potentially be a replaced element
# [09:42] <fantasai> szilles: So why not list the elements that should behave that way
# [09:42] <dbaron> glazou: 'content' can turn anything into a replaced element
# [09:42] <Bert> q+ to ask how I *do* get an IMG to be inline: <DIV.flexbox><DIV.flexbox>...inline... <IMG>... inline</></>
# [09:43] * Zakim sees Bert on the speaker queue
# [09:43] <dbaron> tab: I wouldn't be sad if an inline with 'content' worked wrong in flexbox -- you should need to set it to inline-block
# [09:43] <dbaron> sgalineau: ... shadow dom ...?
# [09:43] <dbaron> sgalineau: If you make your own control with the shadow dom?
# [09:43] <dbaron> tab: Set it to inline-block.
# [09:43] <dbaron> ack bert
# [09:43] <Zakim> Bert, you wanted to ask how I *do* get an IMG to be inline: <DIV.flexbox><DIV.flexbox>...inline... <IMG>... inline</></>
# [09:43] * Zakim sees no one on the speaker queue
# [09:44] <dbaron> Bert: How can I avoid this?
# [09:44] <dbaron> tab: wrap it in a span
# [09:44] <dbaron> fantasai: In most cases you're not going to take a bunch of inline content and use flexbox.
# [09:44] <dbaron> Bert: Say I have table markup and want to lay it out with flexbox instead.
# [09:45] <dbaron> Bert: So I make the table, tr, td flexbox
# [09:45] <dbaron> fantasai: Just make the table and tr flexbox containers, but *don't* make the td flexbox container; it becomes a flexbox item.
# [09:45] <dbaron> Tab: Just make it display:block or display:inline-block
# [09:46] <dbaron> Tab: You want table, tr { display: flexbox } td { display: block }
# [09:46] <dbaron> Tab: Your row is the flexbox, the cells become items, anything inside the cells is irrelevant.
# [09:46] <dbaron> SteveZ: The children of a flexbox are items.
# [09:47] <dbaron> fantasai: Anything with display != inline automatically gets an effective display-outside:flexbox-item
# [09:47] <dbaron> Bert: We're missing something to turn something into a flex-item
# [09:47] <dbaron> Tab: There aren't use cases for having that value
# [09:48] <dbaron> glazou: Not only that, there's no concept of having a child of a flexbox container not being a flexbox item. It's not meaningful.
# [09:48] <dbaron> Bert: Why isn't the block being wrapped in anonymous flexbox item?
# [09:48] <dbaron> SteveZ: You want the flexing on the block to flex.
# [09:49] <dbaron> Tab: [explains model again]
# [09:49] <dbaron> glazou: So, Bert, what do you want if first two cells are set to display:flex-item and third is display:block?
# [09:49] <dbaron> Bert: Then the third gets wrapped in an anonymous flex item.
# [09:50] * Quits: AlexD (qw3birc@128.30.52.28) (Ping timeout)
# [09:50] <dbaron> Bert: <div> flexbox
# [09:50] <dbaron> <div>...</>
# [09:50] <dbaron> <img>
# [09:50] <dbaron> ...ABC...
# [09:50] <dbaron> <div>..</>
# [09:50] <dbaron> </>
# [09:51] <dbaron> If I turn span from inline into block, I still want this stuff to be a single item.
# [09:51] <dbaron> Tab: That's not doable.
# [09:51] <dbaron> Bert: If this were a table and a cell, I could do this.
# [09:52] <dbaron> vhardy: I can see Bert's point that we have a different behavior between flexboxes and tables.
# [09:52] <dbaron> Tab: If we did flexbox-item, then the default case wouldn't work well.
# [09:53] <dbaron> SteveZ: Tables require a td, this doesn't require a flexbox item.
# [09:53] <dbaron> SteveZ: Typical use case for flexbox wants to not require equivalent of td.
# [09:54] <dbaron> fantasai: ...
# [09:54] <dbaron> Bert: You can just use display: flexbox for both
# [09:54] <dbaron> fantasai, steve, glazou: no, you can't, container and item are different
# [09:55] <dbaron> fantasai: Flexbox automatically promotes other values into display-outside: flex-item. I think that's fine. The only thing I have a problem with is behavior of things like img or object depending on whether the resource loads.
# [09:55] <dbaron> Tab: Eventually we can solve Bert's case with an ability to wrap arbitrary things with a pseudo-element.
# [09:55] <dbaron> Bert: What's the difference between a flexbox with a single item and a block?
# [09:56] * Joins: AlexD (qw3birc@128.30.52.28)
# [09:56] <dbaron> Tab: I'm confused about what we're still talking about.
# [09:56] <dbaron> Bert: ... don't need special behavior for images
# [09:57] <dbaron> Tab: People expect to be able to fill a flexbox with images.
# [09:57] * Joins: howcome (howcome@193.105.139.140)
# [09:58] <dbaron> fantasai: [draws]
# [09:58] <dbaron> fantasai: So the issue is <div flexbox> <img> <img> <img> </div>
# [09:58] <dbaron> fantasai: When the images load I get 3 flex items, but if images don't load...
# [09:58] <dbaron> fantasai: <div flexbox> <img alt=foo> <img alt=bar> <img alt=baz> </div>
# [09:59] <dbaron> fantasai: I just get one item with foo bar baz.
# [09:59] <dbaron> Florian: Agree this is a problem. Whether we pick the first always or second always is secondary.
# [10:00] <dbaron> vhardy: Could we have a ... ?
# [10:00] <dbaron> fantasai: Is an image an element that is replaced, or is an image an img element (special-case rules for HTML)?
# [10:01] <dbaron> SteveZ: I thought modulo David's comment that we agree the intent is that if user intended it to be replaced, it should keep behaving like it's replaced.
# [10:01] <dbaron> dbaron: Just say "if it's replaced or attempted to load a resource that would have caused it to be replaced"
# [10:02] <dbaron> Tab: Just working around bug of display:inline rather than inline-block
# [10:03] <dbaron> fantasai: [proposes alternative]
# [10:03] <dbaron> glazou: [says something]
# [10:03] * Joins: tabatkins__ (qw3birc@128.30.52.28)
# [10:04] <fantasai> I just pointed out that you can get the behavior you want by setting 'display: inline-block' or 'display: block' on the items
# [10:04] <dbaron> SteveZ: I think there's a magic property attached to items that says it stays atomic if the alt text shows up.
# [10:04] <dbaron> fantasai: That's display:inline-block
# [10:04] <dbaron> SteveZ: No, more magic than that.
# [10:04] <dbaron> SteveZ: If things in future of HTML get ...
# [10:04] <dbaron> fantasai: Then default style sheet could make them display: inline-block
# [10:05] <dbaron> fantasai: Right now img is display:inline
# [10:05] <dbaron> SteveZ: Only want this to happen in the context of a flexbox
# [10:05] <dbaron> Tab: We know what we want to do
# [10:05] <dbaron> Tab: I think we should resolve that all HTML replaced elements work even if they don't load.
# [10:06] <dbaron> fantasai: It matters how, we need to discuss this.
# [10:06] <alexmog_> 29
# [10:06] <fantasai> fantasai: So you want 'display: inline-block-if-parent-is-flexbox'?
# [10:06] <dbaron> Tab: If we can't figure it out tonight, we can bring it up again tomorrow.
# [10:07] <dbaron> resolution???: We want replaced elements that are children of a flexbox to always be flexbox items, even when the resource they're trying to load doesn't load.
# [10:08] <dbaron> glazou: Do you need ability to put first 2 images in one flex item and third in its own?
# [10:08] <dbaron> dbaron: Put first 2 in a container?
# [10:08] <dbaron> SteveZ: Could have a property called flex-atomic.
# [10:10] <dbaron> Tab: And that's acceptable to do later.
# [10:10] <dbaron> Bert: But it's easier to say inline elements don't turn into flex items.
# [10:10] <dbaron> fantasai: Have all elements turn into flex items?
# [10:10] <dbaron> tab: I'd rather have text-inline-text not be broken
# [10:11] <dbaron> Tab: Bert, what you're objecting to is what most authors want based on existing usage.
# [10:11] <dholbert> fantasai, your proposal would make <div style="display:flexbox">text followed by <i>italics</i></div> weird (the <i> would become its own item)
# [10:12] <fantasai> yeah, but the argument is that isn't a good use case
# [10:12] <dbaron> Straw poll: (a) accept behavior Tab wants or (b) continue discussion
# [10:12] <dbaron> vhardy a
# [10:12] <dbaron> alexd a
# [10:12] <dbaron> glenn abstain
# [10:12] <dbaron> jdaggett abst
# [10:12] <fantasai> I don't know what a) is, because "wanted to be a replaced element" is not defined
# [10:13] <dbaron> dbaron a
# [10:13] <dbaron> ted a
# [10:13] <dbaron> arno abst
# [10:13] <dbaron> dirk abst
# [10:13] <dbaron> alan stearns a
# [10:13] <dbaron> fantasai: [discussion]
# [10:14] <dbaron> fantasai b
# [10:14] <dbaron> shane a
# [10:14] <dbaron> sylvain a
# [10:14] <dbaron> ren abst
# [10:14] <dbaron> steve a
# [10:14] <fantasai> fantasai: Tab's proposal isn't defined, how can I vote for or against it?
# [10:14] <dbaron> rik abst
# [10:14] <dbaron> glazou a
# [10:14] <dbaron> florian a
# [10:14] <dbaron> a a abstain abstain
# [10:14] <dbaron> Bert b
# [10:14] <dbaron> jet a
# [10:14] <dbaron> howcome b
# [10:15] <dbaron> CONCLUSION: Let tab propose something and we'll discuss his proposal.
# [10:15] <dbaron> tab: Intention is that if we introduce display-inside/outside, intention is that when that happens flex items will get a computed display-outside of flex-item
# [10:16] <dbaron> tab: This means that the serialized computed value of display will in future change for flex items from "block" to "flex-item block"
# [10:16] <dbaron> tab: I think it'll probably be fine, so not something we need to worry about now.
# [10:16] <dbaron> florian: fine by me
# [10:16] <dbaron> vhardy: Is the plan to have computed value of display be display-inline, display-outside, or both?
# [10:17] <dbaron> tab: serialization produces the old value when there's an old value that matches the pair
# [10:17] <dbaron> dbaron: general rule that serialization produces shorter value
# [10:18] <dbaron> Bert: So you're proposing value of display-outside depends on parent
# [10:18] <dbaron> fantasai: We have a similar case for the root element.
# [10:18] <dbaron> fantasai: we also do this for match-parent in css3-text
# [10:18] * Zakim sees Meeting_Room ask to turn on the light
# [10:19] <dbaron> fantasai: ...
# [10:19] <dbaron> Bert: Ah, I think it's ok if only the computed value changes.
# [10:19] <dbaron> Tab: So, the effect of visibility:collapse on flex items.
# [10:19] <dbaron> Tab: visibility:collapse is generally useless, but has special behavior for table rows/columns
# [10:20] <dbaron> fantasai: But goal was to allow dynamic expansion/collapsing
# [10:20] <alexmog_> didn't we discuss and resolve this before?
# [10:20] <dbaron> tab: without introducing relayout jitter
# [10:20] <alexmog_> as "collapse doesn't do anything special in flexbox"?
# [10:20] <dbaron> fantasai: The goal is that thing with visibility:collapse should disappear from layout but still influence surrounding content
# [10:20] <dbaron> fantasai: e.g., disclosure element
# [10:21] <dbaron> fantasai: this is goal... visibility:collapse does bad job of solving this. But otherwise behaves like hidden.
# [10:21] <dbaron> fantasai: There was a thread on what collapse should do for flexbox.
# [10:21] <dbaron> fantasai: I think could say it doesn't impact layout but still in the tree for animations/counters.
# [10:22] <dbaron> fantasai: Could collapse in main axis but still affect cross size of flexbox.
# [10:22] <dbaron> SteveZ: So like having a strut in the cross direction
# [10:22] <dbaron> fantasai: alternatively, like display:none but still in the box tree
# [10:22] * Joins: alexmog__ (qw3birc@128.30.52.28)
# [10:22] <dbaron> q+
# [10:22] * Zakim sees dbaron on the speaker queue
# [10:23] <dbaron> tab: a better display:none that doesn't turn off animations
# [10:23] <dbaron> fantasai: so timeline is still running while it's not displayed
# [10:24] <dbaron> florian: question about having it still affect cross axis... can we always know without having it do layout in the other direction?
# [10:24] <dbaron> fantasai: Would need to layout (a) once with all the elements there including those that are collapsed to figure out the strut sizes and (b) again with them gone
# [10:24] * Quits: alexmog_ (qw3birc@128.30.52.28) (Ping timeout)
# [10:25] <fantasai> Florian: Seems like keeping the cross-axis strut is more likely what you want, but haven't thought about it much
# [10:25] <fantasai> Tab: You could, e.g. have a meu-bar across the top of the page, some items one line others two, don't want the height to jiggle when you collapse a two-line item
# [10:25] <fantasai> dbaron: Not sure that works the way you want
# [10:26] <fantasai> dbaron: you will get jiggling, because if you collapse a one-line item so there's enough room for 2-line to be 1-line, then it'll still jiggle
# [10:26] <dbaron> ack dbaron
# [10:26] * Zakim sees no one on the speaker queue
# [10:26] <fantasai> Tab: No, the strut is the height as 2-line
# [10:26] <fantasai> dbaron: ok
# [10:26] <SteveZ> q+
# [10:26] * Zakim sees SteveZ on the speaker queue
# [10:26] <fantasai> dbaron: I don't think it's a good idea to introduce a general collapsing behavior for new layout modes
# [10:27] <fantasai> dbaron: I'm ok with the strut thing
# [10:27] <fantasai> dbaron: I think the no-strut-but-like-display-none is not something we should do in Flexbox, b/c if we want that mode we should have it for everything
# [10:27] <glazou> ack SteveZ
# [10:27] * Zakim sees no one on the speaker queue
# [10:27] <fantasai> szilles: I understand how this works for a 1-line flexbox, don't see how to do a multiline flexbox
# [10:27] <fantasai> Tab: Correct, we can't.
# [10:27] <fantasai> Tab: thought about this
# [10:28] <fantasai> Tab: Should work for single-line multi-line flexbox
# [10:28] <fantasai> Tab: ...
# [10:28] <fantasai> Tab: It's still useful, take e.g. your toolbar at the top of the screen
# [10:28] <fantasai> Tab: under normal screen widths it's a single line
# [10:28] <fantasai> Tab: But you set wrap on it so that on narrow screens it's 2-line
# [10:29] <fantasai> Tab: you lose the ability to have stable height, but it's compact
# [10:29] <dbaron> s/.../with multi-line it can cause really bad behavior like completely empty lines, extra space/
# [10:29] <dbaron> fantasai: If you rewrap as result of a lot of stuff collapsing then it will collapse the height as well.
# [10:30] <fantasai> ...
# [10:30] <dbaron> Steve: Compute height of strut as if laid out all on one very long line.
# [10:30] <dbaron> fantasai: Except now each line is independently sized
# [10:31] <dbaron> fantasai: If flexbox had consistent height per line across entire flexbox then that would make sense.
# [10:31] <dbaron> tab: That would be less than ideal... baseline alignment can produce different line-heights
# [10:31] * Quits: dstorey (Adium@67.180.84.179) (Quit: Leaving.)
# [10:32] <dbaron> dbaron: Could mean that if you collapse something it increases height of line
# [10:32] <dbaron> Steve: If became important, could introduce a property saying max, so collapsing behavior would do right thing.
# [10:32] <dbaron> SteveZ: property would say use max height for all lines
# [10:32] <dbaron> Tab: Seems like smth we could do in future.
# [10:33] <dholbert> yes
# [10:33] <dbaron> s/smth/something/
# [10:33] <fantasai> zakim, who is here?
# [10:33] <Zakim> On the phone I see Meeting_Room, dholbert, alexmog
# [10:33] <Zakim> On IRC I see alexmog__, tabatkins__, howcome, AlexD, SteveZ, shanestephens, kojiishi_, krit, glenn, jet, vhardy_, arno, glazou, Zakim, dbaron, Liam, alexmog2, dholbert, jdaggett,
# [10:33] <Zakim> ... florianr, kennyluck, arronei_, tantek, paul___irish, danielfilho, RRSAgent, ed, shepazu, logbot, macpherson, isherman, leaverou, stearns, arronei, dglazkov, kojiishi, trackbot,
# [10:33] <Zakim> ... krijnh, decadance, fantasai, TabAtkins_, hober, gsnedders, CSSWG_LogBot, vhardy, sylvaing, plinss, alexmog, shans, Hixie, Bert
# [10:33] <dbaron> Steve: possible desire for strut behavior
# [10:33] <dbaron> Steve: known to only work well with single line
# [10:33] <dbaron> Tab: As long as Alex and Daniel are ok with it I'd like to resolve on proposal (a) that collapsed items create a strut
# [10:33] <dbaron> dholbert: sounds ok to me
# [10:35] <dbaron> alexmog: seems expensive. Do you really want that?
# [10:35] <dbaron> tab: only if things are visibility:collapse
# [10:35] <dbaron> alexmog: ...
# [10:35] <dbaron> Tab: yes
# [10:36] * dholbert http://wiki.csswg.org/spec/css3-flexbox
# [10:36] <fantasai> "Stays in box tree, but has special layout: Do layout once normally, then collapse it to a strut of its line's cross size and lay out again. (This keeps the cross-size stable if the flexbox is single-line or a single line of multi-line.)"
# [10:36] <glazou> RESOLVED: Stays in box tree, but has special layout: Do layout once normally, then collapse it to a strut of its line's cross size and lay out again. (This keeps the cross-size stable if the flexbox is single-line or a single line of multi-line.)
# [10:36] <fantasai> (for visibility: collapse)
# [10:36] <dbaron> <br duration="10m" />
# [10:36] * dholbert is now known as dholbert|afk
# [10:40] * Quits: AlexD (qw3birc@128.30.52.28) (Ping timeout)
# [10:47] * Quits: kojiishi_ (kojiishi@193.105.139.140) (Ping timeout)
# [10:52] * Joins: AlexD (qw3birc@128.30.52.28)
# [10:52] <fantasai> </br>
# [10:52] <fantasai> dholbert|afk: ping
# [10:53] <glazou> you could also say <nextitem style="pause-before: 10m"/>
# [10:54] <fantasai> Scribe: fantasai
# [10:54] * Joins: kojiishi_ (kojiishi@193.105.139.140)
# [10:55] <dbaron> Zakim, who is on the phone?
# [10:55] <Zakim> On the phone I see Meeting_Room, dholbert, alexmog
# [10:55] <fantasai> Tab: First issue is, Alex wanted to split flex property into a shorthand
# [10:55] * Zakim fantasai, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [10:55] <fantasai> Tab: It took 3 components, now we have longhands for them
# [10:55] <fantasai> dholbert: I haven't done that yet, but think it's reasonable
# [10:56] <fantasai> Tab: We made flex-grow and flex-shrink default to 1, and flex-basis default to 'auto'
# [10:56] * dholbert|afk is now known as dholbert
# [10:56] <fantasai> Tab: But there's special behavior in the shorthand: if you leave out flex-basis, it defaults to '0px' rather than 'auto' (which is the initial value)
# [10:57] <fantasai> Tab: This is so that flex: 1; continues to do absolute flex
# [10:57] <Bert> q+ to ask about chosing betwwen flex margin and flex padding
# [10:57] * Zakim sees Bert on the speaker queue
# [10:57] <dbaron> fantasai: Are we happy with splitting flex into the three properties?
# [10:58] <fantasai> RESOLVED: Split flex into flex-grow/flex-shrink/flex-basis
# [10:58] <fantasai> fantasai: Next question on box-sizing, how does it interact with flex-basis?
# [10:59] <dbaron> fantasai: If you set a 'width' or a 'height', 'box-sizing' indicates whether that's content-box, padding-box, or border-box.
# [10:59] <dbaron> fantasai: Question is: does that also affect flex-basis?
# [10:59] <dbaron> fantasai, tab: I think it's clear it should be yes.
# [10:59] <fantasai> dbaron: So flex-basis defaults to auto?
# [11:00] <fantasai> Tab: initial value is auto, but in a lot of cases it will become zero
# [11:00] <fantasai> RESOLVED: box-sizing affects flex-basis
# [11:01] <fantasai> fantasai: next issue is, if the flex item inflexible, do we still use flex-basis, or do we just use width/height
# [11:01] <fantasai> Tab: Reason we defined flex-basis is b/c the direction you want is the main dimension, which could be either width or height
# [11:01] <fantasai> Tab: There's an argument that if you're inflexible, you don't need to care about flex-basis
# [11:02] <fantasai> szilles: Seems more confusing from user POV
# [11:02] <fantasai> szilles: Seems it would be better if you always used basis when you're in a flex
# [11:02] <fantasai> Alex: I don't see any reason for doing anything differently if flexibility is zero
# [11:02] <fantasai> RESOLVED: use flex-basis, even when flexibility is zero
# [11:03] <fantasai> Tab: default flexibility of flex items -- are they flexible or inflexible?
# [11:03] <fantasai> Tab: Right now default says flexible and auto-sized (i.e. use width/height value as appropriate)
# [11:03] <fantasai> Tab: I think this is the best option given how the shorthand works
# [11:03] <fantasai> szilles: Why are you putting them in a flexbox if not to flex them?
# [11:04] * Quits: leaverou (leaverou@89.210.12.77) (Quit: leaverou)
# [11:04] <fantasai> Tab: maybe you want reordering or alignment controls from flexbox
# [11:05] <fantasai> dbaron: what's the default amount of flex?
# [11:05] <fantasai> tab: 1
# [11:05] <fantasai> dbaron: And flex takes floats?
# [11:05] <fantasai> Tab: yes
# [11:05] <fantasai> Bert: do you need more than one level of flex?
# [11:05] <fantasai> Tab: There's only one right now, but you could add others later
# [11:06] <fantasai> Bert: Why is it not a boolean?
# [11:06] <fantasai> Tab: Oh, if you have 2 items and you have 1 and 2 flex values, the second will be twice as big as the first
# [11:06] <fantasai> Bert: I would have kept ordinal group rather than flex
# [11:06] <fantasai> Tab: could approximate wrt orders of magnitude
# [11:06] <fantasai> Alex: I'm a little concerned about this, have some experience with not flexible by default
# [11:06] <fantasai> Alex: Don't have any experience with flexible by default
# [11:06] <fantasai> Alex: It's probably good
# [11:07] <fantasai> fantasai: It's easy to turn off, just set "flex: none"
# [11:07] <fantasai> fantasai: (Now default is "flex: auto")
# [11:07] <fantasai> Alex: one point is that flexbox is even closer to other kinds of containers
# [11:08] <fantasai> Alex: Everything gets max-content if they're size auto and flex is zero, and these are defaults
# [11:08] <fantasai> Alex: our default is flex: 1, then content actually sizes to flexbox
# [11:08] * fantasai confused
# [11:08] <fantasai> Tab: so, is that objecting or agreeing?
# [11:09] <fantasai> Alex: Have a concern, but no particular reason for the concern
# [11:09] <fantasai> Alex: I am more default being flexible than not
# [11:09] * Joins: SimonSapin (simon@82.232.219.95)
# [11:09] <fantasai> dbaron: I feel like there are a bunch of use cases where you want to use a flex box b/c want a bunch of things, and want one of them to flex and rest of them not to
# [11:10] <fantasai> Tab: Just a bit more work, have to set flex: none on all the items
# [11:10] <fantasai> dbaron: is it more common to do flexible or inflexible?
# [11:10] <fantasai> dbaron: ... I'm ok with it
# [11:11] <fantasai> RESOLVED: items are flexible by default
# [11:12] <fantasai> alex: Issue - if you set 'flex: <number>', it sets negative flexibility to its default. Should it set both?
# [11:13] <fantasai> fantasai: negative flexibility ... usually want item that grows fastest not to shrink fastest
# [11:13] <fantasai> alex: ...
# [11:13] <fantasai> Tab: Right now, because of shorthand behavior, negative flex defaults to one..
# [11:13] <fantasai> alex: flex: 0 means positive flexilibity of zero, but negative flex of one
# [11:14] <fantasai> fantasai: yeah, that's odd, but you should just set 'flex: none'
# [11:14] <fantasai> Tab: Given we have 'none', I'm ok with flex: 0;
# [11:14] <fantasai> alex: flex: 0 100px will allow shrinking
# [11:15] <fantasai> fantasai: let's return to this after talking aboutnegative flex
# [11:15] <fantasai> next issue - Tab: If you set flex-basis to auto, does it compute to the basis or does it just resolve at layout time?
# [11:16] <fantasai> Tab: don't know what implementations do
# [11:16] <fantasai> dholbert: For transitions and animations, I think it's best to compute to the actual length
# [11:16] <fantasai> dholbert: though that's not how I implement it right now... but I think it's better to compute through
# [11:17] <fantasai> Alex: what does it compute to for non flexbox-items?
# [11:17] <fantasai> Tab, fantasai: hm, should compute to 'auto' on non flexbox-items
# [11:18] <fantasai> Alex: Does it compute to the computed value or the used value of width/height?
# [11:18] <fantasai> fantasai: CSS computed value, not DOM getComputedValue
# [11:19] <fantasai> dholbert: One slightlky odd case, what if actual computed value of width is 'auto'?
# [11:19] <fantasai> Tab: That's fine, you just get 'auto' back
# [11:20] <fantasai> RESOLVED: on flex items flex-basis of 'auto' computes to computed width/height (as appropriate); on elements that are not flex-items, it always computes to 'auto'
# [11:20] <fantasai> issue - negative flex
# [11:21] <fantasai> http://www.w3.org/mid/2C86A15F63CD734EB1D846A0BA4E0FC81A3EDD72@CH1PRD0310MB381.namprd03.prod.outlook.com
# [11:21] <fantasai> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16856
# [11:21] <fantasai> Tab: Flexbox with 2 children, one small, one really big
# [11:21] <fantasai> Tab: overflows, negative flex is allowed
# [11:21] <fantasai> Tab: right now, take overflow amount as negative space, split evenly to children
# [11:22] <fantasai> Tab: small item shrinks to zero, rest of space shrinks other item
# [11:22] <fantasai> Tab: This is bad -- small item just dies
# [11:22] <fantasai> Tab: Alex proposes a division-based reduction for negative flexibility
# [11:22] <fantasai> Tab: So these reduce by a ratio rathe rthan absolute amount of the free space
# [11:22] <fantasai> Tab: effect of this shoudl be that, instead of one's dead and other fills remaining space,
# [11:22] <fantasai> Tab: you get something a little more proportional
# [11:23] <fantasai> Tab: small items is still smaller, but has same proportion to big item as in unflexed situation
# [11:23] <fantasai> Tab: haven't checked his math yet
# [11:23] <fantasai> dbaron: what's default negative flexibility
# [11:23] <fantasai> fantasai: that's a separate issue -- could default to either zero or 1
# [11:24] <fantasai> dbaron: Normally in a situation like that, you'd have small item inflexible
# [11:24] <fantasai> fantasai: but if you do negative flex everything, what does it do
# [11:25] <fantasai> Tab: This compounds your flex basis into the formula
# [11:25] <fantasai> Tab: It multiplies your basis by your negative flex, and this is how you distribute the negative space
# [11:25] <fantasai> Tab works through the example with one box as 100px and the other at 900px
# [11:26] <fantasai> dbaron: I'm ok with it
# [11:26] <fantasai> Tab: Seems reasonable
# [11:26] <dholbert> agreed
# [11:26] <fantasai> dholbert: I think it sounds like a good proposal
# [11:26] <fantasai> RESOLVED: accept Alex's new formulation for negative flexibility
# [11:26] <tabatkins__> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16856 comment 1 for the formulation
# [11:30] <fantasai> [fantasai explains reasoning for turning negative flex on by default]
# [11:30] <fantasai> dbaron: does negative flexing affect multiline flexbox?
# [11:30] <fantasai> Tab: Only in the case that one single item overflows the box, in which case it pulls it back inside
# [11:30] <fantasai> Tab: you line break first, then apply flex
# [11:31] <fantasai> Alex: If you say 'flex: 0 auto', it will default flexibility to one
# [11:32] <fantasai> fantasai: think we should optimize for the common cases, and setting flex-basis to a value other than auto or zero seems like uncommon case
# [11:32] <fantasai> fantasai: if we really want to , we can make shorthand defaulting smarter
# [11:32] <fantasai> Tab: e.g. if flex is set to zero, it sets both to zero
# [11:33] * dholbert nope
# [11:33] <fantasai> RESOLVED: Negative flexibility is 1 by default
# [11:33] <fantasai> shorthand right now:
# [11:34] <fantasai> - flex: none -> 0 0 auto
# [11:34] <fantasai> - flex: auto -> 1 1 auto
# [11:34] <fantasai> - flex: <integer> -> <integer> 1 0px
# [11:34] <fantasai> Question is, what happens if flex: 0; or flex: 0 <size>;
# [11:34] <dbaron> s/integer/number/
# [11:34] <dbaron> s/integer/number/
# [11:35] <fantasai> Option 0: negative flex defaults to 1
# [11:35] <fantasai> Option 1: negative flex defaults to 0 in case of positive flex being set to 0
# [11:35] <fantasai> fantasai: I'm ok with either
# [11:36] <fantasai> dbaron: so if you have two integers, it sets positive and negative
# [11:36] <fantasai> dbaron: if you have one integer, it sets positive, and quesiton is what the default negative flex is
# [11:36] * dholbert doesn't have a strong preference from an implementation perspective
# [11:36] <fantasai> Tab: yeah. We already have a special defaulting thing for flex-basis already (defaults to 0px in the case of a flex being present, despite auto being the initial value)
# [11:38] <fantasai> dbaron: 'flex: 0', if you only do the one special case you mentioned, then the basis is 0px
# [11:38] <fantasai> dbaron: if the basis defautls to 0px in the shorthand, then that's uselsess anyway
# [11:38] <fantasai> ...
# [11:39] <fantasai> dbaron: seems more reasonable to have defaulting for flex-basis, not the integers
# [11:39] <fantasai> Tab: original goal was to have absolute flex easy, just specify a flex
# [11:39] <fantasai> Tab: and to have relative flex easy: just set to auto
# [11:40] <fantasai> dbaron: so if the author wants an inflexible size, they have to set 'flex: 0 0 size'
# [11:40] <fantasai> Tab: Yes, or set flex to none and use width/height
# [11:40] <dbaron> Tab: which is preferred
# [11:41] <fantasai> Bert: Why do we set flex-basis and not width/height?
# [11:41] <fantasai> Tab: width/height is physical, flex is logical wrt flex flow
# [11:42] <fantasai> fantasai: also it's confusing for people to set width/height to zero when they want a flex basis of zero, since they don't *want* the width to be zero
# [11:42] <fantasai> Tab explains absolute vs. relative flex to Bert
# [11:43] <tabatkins__> fantasai: There's two ways to do flex.
# [11:43] <tabatkins__> fantasai: There's zero-based.
# [11:43] <tabatkins__> fantasai: You have an element with three children, flexes set to 1, 1, and 2.
# [11:43] <tabatkins__> fantasai: If flex-bases is 0, they'll become 1/4, 1/4, and 1/2, maintaining the ratios.
# [11:43] <tabatkins__> fantasai: If I do a flex basis of auto, it means lay out the contents first.
# [11:44] <tabatkins__> fantasai: So if one of them has a long word, and another has a short word...
# [11:44] <tabatkins__> fantasai: You then figure out the *extra* space, and distribute that according to 1/4,1/4,1/2 and add it to the layout sizes.
# [11:47] <fantasai> ...
# [11:47] <fantasai> back to topic
# [11:48] <fantasai> dbaron: Now that we just changed the way negative flex distribution happens
# [11:48] <fantasai> dbaron: not sure I'm still convinced you dont' want the negative and positive flexes to be the same
# [11:48] <fantasai> fantasai: no, still do -- higher flex means it shrinks faster
# [11:49] <fantasai> fantasai: don't want item that grows the fastests to shrink the fastests
# [11:49] * fantasai has soo many typos to fix...
# [11:49] <fantasai> dbaron: Not convinced that the special case you're proposing for zero is particularly useful
# [11:50] <fantasai> dbaron: Special case proposed for shorthand is that *if* positive flex defaults to zero, negative flex also defaults to zero, instead of defaulting to 1 like everywhere else
# [11:50] <fantasai> fantasai: I'm ok with either way
# [11:50] <fantasai> dbaron: I'm inclined not to do the special casing for 0
# [11:51] <fantasai> dbaron: seems like one more thing that could trip them up, and doesn't feel all that useful
# [11:51] <fantasai> dbaron: though if you have a strong feeling, I don't mind
# [11:51] <fantasai> Tab: don't feel strongly either
# [11:51] <dbaron> s/trip them up/confuse authors trying to learn how flexbox works/
# [11:52] <fantasai> Alex: Unusual to have flexibility that's not one or zero, unless flex basis is zero (in which case you never "shrink" anyway)
# [11:52] <fantasai> Alex: So could set both numbers to same thing
# [11:52] <fantasai> Tab: No, I don't like that. Whole reason we split them out was so that itme that grows fastests doesn't shrink fastest
# [11:53] <fantasai> Tab: I'd be ok with not having the special case here.
# [11:53] <fantasai> Tab: Have an authoring guideline that says to set width/height
# [11:53] <Bert> (wild idea: make the default neg flex the inverse of the pos flex: X and 1/X..., except for 0, which becomes 0)
# [11:54] <fantasai> fantasai: Suggest we go with defautl as 1 for now, call out as an issue for feedback. We have two clear proposals, both ar eacceptable to everyone and we don't have strong opinions. If LC comments come back with more info or strong opinions, we can change.
# [11:55] <fantasai> Alex: prefer to have a special case
# [11:55] * Joins: leaverou (leaverou@195.251.255.151)
# [11:58] <fantasai> fantasai: if you have bunch of flexboxes 100px flex basis, have flex of 1, 2, 3, and then shrink, what happens?
# [11:58] <dbaron> Present: Håkon Wium Lie, Jet Villegas, Bert Bos, Liam Quin, Koji Ishii, Peter Linss, Florian Rivoal, Daniel Glazman, Rik Cabanier, Steve Zilles, Ren Ando, Sylvain Galineau, Shane Stevens, Tab Atkins, Elika Etemad, Alan Stearns, Dirk Schultze, Arno Guidol, Edward O'Connor, David Baron, John Daggett, Glenn Adams, Alex Danilo, Vincent Hardy
# [11:58] <fantasai> fantasai: Would want to think about this, not sure it works...
# [11:59] <fantasai> fantasai: suggest we defer this to tomorrow
# [12:00] <dbaron> fantasai: Consider (a) defaulting behavior of negative flex in shorthand and (b) Bert's suggestion to invert negative flexes
# [12:00] * Quits: leaverou (leaverou@195.251.255.151) (Quit: leaverou)
# [12:00] <dbaron> fantasai: Is that just a default shorthand behavior or the way negative flex works in general?
# [12:00] <dbaron> Bert: one other issue: it doesn't say what a % on flex-basis means
# [12:00] <dbaron> Tab: Just like normal layout
# [12:00] <dbaron> dbaron: means the same as % on width or height?
# [12:00] <dbaron> tab: yes
# [12:00] <dbaron> Bert: In the property definition there is no percentage line
# [12:01] <dbaron> Bert: The "Percentages" line; could just say "see text".
# [12:01] <dbaron> dbaron: for flex-basis, not for shorthand flex
# [12:01] <fantasai> ACTION Tab: fix flex-basis percentage line in propdef table
# [12:01] * trackbot noticed an ACTION. Trying to create it.
# [12:01] * RRSAgent records action 1
# [12:01] <trackbot> Created ACTION-458 - Fix flex-basis percentage line in propdef table [on Tab Atkins Jr. - due 2012-05-17].
# [12:02] <fantasai> next issue - implied minimum size of flexbox items
# [12:02] <fantasai> Tab: Flexbox sizing does pay attention to min/max constraints
# [12:02] <fantasai> Tab: But min constraint defaults to zero
# [12:02] <fantasai> Tab: This might not be ideal
# [12:02] <fantasai> Tab: In other layout modes, might have other min-content sizing
# [12:02] <fantasai> Tab: Tables for example floor at min-content
# [12:02] <fantasai> Tab: Maybe we should do that as well
# [12:03] * Joins: leaverou (leaverou@195.251.255.151)
# [12:03] <fantasai> Alex: If width is 'auto' and 'min-width: 0' , in that situation you'll have min-content as a minimum
# [12:03] <fantasai> Tab: special case of those two values having those two values?
# [12:03] <fantasai> Alex: yes
# [12:05] <fantasai> fantasai: alternate proposal is to introduce 'auto' value as initial value of 'min-width/height'.
# [12:06] <fantasai> fantasai: this can compute to '0' if we need to on non-flexbox-items (for back-compat), or not
# [12:06] <fantasai> fantasai: but then flexbox items can look at the min size constraint, see that it's auto, and know that auto means use min-content as the minimum
# [12:06] <fantasai> fantasai: authors can still turn that off by setting it explicitly to 0
# [12:06] <fantasai> Florian: I think I like that
# [12:07] <fantasai> Tab: Gives friendly default behavior, e.g. navigation bar with text, want each item to be at least as wide as a single word
# [12:09] <fantasai> ...
# [12:09] <fantasai> proposal is to add definition of min-width/height: auto to Flexbox, as described above
# [12:10] <fantasai> fantasai: This lets us do similarly smart things for other layout modes as we add them, which is probably a good thing
# [12:10] <fantasai> Florian: certainly less hacky than getting the behavior the way Alex was doing
# [12:10] <fantasai> dbaron: This is compatible with Gecko flexbox
# [12:10] <fantasai> dbaron: It doesn't let you go smaller than min-content
# [12:11] <fantasai> dbaron: Gecko flexbox treates min-width: 0 as magic
# [12:11] <fantasai> dbaron: So people using Gecko flexbox will use min-width: 1px when they want to go below intrinsic
# [12:11] <fantasai> RESOLVED: add 'auto' keyword as initial value of min-width/height as specified above
# [12:12] <fantasai> fantasai: side-tangent -- do we want it to compute to auto on table cells?
# [12:13] <fantasai> dbaron: would need to think about that
# [12:13] <fantasai> Tab: we'll make it go to zero always now, and then if find a way to make it compatible, handle as LC comment
# [12:13] <fantasai> topic - pagination
# [12:14] <fantasai> Tab: multi-line row flexbox
# [12:14] <fantasai> (tab is drawing an example
# [12:14] <fantasai> Tab: with stuff in it
# [12:14] <fantasai> Tab: this is a tall thing, pagination is in play
# [12:14] <fantasai> Tab: page line cuts right here or something
# [12:16] * Quits: leaverou (leaverou@195.251.255.151) (Quit: leaverou)
# [12:16] <fantasai> fantasai explaisn the issue
# [12:17] <fantasai> dbaron: Do you have breaking of multiline column flexboxes?
# [12:17] <fantasai> fantasai: yes, it's complicated, roughly like multi-col layout
# [12:18] <fantasai> Bert: Sounds to me like that item wants to be on its own line
# [12:18] <fantasai> fantasai: could make break-before/after: always trigger breaks on flexbox lines
# [12:20] <fantasai> fantasai: other values of break (e.g. column/page/left/right) would still propagate to the line, but always would trigger a line break in all modes, and a page break in paged mode
# [12:21] <fantasai> howcome: wouldn't expect page breaking to be used much on flexbox
# [12:21] <fantasai> Tab: but line breaking, definitely
# [12:22] <fantasai> Tab: would be weird to say, you ignore page break controls in flexbox
# [12:22] <fantasai> for no good reason
# [12:22] * dbaron is getting hungry and wonders if lunch is sitting outside for us
# [12:23] <fantasai> fantasai: So proposal is break-before/after: always triggers a flex-line break, and all values that trigger fragmentation get propagated to the flex line
# [12:23] <fantasai> RESOLVED: proposal accepted
# [12:24] * Quits: logbot (logbot@110.173.227.145) (Client exited)
# [12:24] * Joins: logbot (logbot@110.173.227.145)
# [12:25] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012May/0027.html
# [12:25] <fantasai> Tab: our paging algorithm right now is optimized for page-at-a-time layout
# [12:26] <fantasai> ...
# [12:26] <fantasai> fantasai: suggest we go to next issue, which is to make the paging algorithms informative
# [12:27] <fantasai> Tab: We're not sure they're correct, and they're simplified, so we'll leave them in as implementation advice, but not normative
# [12:28] <fantasai> Tab: Nobody has well-defined pagination yet, so not worse than other layout modes
# [12:28] <fantasai> szilles: Make sure to note that doing better is acceptable and encouraged
# [12:29] <fantasai> Tab: bullet points that say how to deal with break properties stay normative
# [12:29] <fantasai> Tab: but actual rules for precisely how to do layout, become informative
# [12:29] <fantasai> howcome: make it a subsection
# [12:29] <fantasai> Tab: yeah
# [12:30] <fantasai> RESOLVED: make page-breaking algorithms for flexbox informative, as an example, UAs can do better
# [12:31] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012May/0007.html
# [12:31] <fantasai> Tab: previously, there was a difference in cross-sizing for single-line and multi-line
# [12:32] <fantasai> Tab draws a single line flexbox
# [12:32] <fantasai> Tab: if you had one item that was extra big inside of it
# [12:32] <fantasai> Tab: question is, the flexbox line, which we use for alignment, how big should it be?
# [12:32] <fantasai> Tab: should it be the height of the big item, or height of the flexbox?
# [12:32] <fantasai> Tab: Old flexbox set it to size of the flexbox in single-line mode, but to the height of the tall box in multiline mode
# [12:33] <fantasai> Tab: top/bottom aligned bits would align within the flexbox element, and stretch items would stretch to fit it
# [12:33] <fantasai> Tab: In second case (multiline) the flexbox line would stretch to height of big item, and items woudl aling to bottom/top of that/ stretch to height of that
# [12:34] <fantasai> Tab: [even in case of having a single line]
# [12:34] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012May/0299.html
# [12:34] <fantasai> fantasai reads Alex's choices
# [12:38] <fantasai> Tab: for case C, could get into inconsistent situation with text size wrapping, e.g. vertical text stretch inside first line, when it wraps behavior changes, so size is different of this item, which causes the wrapping to wrap differently
# [12:38] <fantasai> szilles: advantage of bottom drawing is it doesn't distinguish between multiline and single line
# [12:39] <fantasai> fantasai: related question is whether flex-line-pack: stretch can shrink the lines in order to fit inside the flexbox
# [12:40] <fantasai> fantasai: you could get the first (old single-line) behavior also for multiline cases
# [12:40] <fantasai> fantasai: though it means that multiline mode, items will overflow each line instead of lines overflowing flexbox
# [12:40] <fantasai> Tab: This only is an issue if you are using a cross-size that's just too smal
# [12:41] <fantasai> Tab: My proposal is to keep the current spec, which puts them always in the second situation
# [12:41] <fantasai> Alex: if you compare with vertical-align, there are multiple values for [...]
# [12:41] <fantasai> Tab: We share all the basic values between vertical-align and flex-align, we miss the ones based on text metrics
# [12:41] <fantasai> Alex: in single-line case there's no wrap, the height of the flexbox is the height of the line
# [12:42] <fantasai> Alex: vertical top and bottom will align with top and bottom of the flexbox
# [12:42] <fantasai> Alex: Don't want to change to align to overflowing items, just to handle the multiline case
# [12:42] <fantasai> Tab: Introduces unfortunate case that whether you wrap or not changes behavior
# [12:43] <fantasai> Alex: in multiline height of line can't be set explicitly; single-line mode, can do that by setting it to the height of the flex box
# [12:44] <fantasai> szilles: for inline setting, the container has no height of line
# [12:45] <fantasai> fantasai: the vertical text case you gave, doesn't apply because the size of that item is determined by the fill-available into the cross-size of flexbox
# [12:45] <fantasai> fantasai: so it's height won't change -- it'll either be short b/c doesn't wrap, or it will fill the flexbox and the line will fill the widht of the flexbox
# [12:46] * Quits: kojiishi_ (kojiishi@193.105.139.140) (Ping timeout)
# [12:47] <fantasai> reveiwing Alex's proposal C
# [12:47] <fantasai> Tab: I'm ok with that now
# [12:48] <fantasai> szilles: so if baselines are snapped to the line grid, does that move the flex box, or does that move the items?
# [12:49] <fantasai> fantasai: you have a problem with line grid anyway, regardless of the sizing of the line
# [12:50] <fantasai> fantasai: since alignment can change how it snaps to the line grid, which can change its sizing...
# [12:50] <fantasai> Tab: So, if we pay attention to line grid, which we'll want to, it will force us to move the flex line or have items overflowing
# [12:50] <fantasai> Tab: so we might as well embrace that and make it happen in general, so that the line does not auto-size to the flexbox, it autosizes to the line
# [12:51] <fantasai> szilles: you've got the container, and you've got the line that goes in the container
# [12:51] <fantasai> szilles: when I say sanp, which moves?
# [12:52] <fantasai> Florian: if it only overflows if the flexbox is set to a definite size, it's not that bad
# [12:52] <fantasai> Florian: If it overflowed in auto-sizing case,s that would be bad
# [12:53] <fantasai> Tab: ...
# [12:53] <fantasai> Tab: either way work
# [12:53] <fantasai> szilles: So you create a line, which as a baseline, which you are aligned to. You take that line, and align it to the grid
# [12:53] <fantasai> szilles: your'e saying as I compute the individual lines, I sanp those to the lien grid
# [12:53] <fantasai> szilles: those will result in different results
# [12:54] <fantasai> Tab: I think the way things generally work, I think it's a slightly saner approach when we accommodate line-grid explicitly
# [12:54] <fantasai> Tab: point is, either way, if it causes something to get too large, it'll overflow no matter which decision we make here
# [12:55] <fantasai> ...
# [12:55] <fantasai> szilles: if I set a container height and have an object overflowing it, seems like an edge case
# [12:57] <fantasai> fantasai: use case is, e.g. toolbar, where most items are inside the flexbox, but focused item is big, overflowing the flexbox, for visual effect (margins used to prevent overlapping with toher content; overflowing is intentional effect)
# [12:58] <fantasai> Bert has mild preference for A
# [12:58] <fantasai> szilles has mild prefreence for B
# [12:58] <fantasai> Bert: [gives some use case]
# [12:58] <fantasai> Tab: No, C will give you this behavior as long as you only have a single line
# [12:58] <fantasai> Tab: so it's actually what you want
# [12:59] <fantasai> Bert: if I set min-height on the flexbox
# [12:59] <SteveZ> my preference for B is based on not having the "top" and "bottom" keywords for alignment have a different behavior or fles-lines and inline lines.
# [13:00] <fantasai> fantasai explains that case
# [13:00] <fantasai> Bert: ah, missed the extra if clause
# [13:00] <fantasai> RESOLVED: adopt proposal C in http://lists.w3.org/Archives/Public/www-style/2012May/0299.html
# [13:01] * Quits: SimonSapin (simon@82.232.219.95) (No route to host)
# [13:02] * dholbert bye
# [13:02] * dholbert thanks!
# [13:02] <Zakim> -alexmog
# [13:03] <Zakim> -dholbert
# [13:03] * plinss is now known as plinss_away
# [13:04] * Quits: glenn (gadams@193.105.139.140) (Client exited)
# [13:05] * dholbert is now known as dholbert|zzz
# [13:05] * Quits: arno (arno@193.105.139.140) (Quit: Leaving.)
# [13:06] * Joins: SimonSapin (simon@82.232.219.95)
# [13:06] * Quits: AlexD (qw3birc@128.30.52.28) (Ping timeout)
# [13:08] <Zakim> disconnecting the lone participant, Meeting_Room, in Team_(css)07:12Z
# [13:08] <Zakim> Team_(css)07:12Z has ended
# [13:08] <Zakim> Attendees were +49.403.063.68.aaaa, Meeting_Room, +1.831.334.aabb, dholbert, +1.206.923.aacc, alexmog
# [13:23] * Zakim excuses himself; his presence no longer seems to be needed
# [13:23] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [13:32] * plinss_away is now known as plinss
# [13:41] * Joins: kojiishi_ (kojiishi@193.105.139.140)
# [13:42] * Quits: tabatkins__ (qw3birc@128.30.52.28) (Ping timeout)
# [13:50] * Joins: tabatkins__ (qw3birc@128.30.52.28)
# [13:51] * Joins: glenn (gadams@193.105.139.140)
# [14:00] <jdaggett> http://mongoliantype.com/2012/05/07/la-semaine-de-la-mongolie-a-paris/
# [14:02] * Joins: vhardy__ (vhardy@193.105.139.140)
# [14:02] * Quits: vhardy_ (vhardy@193.105.139.140) (Connection reset by peer)
# [14:06] <fantasai> Scribe: fantasai
# [14:06] <fantasai> Topic: Planning future meetings
# [14:06] <fantasai> plinss: We're getting busy. Got a lot more work than we have time to do.
# [14:06] <fantasai> plinss: Daniel and I were debating what ot do about that
# [14:06] <fantasai> plinss: we can increase length of telecons, or length/frequency of F2Fs, or both
# [14:06] * Joins: AlexD (qw3birc@128.30.52.28)
# [14:06] <fantasai> dbaron: Another suggestion is to try to resolve on more things not on telecons or F2Fs
# [14:06] <fantasai> dbaron: try to resolve issues by email, the way WebApps group does
# [14:07] * hober yes!!!! this!!!!
# [14:07] <fantasai> dbaron: They post a Call for Consensus, and make decisions by email
# [14:07] <fantasai> ?: public list or csswg
# [14:07] <fantasai> Bert: I won't see it on the public mailing list
# [14:07] <fantasai> plinss: too much noise on the public list
# [14:08] <fantasai> glazou: I have conceptual problem with making all that on the mailing list
# [14:08] <fantasai> glazou: When on conf calls we say we'll review document, make a decision in 2 weeks time
# [14:08] <fantasai> glazou: Who reveiwed it? One, maybe 2 persons?
# [14:08] <fantasai> dbaron: it will work if you actually make the decision whether or not people reviewed it
# [14:08] <fantasai> glazou: That's not how it work, make a decision, then months later someone will reraise it
# [14:09] <fantasai> dbaron: This is one of the only WGs on core stuff that is in web browsers that still does synchronous decisions
# [14:09] <fantasai> glazou: Taking HTMLWG as an example is not a good idea
# [14:09] <fantasai> dbaron: large number of groups that switched to this model
# [14:09] <fantasai> glazou: we don't all have to do the same thing, and this WG is still working
# [14:09] <fantasai> dbaron: A lot of us frustrated by how we spend time in meetings
# [14:10] <fantasai> sylvaing: we can scale using the same way
# [14:10] <fantasai> glazou: We can try, but I don't think it will work well
# [14:10] <fantasai> szilles: I think in the cases where there is a fairly clear solution, concrete proposal you have week to review and raise objections
# [14:10] <fantasai> szilles: that can easily work on email
# [14:10] <fantasai> szilles: More concerned about kind of discussion we just had here, e.g. rules for overflowing
# [14:10] <sylvaing> I don't think dbaron was saying the WG does not work currently, simply that our way or working cannot scale
# [14:10] <fantasai> szilles: there was alternative proposals, really hard to get out all the alternativesly
# [14:11] <fantasai> szilles: useful for group time, you're educating bunch of people simultaneously and discussing ...
# [14:11] <fantasai> hober: group requires so much specialized knowledge to make decisions with
# [14:11] <fantasai> hober: I have much trouble remembering details in synchronous fashion
# [14:11] <fantasai> hober: if it's by email, I can take a day to look into it and then respond
# [14:12] <vhardy__> q+
# [14:12] <fantasai> fantasai: ... [there's value in both email and synchronous discussions]
# [14:13] <fantasai> fantasai: ... [could have model that's a hybrid of both]
# [14:13] <fantasai> jdaggett: [discusses difficulties of 2am calls]
# [14:14] <fantasai> glazou: We don't take all items to discussion on telecon, only items that seem to need discussion
# [14:14] <fantasai> glazou: Given high volume, it's hard to know when a thread is stabilized and ready for WG resolution
# [14:14] <fantasai> vhardy: I've seen WebApps people able to resolve stop
# [14:14] <fantasai> vhardy: do they have a tool to support the discussion, or is it all email?
# [14:15] <fantasai> Tab: Having something that needs discussion than mailing list isn't only reason it goes on agenda
# [14:15] <vhardy__> s/resolve stop/resolve issues
# [14:15] <fantasai> Tab: Some thing need resolution by the WG
# [14:17] <fantasai> Tab: e.g. flexbox issues, not all of them need to be discussed F2F
# [14:17] <fantasai> fantasai talks about having a preparation of issues before they go on the call
# [14:18] <fantasai> szilles: To submit an agenda item, you have to post that summary
# [14:18] <fantasai> dbaron: would prefer to do wiki than email
# [14:18] <fantasai> glazou: want it archived better than on a wiki
# [14:19] <fantasai> dbaron: problem with email is that people reply to it, and it becomes a thread
# [14:19] <fantasai> dbaron: alternativel proposal
# [14:19] <fantasai> dbaron: maintain a list of proposed agenda items in a wiki, and when the item comes up for discussion, chairs paste that into the agenda email
# [14:20] <fantasai> sylvaing: so you queue things up on the wiki, then,... yeah
# [14:20] <sylvaing> then archive the actual agenda on the mailing list
# [14:20] <fantasai> szilles: if they put it on the agenda, does it get cleared from the wiki?
# [14:20] <fantasai> fantasai: suggest that the chairs take responsibility to clear the wiki after it's been discussed and closed
# [14:21] <fantasai> glazou: problem isn't this, problem is number of specs
# [14:21] <fantasai> ...
# [14:21] <fantasai> Tab: we have a scaling problem, we have to solve it
# [14:21] <fantasai> Tab: we didn't have as much to talk about before, now we do, and we have to solve the scalingproblem
# [14:21] <fantasai> sylvaing: It would be nice that the half of animations issues that can be resolved on the mailing list oculd be done
# [14:21] <fantasai> plinss: I don't have a problem with it in principle
# [14:22] <fantasai> plinss: But we've tried it, and it hasn't work
# [14:22] <fantasai> plinss: We've taken issues to mailing list before, and next week nothing else has happened
# [14:22] <fantasai> plinss: My fundamental concern with trying to resolve on mailing list is the overwhelming amount of traffic on www-style
# [14:22] <fantasai> plinss: Nobody can read it all
# [14:23] <fantasai> plinss: if we say, here's the discussion and we'll resolve unless there's object, only 3 people will read it
# [14:23] <fantasai> hober: call for consensus would have to be a new thread
# [14:23] <fantasai> sylvaing: but who in here has ability to make informed decisions on everything we discuss (aside from dbaron)?
# [14:23] <fantasai> Tab: you flag those thread
# [14:23] <fantasai> plinss: Even issues that get flagged, easy to miss
# [14:24] <fantasai> plinss: ... anecdotes from using mailing list ...
# [14:24] <fantasai> Florian: People who participated in the original thread start a new thread tagged [call for resolution] with the summary
# [14:25] <fantasai> glazou: you don't think contributors on www-style won't reply to those threads?
# [14:25] <fantasai> dbaron: if someone is making too much nose, tell them to stop
# [14:25] <fantasai> shane: if this is a problem, why not start another list for resolution
# [14:25] <fantasai> shane: publicly-readable, WG-writeable
# [14:25] * hober shane++
# [14:26] <fantasai> discussion of public vs private mailing lists
# [14:26] <fantasai> jdaggett: let me turn this around and say, glazou and plinss who are objecting to this, maybe you have something in mind
# [14:27] <fantasai> jdaggett: are you proposing more meetings, or what?
# [14:27] <fantasai> plinss: I think short-term, we should extend telecons to 90 minutes
# [14:27] <fantasai> plinss: pretty much every telecon we cut someone off at the end, extra 30 minutes would help
# [14:27] <fantasai> krit: I think it's a benefit to have 1 hr, have to concentrate on something
# [14:28] <fantasai> hober: Then instead of talking about something for 45 minute sthat should've been 20 minutes, would let that run to 60 minute sinstead, no win
# [14:28] <fantasai> szilles: ... modularization
# [14:28] <fantasai> Florian: not about modularization, about breadth of CSS
# [14:28] <fantasai> szilles: one suggestion I have is if you wen to a longer telephone call, that you have a part of it which is general topics, and another, anounced ahead of time, that is focused e.g. Flexbox
# [14:28] <fantasai> szilles: and people who don't want to engage, can drop off during that call
# [14:29] <fantasai> hober could have separate calls
# [14:29] <fantasai> fantasai: if you want to talk about text, maybe do not at 2am Japan time
# [14:30] * stearns thinks this is important to minute: steve: text is impossible
# [14:30] <fantasai> plinss: anyway, we need to wind this up
# [14:30] <fantasai> plinss: I'm not hearing consensus on moving to 90minute telecons
# [14:30] <fantasai> dbaron: I woud rather not
# [14:30] <fantasai> several: more frequent telecons
# [14:31] <fantasai> glenn: I would prefer two a week, one being general and one topic-specific
# [14:31] <fantasai> glenn: rather than one 90 minute call
# [14:31] <fantasai> Tab: prefer staggering, better to accommodate other timezones
# [14:31] <fantasai> plinss: not hearing consensus on any one solution, push aside for not
# [14:31] <fantasai> now
# [14:32] * sylvaing fwiw I'm not sure what a general topic is. modularization is also specialization.
# [14:32] <fantasai> plinss: Offer for F2F meeting in September in Zurich, not sure if idea was to replace San Diego or what
# [14:32] <fantasai> vhardy: There's a conference in Zurich, so SVGWG going there to meeting
# [14:32] <fantasai> Tab: could throw an FXTF day onto it, but not add CSSWG on top of it
# [14:33] <fantasai> szilles: does that mean we can do less FXTF stuff in August?
# [14:33] <fantasai> plinss: don't think we should take FXTF day every F2F
# [14:33] <fantasai> plinss: So keep CSS in SD in August
# [14:33] <fantasai> plinss: Don't want to add CSS meeting in September?
# [14:33] <fantasai> jdaggett: We should do 3 days at TPAC
# [14:33] <fantasai> Sun-Mon-Tues
# [14:33] <fantasai> jdaggett offers Tokyo next march
# [14:34] <fantasai> fantasai: also had an offer for Tucson from Molly fo rnext year
# [14:35] <fantasai> discussion of meeting dates/places
# [14:36] <fantasai> February: Tokyo or Arizona?
# [14:36] <fantasai> shane: we can offer sydney as well
# [14:38] <fantasai> jdaggett: tentatively, February in Tucson, May in Tokyo
# [14:40] <fantasai> PENCILLEDIN: February in Tucson, May in Tokyo
# [14:40] <fantasai> fantasai: Style attr has 2 passes from IE and FF, go to PR?
# [14:41] <fantasai> RESOLVED: Take CSS Style Attributes to PR
# [14:41] <fantasai> ACTION fantasai: publish test results etc.
# [14:41] * trackbot noticed an ACTION. Trying to create it.
# [14:41] * RRSAgent records action 2
# [14:41] <trackbot> Created ACTION-459 - Publish test results etc. [on Elika Etemad - due 2012-05-17].
# [14:41] <fantasai> Topic: Multicol Test Suite
# [14:41] <fantasai> howcome: bunch of tests at Opera, not all submitted but in process
# [14:42] <fantasai> plinss: Shepherd shows 42 testcases, harness shows 23
# [14:43] <fantasai> howcome: I encourage people to try their implementations
# [14:44] * Joins: miketaylr (miketaylr@70.112.101.224)
# [14:44] <fantasai> howcome shows off some tests
# [14:44] <fantasai> howcome asks MS to look at the tests
# [14:45] <fantasai> and Mozilla, and Chrome
# [14:45] <fantasai> ACTION Tab: run multicol tests in Chrome
# [14:45] * trackbot noticed an ACTION. Trying to create it.
# [14:45] * RRSAgent records action 3
# [14:45] <trackbot> Created ACTION-460 - Run multicol tests in Chrome [on Tab Atkins Jr. - due 2012-05-17].
# [14:46] <fantasai> stearns: how do you run the tests in Chrome? Tests don't have a prefix. Do you run grep on them?
# [14:46] <fantasai> fantasai: will ideally have build system handle that, for now I'd run a regex
# [14:47] <fantasai> stearns: We have an ad-hoc policy of asking for reviews, maybe getting reviews
# [14:47] <fantasai> stearns: wondering if we can be more organized, exchange reviews
# [14:47] <fantasai> fantasai suggests QA people exchange reviews amongst themselves
# [14:48] <fantasai> hober: does Shepherd email people about new tests to review?
# [14:48] <fantasai> plinss: who should it email?
# [14:48] <fantasai> krit: could email owner of test
# [14:48] <fantasai> plinss: could have owner of test, commenters, owner of suite get emailed
# [14:49] <fantasai> krit: one thing to write tests, also have to review tests
# [14:49] <fantasai> vhardy: Should we try to accept tests, and when someone runs the test against implementation
# [14:49] <fantasai> vhardy: they'll report errors
# [14:49] <fantasai> dbaron: I've been pushing for that for awhile
# [14:49] <fantasai> Florian: It's the passed for the wrong reason that's more annoying
# [14:51] <fantasai> ...
# [14:54] <fantasai> fantasai: could approve tests that pass multiple implementations, but should track tests that aren't reviewed manually separately, so that if someone does want to go through them they know which ones to review
# [14:54] <fantasai> ....
# [14:54] <fantasai> stearns: should not have them stuck in Awaiting Review
# [14:55] <fantasai> plinss: Suggest doing what we did with 2.1, build them into the test harness, run the tests, shift them into approved once the test suite seems stable, but don't give them reviewer links until they're individually reviewed
# [14:56] <howcome> Here's an alternative way to get to the multicol tests
# [14:56] <howcome> http://test.csswg.org/source/contributors/opera/submitted/multicol/
# [14:57] * dbaron wonders what issue we're trying to solve now
# [14:57] <fantasai> ...
# [14:57] <dbaron> Topic: Box Alignment
# [14:58] <sylvaing> scribenick:sylvaing
# [14:58] <dbaron> http://fantasai.inkedblade.net/style/specs/css3-align/
# [14:58] <hober> http://fantasai.inkedblade.net/style/specs/css3-align/
# [14:59] * Bert , seeing that we have failed to solve it in the past 12 years, wonders if 30 minutes really will be enough. :-)
# [14:59] <sylvaing> fantasai: the idea is to 'align' all the CSS alignment properties and resolve issues that have been put off for a long time
# [15:00] <sylvaing> fantasai: CSS1 and 2 supported text-align, vertical align, auto margins
# [15:00] <sylvaing> fantasai: new modules had many more alignment methods such as flexbox
# [15:00] <sylvaing> fantasai: grid adds two properties
# [15:00] <sylvaing> fantasai: in order to support the alignment attributes in html, more properties were needed
# [15:01] <sylvaing> fantasai: so the challenge is to come up with a set of common properties that can be shared across modules
# [15:01] <sylvaing> fantasai brings up the proposal
# [15:01] <sylvaing> fantasai: there two axis of alignment; there is the main axis of block flow. and a secondary axis for inline alignment (cross axis in flexbox)
# [15:02] <sylvaing> fantasai: you'll either want to align the box within its parent or align the content of the box...
# [15:02] <sylvaing> fantasai:...within itself
# [15:02] <sylvaing> fantasai: i tried to come up with a logical system to organize both axises
# [15:03] <sylvaing> fantasai: the first part of the name defines what is getting aligned: box, when the box aligns itself, content when its content is being aligned
# [15:03] <sylvaing> fantasai: then justify is in the inline axis and align is in the stacking axis e.g. box-align, box-justify
# [15:04] <sylvaing> howcome: are these meant to be aliases?
# [15:04] <sylvaing> fantasai: they would replace flexbox and grid properties, add new functionality to block and table alignment
# [15:04] <sylvaing> howcome: if people use text-align?
# [15:04] <sylvaing> fantasai: this is separate, none of these affect text-align
# [15:05] <sylvaing> howcome: so text-align and content-justify do not overlap ?
# [15:06] <sylvaing> dbaron, fantasai: content-justify align children
# [15:07] * Quits: miketaylr (miketaylr@70.112.101.224) (Quit: Leaving...)
# [15:07] <sylvaing> ...
# [15:08] <sylvaing> (discussing axis and checks in the table in the spec)
# [15:08] <sylvaing> fantasi: box-align does not apply to blocks because a block can't control its vertical position within its parent, it can only control its horizontal position
# [15:09] <sylvaing> (fantasai draws diagram on board)
# [15:10] <sylvaing> a grid item inside its grid cell map box-justify to grid-row-align and box-align to grid-column-align
# [15:10] <sylvaing> if the inner element is a block it can't control its own alignment within its parent but it can control its box-justify
# [15:11] <sylvaing> dbaron: so in inline layout justify controls the horizontal layout. shouldn't -justify control vertical alignment for blocks?
# [15:11] <sylvaing> fantasai: no, -justify controls the inline direction alignment
# [15:12] <sylvaing> fantasai: justify is horizontal alignment, align is vertical (modulo writing modes)
# [15:13] <sylvaing> dbaron: I thought we should have only 4 properties out of these 6
# [15:13] <sylvaing> dbaron: I think we could do without box-justify and items-justify
# [15:13] <sylvaing> fantasai: no, because grid needs box-justify
# [15:14] <sylvaing> fantasai: box-justify works in a manner similar to margins but adds to margins
# [15:15] <sylvaing> fantasai: the use-case for box-justify in blocks is wanting margins in addition to alignment
# [15:15] <sylvaing> fantasai: for example if I have a shrink-wrapped table, I want a 1em margin around it but I also want the table centered
# [15:15] <sylvaing> fantasai: but if the table fills its containing block I still want 1em between the table and its containing block
# [15:15] <Bert> (TeX-way to center: 'margin: 1em + 1fill')
# [15:16] <sylvaing> dbaron: I thought this is what box-align did
# [15:17] <sylvaing> fantasai: content-justify applies to the children of a block. it has an auto value which, only on a block element, computes to the value of its parent. this supports the HTML align attribute which inherits
# [15:18] <sylvaing> fantasai: content-align allows the children of a block to be centered vertically
# [15:18] <sylvaing> fantasai: it's like vertical-align for tables but applies across other box types
# [15:19] <sylvaing> fantasai: any value of content-align other than auto creates a BFC
# [15:19] <sylvaing> vhary: any value to automatically distribute space using content-align?
# [15:19] <sylvaing> s/vhary/vhardy
# [15:19] <sylvaing> fantasai: we could add a distribute value
# [15:19] <sylvaing> florian: since flexbox would depend on this, how do we move forward?
# [15:20] <sylvaing> fantasai: we would rename all the relevant flex properties using these names. we would define how they work for flexbox. for other elements, they have no effect unless defined by another module
# [15:21] <sylvaing> florian: we could keep the flexbox properties as they are. later we can introduce the new ones and they would work as shorthand expanding into the block align longhands. not sure whether that would make them aliases on the OM side.
# [15:21] <sylvaing> szilles: is it just a name change or is it a semantic change ?
# [15:21] <sylvaing> fantasai: it's a name change for flexbox
# [15:21] <sylvaing> szilles: I'm trying to distinguish their impact on flexbox vs. other specs
# [15:22] <sylvaing> szilles: if it's only a name change for flexbox this is very scoped. whether we propagate this to other modules can be done at a later time
# [15:22] <sylvaing> florian: except these properties can be applied to other things today and do nothing, then someday they'll do something
# [15:23] <sylvaing> dbaron: I agree with both of you. the timeframe of this evolution would have to be contained.
# [15:24] <sylvaing> (fantasai draws pretty blue and red boxes on paper)
# [15:24] <sylvaing> (multi-line flexbox with a number of items)
# [15:25] <sylvaing> fantasai: the alignment of flexboxes is controlled by 5 properties
# [15:26] * sylvaing if content-* applies inside and box-* applies outside, should future display-inside/display-outside align their name too?
# [15:27] <dbaron> fantasai: alignment of text to bottom inside red boxes is controled by content-align on red boxes
# [15:27] <dbaron> fantasai: alignment of red boxes within line is controled by flex-item-align on red box, whose auto value means to default to flex-align on green box
# [15:28] <dbaron> fantasai: alignment of red boxes within line is controlled content-justify/flex-pack
# [15:29] <Bert> q+ to ask about mixture of 'box-align: bottom' and 'box-align: top' on siblings.
# [15:30] <sylvaing> szilles: there is an analogy between lines in flexbox and lines in text. this model scales up the text behavior higher up.
# [15:30] <sylvaing> dbaron: I think the axis make sense in this flexbox example. I'm not sure I agree with the block example.
# [15:31] <sylvaing> alex: I think we should rename *-align with *-stack e.g. box-stack, content-stack
# [15:32] <sylvaing> fantasai: I'm not sure content-stack: baseline sounds right
# [15:32] <sylvaing> howcome: I don't really understand how this applies to blocks. don't you have to take it out of flow?
# [15:33] * Joins: myakura (myakura@221.171.5.98)
# [15:33] <sylvaing> fantasai: no. you would make your content center vertically
# [15:33] <sylvaing> fantasai: the entire content of a box has a particular height; if you have leftover space you can align within that
# [15:33] <sylvaing> bert: content-align aligns all the content. how do I align one child?
# [15:34] <sylvaing> fantasai: how would you align only one child?
# [15:34] <dbaron> Bert's case is the reason I don't think we should have box-justify and items-justify
# [15:34] <sylvaing> fantasai: I think this is a case that should be handled using flexible margins
# [15:36] <sylvaing> bert re-explains his example: a 4-column layout, each column has some images, text and color information at the bottom....(Bert will post link)
# [15:36] <sylvaing> florian: what are we resolving on?
# [15:37] <sylvaing> fantasai: 1) whether we want to move towards a common alignment model 2) whether we want flexbox to be based on this proposal
# [15:37] <Bert> http://www.w3.org/Talks/2012/0509-CSS-ftf/scan-12-small.jpg
# [15:37] <sylvaing> szilles: I think we should move flexbox to this. this will also help upcoming modules.
# [15:38] <sylvaing> fantasai: I think you want both content-* and text-* properties since you might want to align the blocks children and inline children of a block differently
# [15:39] <sylvaing> howcome: how does this interact with floats?
# [15:40] <sylvaing> fantasai: I don't think it applies to floats
# [15:40] <sylvaing> howcome: don't we want to look into this before moving this beyond flexbox?
# [15:40] <sylvaing> szilles: we're no worse off with this names vs. the flex-* ones
# [15:40] <sylvaing> szilles: these might generalize
# [15:41] * Joins: BradK (bradk@99.7.175.117)
# [15:42] <sylvaing> florian: there is a risk that these properties will be applied using 'blanket' selectors and content will break in the future.
# [15:42] <sylvaing> fantasai: I can work on this at a high priority
# [15:42] <sylvaing> florian: we do not have content dependency for flexbox at least
# [15:42] <sylvaing> vhardy: I think this is a great proposal. I agree it's high priority.
# [15:43] <sylvaing> howcome: I think the start/before value names will confuse people
# [15:43] <sylvaing> bert: most people don't need start/end/before/after
# [15:43] <sylvaing> plinss: can we resolve to keep working on this?
# [15:43] <sylvaing> dbaron: I agree we should resolve to work on this
# [15:44] <sylvaing> RESOLVED: fantasai to continue working on this proposal
# [15:44] <sylvaing> fantasai: see Issue 2 about the naming model
# [15:45] <howcome> howcome: we should keep using top/right/bottom/left, this is what users expect
# [15:45] <sylvaing> RESOLVED: flexbox alignment properties to be replaced by content-*/box-* equivalents
# [15:46] <Bert> (Where I think "this proposal" means: an attempt to generalize alignment across different box types, not necessarily with six properties.)
# [15:46] <sylvaing> florian: I'm happy with box and content
# [15:46] <sylvaing> vhardy: I find the verb-what convention easier
# [15:47] <sylvaing> Topic: Box generation
# [15:48] * Quits: Hixie (ianh@129.241.93.37) (Client exited)
# [15:49] <sylvaing> (Topic cancelled due to time available)
# [15:49] <sylvaing> <break>
# [15:50] <BradK> Break until grid in 15 min?
# [15:50] <BradK> Hi, BTW.
# [15:52] * Quits: kojiishi_ (kojiishi@193.105.139.140) (Ping timeout)
# [15:56] * Quits: AlexD (qw3birc@128.30.52.28) (Ping timeout)
# [15:59] * dholbert|zzz is now known as dholbert
# [16:09] <fantasai> BradK: yep, should be starting soonish
# [16:12] <dbaron> Zakim, code?
# [16:12] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [16:12] <dbaron> Zakim, room for 5?
# [16:13] <Zakim> ok, dbaron; conference Team_(css)14:05Z scheduled with code 26632 (CONF2) for 60 minutes until 1505Z; however, please note that capacity is now overbooked
# [16:13] <fantasai> dholbert: ^
# [16:13] <dholbert> thanks
# [16:13] <Zakim> Team_(css)14:05Z has now started
# [16:13] <Zakim> +dholbert
# [16:13] * Joins: AlexD (qw3birc@128.30.52.28)
# [16:13] * Joins: PhilCupp (PhilCupp@131.107.174.99)
# [16:14] <fantasai> PhilCupp: ^
# [16:14] <fantasai> er
# [16:14] <dbaron> Zakim, code?
# [16:14] <Zakim> the conference code is 26632 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), dbaron
# [16:14] <dbaron> PhilCupp, ^
# [16:14] * Joins: kojiishi_ (kojiishi@193.105.139.140)
# [16:14] <Zakim> +[Microsoft]
# [16:14] <Zakim> +Meeting_Room
# [16:16] <fantasai> my issues - http://wiki.csswg.org/spec/css3-grid-layout#issues-for-f2f
# [16:16] <fantasai> s/issues/issues list/
# [16:16] <sylvaing> scribenick: shans
# [16:16] <shanestephens> fantasai: I compiled a list after discussing with Microsoft
# [16:16] <sylvaing> scribenick: shanestephens
# [16:17] <shanestephens> fantasai: I compiled a list after discussing with Microsoft
# [16:17] <dbaron> Topic: Grid layout
# [16:17] <Zakim> + +1.512.587.aaaa
# [16:18] <shanestephens> … scoping principles we tried to apply were minimum set that is useful for this level of grid
# [16:18] <shanestephens> … to just reduce to as small a set as possible
# [16:18] <shanestephens> … other principle was to just have coordinate based system and leave others to a higher level
# [16:18] <shanestephens> … more sophisticated addressing handled by template or level 2 of grid
# [16:19] <shanestephens> … from those principles came suggestion: move template out of grid and have bert keep in template spec
# [16:19] <shanestephens> … drop named lines from this level of grid layout
# [16:19] <shanestephens> … other issues on positioning things with negative indexes or indexing from last line - push out as next level feature
# [16:19] <shanestephens> … just focus on layout and positioning needed for layout
# [16:20] <shanestephens> marcus: didn't make sense to have template in both specs
# [16:20] <shanestephens> … 2nd reason wanted to get more implementations faster
# [16:20] <shanestephens> … got feedback from firefox about core aspects and want to reduce to those aspects
# [16:21] <shanestephens> … tried to reduce complexity for first version
# [16:21] <glazou> s/marcus/markus
# [16:21] <shanestephens> phil: questioned whether or not the grid is suited to thinking about content in tracks and position content by defining rectangular area using start track and span length
# [16:21] <shanestephens> … or instead talk about lines.
# [16:22] <shanestephens> … conclusion was that you needed to talk about tracks in the spec because all the styling functions are creating space for tracks
# [16:22] <shanestephens> … but only need to talk about lines if lines are part of a positioning scheme
# [16:22] <shanestephens> … so it's easier to eliminate the concept of lines and just talk about tracks
# [16:22] <shanestephens> … think we can simplify all the language in the spec
# [16:22] <shanestephens> tabatkins: and then later on name the tracks
# [16:23] <shanestephens> plinss: I want to avoid that. The real power in grid is having the lines
# [16:23] <shanestephens> phil: real power in grid is dividing the space afforded to the grid by its parent
# [16:23] <shanestephens> … whether you make use of the space by referring to four lines or some tracks that intersect is a difference of perspective
# [16:23] <shanestephens> … doesn't change functionality
# [16:24] <shanestephens> plinss: I think it's a mental model shift. The way grids have been used traditionally in page layout, designers don't think in terms of tracks but in terms of lines.
# [16:25] <shanestephens> … page layout with grid - classic example: multiple columns, one with sidebars and no text. The column next to that one - the headings span out into the sidebar column.
# [16:25] <shanestephens> … the headings should be part of one flow in the middle track, but certain elements snap to different grid lines so they don't really live within a track.
# [16:26] <shanestephens> phil: I totally agree they don't live within a track, but think of the model - track has content structure. You define tracks and cells with additional properties. In grid you can have overlapping cells because the rectangular region is defined on the items. Free to say you have a heading that spans into some center track and then something else that intersects but doesn't occupy the same space.
# [16:26] <shanestephens> … not in same container but share reference to same tracks (??)
# [16:27] <shanestephens> … so I agree that tracks aren't containers, just spaces, and some of the intersections of rows and columns can define a region for positioning an item
# [16:27] <shanestephens> … so the concepts are equivalent.
# [16:27] <shanestephens> … Argument is that it'll be easier to read the spec if the mental model is around tracks.
# [16:27] <SteveZ> q+
# [16:27] * Zakim sees SteveZ on the speaker queue
# [16:28] <shanestephens> plinss: I agree that the shift in terminology isn't changing the features
# [16:28] <shanestephens> … my concern is the mental model. CSS is about cells and boxes, grids gives you a different model. I don't want to lose that.
# [16:28] <shanestephens> phil: Are you a fan of the spec as it reads now?
# [16:28] <shanestephens> plinss: I haven't had a chance to look
# [16:29] <shanestephens> markus: Feedback we got is that spec is confusing. Reading through it introduces lots of models that do the same thing. Confusion: which should be used?
# [16:29] <shanestephens> …We agree with your point. Lots of possible positioning models that can live on grid. Absolute positioning. Templating.
# [16:29] <shanestephens> …which is the fundamental concept and which can build on that?
# [16:30] <shanestephens> phil: 4 positioning schemes in current spec: template, named line, using numbers to denote start/end lines, using numbers to define starting track and span length
# [16:30] <shanestephens> … we want to boil that down to just 1
# [16:30] <shanestephens> … because simpler is better
# [16:30] <shanestephens> plinss: let's move on. I'll provide feedback over email.
# [16:31] <shanestephens> stevez: 2 other things that lines give that change functionality: (a) by using lines instead of numbers can add a line in the middle of the grid and don't have to redo positioning. Named lines give you more editing generality.
# [16:32] <shanestephens> …(b) using media queries can come up with different grids using same named lines for different media - e.g. branch headings out if there's enough space.
# [16:32] <shanestephens> phil: One distinction - we're talking about the concept of lines as numbers vs. tracks as numbers, not concept of named lines
# [16:32] <dbaron> Zakim, who is noisy?
# [16:32] <Zakim> - +1.512.587.aaaa
# [16:32] <Zakim> dbaron, listening for 10 seconds I heard sound from the following: [Microsoft] (78%), Meeting_Room (13%)
# [16:33] <shanestephens> phil: There's no difference between numbering systems. Doesn't apply to named lines.
# [16:33] <Zakim> + +1.512.587.aabb
# [16:33] <shanestephens> stevez: we are talking about named lines.
# [16:33] <shanestephens> phil: your point: do we need some kind of indirection? Argument is one of leveling - does it need to be in the first version of the grid spec?
# [16:34] <shanestephens> phil: not minimum level of functionality that provides usability
# [16:34] <shanestephens> stevez: if you want to give users a good model for using grid, not having naming schemes leads them down the wrong path.
# [16:34] <shanestephens> plinss: if you want to avoid complexity, drop indexed system before name-based system.
# [16:35] <shanestephens> markus: we are seeing that it's easier for people to think in terms of numbers right now, because of history. Wouldn't go against that right now.
# [16:35] <Bert> q+ to say names require you to think of names, where there actually is no semantics, and it is not extensible for auto-plcameent (a-priori unknown # of rows)
# [16:35] * Zakim sees SteveZ, Bert on the speaker queue
# [16:35] <plinss> ack stevez
# [16:35] * Zakim sees Bert on the speaker queue
# [16:36] <shanestephens> phil: also defer because the concepts need time to mature. Discussion with fantasai indicated named lines got verbose because you're naming all 4 edges.
# [16:36] <shanestephens> … but with template syntax only need to assign one value.
# [16:36] * Joins: nimbu (Adium@192.150.10.200)
# [16:37] <shanestephens> … When using named lines, theory is you want something that says this is my header start line, header end line. Need pairs for both row and column dimensions. Now if you want to change definition of grid, relocate those four names. With that model you're going to have 4 names x number of grid items that you want to make maintainable. That's lots to type - haven't created ease of maintenance tool.
# [16:37] <shanestephens> … not convinced that named lines actually solve the problem we set out to solve. Not positive that templates are better.
# [16:37] <shanestephens> … but shorter to type, and talking about regions instead of items - can't type 2 letters in same spot.
# [16:38] <shanestephens> … argument against template system is it doesn't give full power of grid.
# [16:38] <shanestephens> … both of these areas could use some bake time.
# [16:38] * sylvaing notes we have now spent 25mn on the same issue
# [16:38] <shanestephens> plinss: let's move on
# [16:38] <plinss> ack bert
# [16:38] <Zakim> Bert, you wanted to say names require you to think of names, where there actually is no semantics, and it is not extensible for auto-plcameent (a-priori unknown # of rows)
# [16:39] * Zakim sees no one on the speaker queue
# [16:39] <shanestephens> bert: need numbers anyway
# [16:39] <shanestephens> … so that's enough to have in the core. Can add other notations later.
# [16:39] <shanestephens> elica: next issue: discussion on mailing list about adding ability to do gutters on grid lines so you don't need to create an extra set.
# [16:39] <shanestephens> … we said we could reuse the column-gap property
# [16:40] <shanestephens> s/elica/fantasai
# [16:40] * Quits: kojiishi (kojiishi@222.158.227.129) (Quit: Leaving...)
# [16:40] <shanestephens> fantasai: so also add row-gap for other dimension
# [16:40] <shanestephens> bert: not necessary, very limited - can only have one type of gap for all columns. If you have something that spans multiple columns where does the gap end?
# [16:40] <shanestephens> fantasai: would span over the gap.
# [16:41] <shanestephens> tabatkins: one of the reasons you need this kind of gap - if you want to do flex box in a grid you can kind of do it <draws on board>
# [16:41] <shanestephens> … but you can't specify gutters. If you do them as empty rows and columns the content will try to expand into them
# [16:42] <shanestephens> … really want a declarative mechanism
# [16:42] <shanestephens> stevez: why isn't that a property of a track?
# [16:42] <shanestephens> phil: tracks don't have properties because there's no track element to style
# [16:42] <shanestephens> tabatkins: could put into grid rows, but is unclear which track the gutter would belong to
# [16:42] <shanestephens> phil: they're the spaces between the tracks
# [16:43] <shanestephens> tabatkins: probably almost always want uniform gutters
# [16:43] <shanestephens> stevez: not objecting to simple mechanism, but bert's point was that it doesn't provide arbitrary gutters. So a separate mechanism for specifying a col or row that is intentionally blank seems to be a useful feature.
# [16:43] <shanestephens> … was in original proposal
# [16:43] <shanestephens> tabatkins: +1
# [16:44] <shanestephens> fantasai: in the cases where you want non-uniform gutters have small number of elements that you're styling individually. Easier to use ??
# [16:44] <shanestephens> phil: so uniform gutters mean we could just adopt column-gap and define row-gap. If we want a non-uniform mechanism we'd need to provide a list of gutters or something
# [16:44] <shanestephens> markus: sounds like a great feature for next level
# [16:44] <shanestephens> stevez: actually I was saying you could declare a column or row as being a gap
# [16:45] <shanestephens> phil: like a gap() function or something
# [16:45] <shanestephens> bert: can leave that to templates. That's what they do
# [16:45] <shanestephens> markus: sounds like agreement for a basic mechanism in spec
# [16:45] <shanestephens> fantasai: next, some naming things. Grid spec has grid-flow, want to align with syntax of flex-flow
# [16:46] * Joins: Ms2ger (Ms2ger@91.181.124.114)
# [16:46] <shanestephens> … row means add more rows as you add content, column means …, layer means create stack in the current cell
# [16:46] <shanestephens> … previously row and column were flipped. Very confusing. None becomes layer to be more clear.
# [16:47] <shanestephens> markus: feedback from tooling people - really liked layer approach. But others might want to do things other ways.
# [16:47] <shanestephens> bert: alternative I had was to use grid-row property for that - have a keyword that says this goes into next row, and one on column that says this goes into the same column
# [16:48] <shanestephens> fantasai: doesn't handle a lot of auto-placement situations because you can't wrap onto the next line. If you have 100 items and just want them to flow into a grid, can't do that without nth-child.
# [16:48] * sylvaing are we resolving anything?
# [16:48] <shanestephens> … if you throw in different spans, definitely can't do that.
# [16:48] <shanestephens> bert: can do that with normal selectors
# [16:48] <shanestephens> tabatkins: yeah need to explicitly do it. More complex than it should be for the use case.
# [16:49] <shanestephens> bert: normal case is that you don't fill lines but that certain elements need to be in particular places.
# [16:49] <shanestephens> tabatkins: still really easy to do in this syntax
# [16:49] <shanestephens> fantasai: both use cases useful, each set of syntaxes can do things the other one can't. So we should have both approaches.
# [16:50] <shanestephens> bert: e.g. I want to have a table, transposed. That's easy to do by saying every td:first-child goes into the next column
# [16:50] <shanestephens> howcome: are you saying this is possible with grid flow?
# [16:50] <shanestephens> bert: yes
# [16:50] <shanestephens> phil: grid flow would be property of grid. Not targeting individual items.
# [16:51] <shanestephens> bert: but if you want every <tr> to start a new column, then (??)
# [16:52] <shanestephens> markus: so we all agree basic functionality should be there but are now talking about finer points. Move to email? Both approaches have value, different ways of achieving same thing
# [16:52] <Bert> tr {grid-flow: column} td {grid-flow: row} or td:first-child {grid-column: next; grid-row: 1}
# [16:55] <shanestephens> discussion about repeat patterns and whether row means row
# [16:55] * sylvaing feels sorry he suggested resolving something
# [16:57] <shanestephens> RESOLVED: rename the values of grid-flow so that row adds rows, column adds columns, and layer just stacks grid items on top of each other.
# [16:57] <shanestephens> phil: let's go back and see if there are resolutions on the other ones too. Gutters:
# [16:58] <Bert> (So if 'grid-flow' doesn't influence the autoplacement, how do you say where the next child goes?)
# [16:58] <shanestephens> plinss: we only had a dissuasion, no conclusion.
# [16:59] <shanestephens> bert: we don't need them. We can use margins.
# [16:59] <shanestephens> tabatkins: margins don't collapse. So you get double-wide gaps in the middle.
# [17:00] <shanestephens> … you want 0 on the edges and 10 on other lines. Can't do it without using nth-child
# [17:00] <Bert> div::slot(a) {margin-left: 10px}
# [17:00] <shanestephens> phil: also can't center the margin on the line
# [17:01] <shanestephens> phil: are there any objections to adding these?
# [17:01] <shanestephens> bert: certainly not in the core, they might hurt us later
# [17:01] * Quits: paul___irish (paul___iri@205.186.165.150) (Ping timeout)
# [17:01] <shanestephens> stevez: same as multicolor?
# [17:01] <shanestephens> s/multicolor/multicol/
# [17:02] <shanestephens> bert: I think we're doing the wrong thing but won't give an objection
# [17:02] <BradK> I'm in favor of gutter gaps
# [17:02] <shanestephens> bert: I've never needed it. Why add it?
# [17:03] <shanestephens> phil: I didn't hear your solution to putting the gutter down the center of the line rather than on one side.
# [17:03] * Joins: paul___irish (paul___iri@205.186.165.150)
# [17:03] <shanestephens> RESOLVED: add row-gap and column-gap to the specification such that they provide uniform gutters
# [17:04] <shanestephens> phil: lines versus tracks as numbering. I don't think we'll get a resolution on that but we have an action.
# [17:04] <shanestephens> ACTION plinss to read new version of spec and provide feedback to phil
# [17:04] * trackbot noticed an ACTION. Trying to create it.
# [17:04] <trackbot> Created ACTION-461 - Read new version of spec and provide feedback to phil [on Peter Linss - due 2012-05-17].
# [17:05] <shanestephens> phil: alternative addressing schemes. grid template syntax with lettering of cells and named lines - proposing that they are deferred
# [17:05] <Bert> I think Elika's split means: Core = 'grid-rows', 'grid-columns', 'grid-position-{x,y}' (incl. same/next/auto-placement), 'vertical-align' (or equiv.), and the constraint system to calculate sizes, pagination. Rest = 'grid-template', 'grid' shorthand, ::slot(), 'flow', (and then in level 4: 'chains', page-based grid templates)
# [17:05] <shanestephens> … do we have a resolution or action?
# [17:06] <shanestephens> stevez: not in favour
# [17:06] <shanestephens> stevez: worried we won't ever specify these modes
# [17:07] * Joins: dstorey (Adium@67.180.84.179)
# [17:07] <shanestephens> dbaron: I think that if you think the feature is important you should keep it in
# [17:07] <shanestephens> … not familiar enough with specification to have strong opinion, but reasoning is dangerous because you can take a long time to get back to things
# [17:08] <shanestephens> plinss: I share steve's concern that by not having it in level 1 you won't teach people to use it the right way
# [17:08] <shanestephens> fantasai: would prefer to keep template rather than named lines, agree that named lines syntax is really awkward.
# [17:08] <shanestephens> plinss: I propose we revisit this when I have had a chance to provide feedback
# [17:10] <BradK> I hope we can at least keep templates.
# [17:10] <shanestephens> stevez: I'm concerned that moving templates out of this spec and into bert's changes behavior. It's a non-trivial change.
# [17:10] <shanestephens> phil: I think there needs to be clear scope separating these two specs. Right now there's significant overlap, with some conflicts.
# [17:11] <BradK> Templates and grid go together very well. Like chocolate and peanut butter.
# [17:11] <shanestephens> … beyond that, there's additional functionality in the templates spec that we don't want to see come into the grid spec.
# [17:11] <shanestephens> fantasai: declaring grid, positioning, templating and layout algorithm all in both specs and incompatible.
# [17:11] <shanestephens> … need to move them into one place
# [17:12] <shanestephens> bert: more compatible than they used to be.
# [17:12] <shanestephens> sylvaing: but still in 2 places
# [17:12] <shanestephens> stevez: I'm concerned that if templates are to provide a named interface to grids, having them in a different spec is a bad idea.
# [17:12] <shanestephens> fantasai: well that's fine, they still need to be in just one spec
# [17:12] <shanestephens> phil: have had 2 specifications because of disagreement on some functionality.
# [17:13] <shanestephens> phil: needs to be a resolution about which model to support, and which specification to put it in.
# [17:13] <shanestephens> plinss: don't have enough time to solve this right now.
# [17:14] <shanestephens> ACTION Markus, phil and bert to get together and work out how to resolve the templating specifications to remove overlap
# [17:14] * trackbot noticed an ACTION. Trying to create it.
# [17:14] <trackbot> Sorry, couldn't find user - Markus,
# [17:14] <dbaron> ScribeNick: dbaron
# [17:15] <shanestephens> ACTION markus to get together with phil and bert and work out how to resolve the templating specifications to remove overlap
# [17:15] * trackbot noticed an ACTION. Trying to create it.
# [17:15] <trackbot> Created ACTION-462 - Get together with phil and bert and work out how to resolve the templating specifications to remove overlap [on Markus Mielke - due 2012-05-17].
# [17:15] <dbaron> Topic: CSS3 fonts
# [17:15] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2012May/0369.html
# [17:15] <dbaron> jdaggett: I just dropped in url for post i sent a few days ago
# [17:16] <dbaron> jdaggett: css3 fonts defines support for font features. Designed to enable features if they exist in the font, but we don't provide a fallback.
# [17:16] <Zakim> -dholbert
# [17:16] <PhilCupp> thanks for great grid discussion... dropping off call
# [17:16] <Zakim> -[Microsoft]
# [17:16] <dbaron> jdaggett: But there are a couple of exceptions where we do provide fallback:
# [17:16] <dbaron> jdaggett: For small-caps, if a font doesn't have small-caps glyphs, user-agent will synthesize
# [17:16] * Quits: PhilCupp (PhilCupp@131.107.174.99) (Quit: PhilCupp)
# [17:16] <dbaron> jdaggett: Other case where we do fallback is superscript and subscript, which is semantic, so requires fallback
# [17:17] <dbaron> jdaggett: [Shows demo]
# [17:17] <dbaron> jdaggett: I have a bunch of fonts with subscript and superscript variant glyphs
# [17:17] <dbaron> jdaggett: this shows what you see with browsers today and with variants
# [17:18] <dbaron> jdaggett: first is the subscript variant designed by the type designer -- the weight is designed to match the weight of what it's in
# [17:18] <dbaron> jdaggett: the third shows what happens when you shrink it down -- it looks lighter
# [17:18] <Zakim> - +1.512.587.aabb
# [17:19] <dbaron> jdaggett: these special subscript/superscript glyphs are designed in the same design space as the font -- there's no resizing/offsetting for the subscript/superscript when using the glyphs designed for it
# [17:19] <dbaron> jdaggett: the way we do subscript/superscript today we modify the baseline (vertical-align: sub/super) and reduce the font size
# [17:19] <dbaron> jdaggett: To use the sub/super glyphs, you have to not do that
# [17:20] <dbaron> jdaggett: The font also has metrics that say the suggestions of the font designer for where the subscript should go (position & size)
# [17:20] <dbaron> jdaggett: the middle (red) item is a super/sub sized and positioned based on these metrics
# [17:21] <dbaron> jdaggett: they're not matched to the variant glyphs (e.g., less offset in Minion)
# [17:21] <dbaron> jdaggett: or, e.g., in Whitney, the metrics are bigger and less offset to compensate for the weight
# [17:22] <dbaron> jdaggett: problem with this: in a situation where some characters are supported and others are not, it's difficult to synthesize a combination
# [17:22] * Quits: alexmog__ (qw3birc@128.30.52.28) (Ping timeout)
# [17:23] <dbaron> (clarifying question from vhardy about diff betw 2nd and 3rd)
# [17:23] <Zakim> disconnecting the lone participant, Meeting_Room, in Team_(css)14:05Z
# [17:23] <Zakim> Team_(css)14:05Z has ended
# [17:23] <Zakim> Attendees were dholbert, [Microsoft], Meeting_Room, +1.512.587.aaaa, +1.512.587.aabb
# [17:23] * Parts: howcome (howcome@193.105.139.140)
# [17:23] <dbaron> jdaggett: so, if we just use variant glyphs, we'll have problems: shows Minion Pro having variants for (, 2, and ), but not for [ and ]
# [17:24] <dbaron> jdaggett: in the first link, one of my first points is that when we do fallback, we need to do it across the entire text span
# [17:24] <dbaron> jdaggett: so we synthesize even when part of the text span supports part of the variant glyphs
# [17:25] <dbaron> jdaggett: So with Minion pro you'd synthesize all of "[2]" but would use variant glyphs for all of "(2)"
# [17:25] <dbaron> jdaggett: The metrics aren't there in the font to let us synthesize on a per-character basis
# [17:25] <dbaron> SteveZ: So this is unusual since we're doing glyph subst on a per-span basis rather than per-char basis
# [17:26] <dbaron> jdaggett: The other problem we have here is that we have this existing mechanism for super scripts and subscripts that does it in a structural way
# [17:26] <dbaron> jdaggett: coming up with a backwards-compatibile way of doing this is hard
# [17:26] <dbaron> jdaggett: since if you use the designed glyphs, you need vertical-align: baseline and inherited font size, i.e., need to turn off existing mechanism
# [17:26] <dbaron> jdaggett: see testcase in bottom of post
# [17:27] <dbaron> jdaggett: you can see that for this case we're turning on font-variant position superscript and turning off vertical-align and font size reduction from default style sheet
# [17:27] * sylvaing Professor Daggett is in control
# [17:27] <BradK> How do you define text span? All the text in an element? Including text that is inserted later?
# [17:27] <dbaron> SteveZ: One side effect is that I no longer sure how to compute the vertical extent of the subscripts and how they affect line height according to css
# [17:27] <dbaron> jdaggett: in my mind, this should have no impact on the line box
# [17:28] <dbaron> jdaggett: when the designer put the metrics in, they're designed so they're just like any other character
# [17:28] <dbaron> SteveZ: so there's no actual baseline shift
# [17:28] <fantasai> fantasai: there's a visual shift, but no actual shift
# [17:28] <dbaron> jdaggett: So whether it has subscripts or not, this will produce a page that doesn't have varying line heights
# [17:29] <dbaron> jdaggett: there was a proposal (see post) from fantasai and dbaron to come up with something that would shoehorn magic behind the scenes so when this matched vertical-align, you'd undo the vertical-align and font size changes
# [17:29] <dbaron> jdaggett: what this won't do is cover the case where you have nested subscripts or superscripts
# [17:29] <dbaron> jdaggett: (replying to Florian) fonts never have glyphs for nested sub/super
# [17:30] <dbaron> jdaggett: And this won't line up with images (since you're not getting the baseline shift)
# [17:30] <dbaron> jdaggett: So this can only do a subscript of the super/subscript stuff you can do today.
# [17:30] <dbaron> Florian: So if you have an image and glyphs, you can't use the special glyphs
# [17:30] <dbaron> jdaggett: So what I'm arguing for is that we have less magic, and authors have to be aware that this is only typographic sub/super and not structural
# [17:31] <dbaron> fantasai: So if authors try to use this for sub/super, the sub/superscripting will fail for nesting or non-text
# [17:31] <dbaron> jdaggett: Details of original post by fantasai/dbaron rely on metrics which doesn't work since these metrics aren't right
# [17:31] <dbaron> jdaggett: I think you could still come up with magic that ... .
# [17:31] * Quits: kojiishi_ (kojiishi@193.105.139.140) (Ping timeout)
# [17:32] <dbaron> jdaggett: There's existing content that's out there, so it's safer to say that: here's how you do this, cover the 90% use case (just text, short runs).
# [17:32] <dbaron> jdaggett: Do we need to talk more about alternate proposal, wanting magic?
# [17:32] <dbaron> fantasai: How do you determine bounds of text run that needs to be considered together?
# [17:32] <dbaron> jdaggett: No wording for that yet.
# [17:32] <dbaron> jdaggett: Wanted general agreement for it first before getting to actual wording
# [17:33] <dbaron> jdaggett: Thinking roughly: across spans of contiguous text (but can span sub-elements)
# [17:33] <dbaron> SteveZ: If I've got a span, and turned on typographic sub/super, and do a baseline shift inside that, what happens?
# [17:33] <dbaron> jdaggett: You get a baseline shift -- probably not going to look right.
# [17:33] <dbaron> peterl: I'm not seeing in the email how you turn on this type of superscript
# [17:34] <dbaron> jdaggett: just turn on font-variant-position
# [17:34] <dbaron> jdaggett: There's an example in the spec that includes the turning of of v-a and font-size
# [17:34] <dbaron> TabAtkins: and for fallback, @supports queries
# [17:34] <dbaron> Bert: That example tests whether the user-agent is able to do this, but dosen't check whether the font has a suitable glyph
# [17:35] <dbaron> jdaggett: Supporting the property means the UA will do fallback if the font doesn't support it
# [17:35] <dbaron> SteveZ: That's the new piece added this time around
# [17:35] <dbaron> fantasai: I'm not totally convinced we shouldn't be doing something smarter where people are putting elements inside it
# [17:35] <dbaron> fantasai: I like the idea of doing the idea of fallback at a span level
# [17:36] <dbaron> Liam: Isn't the answer that if you're already deciding not to use the native glyphs, then if you find an element inside, fall back to synthetic mechanism for the whole thing?
# [17:36] <dbaron> fantasai: The way it's defined right now, super inside super wouldn't nest
# [17:36] <dbaron> jdaggett: It's bad if you think it has to support that -- but I don't think we need to support that.
# [17:36] <dbaron> jdaggett: There's already a default mechanism that allows that.
# [17:36] <dbaron> q+
# [17:36] * Zakim sees dbaron on the speaker queue
# [17:37] <dbaron> peterl: If the designer specifies font-variant-position: sub, they'll get scaled down glyphs as fallback, right?
# [17:37] <dbaron> jdaggett: yes
# [17:37] <dbaron> Bert: ...
# [17:37] <dbaron> jdaggett: ...
# [17:37] <dbaron> Bert: ok, but I can see examples here... in general, do fonts scale down well?
# [17:38] <dbaron> fantasai: It's better if you don't scale and use the appropriate glyphs?
# [17:38] <fantasai> s/?/
# [17:38] <fantasai> /
# [17:38] <fantasai> jdaggett: the point here is to use the glyphs in the font
# [17:39] <fantasai> dbaron: How does this handle underlining?
# [17:39] <fantasai> dbaron: That's sort of a common case
# [17:39] <fantasai> dbaron: e.g. used in Wikipedia
# [17:39] <fantasai> szilles: underline isn't affected generally
# [17:40] <fantasai> dbaron: no, if you draw the underline just for the superscript
# [17:40] <fantasai> dbaron: how do you get that position correctly
# [17:40] <fantasai> jdaggett: so the answer here is that the underline will be drawn at the main baseline
# [17:40] <dbaron> ack dbaron
# [17:40] * Zakim sees no one on the speaker queue
# [17:40] <Bert> (I was thinking of the TeX fonts, which actually use slightly different glyphs for 8pt and for 10pt, so that you can use them together.)
# [17:40] <fantasai> fantasai: you might wind up doing fallbacks in the case of text-decoration
# [17:41] <fantasai> plinss: in Wikipedia, the decoration appears only on :hover -- that's not going to work
# [17:41] <dbaron> peterl: Well, on wikipedia the underline only shows up on :hover, which would mean doing fallback when there's decoration wouldn't be so great
# [17:41] <fantasai> dbaron: you'd switch into fallback on :hover
# [17:42] <fantasai> ACTION jdaggett: figure out text-decoration interaction with font-variant-position
# [17:42] * RRSAgent records action 4
# [17:42] * trackbot noticed an ACTION. Trying to create it.
# [17:42] <trackbot> Created ACTION-463 - Figure out text-decoration interaction with font-variant-position [on John Daggett - due 2012-05-17].
# [17:42] <fantasai> ACTION jdaggett: define what scopes the run of things falling back
# [17:42] * RRSAgent records action 5
# [17:42] * trackbot noticed an ACTION. Trying to create it.
# [17:42] <trackbot> Created ACTION-464 - Define what scopes the run of things falling back [on John Daggett - due 2012-05-17].
# [17:43] <dbaron> proposed resolution: accept two points in http://lists.w3.org/Archives/Public/www-style/2012May/0369.html pending actual wording from jdaggett
# [17:43] <dbaron> fantasai: I'm less comfortable with second one since if you're styling content and didn't account for some of the stuff that's in there you'll get weird behavior
# [17:43] * Quits: krit (krit@192.150.10.201) (Connection reset by peer)
# [17:43] <dbaron> jdaggett: I think we can resolve on this and then we can have caveats
# [17:44] <dbaron> fantasai: Ideally, I'd like this to work in the general case
# [17:44] <dbaron> jdaggett: I think that's a good ideal, but that endns up not serving the 90% case very well
# [17:44] <dbaron> fantasai: I want to solve both and I think it's possible
# [17:44] <dbaron> jdaggett: I disagree... but if you have another proposal we can talk about that
# [17:45] <dbaron> SteveZ: informational question: if in the middle examples, I wanted to make "2" black, so I put a span <sup>(<span>2</span>)</sup>...
# [17:45] <dbaron> jdaggett: my action item to figure that out...
# [17:45] <dbaron> jdaggett: My intention is that it's a contiguous text run; need not be one single element, so it would work
# [17:46] <dbaron> jdaggett: if you say <p>f<span>i</span> in Firefox today, you'll see a ligature that's half black and half red
# [17:46] * Joins: krit (krit@192.150.10.201)
# [17:47] <dbaron> peterl: fantasai, ok with resolving now, and you can maybe come back with improved proposal?
# [17:47] <dbaron> fantasai: ok
# [17:47] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2012May/0375.html
# [17:47] <fantasai> fantasai: I agree 100% with the first point
# [17:47] <dbaron> RESOLUTION: accept two points in http://lists.w3.org/Archives/Public/www-style/2012May/0369.html ; jdaggett to provide actual wording
# [17:47] <dbaron> jdaggett: relatively minor point about small caps
# [17:47] <fantasai> s/RESOLUTION/RESOLVED/
# [17:48] <dbaron> jdaggett: with a font thas has either small-caps variant or doesn't, we have the fallback be determined by whether the font itself supports small-cap glyphs
# [17:48] <dbaron> jdaggett: i.e., that we don't do per-glyph checking
# [17:48] <dbaron> jdaggett: That's different from the super/sub case.
# [17:48] * Joins: kojiishi (kojiishi@193.105.139.140)
# [17:48] <dbaron> jdaggett: Good reason for this: fonts typically support all or nothing, unlike for sub/super where they typcially support only a few chars
# [17:48] <dbaron> peterl: Typically, or universally?
# [17:49] <dbaron> jdaggett: Close to universal
# [17:49] <dbaron> jdaggett: A font like Arial is not actually designed by one person, designed by several people.
# [17:49] <dbaron> jdaggett: Can get cases where Latin, Cyrillic work, Greek doesn't
# [17:49] <dbaron> jdaggett: so I want cases that this can be done on a per-script basis
# [17:49] <dbaron> jdaggett: which would allow user-agents to do this check on a per-script basis
# [17:49] <dbaron> jdaggett: per-glyph checking is a much higher implementation cost
# [17:50] <dbaron> jdaggett: theres' a difference in the way the model worsk, but warranted by the nature of the font
# [17:50] <dbaron> jdaggett: there's always the poential that what a browser would synth is not precisely what a font would do
# [17:50] <dbaron> jdaggett: because of casing rules, e.g., for Greek
# [17:50] <dbaron> jdaggett: so there's potential font won't match browser casing rules
# [17:51] <dbaron> jdaggett: So, e.g., if you were to take a font that supported small-caps and strip out the information that enables it and have the browser synthesize it, those two results may not necessarily match the same set of characters, because the browsers upper/lowercase may not be what the font designer used when he set up the small-caps feature.
# [17:51] <dbaron> fantasai: Does Greek keep diacritics in small-caps (rather than all-caps)?
# [17:51] <dbaron> jdaggett: I'm saying there's room for differences
# [17:52] <dbaron> jdaggett: I wanted to directly tie uppercase and lowercase function to text-transform
# [17:52] <dbaron> jdaggett: I want the handling of synthetic small-caps to match the casing used in the text-transform feature, which means the check for "do I need to small-cap this glyph" uses the same case transformations that are used for text-transform
# [17:53] <dbaron> fantasai: There are 2 casing things you need to do: (1) check "is this glyph lowercase?" and if so synthesize a small-cap and (2) convert from lowercase to uppercase and shrink the glyph
# [17:53] <dbaron> fantasai: (2) is where you need the case transform table
# [17:53] <dbaron> jdaggett: And I'm saying that should match text-transform
# [17:54] <dbaron> fantasai: the wording here is really vague:
# [17:54] <dbaron> fantasai: capital letters are not affected by small-caps
# [17:54] <dbaron> jdaggett: but are by all-caps
# [17:54] <dbaron> fantasai: so you want to say only bicameral scripts are affected
# [17:54] <dbaron> jdaggett: I want to say it's exactly like text-transform
# [17:54] <dbaron> jdaggett: i think these 2 features should be consistent
# [17:55] * fantasai just thinks the wording proposed is confusing
# [17:55] <dbaron> SteveZ: implied text-transform...?
# [17:55] <dbaron> jdaggett: I'm just saying the case transformations used for small-caps are the same that are used for text-transform
# [17:55] <dbaron> SteveZ: ...
# [17:56] <dbaron> jdaggett: The reason for that is that if text-transform puts in special rules for special casing, we don't want to have to go back and modify two specs
# [17:56] <dbaron> fantasai: I Think you have a good point but the wording is confusing
# [17:56] <fantasai> ACTION fantasai: propose less confusing wording
# [17:56] * RRSAgent records action 6
# [17:56] * trackbot noticed an ACTION. Trying to create it.
# [17:56] <trackbot> Created ACTION-465 - Propose less confusing wording [on Elika Etemad - due 2012-05-17].
# [17:56] <dbaron> jdaggett: I'll rework the wording
# [17:56] <dbaron> jdaggett: only other thing about css3-fonts is that I published today revised wording of font-family syntax from the last telecon
# [17:57] <dbaron> Håkon: formal grammar?
# [17:57] <dbaron> jdaggett: Yes. Deal with inclusion of 'inherit' within font family name, e.g., 'font-family: foo inherit' is invalid
# [17:57] <dbaron> jdaggett: saying you need quotes in that case
# [17:57] <dbaron> Bert: you said you put in some text
# [17:58] <dbaron> jdaggett: on the mailing list
# [17:58] <dbaron> jdaggett: I'm piggybacking on changes I proposed for css3-values, issues with case sensitivity.
# [17:58] <dbaron> Bert: It's a change from CSS 2.1
# [17:59] <dbaron> jdaggett: Fixing ambiguity, I don't think it's a change.
# [17:59] <dbaron> Tab: We already resolved on this last week or the week before
# [17:59] <dbaron> Bert: The resolution I recorded was ...
# [17:59] <dbaron> Tab: That wasn't the resolution we were trying to get
# [17:59] <dbaron> Tab: If you want to reopen, please do it on the mailing list
# [18:00] <dbaron> Bert: we should not change 2.1
# [18:00] <dbaron> Bert: 2.1 is very clear except for the case where there is a font name called inherit, unquoted
# [18:00] <dbaron> tab: anything else?
# [18:00] <fantasai> ACTION fantasai: review css3-fonts wording on font-family syntax
# [18:00] * trackbot noticed an ACTION. Trying to create it.
# [18:00] * RRSAgent records action 7
# [18:00] <trackbot> Created ACTION-466 - Review css3-fonts wording on font-family syntax [on Elika Etemad - due 2012-05-17].
# [18:01] <dbaron> jdaggett: I'm done. Just from a spec level I'm trying to go through the spec, publish another WD in the next couple weeks.
# [18:01] <dbaron> jdaggett: Last sticky issue is font matching for clusters (base characters with combining diacritics, variation selectors). Once that's ironed out I think will want to consider moving to last call.
# [18:01] <dbaron> jdaggett: fantasai has some comments about @feature-values to post to the mailing list
# [18:02] <dbaron> jdaggett: past that I'll start asking people to take a look at the spec, look for things ambiguous, unclear, could be better explained
# [18:03] * Quits: jdaggett (jdaggett@193.105.139.140) (Quit: jdaggett)
# [18:03] <dbaron> Topic: anything else?
# [18:03] <dbaron> Tab: rename display:flexbox to display:flex
# [18:04] <dbaron> Tab: and change spec terminology from flexbox -> flex container, and flexbox item to flex item
# [18:04] <dbaron> Florian: would want to do either both or neither
# [18:05] <dbaron> peter: any objcetions?
# [18:05] <dbaron> RESOLVED: rename display:flexbox to display:flex
# [18:05] <dbaron> RESOLVED: change spec terminology from flexbox -> flex container, and flexbox item to flex item
# [18:05] <dbaron> Topic: update
# [18:06] <dbaron> vhardy: last time I showed a tool to help editors with issue tracking
# [18:06] <dbaron> vhardy: if you want to use bugzilla to track your issues and make sure they're in your spec
# [18:06] <dbaron> vhardy: a tool for editors, not meant to be published
# [18:06] <dbaron> vhardy: checks for issue markers and checks bugzilla
# [18:06] <dbaron> vhardy: Will tell you if you have issues that are resolved that should be removed, or new ones that should be mentioned in the spec
# [18:07] <dbaron> vhardy: I put this in the shared repository under root of spec directory
# [18:07] <dbaron> Florian: only bugzilla, not tracker?
# [18:07] <dbaron> vhardy: right
# [18:07] <dbaron> Bert: way to put this in postprocessor rather than only insert when you're online?
# [18:07] * Joins: jdaggett (jdaggett@193.105.139.140)
# [18:07] <dbaron> vhardy: you need to insert issues at a particular point in your spec
# [18:08] <dbaron> Bert: but I put the issue number in the spec
# [18:08] <dbaron> Bert: because it's not done by the postprocessor I have to make a link myself
# [18:08] <dbaron> Bert: I'd like to just put ISSUE -dash- 217 and have the postprocessor just make it a link
# [18:08] <dbaron> vhardy: I don't have access to the postprocessor
# [18:08] <dbaron> Bert: wondering if this code is readable enough...
# [18:09] <dbaron> vhardy: I didn't write it... but his code is very legible
# [18:09] <fantasai> plinss: on this topic, we wer etalking about test annotation script
# [18:09] * Liam thanks dbaron for letting in some oxygen
# [18:09] * Quits: vhardy__ (vhardy@193.105.139.140) (Quit: vhardy__)
# [18:09] <fantasai> plinss: Tim doesn't allow us to have it on /TR/
# [18:09] <fantasai> plinss: But he will allow us to add to /TR/ specs a link to an annotated version
# [18:10] <fantasai> plinss: so thinking of putting /TR/ specs mirrored on csswg.org
# [18:10] <dbaron> plinss: because it makes specs in /TR/ mutable based on something off of w3.org servers
# [18:10] <fantasai> plinss: can do annotations and anything else we want there
# [18:10] * Quits: glazou (glazou@193.105.139.140) (Quit: glazou)
# [18:10] <fantasai> Meeting closed.
# [18:10] * Quits: jet (jet@193.105.139.140) (Quit: jet)
# [18:10] * Quits: AlexD (qw3birc@128.30.52.28) (Quit: Page closed)
# [18:11] * Quits: arronei_ (Arron@24.17.123.244) (Quit: arronei_)
# [18:11] * Quits: kojiishi (kojiishi@193.105.139.140) (Quit: Leaving...)
# [18:12] * Quits: tabatkins__ (qw3birc@128.30.52.28) (Ping timeout)
# [18:13] * plinss is now known as plinss_away
# [18:14] * Quits: SteveZ (chatzilla@193.105.139.140) (Ping timeout)
# [18:16] * Joins: glazou (glazou@193.105.139.140)
# [18:17] * Quits: glazou (glazou@193.105.139.140) (Quit: glazou)
# [18:18] * sylvaing is now known as sylvaing_away
# [18:18] * Quits: jdaggett (jdaggett@193.105.139.140) (Quit: jdaggett)
# [18:21] * Joins: jet (jet@193.105.139.140)
# [18:25] * Quits: shanestephens (shanesteph@193.105.139.140) (Quit: shanestephens)
# [18:25] * Quits: florianr (florianr@193.105.139.140) (Ping timeout)
# [18:25] * Quits: glenn (gadams@193.105.139.140) (Client exited)
# [18:26] * Quits: BradK (bradk@99.7.175.117) (Quit: Buh bye)
# [18:26] * Quits: jet (jet@193.105.139.140) (Quit: jet)
# [18:27] * Quits: dbaron (dbaron@193.105.139.140) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [18:34] * Quits: Liam (liam@128.30.52.169) (Ping timeout)
# [18:38] * Quits: myakura (myakura@221.171.5.98) (Client exited)
# [18:51] * Quits: shepazu (shepazu@128.30.52.169) (Client exited)
# [18:52] * Joins: shepazu (shepazu@128.30.52.169)
# [19:03] * Quits: krit (krit@192.150.10.201) (Connection reset by peer)
# [19:03] * Joins: miketaylr (miketaylr@70.112.101.224)
# [19:07] * Joins: Rossen (Rossen@131.107.0.125)
# [19:10] * sylvaing_away is now known as sylvaing
# [19:14] * Quits: dstorey (Adium@67.180.84.179) (Quit: Leaving.)
# [19:43] * Joins: dstorey (Adium@144.189.101.1)
# [19:44] * Quits: miketaylr (miketaylr@70.112.101.224) (Quit: dflk;adfslkj;alsiekfj;laiskdf)
# [19:52] * Zakim excuses himself; his presence no longer seems to be needed
# [19:52] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [21:10] * Quits: dstorey (Adium@144.189.101.1) (Quit: Leaving.)
# [21:20] * Quits: SimonSapin (simon@82.232.219.95) (Ping timeout)
# [21:26] * Joins: myakura (myakura@221.171.5.98)
# [21:29] * Quits: myakura (myakura@221.171.5.98) (Ping timeout)
# [21:41] * plinss_away is now known as plinss
# [21:52] * Joins: SteveZ (chatzilla@88.71.76.2)
# [21:53] * Joins: krit (krit@88.71.76.2)
# [21:54] * Quits: Rossen (Rossen@131.107.0.125) (Ping timeout)
# [22:01] * Quits: dholbert (dholbert@98.248.36.12) (Quit: dholbert)
# [22:02] * Quits: tantek (tantek@50.1.62.23) (Quit: tantek)
# [22:26] * Quits: krit (krit@88.71.76.2) (Connection reset by peer)
# [22:26] * Joins: krit1 (krit@88.71.76.2)
# [22:39] * Joins: shanestephens (shanesteph@85.183.206.243)
# [22:44] * sylvaing is now known as sylvaing_away
# [22:44] * Quits: krit1 (krit@88.71.76.2) (Quit: Leaving.)
# [22:47] * Joins: vhardy_ (vhardy@88.71.76.2)
# [22:54] * Quits: SteveZ (chatzilla@88.71.76.2) (Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725])
# [22:57] * Quits: shanestephens (shanesteph@85.183.206.243) (Quit: shanestephens)
# [23:02] * Quits: Ms2ger (Ms2ger@91.181.124.114) (Ping timeout)
# [23:10] * Joins: dstorey (Adium@144.189.101.1)
# [23:12] * Joins: glenn (gadams@88.71.76.2)
# [23:15] * Joins: jet (jet@217.5.145.235)
# [23:28] * Joins: tantek (tantek@50.1.62.23)
# [23:34] * Joins: ksweeney (ksweeney@63.119.10.10)
# [23:40] * plinss is now known as plinss_away
# [23:44] * Parts: ksweeney (ksweeney@63.119.10.10)
# [23:48] * Quits: jet (jet@217.5.145.235) (Quit: jet)
# [23:53] * Quits: vhardy_ (vhardy@88.71.76.2) (Quit: vhardy_)
# [23:56] * Joins: vhardy_ (vhardy@88.71.76.2)
# [23:59] * Quits: vhardy_ (vhardy@88.71.76.2) (Quit: vhardy_)
# Session Close: Fri May 11 00:00:01 2012

The end :)