/irc-logs / w3c / #css / 2013-09-11 / end

Options:

# Session Start: Wed Sep 11 00:00:00 2013
# Session Ident: #css
# [00:01] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [00:10] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [00:27] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [00:27] * Joins: zcorpan (~zcorpan@public.cloak)
# [00:32] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [00:34] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [01:16] * heycam|away is now known as heycam
# [01:34] * Joins: jdaggett (~jdaggett@public.cloak)
# [01:38] * Joins: zcorpan (~zcorpan@public.cloak)
# [01:45] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [02:01] * heycam is now known as heycam|away
# [02:05] * heycam|away is now known as heycam
# [02:15] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [02:35] * Joins: cabanier (~cabanier@public.cloak)
# [02:47] * Quits: tobie (tobie@public.cloak)
# [03:01] * Joins: tobie (tobie@public.cloak)
# [03:02] * Quits: tobie (tobie@public.cloak)
# [03:04] * Joins: myakura (~myakura@public.cloak)
# [03:08] * Joins: rhauck1 (~Adium@public.cloak)
# [03:13] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [03:15] * Quits: rhauck1 (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [04:32] * Joins: dauwhe (~dauwhe@public.cloak)
# [05:04] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [05:05] * heycam is now known as heycam|away
# [05:14] * Joins: dauwhe (~dauwhe@public.cloak)
# [05:16] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [05:32] * heycam|away is now known as heycam
# [07:30] * Joins: teoli (~teoli@public.cloak)
# [07:43] * Joins: teoli_ (~teoli@public.cloak)
# [07:44] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [08:11] * Quits: teoli_ (~teoli@public.cloak) (Client closed connection)
# [08:13] * Joins: zcorpan (~zcorpan@public.cloak)
# [08:17] * Joins: dauwhe (~dauwhe@public.cloak)
# [08:20] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [08:24] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [08:26] * Joins: dbaron (~dbaron@public.cloak)
# [08:26] <dbaron> trackbot, start telecon
# [08:26] * trackbot is preparing a teleconference.
# [08:26] * Joins: RRSAgent (rrsagent@public.cloak)
# [08:26] <RRSAgent> logging to http://www.w3.org/2013/09/11-css-irc
# [08:26] <trackbot> RRSAgent, make logs member
# [08:26] <RRSAgent> I have made the request, trackbot
# [08:26] * Joins: Zakim (zakim@public.cloak)
# [08:26] <trackbot> Zakim, this will be Style_CSS FP
# [08:26] <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
# [08:26] <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
# [08:26] <trackbot> Date: 11 September 2013
# [08:26] <dbaron> RRSAgent, make logs public
# [08:26] <RRSAgent> I have made the request, dbaron
# [08:26] <dbaron> Zakim, remind us in 10 hours to go home
# [08:26] <Zakim> ok, dbaron
# [08:33] * liam zakim, list
# [08:33] * Zakim sees no active conferences and none scheduled to start in the next 15 minutes
# [08:33] * liam too early (won't be there today in any case I think)
# [08:44] * Joins: zcorpan (~zcorpan@public.cloak)
# [08:45] * Joins: teoli (~teoli@public.cloak)
# [08:51] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [08:51] * Joins: myakura (~myakura@public.cloak)
# [08:52] * Joins: astearns (~astearns@public.cloak)
# [08:53] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [08:55] * Joins: Mike_L (~Mike_L@public.cloak)
# [08:55] * Parts: Mike_L (~Mike_L@public.cloak)
# [08:58] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [09:02] <jdaggett> dbaron: can you enable the vidyo connection?
# [09:03] * Joins: cyril (~cyril@public.cloak)
# [09:06] <astearns> jdaggett: dbaron is still letting people in the building. we're about 1/3 present, people are still getting some breakfast
# [09:07] <jdaggett> ok
# [09:13] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [09:13] * Joins: zcorpan (~zcorpan@public.cloak)
# [09:14] * Joins: krit (~krit@public.cloak)
# [09:14] * Joins: shans__ (~shans@public.cloak)
# [09:15] * krit thinks we should start with a discussion about responsive images
# [09:15] <hober> shans: https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFTimeUtils/Reference/reference.html
# [09:16] * Joins: ian (~ian@public.cloak)
# [09:18] * Joins: israelh (~israelh@public.cloak)
# [09:21] * Joins: sgalineau (~sgalineau@public.cloak)
# [09:21] * Joins: yamamoto (~yamamoto@public.cloak)
# [09:25] * Joins: michou (~mibalan@public.cloak)
# [09:26] * Joins: projector (~projector@public.cloak)
# [09:26] * Joins: glazou (~glazou@public.cloak)
# [09:33] <jdaggett> what room are you guys in?
# [09:33] <sgalineau> salle des fetes 123
# [09:34] <TabAtkins> ScribeNick: TabAtkins
# [09:34] * Joins: Rossen_ (~Rossen@public.cloak)
# [09:34] * leaverou_away is now known as leaverou
# [09:35] <TabAtkins> [not minuting the introductions]
# [09:35] <jdaggett> is dbaron around?
# [09:35] <dbaron> jdaggett, yes
# [09:35] <sgalineau> yes
# [09:35] <jdaggett> dbaron: what's the vidyo room?
# [09:35] <TabAtkins> Topic: Agenda
# [09:35] <dbaron> jdaggett, use PAR 123 Salle des Fêtes
# [09:35] <dbaron> jdaggett, though we're not dialed in
# [09:36] <dbaron> jdaggett, oh, we are dialed in :-)
# [09:36] <Rossen_> yes
# [09:36] <astearns> yes, john
# [09:36] <sgalineau> you now have a booming voice
# [09:36] <projector> yes we can hear you
# [09:37] <projector> SUPER LOUD
# [09:37] * Joins: Mads_Co3 (~Mads_Co3@public.cloak)
# [09:38] * Joins: tantek (~tantek@public.cloak)
# [09:38] <sgalineau> think of that Skype gizmo, but with 300W speakers
# [09:38] <jdaggett> ok, i'll try and move away from the mike...
# [09:38] <jdaggett> heh
# [09:39] * Joins: kawabata (~kawabata@public.cloak)
# [09:39] * Joins: leif (~lastorset@public.cloak)
# [09:40] <TabAtkins> glazou: How much time do you need for Fonts?
# [09:40] <jdaggett> for font load events, probably better to talk thurs am
# [09:42] * Joins: SteveZ (~SteveZ@public.cloak)
# [09:42] <sgalineau> Compositing&Blending is a small item; best at end of day Thur. so Rik can call in
# [09:42] <dbaron> Present: Jet Villegas (Mozilla), Bert Bos (W3C), Håkon Lie (Opera), David Baron (Mozilla), Koji Ishii (Rakuten), Mihai Balan (Adobe), Sylvain Galineau (Adobe), Dirk Schultze (Adobe), Tantek Çelik (Mozilla), Ted O'Connor (Apple), Shane Stevens (Google), Ian Kirkpatrick (Google), Tab Atkins (Google), Lea Verou (Invited Expert), Simon Sapin (Mozilla), Leif Arne Storset (Opera), Kawabata (NTT), Yamamoto (NTT), Glenn Adams (Cox), Rossen Atanassov (Microsoft), fant
# [09:42] <dbaron> asai (Mozilla), Israel Hilerio (Microsoft), Simon Pieters (Opera), Steve Zilles (Adobe), Daniel Glazman (Disruptive Innovations), Peter Linss (HP), Alan Stearns (Adobe), John Daggett (Mozilla, remotely)
# [09:43] * heycam is now known as heycam|away
# [09:49] <astearns> (agenda/schedule wrangling)
# [09:49] <jdaggett> so someone is editing the agenda in the wiki?
# [09:49] <TabAtkins> Agenda: Grid
# [09:49] <fantasai> http://www.w3.org/TR/2013/WD-css3-grid-layout-20130910/
# [09:50] * Joins: shans___ (~shans@public.cloak)
# [09:50] <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Aug/0353.html
# [09:50] <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Aug/0554.html
# [09:53] <TabAtkins> fantasai: At tokyo we discussed the renaming of grid-definition-* to be under a grid-template-* prefix.
# [09:53] <jdaggett> dbaron: the podium mikes aren't on
# [09:53] <TabAtkins> fantasai: Didn't resolve on it.
# [09:53] <dbaron> jdaggett, the podium mike is pointed at the room
# [09:53] <TabAtkins> fantasai: Because these all define the explicit grid, we thought they should have a common prefix.
# [09:53] <jdaggett> ah, purfect!
# [09:53] <TabAtkins> fantasai: Any objections?
# [09:54] * sgalineau too early for bikeshedding
# [09:54] <TabAtkins> RESOLVED: Accept the grid-template-* renaming.
# [09:54] <TabAtkins> fantasai: Next issue is about abspos children of grid containers.
# [09:54] <TabAtkins> fantasai: Two issues.
# [09:54] <TabAtkins> fantasai: First is static position of grid container children.
# [09:55] <TabAtkins> fantasai: What we discussed among grid layout people is to make the static position to be determined as if it were the sole grid item in a fixed-size grid area whose padding edges coincide with the grid container.
# [09:55] * Quits: shans__ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [09:55] <TabAtkins> fantasai: In effect, this will position the child of the grid in the top-left (start/start) corner by default, but you can use justify-self/align-self to move it around.
# [09:55] <glazou> /query SimonSapin
# [09:56] <TabAtkins> fantasai: This isn't just for absposes relative to the grid; it's the staticpos, used when you're just a child of the grid.
# [09:56] <TabAtkins> fantasai: This has the benefit that the alignment properties will have an effect - you can "center" it easily, for example.
# [09:56] <TabAtkins> fantasai: So this gives you a little more power, but doesn't require any interaction with the layout of the rest of the grid.
# [09:56] <TabAtkins> fantasai: So the one consideration with this is that it's not consistent with Flexbox.
# [09:57] <TabAtkins> fantasai: Flexbox tries to find where the item would have been in the flow if it was a real flex child.
# [09:57] <TabAtkins> fantasai: We could try to do that with Grid, but it's more complicated due to 2d. Or we can go back and change Flexbox to have this definition.
# [09:58] * shans___ is now known as shans__
# [09:58] <TabAtkins> TabAtkins: Last time we discussed this, strongest voice for current flexbox beahvior was Brad, so I'd like any decision to be contingent on him approving it later.
# [09:58] <TabAtkins> sylvaing: Why did he want it?
# [09:59] <TabAtkins> fantasai: He thought it was somewhat useful. But I think his use-cases generally you'd want things in a slightly different position anyway.
# [09:59] <TabAtkins> fantasai: The advantage of this definition is that it's somewhat more simple, but it's not consistent with block flow's definition.
# [09:59] <TabAtkins> fantasai: Same with Flexbox, though it's closer.
# [09:59] * Joins: shans___ (~shans_@public.cloak)
# [09:59] <TabAtkins> fantasai: Flexbox tries to be close to normal flow; I just don't think we have strong use-cases for this.
# [10:00] <TabAtkins> TabAtkins: I approve of matching Grid here, so we keep the rule that a single column/row Grid is similar to a Flexbox.
# [10:00] <TabAtkins> fantasai: Right, either that or try to copy Flexbox's behavior in Grid, whatever makes them consistent.
# [10:01] <TabAtkins> fantasai: So I would like implementor opinions, or else I"ll make the decision myself.
# [10:01] <TabAtkins> [summarizes the discussion again for dbaron, who was messing with the door]
# [10:01] <TabAtkins> dbaron: Not doing what flow layout does sounds great to me.
# [10:02] <TabAtkins> dbaron: Fine with me to do what Grid does for Flexbox.
# [10:02] <TabAtkins> dbaron: I'd like to see testcases to see if there's already interop.
# [10:02] <TabAtkins> TabAtkins: There is'nt - I know Blink doesn't follow the spec.
# [10:02] <TabAtkins> fantasai: Moz doesn't quite either.
# [10:02] <TabAtkins> dbaron: Fine with me, then.
# [10:02] <TabAtkins> RESOLVED: Grid child staticpos is resolved as if it's the sole child, and copy the definition over to Flexbox.
# [10:03] <TabAtkins> fantasai: Next abspos issue.
# [10:03] <TabAtkins> fantasai: We discussed in Tokyo allowing the grid-placement properties to affect the position of an abspos item whose containing block is the grid container.
# [10:04] <TabAtkins> fantasai: We talked about 'auto' indicating the padding edge of the grid container.
# [10:04] <TabAtkins> fantasai: [re-explains it slower]
# [10:05] * Quits: shans__ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [10:05] * Joins: tobie (tobie@public.cloak)
# [10:06] <TabAtkins> dbaron: Does this allow anything that grid items can't do?
# [10:06] <TabAtkins> TabAtkins: Somewhat. Grid items can't position onto the padding edge unless that's a grid line.
# [10:06] <TabAtkins> dbaron: Is this required for anything?
# [10:06] <TabAtkins> TabAtkins: Somewhat, yes - it helps address the "stuff on the grid" rather than "stuff in the grid" use-case.
# [10:07] <TabAtkins> dbaron: This sounds like a decent chunk of new abspos functionality.
# [10:07] * glazou 1st time I see Rod Stewart's music used as a door bell :-)
# [10:07] <TabAtkins> dbaron: If there's a good reason for this, I'd expect to see more description in the spec about it.
# [10:07] <TabAtkins> TabAtkins: Yeah, some of th enew thing we've added are lacking in description. Sounds good for me.
# [10:08] * sgalineau glazou, because it's the 1st time you're in a room where 3 people remember who rod stewart is…?
# [10:08] <TabAtkins> fantasai: [explains the details to szilles a little better]
# [10:08] * glazou sgalineau aaaah yes you and I are so old dinosaurs (thinking TTWF)
# [10:09] <TabAtkins> szilles: Why isn't there a property that changes from content to padding edge instead?
# [10:09] <TabAtkins> fantasai: There's not one for abspos in general, but if we add one it'll apply here.
# [10:09] * Quits: israelh (~israelh@public.cloak) (Ping timeout: 180 seconds)
# [10:09] <TabAtkins> szilles: I'm just extending what David's said - it seems strange to do it this way with specific grid functionality without a switch in general.
# [10:09] * glazou Florian will attend the meeting only friday
# [10:10] <TabAtkins> RESOLVED: Add more examples to the abspos section.
# [10:11] <TabAtkins> fantasai: Peter had a proposal that using the ascii-art template should imply the creation of named lines that correspond to he named areas' edges.
# [10:12] <TabAtkins> fantasai: [shows the example in the spec for grid-template-areas]
# [10:12] <TabAtkins> fantasai: So here there'd be four named lines generated by the "main" area - "main-start" and "main-end" in the column dimensions, and the same in the row dimension.
# [10:12] * Quits: cyril (~cyril@public.cloak) ("Page closed")
# [10:12] <TabAtkins> fantasai: This seemed liek a pretty straightforward thing to do, so we added it to the spec.
# [10:12] <dbaron> http://www.w3.org/TR/2013/WD-css3-grid-layout-20130910/#implicit-named-lines
# [10:13] <TabAtkins> fantasai: This acts the same as explicitly named lines, except that it doesn't show up in the serialization of grid-template-rows/etc.
# [10:13] <TabAtkins> ACTION tab to add examples to implicit named lines.
# [10:13] * trackbot is creating a new ACTION.
# [10:13] <trackbot> Created ACTION-577 - Add examples to implicit named lines. [on Tab Atkins Jr. - due 2013-09-18].
# [10:14] <TabAtkins> astearns: What happens if you have one of those templates and a grid-template-row with the same name?
# [10:14] <TabAtkins> fantasai: You just end up with two lines of that name, which is already possible to do explicitly, so it's fine.
# [10:14] * Joins: israelh (~israelh@public.cloak)
# [10:15] <TabAtkins> RESOLVED: Named areas create implicitly named lines.
# [10:16] <TabAtkins> fantasai: The other side of Peter's proposal is that if you create four named lines with the appropriate "foo-start/end" names, it would implicitly create a named area.
# [10:16] <TabAtkins> fantasai: This is nice and symmetrical, but it has some problems. Currently you can't have two slots of the same name - it's invalid at the grammar level.
# [10:16] <TabAtkins> fantasai: But with this implicit areas, you could potentially create multiple areas of the same name.
# [10:17] <TabAtkins> fantasai: Also, since you can have multiple lines of the same name, you have to have rules for deciding *which* foo-start line you use to generate the "foo" area.
# [10:17] <TabAtkins> plinss: All those complications exist anyway - you can also create two lines named "foo-start", and if I address it by lines, I have to resolve that.
# [10:18] <TabAtkins> fantasai: We have rules about how to resolve multiple lines. But we don't currently have those rules for named areas.
# [10:18] <TabAtkins> astearns: But you *could* just use the same rules.
# [10:19] <TabAtkins> TabAtkins: So it wouldn't really create areas, it would just desugar into the appropriate named lines.
# [10:19] <TabAtkins> plinss: Without this, you need to track named lines and named areas independently. With this, you just only store lines, and the ascii syntax just conveniently defines lines.
# [10:20] <TabAtkins> fantasai: So you might end up with a slot in your template named "main", but if you make more "main-start" lines it might not actually land in that slot.
# [10:20] <TabAtkins> astearns: So grid-template-rows/columns wins over areas?
# [10:21] <TabAtkins> TabAtkins: Not necessarily - you'd just use the normal "first line of the name" rule, the source of that line doesn't matter.
# [10:21] <TabAtkins> szilles: So while you can have multiple lines of the sam ename, as far as areas go, only one is useful.
# [10:22] <TabAtkins> RESOLVED: Make named areas just desugar into named lines.
# [10:23] <TabAtkins> TabAtkins: We'll need to make sure that the grammar isn't ambiguous.
# [10:23] <TabAtkins> fantasai: I think we just need to keep the current prioriziation: given "grid-row: foo;", first look for a "foo-start" or "foo-end" named line, then look for "foo".
# [10:24] <TabAtkins> szilles: IN some of the shorthands, the default for the end value is the same as the start value. That works for areas, but not always for lines.
# [10:24] <TabAtkins> fantasai: It still works, depending on your naming.
# [10:25] <TabAtkins> [darn, missing something]
# [10:25] <TabAtkins> fantasai: Say "grid-row: main". We'll then look for "main-start" or "main-end", depending.
# [10:25] <TabAtkins> fantasai: If you say "grid-row: main-start", we'll first look for "main-start-start" and "main-start-end", which probably don't exist, so we'll look for "main-start".
# [10:26] <TabAtkins> szilles: Just saying you need to make sure to handle the defaults properly as you translate them.
# [10:27] <TabAtkins> fantasai: Next issue was about collapsing grid tracks. We tried to come up with some ideas, but don't know what to do.
# [10:27] <TabAtkins> fantasai: But first, subgrids.
# [10:27] <TabAtkins> fantasai: One section we fleshed out was the subgrid section.
# [10:28] <TabAtkins> fantasai: The goal of subgrids is that a lot of times you'll have some portion of a grid that you want to have a border or padding, or some semantic grouping element.
# [10:28] <TabAtkins> fantasai: There is an example in the spec with a bunch of labels and inputs, and it's a jumble of siblings.
# [10:28] <TabAtkins> fantasai: Really, you want them to jsut be in a list. But you couldn't make that work with Grid, because of the <li> containers.
# [10:28] <TabAtkins> fantasai: So the idea of subgrid is to help with this.
# [10:29] <TabAtkins> fantasai: You can currently have nested grids, but they don't interact - the two grids are independent.
# [10:29] <TabAtkins> fantasai: Subgrid lets the child grid align with th eparent grid.
# [10:29] <TabAtkins> fantasai: [explains the spec example]
# [10:30] <TabAtkins> fantasai: Instead of giving the child its own rows and columns, we give it a "subgrid" value.
# [10:30] <TabAtkins> fantasai: You can give the subgrid border/margin/padding, and that automatically gets taken into account.
# [10:31] <TabAtkins> fantasai: The rules are that the number of explicit tracks in a subgrid are given by the grid's own span.
# [10:31] <TabAtkins> fantasai: If the grid has an auto span, you lay it out to find out how many tracks it'll have, and then use that as its span.
# [10:32] <TabAtkins> fantasai: The grid-placement properties for subgrid items are scoped to the subgrid's lines.
# [10:32] <TabAtkins> fantasai: So positioning something at 1/1 doesn't put it at the parent's 1/1, it's the first lines in the subgrid.
# [10:32] <TabAtkins> fantasai: [draws an example]
# [10:33] <jdaggett> dbaron: ok, gotta run
# [10:33] <jdaggett> dbaron: i'll dial back in around 2:30 your time
# [10:33] <dbaron> jdaggett, ok
# [10:34] <TabAtkins> fantasai: For making things easy, the subgrid is always stretched to the columns it covers.
# [10:34] <TabAtkins> fantasai: You can specify explicit named lines in the subgrid - these lines are only exposed in the subgrid.
# [10:35] <TabAtkins> fantasai: If you have an explicit span and position for the subgrid, you know exactly which lines you correspond to in the parent grid, and in that case you inherit the parent's line names as well.
# [10:35] <TabAtkins> fantasai: We only do this in this case, because otherwise you dont' know exactly what tracks you need.
# [10:36] <TabAtkins> glazou: This seems complex. Are implementors actually going to do this?
# [10:36] <TabAtkins> TabAtkins: In the grid layout calls, MS was okay with it.
# [10:36] <dbaron> fantasai: should be in this level because otherwise people will do horrible things removing elements from the markup
# [10:37] * Quits: tobie (tobie@public.cloak)
# [10:37] <TabAtkins> astearns: Would it make sense to have a simpler version of subgrid, without additional lines?
# [10:37] <TabAtkins> glazou: I'm just really afraid this will be at-risk.
# [10:38] <TabAtkins> fantasai: Problem is right now Grid makes it *impossible* to do many layouts without stripping out your good markup.
# [10:38] <TabAtkins> fantasai: subgrid makes it *possible*.
# [10:38] <TabAtkins> szilles: Basic subgrid (without borders/etc) isn't much different from plain grid, right?
# [10:38] <TabAtkins> fantasai: Interaction of padding/etc is actually quite straightforward.
# [10:40] <TabAtkins> fantasai: The hard part is the interaction with the sizing algorithm.
# [10:40] <TabAtkins> Rossen_: Priority-wise this'll be lower.
# [10:40] <TabAtkins> fantasai: So that was subgrids.
# [10:41] <sgalineau> was there some kind of resolution for this?
# [10:41] <TabAtkins> fantasai: Another issue was about the "resolved value" of grid-template-rows/columns.
# [10:41] <TabAtkins> No.
# [10:41] * TabAtkins is planning to interrupt in a sec.
# [10:41] <astearns> probably the resolution should be to mark subgrid as at risk
# [10:41] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [10:42] <TabAtkins> dbaron: It might be nice to both mark the whole of subgrid at-risk, and also mark "optional" parts of it at-risk, so it's not too scary for implementors.
# [10:43] <TabAtkins> szilles: Can you scroll a subgrid?
# [10:43] <TabAtkins> fantasai: Yes... that would be something to mark as at-risk.
# [10:43] <astearns> tabatkins: it doesn't complicate the algorithm, it just adds these specific complications to the algorithm
# [10:44] <TabAtkins> Rossen_: We were thinking of doing initial layout of the subgrid, nicely aligned with the parent grid, and then scrolling is just a window on top of the parent grid.
# [10:44] <TabAtkins> Rossen_: There should be no additional constraints or problems.
# [10:45] <TabAtkins> szilles: Another possibility is to not allow implicit placement of subgrids.
# [10:47] <TabAtkins> fantasai: The syntactic switch for auto span vs explicit span is already there in the syntax, so we can't just not recognize it. :/
# [10:47] <TabAtkins> fantasai: But we can go through and see what we can mark at-risk. But I do believe the basic core functionality does need to be there.
# [10:47] <TabAtkins> RESOLVED: Leave subgrids in, mark it and its component parts individually as at-risk.
# [10:47] <TabAtkins> fantasai: Back to getComputedStyle.
# [10:47] <TabAtkins> fantasai: For compat with MS's impl, we're having gCS return the used value rather than the computed value of these properties.
# [10:47] <TabAtkins> fantasai: We didn't see a clear path to make this consistent, and gCS is already inconsistent anyway, so whatever.
# [10:48] <TabAtkins> fantasai: Any concerns?
# [10:48] <TabAtkins> dbaron: I'm in favor of having them all be computed values, but I guess I"m okay
# [10:48] <TabAtkins> fantasai: We felt the same wya.
# [10:49] <TabAtkins> Rossen_: Tooling was a big thing for us.
# [10:49] <TabAtkins> RESOLVED: gCS returns used values for grid-template-rows/columns.
# [10:50] <TabAtkins> fantasai: Naming issue - some people suggested we call them "grid fields" rather than "grid areas", and adjust the property names accordingly.
# [10:51] <tantek> +1 to grid areas
# [10:51] <TabAtkins> szilles: I believe Peter originally brought this up as being closer to what print grids use.
# [10:51] <TabAtkins> leaverou: I think "areas" make more sense.
# [10:51] <TabAtkins> Rossen_: I think we felt the same way - "area" just feels better.
# [10:52] <TabAtkins> sgalineau: Even with the historical argument, it's weird to only pick one historical name, rather than all of them.
# [10:52] <TabAtkins> glenn: Use "cell"?
# [10:52] <TabAtkins> fantasai: Confusing with tables, and we already use that to mean the intersection of two tracks.
# [10:52] <TabAtkins> RESOLVED: Keep 'grid-area'.
# [10:55] <TabAtkins>
# [10:58] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [11:01] * Joins: oyvind (~oyvinds@public.cloak)
# [11:03] * Quits: astearns (~astearns@public.cloak) (Client closed connection)
# [11:16] * Joins: astearns (~astearns@public.cloak)
# [11:17] <astearns> (more agenda wrangling)
# [11:19] <TabAtkins> Topic: Style attribute
# [11:19] <TabAtkins> fantasai: We have one test failure.
# [11:19] <TabAtkins> fantasai: Interaction with XML namespaced attributes.
# [11:19] <TabAtkins> dbaron: Interaction with xml:base and the ordering of attributes.
# [11:20] <TabAtkins> fantasai: My reccomendation is that we just take it the impl report and explain it's not a failure of style attributes, it's a failure of xml:base.
# [11:20] <fantasai> http://test.csswg.org/suites/css-style-attr/nightly-unstable/report/results.html
# [11:20] <TabAtkins> fantasai: There's one impl that passes, so it's theoretically possible.
# [11:21] <TabAtkins> dbaron: It's the interaction of relative urls in style='' and xml:base. The test has xml:base both before and after the style='', and it works in some and not others.
# [11:21] <TabAtkins> dbaron: Turns out nobody actually cares about xml:base.
# [11:21] <TabAtkins> dbaron: I think we should just argue that this isn't our problem, and go to Rec with it.
# [11:21] <zcorpan> {} in style="" in quirks mode: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2517
# [11:22] <sgalineau> it's a valid test, but if we can REC with it failing and it doesn't interop why does it have to be in the test suite?
# [11:22] <TabAtkins> dbaron: Is this quirk only in Firefox, or in everyone?
# [11:22] <TabAtkins> dbaron: It used to be present in everyone.
# [11:23] <TabAtkins> zcorpan: Blink/WebKit and IE now pass (dont' have the quirk).
# [11:23] <TabAtkins> tantek: Sounds like a Moz bug report, not a spec issue then.
# [11:23] <TabAtkins> fantasai: So are the chairs okay with taking this to rec with the failure?
# [11:24] <TabAtkins> sgalineau: Why have ethe test at all if we don't care?
# [11:24] <TabAtkins> tantek: Historically, we've said that CSS "works" with XML.
# [11:24] <TabAtkins> tantek: I agree with presenting it as a failure that we don't care about.
# [11:24] <TabAtkins> tantek: Better to be upfront and point it out.
# [11:25] <TabAtkins> chrisL: does this work in HTML? We can argue with that too..
# [11:25] <TabAtkins> dbaron: And it works in CSS with one ordering of the two, just not the other.
# [11:25] * sgalineau cue Twilight Zone theme
# [11:25] * Joins: cyril (~cyril@public.cloak)
# [11:25] <TabAtkins> krit: Also, SVGWG agreed not to use xml:base anymore.
# [11:26] <TabAtkins> chrisl: And it works with the ordering that people use in practice (xml:base first?), so it's really an edge case.
# [11:26] <tantek> apparently all your xml:base are not belong to us
# [11:28] <TabAtkins> plinss: I kinda question whether this belongs in this testsuite.
# [11:28] <TabAtkins> TabAtkins: I think it's fine here - we're not unit-testing, we do need to test interaction with techs we purport to be compatible with.
# [11:28] <TabAtkins> fantasai: And we have tests for HTML <base>, so it's appropriate both ways.
# [11:28] <TabAtkins> glazou: So consensus to move to PR?
# [11:28] <TabAtkins> RESOLVED: Take Style Attribute to PR.
# [11:29] <TabAtkins> glazou: Who's doing the transition call?
# [11:29] <TabAtkins> glazou: Bert.
# [11:29] <fantasai> ScribeNick: fantasai
# [11:29] <fantasai> Topic: Preprocessor / Tools for spec writing
# [11:29] * Joins: Koji (~Koji@public.cloak)
# [11:30] <fantasai> ChrisL: One advantage of Tab's preprocessor over Bert's is that it doesn't require Member access
# [11:30] * sgalineau now that I no longer edit anything there is a preprocessor called Bikeshed. Sigh.
# [11:30] <fantasai> TabAtkins: Well, I still use the biblio.ref file that's Member-only, but I have a chached copy on github
# [11:30] <fantasai> TabAtkins: New processor, wrote mainly so I can use Markdown-style paragraphs
# [11:30] <fantasai> TabAtkins: Called it Bikeshed, has nice new features
# [11:31] <fantasai> TabAtkins: Like Bert's preprocessor, has automatic linking
# [11:31] <fantasai> TabAtkins: Can use or <a> for cross-linking
# [11:31] <fantasai> TabAtkins: Automatic ID generation, same biblio entry generation
# [11:31] <fantasai> TabAtkins: Tried to copy Bert's functionality as much as possible
# [11:31] <fantasai> TabAtkins: Additional functionality includes removing all header data, replace with a <pre> block that gives all the relevant data
# [11:32] <fantasai> TabAtkins: Similarly for propdef tables
# [11:32] <fantasai> TabAtkins: Auto-generates all the boilerplate
# [11:32] <sgalineau> https://github.com/tabatkins/bikeshed
# [11:32] <fantasai> dbaron: Can you tweak the boilerplate if necessary?
# [11:32] <fantasai> TabAtkins: Yes
# [11:32] <fantasai> TabAtkins: Markdown-style paragraphs -- don't need tags, makes text readmore cleanly
# [11:33] <fantasai> TabAtkins: Propdef tables much easier to write
# [11:33] * Joins: ChrisL (clilley@public.cloak)
# [11:33] * fantasai SimonSapin can you drop a link to Tab's docs?
# [11:33] <fantasai> TabAtkins: If you're using sublime or ?, have a highlight file
# [11:33] <astearns> http://dev.w3.org/csswg/css-variables/Overview.src.html for example of boilerplate
# [11:33] <SimonSapin> https://github.com/tabatkins/bikeshed
# [11:33] <SimonSapin> https://github.com/tabatkins/bikeshed/tree/master/docs
# [11:33] <fantasai> dbaron: Missing 'Animatable' lines
# [11:34] <fantasai> TabAtkins: Bert's prepprocessor had two auto-link shortcuts, 'f' and ''foo''
# [11:34] <ChrisL> rrsagent, here
# [11:34] <RRSAgent> See http://www.w3.org/2013/09/11-css-irc#T09-30-48
# [11:34] <dbaron> https://github.com/tabatkins/bikeshed/tree/master/docs/markup.md
# [11:34] <fantasai> TabAtkins: I've added a bunch more, e.g. linking to productions
# [11:35] <dbaron> you should say the thing you said about not using tokens in the docs
# [11:35] <fantasai> TabAtkins: The big feature is cross-spec cross-references
# [11:35] <SimonSapin> \o/
# [11:35] <fantasai> TabAtkins: Even outside of CSS -- any spec that Shepherd processes can be auto-linked
# [11:35] <fantasai> TabAtkins: Same way as local link
# [11:36] <fantasai> TabAtkins: Really helpful, because it will also catch lots of broken links
# [11:36] <fantasai> TabAtkins: or links to the wrong place
# [11:36] <fantasai> TabAtkins: Bikeshed throws a bunch of errors. Annoying on first convert, but helps you fix lots of things that were broken
# [11:37] <fantasai> TabAtkins: Comon problem that was missed by old processor -- multiple auto-link targets, used to pick first one, but that was very often wrong (e.g. linking to ''none'' keyword)
# [11:37] <fantasai> TabAtkins: Help docs
# [11:37] <fantasai> TabAtkins: Another fixup is <pre> block indent stripping
# [11:38] <fantasai> TabAtkins: If you want to indent your sections, but have a pre block, can't indent the pre contents.
# [11:38] <fantasai> TabAtkins: Bikeshed strips the leading indentation
# [11:38] <fantasai> TabAtkins: So you can indent your <pre> in source, and have it publish correctly
# [11:38] <fantasai> TabAtkins: Also parses IDL blocks
# [11:39] <fantasai> TabAtkins: Automatically adds definitions to all of them so can auto-link to them more easily
# [11:39] <fantasai> TabAtkins: Relatively easy to install, just a few dependencies, so can run it locally.
# [11:39] <fantasai> TabAtkins: Also can use server, just like Bert's -- it's set up on csswg.org
# [11:39] <fantasai> plinss: Also have automatic generation on csswg.org
# [11:40] <fantasai> TabAtkins: If you do a commit with just the src file, will generate the HTML file on the server
# [11:40] <fantasai> plinss: Nice thing about that is no commits of generated files
# [11:40] <SimonSapin> \o/ again
# [11:40] <fantasai> plinss: It will also regen all the other specs that depend on it
# [11:41] <fantasai> fantasai: It's actually nice to have the generated version in version control, so that you can link to specific revisions
# [11:41] <fantasai> dbaron: Would prefer if robot committed the regenned versions
# [11:42] <fantasai> Alan: Concerned about case where robot generates a version, but there's an error, and I never hear about it
# [11:42] <fantasai> TabAtkins: If you want to start using Bikeshed, you do need to know about auto-linking attributes
# [11:42] * glazou can we discuss changing the name of bikeshed ?-)
# [11:42] <fantasai> TabAtkins: Usually not require,d but sometimes required
# [11:43] <fantasai> TabAtkins: Auto-link targets are typed,
# [11:43] <fantasai> TabAtkins: CSS type sare usually auto-inferred
# [11:43] <fantasai> TabAtkins: But in some cases need to say what type e.g.
# [11:43] <fantasai> attribute DOJString <dfn attribute>name</dfn>;
# [11:43] <glazou> s/DOJString/DOMString
# [11:43] <fantasai> TabAtkins: Need clarifications when have e.g. term and keyword that have same text (like 'inherit')
# [11:44] <fantasai> TabAtkins: For more disambiguation, you can declare what a value or attribute or descriptor belongs to
# [11:44] <fantasai> TabAtkins: by adding a 'for' attribute
# [11:44] <fantasai> TabAtkins: e.g. <a for=flex>none</a>
# [11:44] <fantasai> TabAtkins: Will link to the correct <dfn>none</dfn>, rather than random one.
# [11:44] <fantasai> TabAtkins: Only need to do this if it's ambiguous
# [11:44] <fantasai> TabAtkins: Other than that, completely usable. Using it on most spec's that I've touched in last few months
# [11:45] <fantasai> TabAtkins: Several other people are using it, too
# [11:45] <fantasai> krit: [describes fxtf preprocessing toolchain]
# [11:45] * sgalineau it's preprocessors all the way down
# [11:45] <fantasai> plinss: If there's a spec that bikeshed isn't linking to, trivial to add to Shepherd
# [11:46] <fantasai> krit: Robin has a spec link database
# [11:46] <fantasai> TabAtkins: [...]
# [11:46] <fantasai> TabAtkins: Pulling from specref repo might be fine
# [11:46] <fantasai> TabAtkins: ... anchors to terms
# [11:47] <fantasai> TabAtkins: If you converto over to bikeshed, we export most things (like properties, values), but don't export <dfn> terms by default
# [11:47] <fantasai> TabAtkins: Because specs often define spec-internal terminology
# [11:48] <fantasai> TabAtkins: But can export specific terms by adding export boolean to <dfn> or <dl> containing <dfn>s.
# [11:48] * sgalineau 'Never go full bikeshed'
# [11:48] <tantek> TabAtkins: "I will not entertain any naming debates about bikeshed."
# [11:48] <fantasai> dbaron: Does it do auto-linking without network access
# [11:48] <fantasai> plinss: Downloads data from Shepherd
# [11:49] * Quits: shans___ (~shans_@public.cloak) (Client closed connection)
# [11:49] <fantasai> TabAtkins: Doesn't update yet
# [11:49] * Joins: shans__ (~shans_@public.cloak)
# [11:50] <fantasai> fantasai: Maybe just set up a cron job to commit an update of the data every day
# [11:50] <fantasai> TabAtkins: That would be easy, but won't update people's comps
# [11:50] <fantasai> dbaron: But I could have my auto-update script pull the bikeshed repo
# [11:50] <fantasai> ...
# [11:50] <fantasai> TabAtkins: If you have issues inline in your specs, will generate index of them
# [11:50] <dbaron> ImportError: No module named widlparser.widlparser
# [11:51] <fantasai> TabAtkins: Also, generates links anchoring to section headings etc.
# [11:52] <fantasai> Alan: If you only checkin the source, will auto-generate the processed copy
# [11:52] <fantasai> alexmog: Will it also update...
# [11:52] <fantasai> plinss: Anything that server generates, it will regenerate everything
# [11:52] <glazou> s/alexmog/astearns
# [11:52] <fantasai> astearns: There's a cross-link between shapes and ?. If I change one...
# [11:52] <fantasai> TabAtkins: [...]
# [11:53] <fantasai> plinss: Another nice thing is that, because has extra data about definition types and what they're for, have been improving Shepherd's spec processor
# [11:54] <fantasai> TabAtkins: We will be able to have an index of all CSS at-rules, properties, etc.
# [11:54] <fantasai> TabAtkins: Everybody wants this
# [11:54] <fantasai> TabAtkins: Various efforts to do this, but can auto-gen it now.
# [11:54] <fantasai> plinss: It can be auto-genned on the server, live
# [11:54] <fantasai> Bert: we have a list, but it's auot-generated every 24 hours
# [11:55] <fantasai> TabAtkins: It's just a property list. Can get more info
# [11:55] <fantasai> Bert: But only for specs using bikeshed
# [11:55] <astearns> s/?. If I change one/masking. If I change one and masking needs to be updated, there should be a notification for Dirk/
# [11:55] <fantasai> plinss: Shepherd is already parsing all he specs all the time
# [11:56] <fantasai> TabAtkins: Most things not with bikeshed, won't have as rich data
# [11:56] <fantasai> TabAtkins: but can still get a lot of it out
# [11:56] <fantasai> plinss: Shepherd is getting better, e.g. now can parse IDL
# [11:56] <fantasai> TabAtkins: If anyone wnats help running locally or anything, elt me know
# [11:57] <fantasai> TabAtkins: I can also help with converting over your spec
# [11:57] <fantasai> fantasai: Can you make the module template for bikeshed?
# [11:57] <fantasai> Bert: Your documents, they don't use HTML as input
# [11:57] <fantasai> TabAtkins: They use almost HTML
# [11:58] <fantasai> Bert: I like my documents to be valid HTML
# [11:58] <fantasai> TabAtkins: That's fine, just don't use the shorthand syntax
# [11:58] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [11:58] * Joins: ChrisL (clilley@public.cloak)
# [11:58] <fantasai> Bert: One criteria for mine was that the input can be valid HTML
# [11:58] <fantasai> TabAtkins: Yes, saw your goals and tried ot implementin bikeshed.
# [11:59] <fantasai> TabAtkins: Anything you can do shorthand in Bikeshed, can do longhand as well
# [11:59] <fantasai> krit: Markdown?
# [11:59] <dbaron> TabAtkins: and has good rerun capabilities
# [11:59] <dbaron> (running on its own output)
# [11:59] <fantasai> TabAtkins: Starting a new line of text after a blank line will generate , unless you flip option to not do that
# [12:00] <SimonSapin> SimonSapin: it’s not actually Markdown, just Mardown-style paragraphs
# [12:00] <SimonSapin> TabAtkins: yes
# [12:00] <fantasai> http://api.csswg.org/bikeshed/
# [12:01] <fantasai> Topic: CSS Style Declarations
# [12:01] <glazou> http://lists.w3.org/Archives/Public/www-style/2013Aug/0431.html
# [12:01] * dbaron is glad TabAtkins wrote bikeshed, but hasn't had the chance to try it yet
# [12:01] * fantasai asks btw if we have scheduled transition calls for Cascade?
# [12:01] <fantasai> dbaron: Issue is mostly about how CSSOM deals with !important
# [12:01] <fantasai> dbaron: We used to have interop except Presto
# [12:02] <fantasai> dbaron: Except zack changed how Gecko works to match Presto
# [12:02] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [12:02] * Joins: ChrisL (clilley@public.cloak)
# [12:02] <fantasai> dbaron: Fundamental issue is what model is for element.style.setProperty or element.style.foo
# [12:02] <fantasai> =
# [12:03] <fantasai> dbaron: In a style sheet, if you write p { color: green !important; color: red; }
# [12:03] <fantasai> dbaron: You get green
# [12:03] <fantasai> dbaron: Even though red is afterwrad, you wrote !important on the green, so you get green
# [12:03] <fantasai> dbaron: So if you ask for color in that declaration block, you'd get the first declaration
# [12:04] <fantasai> dbaron: My previous mental model for how this works is that, you are essentially appending another declaration to the block.
# [12:04] <fantasai> dbaron: Suppose you say p.style.color = 'purple'
# [12:04] <fantasai> ...?
# [12:04] <fantasai> dbaron: Multiple questions
# [12:05] <fantasai> dbaron: OM no longer has 'color: red', because only maintains one declaration for any given property
# [12:05] <fantasai> dbaron: So by the time we have OM, no longer have 'color: red'.
# [12:05] <fantasai> dbaron: So when you do p.setProperty(color, purple)
# [12:05] <glazou> glazou: the question is "does the absence of the importance means preserve existing importqnce?"
# [12:05] <fantasai> dbaron: In Webkit/IE/early Gecko
# [12:05] <fantasai> dbaron: This was equivalent to appending a declaration
# [12:05] <fantasai> dbaron: You would not keep purple, because have !important declaration
# [12:06] <fantasai> dbaron: Presto/new-webkit drops the !important declaration and replaces it with purple declaration
# [12:06] <fantasai> dbaron: Ther'e sn obscure use cases for ...
# [12:07] * Bert maybe p.style.color.important = purple?
# [12:07] <fantasai> glazou: If importance is not mentioned in setProperty, it sets the property to the value without importance; doesn't preserve existing importance.
# [12:07] <fantasai> glazou: CSS editors online and offline are base don that behavior
# [12:08] <fantasai> TabAtkins: dbaron's says that setting prop, efectively appends to block, get whatever behavior out of that
# [12:08] <fantasai> TabAtkins: Othe rmodel is finding exiting declaration and replaces its value
# [12:08] <fantasai> TabAtkins: Argue for that because API exposed is one for a single declaration, not a list of declarations
# [12:08] <fantasai> TabAtkins: list-like behavior only shows up in this one particular case
# [12:09] <fantasai> TabAtkins: Don't think we should have this corner case dictate the underlying model
# [12:09] <fantasai> dbaron: More things to think about --
# [12:09] <fantasai> dbaron: When you do setProperty(color,purple)
# [12:09] <fantasai> dbaron: Can get green !important, purple, or purple !important
# [12:10] <sgalineau> fwiw i always thought of style as showing the resolved cascaded set of declarations; the whole !important business does feel like it's another API entirely.
# [12:10] <fantasai> dbaron: Think third option should not be
# [12:10] <fantasai> glazou: I agree with dbaron
# [12:11] <fantasai> dbaron: Don't think we should change the existing API to distinguish betwen omitted argument and empty string, particularly because original API require dall three arguments.
# [12:11] <fantasai> ?: Are there browsers that require third arguments?
# [12:11] <fantasai> dbaron: Gecko did for awhile, so there is a big pile of exisitng ocntent that uses the third argument because it was required.
# [12:12] <fantasai> glazou: I think we're having discussion because where' having setProperty, also setPropertyValue and setPropertyImportance
# [12:12] <fantasai> dbaron: Whole idea of this being unordered set of things doesn't fly anymore
# [12:12] <fantasai> dbaron: All implementations maintain it as ordered
# [12:13] <fantasai> dbaron: We need the ordering if we are going to do logical properties
# [12:13] <leaverou> s/setPropertyImportance/setPropertyPriority/
# [12:13] <fantasai> ?: Spec describes an order
# [12:13] <fantasai> dbaron: Yes. Not sure it's correct, but does describe an order
# [12:13] <fantasai> dbaron: Behavior you get in some cases is weird, because of finding an existing case and making it not (??)
# [12:13] <fantasai> dbaron: We're really not following the model that it's logically append
# [12:14] <fantasai> dbaron: Because if there's an existing declaration, replacing parts of it.
# [12:14] <fantasai> dbaron: I would be fine with SetPropertyValue/SetPropertyPriority
# [12:14] <astearns> I think last two ?: should be s/?:/zcorpan:/
# [12:14] <fantasai> dbaron: Would much prefer that to distinguishing emptystring vs non-vlaue
# [12:14] <fantasai> s/?/zcorpan/
# [12:15] * fantasai thanks astearns, I was just blanking on that
# [12:15] <fantasai> ...
# [12:15] <fantasai> zcorpan: Change setProperty to do what IE does
# [12:15] <fantasai> dbaron: Is everyone ok with changing to IE/WebKit behavior, behaves mostly like appending?
# [12:15] <fantasai> zcorpan: I'm ok with that
# [12:15] <fantasai> TabAtkins: Yeah
# [12:16] <fantasai> RESOLVED: setProperty's handling of importance logically behaves same as appending a declaraiton (like IE/WebKit)
# [12:16] <fantasai> RESOLVED: add a setPropertyValue and setPropertyPriority api
# [12:17] <fantasai> ChrisL: David's been doing this for a long time and seems to know what he's doing, so let's just all agree with him.
# [12:17] <TabAtkins> setPropertyValue appends a new declaration, stealing the importance from the currently winning decl of that property if it exists.
# [12:18] <TabAtkins> setPropertyPriority appends, stealing value. If no decl for that property yet, either no-ops or throws.
# [12:18] <fantasai> glazou: Not having to getPriority to set a value would be great. I like this resolution a lot.
# [12:18] <dbaron> glazou: glad to see addition of setPropertyPriority and setPropertyValue, will really simplify some of my code
# [12:19] <dbaron> (Also, there was some discussion about what setPropertyValue and setPropertyPriority would do when there's no existing declaration: we talked about setPropertyValue behaving like setProperty with "", and setPropertyPriority would either need to no-op or throw
# [12:23] * Quits: glazou (~glazou@public.cloak) (glazou)
# [12:23] * Joins: darktears (~darktears@public.cloak)
# [12:28] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [12:36] * Quits: astearns (~astearns@public.cloak) (Client closed connection)
# [12:37] * Quits: Koji (~Koji@public.cloak) (Client closed connection)
# [12:51] * Joins: curvedmark (~curvedmark@public.cloak)
# [13:01] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [13:02] * Quits: shans__ (~shans_@public.cloak) (Ping timeout: 180 seconds)
# [13:06] * Joins: astearns (~astearns@public.cloak)
# [13:11] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [13:11] * Joins: darktears (~darktears@public.cloak)
# [13:13] * Quits: astearns (~astearns@public.cloak) (Ping timeout: 180 seconds)
# [13:24] * Quits: michou (~mibalan@public.cloak) (Client closed connection)
# [13:25] * Joins: michou (~mibalan@public.cloak)
# [13:27] * Joins: astearns (~astearns@public.cloak)
# [13:28] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [13:32] * Joins: shans__ (~shans_@public.cloak)
# [13:40] * astearns changes topic to 'http://wiki.csswg.org/planning/paris-2013#agenda'
# [13:44] * Joins: leif (~lastorset@public.cloak)
# [13:46] * Joins: krit (~krit@public.cloak)
# [13:47] * Joins: glazou (~glazou@public.cloak)
# [13:47] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [13:48] * Joins: jet (~junglecode@public.cloak)
# [13:48] * Parts: jet (~junglecode@public.cloak) (jet)
# [13:48] * Joins: krit (~krit@public.cloak)
# [13:49] * Joins: jet (~junglecode@public.cloak)
# [13:49] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
# [13:49] <fantasai> ScribeNick: fantasai
# [13:49] <fantasai> Topic: CSS Image Values
# [13:49] <fantasai> TabAtkins: Interpolation rules for images
# [13:49] * Joins: dauwhe (~dauwhe@public.cloak)
# [13:50] <fantasai> TabAtkins: Generic rule for interpoloating between two generic images -- using cross-fade
# [13:50] <fantasai> TabAtkins: Special rules for between gradients, between cross-fades, between filters
# [13:50] <astearns> we have the first two
# [13:51] <fantasai> TabAtkins: Interesting part is when interpolating between a plain image and a filtered image, friendlier to authors to pretend url was set up witll null filters
# [13:51] <fantasai> fantasai: I think that's obvious
# [13:51] <glazou> http://dev.w3.org/csswg/css-images/#interpolating-images
# [13:51] <fantasai> ly the right thing to do
# [13:51] <fantasai> TabAtkins: Similarly for cross-fade
# [13:51] <fantasai> TabAtkins: For other images, want to have normal image to special image handle smoothly
# [13:51] <fantasai> TabAtkins: Question is then between two specialized images
# [13:52] * Joins: SteveZ (~SteveZ@public.cloak)
# [13:52] <astearns> s/images/transition rules/
# [13:52] <fantasai> TabAtkins: How do we want to handle this?
# [13:52] <fantasai> fantasai: Might want to go through all the combinations, and figure out which one makes most sense on the outside
# [13:53] <fantasai> TabAtkins^: Thought maybe use first one, but that's not symmetric across rreversed transitions
# [13:53] <fantasai> TabAtkins: So every time we introduce a new type, have to figure outwhere it goes in the hierarchy?
# [13:53] <fantasai> fantasai: Yeah
# [13:53] <fantasai> TabAtkins: That sounds reasnable
# [13:54] <fantasai> Lea: Shoudl cross-fade be interpreted as doing iterpolation?
# [13:54] <fantasai> TabAtkins: Interesting question
# [13:54] <fantasai> TabAtkins: I think before had idea of having an itnerpolate() function, representing the interpolation between two images
# [13:54] <fantasai> Lea: Filtered gradient to filtered gradient?
# [13:55] <fantasai> TabAtkins: That's another issue...
# [13:55] <fantasai> Shane: Can you give a specific example?
# [13:55] <fantasai> TabAtkins: Transitioning from a filtered image to a cross-faded image. Do you use filtered image rules or cross-fade image rules?
# [13:55] <fantasai> TabAtkins: fantasai suggested doing whichver rules wins
# [13:55] <fantasai> fantasai: You'd do both, nested
# [13:56] <fantasai> TabAtkins: ...
# [13:56] <fantasai> krit: Filter function, cross-fade
# [13:56] <fantasai> krit: Just cross fade?
# [13:56] <fantasai> krit: How would you want to interpolate
# [13:56] <fantasai> TabAtkins: If filter wins, re-interpolate as filter(cross-fade(url)))
# [13:56] * Quits: ian (~ian@public.cloak) (Ping timeout: 180 seconds)
# [13:56] <fantasai> TabAtkins: Interpolate image functions, do recursive interpolation.
# [13:57] * Joins: Rossen_ (~Rossen@public.cloak)
# [13:57] <fantasai> krit: ... have to specify start/end
# [13:57] <fantasai> TabAtkins: I'm not certain it's worth complexity of doing function stacks
# [13:57] <fantasai> TabAtkins: Interpolate outer arguments, inner arguments
# [13:57] <fantasai> krit: I thin kthat's too complex
# [13:57] * Joins: Koji (~Koji@public.cloak)
# [13:58] * Joins: myakura (~myakura@public.cloak)
# [13:58] <fantasai> fantasai; Alternately, say they're two incompatible image types and just cross-fade them
# [13:59] <fantasai> fantasai: Either you create compatible stacks of functions, filling in with no-ops, and interpolate; or you give up and cross-fade.
# [13:59] <fantasai> fantasai: Doing some kind of partial interpolation doesn't make sense.
# [14:01] <fantasai> Tab draws on the board
# [14:01] <fantasai> 1) filter(a,blur(5px))
# [14:02] <fantasai> 2) filter(b,blur(10px))
# [14:02] <fantasai> a) filter(crossfade(a,b), blur(5px-10px))
# [14:02] <fantasai> b) crossfade(1, 2)
# [14:02] <fantasai> ChrisL: a will definitely look better in some cases, if there are large changes in the blur for example
# [14:03] <fantasai> fantasai: I think that's mainly true if the source images are the same. Cross-fade shoudl be fine if they're different.
# [14:03] <fantasai> krit: a seems like more work
# [14:03] <fantasai> sylvaing: Hard to pick one vs other, because design intent is not clear
# [14:03] * Quits: ChrisL (clilley@public.cloak) ("Client combusted")
# [14:04] <fantasai> sylvaing: Different source images, likely you just wante cross-fade
# [14:04] <fantasai> TabAtkins: Hard to infer author intent
# [14:04] <fantasai> TabAtkins: Have inside and outside, have to figureout which one author intends on outside
# [14:04] <fantasai> Shane: ...
# [14:05] <fantasai> TabAtkins: Filters interpolate if you have same sources, same filters
# [14:05] * Joins: ChrisL (clilley@public.cloak)
# [14:05] <fantasai> Shane: Think b is better, because people will be less likely to use
# [14:05] <ChrisL> rrsagent, here
# [14:05] <RRSAgent> See http://www.w3.org/2013/09/11-css-irc#T12-02-00
# [14:05] <fantasai> Shane: It's easy to expand b) later into full recursive interpolation
# [14:06] <fantasai> TabAtkins: For spec, just saying that filter function and future functions like this define their constraints, and if you miss those, just fall back into cross-fade
# [14:06] * Joins: plh (plehegar@public.cloak)
# [14:06] <fantasai> krit: If you have gradient level 1 with same number of stops, different colors, do a cross-fade?
# [14:06] * fantasai confused now
# [14:07] <fantasai> TabAtkins: yes
# [14:07] * Quits: astearns (~astearns@public.cloak) (Client closed connection)
# [14:07] * Joins: astearns (~astearns@public.cloak)
# [14:07] <fantasai> case above is filtered gradients, where gradients are interpolable
# [14:08] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [14:08] <fantasai> ChrisL: Case of different images where you want smarter interpolation is where one image is derived from the other
# [14:08] * Joins: ian_ (~ian@public.cloak)
# [14:08] <fantasai> ChrisL: e.g. text where original is flat, next is pop-up
# [14:09] <fantasai> fantasai: Even in that case, doing a nice job with the blur interpolation won't make up for the act that you're cross-fading the shadow effect or movement effect, which still looks wrong
# [14:09] <fantasai> ChrisL: fair enough
# [14:09] <fantasai> Lea: Is there any reason not to do the fancy interpolation, other than implementation cost
# [14:10] * Joins: Rossen_ (~Rossen@public.cloak)
# [14:10] <fantasai> TabAtkins: Yes. But in this case the difficulty doesn't seem worh the benefit. Benefit is positive, for recursive interpolation, but the difference is subtle, so small difference
# [14:10] <fantasai> TabAtkins: As Shane argued, decent chance that we can change it later
# [14:10] * Joins: astearns_ (~astearns@public.cloak)
# [14:10] <fantasai> TabAtkins: Unlikely to to break anything, likely to just make things prettier
# [14:11] <fantasai> plinss: Probably someone will depend on it anyway
# [14:11] <fantasai> plinss: Is there a way to opt into different behavior?
# [14:11] <fantasai> TabAtkins: Maybe?
# [14:11] <fantasai> TabAtkins: Think we should just opt everyone in
# [14:11] <fantasai> TabAtkins: But could do a falg on transition property or something
# [14:11] <fantasai> krit: If we don't have consensus, shoudl at least say that there are two options that we're considering
# [14:11] <ChrisL> s/falg/flag/
# [14:12] <fantasai> fantasai: Seems fair to put both in the spec and ask for feedback
# [14:12] * Quits: astearns (~astearns@public.cloak) (Client closed connection)
# [14:12] <fantasai> Shane: When you have two values that don't match, 50% switch
# [14:12] <fantasai> Shane: If you want cross-fade, explicitly ask for it
# [14:12] <fantasai> Shane: Makes it very unlikely that people will depend on it
# [14:12] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [14:12] * Joins: ChrisL (clilley@public.cloak)
# [14:12] * ChrisL channelling Eddie Izzard "Do you have a flaaaag?"
# [14:12] <fantasai> TabAtkins: We make things ugly when we don't want people to depend on it
# [14:13] <fantasai> Shane: We want people to use this for matching values
# [14:13] <fantasai> TabAtkins: Want people to be able to interpolate from plain image to filtered image
# [14:13] <fantasai> fantasai: That's uncontroversial, I think. Case we're discussing is when both are complex images
# [14:14] <fantasai> RESOLVED: transitioning from image A to foo(A), infer the foo() on the other side (using no-op arguments)
# [14:14] <fantasai> s/image/plain image/
# [14:15] <fantasai> TabAtkins: Don't do recursive interpolation of images, just do fancy interpolation on the top level
# [14:17] <fantasai> trying to figure out what all the suggested options are
# [14:18] <fantasai> a) recursive interpolation -- build stack of compatible functions, and fancy-interpolate them
# [14:19] <fantasai> b) cross-fade incompatible types
# [14:19] <fantasai> c) flip at 50%
# [14:19] <fantasai> [url() or plain image is considered compatible with all transformed types with same source]
# [14:20] <fantasai> [discussion of what same source means]
# [14:20] <fantasai> TabAtkins: For gradients, would have to be exact same arguments
# [14:20] <fantasai> TabAtkins: same function, same arguments
# [14:21] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [14:21] <fantasai> Lea: Difference between cross-fade and fancy interpolation is not really that small
# [14:21] * glazou asked to increase a bit the temperature of the room but apparently that's complex to do...
# [14:21] <fantasai> Lea: e.g. interpolate between filtered gradients
# [14:22] <fantasai> where color stops are in different places (one side bias vs. other side bias)
# [14:22] <fantasai> leaverou: If interpolate the gradient, will see the color stop shift and change
# [14:22] <fantasai> leaverou: Very different from a cross-fade effect
# [14:22] <fantasai> sylvaing: Is there a big perf cost for doing fancy interpolation, e.g. on phones?
# [14:22] <fantasai> sylvaing: e.g. might need to use cross-fade always on the phone
# [14:23] <fantasai> krit: of course
# [14:23] <fantasai> sylvaing: recursive effect could be too expensive, esp on some devices
# [14:23] <fantasai> sylvaing: So might not work on some devices
# [14:24] <fantasai> leaverou: That's why I asked if implementation complexity. Perf is a different reason
# [14:24] <fantasai> ChrisL: If you have a switch, can have a different style sheet on mobile
# [14:24] <fantasai> sylvaing: And if author really wants recursive effect, can ask for it
# [14:24] <fantasai> TabAtkins: OK, I'll leave this as an open issue
# [14:24] <fantasai> RESOLVED: Mark this as an open issue in the draft
# [14:25] <dbaron> I think it's worth actually researching likely performance costs.
# [14:25] * leaverou LOL glazou
# [14:26] <fantasai> Topic: linear-gradientfixup rules
# [14:26] <fantasai> TabAtkins writes
# [14:26] <fantasai> linear-gradient(white 100px, red 50px, blue, green 200px)
# [14:26] <fantasai> TabAtkins: If you interpolate before fixup, blue gets 125
# [14:27] <fantasai> TabAtkins: If you do fixup first, then interpolation, blue lands at 150
# [14:27] <fantasai> TabAtkins: This is a minor issue in most cases, but if red's position is a percentage, then it depends on size of the image
# [14:27] <fantasai> TabAtkins: So we can't finish the linear-gradient and be able to do transition computations until after layout
# [14:28] <fantasai> TabAtkins: Right now is fixup first, then position interpolation, then transition interpolation
# [14:28] * Joins: tobie (tobie@public.cloak)
# [14:29] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [14:29] <leaverou> wouldn't this also be an issue when doing interpolation between linear-gradient(blue, green 15%, blue) and linear-gradient(blue, green 15px, blue)? Isn't layout info needed here too?
# [14:29] <fantasai> TabAtkins: Propose to position interpolation, transition interpolation, fixup
# [14:29] * Joins: ChrisL (clilley@public.cloak)
# [14:29] <fantasai> TabAtkins: Only effects of are when you have a misordered stop adjacent to an interpolated stop
# [14:29] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [14:29] <fantasai> TabAtkins: Fairly uncommon case.
# [14:30] * Joins: ChrisL (clilley@public.cloak)
# [14:30] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [14:30] <fantasai> TabAtkins: So I think this is a change that we can make
# [14:30] * Joins: myakura (~myakura@public.cloak)
# [14:30] <fantasai> TabAtkins: Think we refused to make the change earlier because we were fatigued and wanted the spec to just stop changing. But should make this change.
# [14:30] * Joins: jdaggett (~jdaggett@public.cloak)
# [14:31] <fantasai> krit: I implemented what Tab suggested, so we can see an example
# [14:31] <fantasai> fantasai: What you say makes sense to me, and i agree with you that it's unlikely to break a significant number of changes, so I'm comfortable saying we should go through with the change.
# [14:31] <fantasai> krit: I'm ok with the change too
# [14:31] <fantasai> krit: got other issues, tho
# [14:31] <fantasai> (not related to this)
# [14:32] <fantasai> Leif: I feel ok with it at this point.
# [14:32] <fantasai> RESOLVED: Proposal accepted
# [14:32] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [14:33] <fantasai> [Bert asks for clarification]
# [14:33] * Joins: ChrisL (clilley@public.cloak)
# [14:34] <fantasai> krit: Spec says repating gradients repeat until infinity
# [14:35] <fantasai> krit: I don't think that you can do that without information the gradient length
# [14:35] <fantasai> Tab writes:
# [14:35] <fantasai> r-l-g(red,blue)
# [14:35] <fantasai> to
# [14:35] <fantasai> r-l-g(yellow,green,black)
# [14:35] <fantasai> TabAtkins: When transitioning between the two, repeat out to infinity
# [14:35] <leaverou> s/r-l-g/repeating-linear-gradient/
# [14:35] <fantasai> dbaron: just need least-common-multiple of the lenghts
# [14:36] <fantasai> krit: you need to know position of the next color stop, doing interpolation
# [14:36] * Quits: Rossen_ (~Rossen@public.cloak) (Client closed connection)
# [14:36] * Joins: Rossen_ (~Rossen@public.cloak)
# [14:37] <fantasai> krit: say yellow is -20px and black is at 10%
# [14:37] <fantasai> TabAtkins: black and yellow then shrae a color stop
# [14:37] <fantasai> y--g--b/y--g--b/y--
# [14:37] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [14:38] * plh rrsagent, where am I?
# [14:38] * RRSAgent See http://www.w3.org/2013/09/11-css-irc#T12-33-58
# [14:38] <fantasai> s/10%/-10%/
# [14:38] * Quits: shans__ (~shans_@public.cloak) (Client closed connection)
# [14:39] * ChrisL is csswg down? can't load agenda
# [14:39] <fantasai> [Tab explains how this all works]\
# [14:39] * astearns_ chrisl: working for me
# [14:39] * Joins: shans__ (~shans_@public.cloak)
# [14:40] <SimonSapin> ChrisL, http://wiki.csswg.org/planning/paris-2013#agenda works for me
# [14:40] <fantasai> TabAtkins: Shouldn't need to do layout for this, can do all static.
# [14:40] <fantasai> TabAtkins: Requires a bit of logic, but can do it
# [14:40] <fantasai> Closed this as not an issue. might need a clarification/example in the spec tho
# [14:41] <fantasai> Next topic - linear gradients at different angles
# [14:41] <fantasai> Animating linear gradient that turns through 90deg or so
# [14:41] * zcorpan dbaron: btw it looks like the style="{}” bug happens in standards mode as well in gecko. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2518
# [14:41] <fantasai> in a box 100px tall, 300px wide
# [14:42] * dbaron zcorpan what version are you using?
# [14:42] * dbaron zcorpan, not for me
# [14:42] <fantasai> TabAtkins: would stretch gradient from 100px to ~400px back down to 300px
# [14:42] * dbaron zcorpan, and not in the code I'm looking at
# [14:43] * glazou zcorpan no redness here in firefox nightly
# [14:43] * zcorpan dbaron: it was 26.0a1 (2013-09-01). now updated to 26.0a1 (2013-09-10) and it doesn't happen. that's surprising
# [14:43] <fantasai> TabAtkins: Suggestion is to have a monotonic change in the gradient lenght thorugh the animation
# [14:43] <astearns_> s/~400px/316.2px/
# [14:44] <fantasai> krit: This requires layout info for interpolation, which we were just trying to avoid
# [14:44] <fantasai> TabAtkins: This is true... not sure how to get around it
# [14:44] * zcorpan dbaron: so now i don't get it in quirks mode either. yay!
# [14:44] <fantasai> krit: I don't think that's a great use case
# [14:44] <fantasai> TabAtkins: I've seen it, e.g. using gradient to emulate a light source
# [14:44] * dbaron zcorpan maybe it's something with live dom viewer and the way it creates the iframe?
# [14:45] <fantasai> Shane: If you assume that the gradient is always inside a square box...
# [14:45] * dbaron zcorpan try loading each test in a new tab without other things in that tab?
# [14:45] <fantasai> TabAtkins: Doesn't help
# [14:47] * zcorpan dbaron: hmm. yeah. that's what's confusing me. seems like there's a different bug with which rendering mode gets used (compatMode in the log doesn't match whether the quirk is applied)
# [14:47] <fantasai> fantasai: If you're going for a light source effect, you don't want to shorten the gradient from the middle anyway, so you're breaking the use case.
# [14:47] <fantasai> Shane: If we just do the nasty inflection point thing, you can get around it by providing mroe keyframes or something
# [14:47] <fantasai> TabAtkins: So drop issue, just keep doing direct argument interpolation
# [14:48] <fantasai> fantasai: people can provid eexplicit length if they need that
# [14:48] <fantasai> New issue - keywords cannot be matched to specific degrees
# [14:48] <fantasai> RESOLVED: No change for above issue
# [14:48] <fantasai> s/above/prev/
# [14:48] <fantasai> l-g(45deg, ...)
# [14:48] <fantasai> l-g-(to top left, ...)
# [14:49] <fantasai> TabAtkins: Depending how you do this, might need layout info to resolve top left
# [14:49] <fantasai> TabAtkins: For square, it's 45deg. For rectangle could be 30deg
# [14:49] <fantasai> TabAtkins: Anywhere from 0-90deg, can't figure out until later
# [14:49] <fantasai> TabAtkins: Could still preserve "to top left" as interpolated value
# [14:50] <fantasai> dbaron: Maybe it's not worth making the other change, if we have to depend on layout here anywya?
# [14:50] <fantasai> ...
# [14:51] <fantasai> krit: I would just say don't interpolate at all in this case
# [14:51] <fantasai> ...
# [14:52] <fantasai> TabAtkins: At computed value time, corner keywords must remain themselves
# [14:52] <fantasai> fantasai: So problem is you have no representation of the partway transition
# [14:53] <fantasai> dbaron: I don't see the point in trying to limit cases where we need layout info if we already need layout info for this
# [14:53] <fantasai> ...
# [14:53] <fantasai> Discussion of itnerpolating between any two values
# [14:54] <fantasai> dbaron: Implementing that requires some kind of interpolate-gradient syntax, internally at least
# [14:55] <fantasai> ...
# [14:55] <fantasai> dbaron: I guess this is going to be hard to implement
# [14:56] <fantasai> fantasai: could come up with some kindof syntax to represent partway betwen keywords, even if it's awkward, nobody is going to want to use it anyway
# [14:56] <fantasai> fantasai: e.g. l-g(to top 50% top left, ...) be halfway between to top and to top left
# [14:56] <fantasai> Shane: I implemented this before we punted to level 4
# [14:57] <fantasai> Shane: pretty much all ofit, or almost all of it
# [14:57] <fantasai> Shane: The need to resolve everything down to used value was enough reason not to push to main branch
# [14:57] <fantasai> Shane: Threw out the implementation
# [14:57] <fantasai> Shane: Because doesn't interpolate like everything else interpolates
# [14:57] * fantasai is hating the echo
# [14:58] <fantasai> ...
# [14:58] <fantasai> TabAtkins: Why so much harder than dealing with calc()?
# [14:58] <fantasai> krit: Before had to hav elayout info for fixup, don't anymore with new resolution
# [14:58] <fantasai> dbaron: I think in our impelmentation it would be conceptually similar to calc()
# [14:58] <fantasai> dbaron: just with graidnet functions instead
# [14:58] <fantasai> dbaron: Except graident functions are more complex, so would be more complex code
# [14:59] <fantasai> ...
# [14:59] <fantasai> dbaron: You have to propaget the thing like calc() all the way through
# [14:59] <fantasai> discussion of applying calc to individual stops vs. gradient functions
# [14:59] <fantasai> TabAtkins: Someday need to deal with height: auto issue...
# [14:59] <fantasai> Shane: I'm with krit, don't think we should allow interpolation between different keywords at this time
# [15:00] <fantasai> TabAtkins: Some of these cases would require an explicit opt-in, e.g. height: 0 to height: auto
# [15:01] * Quits: jet (~junglecode@public.cloak) (Client closed connection)
# [15:01] <fantasai> TabAtkins: If we have switch for that, then can opt-in to more complicated gradient interpolations
# [15:01] <fantasai> Shane: One difference btween CSS and SVG is conversion to used value
# [15:01] * Joins: jet (~junglecode@public.cloak)
# [15:01] <fantasai> ChrisL: SVG conversions betwen gradient/color
# [15:01] <fantasai> ???
# [15:02] <fantasai> ?????
# [15:02] <ChrisL> this reminds me of the situation in SVG where we started only allowing iterpolation between exactly matching things
# [15:02] <fantasai> TabAtkins: Ok, I'm alright withthat
# [15:02] <fantasai> TabAtkins: Should we convert keywords that can be converted to degrees?
# [15:02] <ChrisL> and then gradually added more and more cases in response to feedback so eventually we could interpolate pretty much anything
# [15:02] <fantasai> fantasai: No, because we might evnetually want keyword to keyword
# [15:02] <fantasai> TabAtkins: OK
# [15:03] <fantasai> RESOLVED: Cannot interpolate to/from keyword (unless same keyword)
# [15:03] <fantasai> TabAtkins: Probably same for radial-gradient, too. Ok
# [15:04] <fantasai> leaverou: Why is it not allowed to interpolate with different number of color stops, when can always pad with redundant color stops
# [15:04] <fantasai> TabAtkins: Don't know where to pad: beginning, end, etc.
# [15:05] <fantasai> leaverou: Can always specify explicitly
# [15:05] * krit just crossfade all the things
# [15:05] <fantasai> leaverou: Just don't see why it doesn't just work
# [15:05] <fantasai> dbaron: Hard to get graident stops to move if don't understnad how they align up
# [15:06] <fantasai> TabAtkins: Hard to guess what author's intent was
# [15:06] <fantasai> TabAtkins: That's it for gradients
# [15:08] <leaverou> s/Just don't see why it doesn't just work/I just thought that any way we pick would be better than cross-fading/
# [15:08] * fantasai thanks :)
# [15:09] <astearns_> https://plus.google.com/105664254861136730001/about
# [15:09] * Quits: jet (~junglecode@public.cloak) (jet)
# [15:11] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [15:11] * Joins: ChrisL (clilley@public.cloak)
# [15:12] <dbaron> http://www.lesathlètes.com/menu/menu.pdf
# [15:14] <TabAtkins>
# [15:21] * Joins: dauwhe (~dauwhe@public.cloak)
# [15:25] * Joins: myakura (~myakura@public.cloak)
# [15:31] * Joins: rossen__ (~rossen@public.cloak)
# [15:32] <rossen__> can somebody please come and open the door for us?
# [15:33] * Quits: rossen__ (~rossen@public.cloak) ("Page closed")
# [15:39] <TabAtkins> ScribeNick: TabAtkins
# [15:39] <TabAtkins> howcome: Quote: "the stylesheet business quickly devolves into something where each person claims to be napolean, while asserting all others are pretenders".
# [15:40] <dbaron> s/napolean/Napoleon/
# [15:40] <TabAtkins> howcome: So if this turns into a shouting match, remember that I'm Napolean.
# [15:40] <TabAtkins> howcome: We're very close to finishing.
# [15:40] <TabAtkins> howcome: We had a test suite go from submitted ot approved.
# [15:40] <TabAtkins> howcome: Gerard has been working on this.
# [15:41] <TabAtkins> Topic: multicol
# [15:41] * sgalineau napoleon-complex: auto;
# [15:41] <TabAtkins> howcome: Three remaining issues.
# [15:41] <astearns_> http://lists.w3.org/Archives/Public/www-style/2013Sep/0164.html
# [15:42] * sgalineau Restaurant dessert options include 'Nothing, I have a marathon this w-e' for 4 euros
# [15:42] <TabAtkins> howcome: In any case we'll have to go back to LC, so we'll have to add new options.
# [15:42] <TabAtkins> glazou: The issues are listed in some tracker?
# [15:42] * dbaron sgalineau that's only on the lunch menu
# [15:42] <TabAtkins> howcome: The list of issues is this email.
# [15:43] <TabAtkins> howcome: First issue is about z-order of column rules.
# [15:43] <TabAtkins> howcome: Maybe the spec already specifies what we want?
# [15:43] <TabAtkins> Rossen_: First cam eup during tucson f2f.
# [15:43] <ChrisL> rrsagent, here
# [15:43] <RRSAgent> See http://www.w3.org/2013/09/11-css-irc#T13-40-04
# [15:43] <TabAtkins> Rossen_: Spec at the time required that column rules are painted below the inline content, and above backgrounds.
# [15:43] <TabAtkins> Rossen_: Which made things inconsistent.
# [15:44] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [15:44] <TabAtkins> Rossen_: So we'd need another layer to make that happen.
# [15:44] <TabAtkins> Rossen_: Which nobody wants.
# [15:44] <TabAtkins> Rossen_: For that reason we decided to draw column rules as part of the inline content layer.
# [15:44] <TabAtkins> Rossen_: Hakon is saying that, in addition to that, people thought that column rules should paint on top fo the multicol's border.
# [15:44] <TabAtkins> Rossen_: I responded that this should happen automatically for overflow:visible.
# [15:45] <TabAtkins> Rossen_: For overflow:hidden or scroll, they'll be clipped anyway, so we don't need to specify anything unless we do something extra crazy.
# [15:45] <TabAtkins> Rossen_: So I think we can just drop issue 3.
# [15:45] * ChrisL someone tell google+ that http://www.lesathlètes.com/ and http://www.lesathletes.com/ are not the same site. "just drop all accents" does not work
# [15:46] <TabAtkins> szilles: If I overflow the column, does the text paint above or below the rule?
# [15:46] <TabAtkins> Rossen_: Over the rules.
# [15:46] <TabAtkins> szilles: I think you need to add that to the spec.
# [15:46] <TabAtkins> action rossen to add spec text to multicol specifying that text draws over column rules.
# [15:46] * trackbot is creating a new ACTION.
# [15:46] <trackbot> Created ACTION-578 - Add spec text to multicol specifying that text draws over column rules. [on Rossen Atanassov - due 2013-09-18].
# [15:47] <TabAtkins> Bert: Are you sure that the spec doesn't already specify that?
# [15:47] <TabAtkins> Bert: It says that all text is on top of the rule.
# [15:47] <TabAtkins> Bert: Already has examples about a very wide rule.
# [15:48] <TabAtkins> Rossen_: The way it was specified at the time, column rules were supposed to be treated as part of the background layer.
# [15:48] <TabAtkins> Rossen_: But you need to scroll them, so they're not part of the background layer.
# [15:48] <TabAtkins> Rossen_: And if they're on the column layer, do they interact with z-index?
# [15:49] <TabAtkins> howcome: Next issue, clipping issue.
# [15:49] * Joins: jet (~junglecode@public.cloak)
# [15:50] <TabAtkins> howcome: We currently say that flowing content that extends into column gaps is clipped in the middle of the gap.
# [15:50] <sgalineau> spec only says 'column rules are drawn just above the background'
# [15:50] <TabAtkins> howcome: I think this makes sense in most cases, but it's weird that if the long content is in the last column, it'll just overflow outside of the element without clipping.
# [15:50] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [15:50] * Joins: ChrisL (clilley@public.cloak)
# [15:51] <TabAtkins> howcome: Someone asked for multicol to just always clip strongly.
# [15:51] <TabAtkins> szilles: Can't you just use 'overflow'?
# [15:51] <TabAtkins> howcome: That's my thought too.
# [15:51] * dbaron ChrisL made the edit in mapmaker, pending review. It required inputting it as www.xn--lesathltes-56a.com, but it shows correctly once I do that
# [15:52] <TabAtkins> howcome: Related, if you have an image that overflows across a column *and* below the multicol, the spec doesn't say what to do with the section outside of the multicol - do you still clip down, or make it non-rectangular?
# [15:52] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [15:52] * Joins: ChrisL (clilley@public.cloak)
# [15:53] <TabAtkins> szilles: Guess it depends on the model - if I have opaque columns, I can say that it's because the column overpaints it, so you should expose the bottom corner.
# [15:53] <TabAtkins> zcorpan: But you can have transparent columns, so that doesn't hold.
# [15:53] * Rossen_ steve: the current text is already good for your issue "Column rules are painted in the inline content layer, but below all inline content inside the multicol element."
# [15:53] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [15:53] * Joins: ChrisL (clilley@public.cloak)
# [15:53] <TabAtkins> szilles: Can I object to the clipping altogether?
# [15:54] <TabAtkins> szilles: Unless you put in an ellipsis or something indicating the clipping is happening, you've changed the meaning of the content.
# [15:54] <TabAtkins> howcome: Should we honor 'overflow'?
# [15:54] <TabAtkins> Rossen_: If we could target columns, yeah.
# [15:54] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [15:54] * Joins: ChrisL (clilley@public.cloak)
# [15:55] <TabAtkins> Rossen_: But we can't, so we should just take the static position that all columsn are overflow:visible or overflow:hidden by default.
# [15:55] <TabAtkins> Rossen_: So do you want to lose the content, or overlap it somehow? I think losing the content is always worse.
# [15:55] <TabAtkins> glazou: [yeah, you can lose content]
# [15:55] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [15:55] * Joins: ChrisL (clilley@public.cloak)
# [15:56] <TabAtkins> TabAtkins: Yeah, I think the column clipping is inconsistent with the eventual future of individually-addressable columns anyway.
# [15:56] <TabAtkins> howcome: Sounds okay.
# [15:56] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [15:56] <TabAtkins> howcome: So should we see if people want the clipping?
# [15:56] * Joins: ChrisL (clilley@public.cloak)
# [15:57] <TabAtkins> dbaron: I'm fine with dropping this. I'm much more fine with dropping the clipping than being unclear about what's clipped and where.
# [15:57] <TabAtkins> RESOLVED: Columns do not clip anything. (As if ::column just had overflow:visible by default.)
# [15:58] <TabAtkins> Regarding previous topic:
# [15:58] <TabAtkins> n/m
# [15:58] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [15:59] * Joins: ChrisL (clilley@public.cloak)
# [15:59] * Quits: Rossen_ (~Rossen@public.cloak) (Client closed connection)
# [16:00] * Joins: Rossen_ (~Rossen@public.cloak)
# [16:00] <TabAtkins> howcome: Last issue.
# [16:00] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [16:00] * Joins: ChrisL (clilley@public.cloak)
# [16:01] <TabAtkins> howcome: The CR says that column-fill will only be used (in continuous media) if the column height is constrained.
# [16:01] <TabAtkins> howcome: There is a case to be made that we should consult this in all cases, even if it's unconstrained.
# [16:01] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [16:01] * Joins: ChrisL (clilley@public.cloak)
# [16:02] <TabAtkins> howcome: So even if you have infinite space, we should still do column balancing.
# [16:02] * Quits: Mads_Co3 (~Mads_Co3@public.cloak) ("Page closed")
# [16:02] <TabAtkins> Rossen_: So this is saying "do you want to auto-balance or not?", and if you're already specifying with column breaks...
# [16:03] <TabAtkins> howcome: ???
# [16:03] <TabAtkins> szilles: So you have three oclumns. Put a break in the first column. Are the last two balanced?
# [16:04] <TabAtkins> Rossen_: If you don't have that property, you have to consider every section of content between breaks as a balanceable unit.
# [16:04] <TabAtkins> Rossen_: After you're done, ???
# [16:05] <TabAtkins> plinss: Theoretically, you could balance columsn with breaks.
# [16:06] <TabAtkins> plinss: You could balance several columns with breaks.
# [16:06] <TabAtkins> dbaron: For example, if you have 10 columns and one column break somewhere in the middle, you can decide whether that break is between 3rd and 4th, or 4th and 5th, whatever, to achiev emaximum blaance.
# [16:07] <TabAtkins> dbaron: Another hard thing is when your container has explicit height versus not explciit.
# [16:07] <TabAtkins> dbaron: If your container has an explicit height and is paginated...
# [16:07] <TabAtkins> dbaron: And for extra fun, I think the model of pagination is that you don't do balancing on any but the last page.
# [16:07] <dbaron> I think there was another hard case here but I've forgotten what it was.
# [16:08] <TabAtkins> glazou: An issue with balancing and wysywig.
# [16:08] <TabAtkins> glazou: Say you have three columns without breaks.
# [16:08] <TabAtkins> glazou: At some point, author introduces a column break.
# [16:08] <TabAtkins> glazou: Remaining content is balanced in the other columns, which increases the height of the entire container.
# [16:09] <TabAtkins> glazou: So I suggest to balance not in height, but in number of columns, or else it'll be visually broken.
# [16:09] <dbaron> Oh, the other case is if you have overflowing columns
# [16:09] <TabAtkins> ChrisL: There are two cases. 1, the author wants a set amount of text a tthe top of the column, a break, and the rest everywhere else.
# [16:10] <TabAtkins> ChrisL: 2, they want a particular gap at the bottom, and they care about the gap being a particular size.
# [16:10] <TabAtkins> ChrisL: And we can't tell them apart.
# [16:11] <TabAtkins> fantasai: If you want some minimum amoutn of space, you do a margin. If you want some space *and* nothing after it, you use a column break.
# [16:11] <TabAtkins> Rossen_: In your case, is the number of columns specified?
# [16:11] <TabAtkins> howcome: Yes, otherwise it'll just be 1.
# [16:11] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [16:12] <TabAtkins> howcome: So if it's set to 3, and balancing is turned off, all of it should go to the first column, with the other two empty.
# [16:12] <TabAtkins> plinss: ???
# [16:12] * Joins: ChrisL (clilley@public.cloak)
# [16:12] <TabAtkins> howcome: So it sounds like we have agreement that we should honor column-fill even in unconstrained environments.
# [16:13] <TabAtkins> dbaron: I remembered my other hard case.
# [16:13] <TabAtkins> dbaron: What happens when your container has a specified height, and what is auto is your column count.
# [16:13] <TabAtkins> dbaron: You're producing columns of a certain width, and just filling in columns as needed.
# [16:13] <TabAtkins> dbaron: I think the spec is clear that you want to balance if you haven't overflowed, but what about if you have overflowed?
# [16:13] <TabAtkins> howcome: The spec is clear about this now - the property has no effect in overflow columns.
# [16:15] <dbaron> commenting on "In continuous media, this property does not have any effect in overflow columns (see below). " quote from http://dev.w3.org/csswg/css-multicol/#column-fill
# [16:15] <TabAtkins> fantasai: There's a statement about continuous media, but you can have overflow columns in print media.
# [16:16] <TabAtkins> fantasai: I don't see why the statement needs to be specific to continuous.
# [16:16] <TabAtkins> fantasai: [draws her example]
# [16:17] <TabAtkins> fantasai: You have a fixed-height box in a paged context. The box is multicol with too much content. That content just plain overflows.
# [16:18] <TabAtkins> szilles: In principle, you could just generate more boxes, rather than overflowing.
# [16:18] <TabAtkins> dbaron: I think that is just something this spec doesn't do.
# [16:18] <TabAtkins> fantasai: That's what dbaron's overflow spec is for.
# [16:20] <TabAtkins> RESOLVED: Remove the restriction about overflow columns only being in continuous media.
# [16:20] <TabAtkins> howcome: Back to the issue. Do we specify the interaction between column breaks and balancing?
# [16:20] <TabAtkins> szilles: Yes, but it's hard.
# [16:20] <dbaron> RESOUTION (2): ... and the continuous media restriction on the statement that column-fill has no effect on overflow columns
# [16:21] <TabAtkins> plinss: So, columsn are only balanced on the last page?
# [16:22] <TabAtkins> howcome: No. Roc argued that balancing should apply on pages with hard page breaks.
# [16:22] <TabAtkins> plinss: So we make it generic, and balance just between breaks.
# [16:23] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [16:24] <TabAtkins> dbaron: So between hard page breaks, and anything but a soft column break?
# [16:24] <TabAtkins> dbaron: Like between a soft page break and a hard page break?
# [16:24] <dbaron> Q is what to do about soft page breaks
# [16:24] * Quits: Rossen_ (~Rossen@public.cloak) (Client closed connection)
# [16:24] * Joins: Rossen_ (~Rossen@public.cloak)
# [16:25] <TabAtkins> fantasai: I think it makes most sense to balance within a given column row. I don't think it makes sense to balance between, say, the start of the mutlicol and hard break, when there are more columns in the row.
# [16:26] <TabAtkins> fantasai: That gives you differ-height columns, which goes against the point of balancing in the first place.
# [16:26] <TabAtkins> howcome: So what's the suggestion?
# [16:26] <TabAtkins> fantasai: When you hit a hard column break, turn off balancing for that row.
# [16:27] <TabAtkins> howcome: For continuous media, that'll do bad things. In infinite height, you'll get a really long column if you turn off balancing entirely due to a column break.
# [16:28] <TabAtkins> plinss: I think that within a column row, you'll do your best to balance between the column breaks.
# [16:28] <TabAtkins> plinss: And then you take the longest column, and that's the column height for that row.
# [16:29] <TabAtkins> howcome: Given a very long paragraph followed by a very short one, with hard breaks between them, the best strategy is to balance the long paragraph first, then balance the last.
# [16:30] <TabAtkins> howcome: I think it's bad to simply not balance.
# [16:30] <TabAtkins> dbaron: I think you'd get that by balancing across the breaks as well - run the balancing algorithm *with* breaks involved.
# [16:31] <TabAtkins> dbaron: For example, if the second paragraph is a bit larger, at some point you can decide between placing the break between 3rd and 4th column, or between 2nd and 3rd column.
# [16:31] <astearns_> (much drawing of column boxes)
# [16:31] <TabAtkins> dbaron: This also makes a difference if we're in a situation where we have two columns for each.
# [16:32] <TabAtkins> dbaron: Say first paragraph is 60% of the text, second paragraph is 40%. Break goes between 2/3 column.
# [16:33] <TabAtkins> dbaron: Do you balance the first two columns, then draw the third column down to the same height, and have the last column just th eleftover (not balanced)?
# [16:33] <TabAtkins> dbaron: Or balance the first two, then balance the second two independently?
# [16:33] <TabAtkins> dbaron: I think the first is preferable.
# [16:33] <TabAtkins> plinss: Agreed.
# [16:34] <TabAtkins> howcome: Isn't this multipass?
# [16:34] <TabAtkins> dbaron: No more than existing balancing, I think.
# [16:34] * ChrisL chanelling 5th element "Multipass!"
# [16:35] <TabAtkins> fantasai: I think that's right.
# [16:36] <TabAtkins> Bert: The goal is that each column row should be as short as possible when balanced, yes?
# [16:36] <TabAtkins> howcome: Yeah.
# [16:36] <TabAtkins> dbaron: Right. The page break controls how much content is on a page.
# [16:36] <fantasai> fantasai: In Gecko, we try to find the soft-break column height that is the shortest we can have without causing overflow
# [16:37] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [16:37] * Joins: darktears (~darktears@public.cloak)
# [16:37] <dbaron> I think we were starting to get consensus on the idea that we do balancing for each "row" of columns, whether or not it has hard column-breaks in the middle of it, but never do balancing across different rows of columns.
# [16:37] <TabAtkins> Bert: A page can get a lot shorter if you allow balancing between soft breaks, if the last thing was a non-breakable paragraph that gets shifted to the next page.
# [16:37] <dbaron> But Bert seems to disagree
# [16:38] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [16:38] * Joins: darktears (~darktears@public.cloak)
# [16:38] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [16:38] * Joins: darktears (~darktears@public.cloak)
# [16:38] <TabAtkins> plinss: When laying out a book, they generally don't rely on fully automatic layout anyway. So if column balancing ends up with a short page, they'll probably violate the non-breaking rule for that page.
# [16:39] <TabAtkins> howcome: Right, but the goal is still to be balanced.
# [16:39] <TabAtkins> Bert: ???
# [16:39] <TabAtkins> Bert: I think filling comes before balancing.
# [16:40] <TabAtkins> szilles: I think controlling that might be a switch between between "last only" (or rather, only between soft and hard breaks) or "balance between every page break".
# [16:41] <TabAtkins> fantasai: Lea, you've been working with paged media recently.
# [16:41] <dbaron> I have a suggestion that's an alternative to another property
# [16:41] <TabAtkins> leaverou: I've not had experience with multicol in my book so far - the pages are single-col.
# [16:42] <Bert> (My '??' were trying to say that a page that is not the last page of a chapter should preferrably be full-height, even if that means unbalanced columns. I agree with Steve that a designer might want to have the choice.)
# [16:42] <TabAtkins> fantasai: [explains to Lea]
# [16:42] <TabAtkins> fantasai: What if you have an unbreakable thing near the bottom fo the second-to-last page, so it gets pushed.
# [16:42] <TabAtkins> fantasai: There's a gap now, a soft break.
# [16:42] <TabAtkins> fantasai: Do you want to go back and balance those two columns, or leave that gap there?
# [16:43] <TabAtkins> fantasai: Assuming the author is already balancing the last page.
# [16:43] <TabAtkins> leaverou: I think it's clear that the author indicating no gaps means they want it all the time.
# [16:43] <TabAtkins> leaverou: I can't think what happens in most books.
# [16:43] <TabAtkins> fantasai: Most books don't have large things floating around in their content, so they don't see it.
# [16:43] <TabAtkins> fantasai: Or they manually adjust things.
# [16:44] <fantasai> to avoid such gaps
# [16:44] <TabAtkins> SimonSapin: I've heard of systems, maybe not with CSS, that balance across pages so that if you have an image that goes accross page, that gap gets distributed across several prior pages.
# [16:44] <dbaron> column-fill: auto | balance-last | balance-all (or name one of them balance rather than balance-...)
# [16:45] <TabAtkins> SimonSapin: I'm saying that in Paged Media, for page breaks, we decided to leave that to impls.
# [16:45] <TabAtkins> fantasai: I think we should definitely define this.
# [16:45] <TabAtkins> dbaron: There was a brief discussion about a control for this.
# [16:46] <TabAtkins> dbaron: There's not necessarily a need for a new property - we could just have a new value.
# [16:46] <TabAtkins> dbaron: One called "balance" and one called something else, with one of them doing the preferred default behavior and the other doing the other thing.
# [16:46] <fantasai> dbaron: or balance-last and balance-all
# [16:47] * Quits: israelh (~israelh@public.cloak) (Ping timeout: 180 seconds)
# [16:47] * sgalineau in CSS, last is a relative concept
# [16:48] <TabAtkins> plinss: balance-last would take effect at the end, and any set of columns where you have a hard break.
# [16:48] * glazou CSS itself can be quite relative :-)
# [16:48] * sgalineau is warming up to CSS as a concept
# [16:48] <TabAtkins> dbaron: Not sure about that - you can have a hard column break in the middle of a row.
# [16:48] * glazou thinks it's time to suggest renaming the concept of "balancing" to divert the discussion
# [16:49] <TabAtkins> plinss: lf you have a ???
# [16:49] <TabAtkins> fantasai: Moz's algo is that you have a row of columns.
# [16:49] <TabAtkins> fantasai: The column height (how high your column rules are) is consistent for tdhe entire row.
# [16:49] <TabAtkins> fantasai: And you pick the shortest height that doesn't overflow, while honoring the column breaks.
# [16:50] <TabAtkins> plinss: I'm not sure if that's accurate.
# [16:51] <TabAtkins> TabAtkins: I think it is - balancing isn't really about getting equal-height columns (that's just a usual result). It's about getting a minimum height.
# [16:51] <TabAtkins> plinss: If you have a break in the second column, it shouldn't move from that column.
# [16:52] <TabAtkins> fantasai: No, it should be able to move the break around. It won't move text across pages.
# [16:52] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [16:52] <TabAtkins> TabAtkins: Yeah, you can move text or breaks around *in a given row*, but nothing gets shifted to other rows due to balancing.
# [16:53] <TabAtkins> szilles: Would the minimum height violate widows/orphans?
# [16:53] * ChrisL in CSS, the columns balance *you*
# [16:53] <TabAtkins> fantasai: No, it's the minimum achieveable height, *honoring all the other properties*.
# [16:54] <TabAtkins> howcome: We still need to decide between one or two balancing keywords.
# [16:54] * glazou all your columns are balance to us
# [16:54] <TabAtkins> fantasai: I think balance-all and balance-last are great, but we already have "balance" interop.
# [16:54] <TabAtkins> fantasai: So we need to decide which behavior gets named "balance".
# [16:55] <TabAtkins> howcome: I think "balance-last" is a good keyword.
# [16:55] <dbaron> howcome^: but people are using 'balance', so we should keep it and add one of the others for the other meaning
# [16:55] <TabAtkins> TabAtkins: So "balance" does the all-balancing?
# [16:55] <TabAtkins> howcome: Yeah.
# [16:55] * Joins: SteveZ (~SteveZ@public.cloak)
# [16:56] * Quits: Rossen_ (~Rossen@public.cloak) (Client closed connection)
# [16:56] * Joins: Rossen_ (~Rossen@public.cloak)
# [16:56] <TabAtkins> TabAtkins: So this controls behavior for all non-column breaks?
# [16:57] <TabAtkins> TabAtkins: Like between soft region breaks?
# [16:57] <TabAtkins> howcome: yes.
# [16:57] <TabAtkins> fantasai: So what's implementations here?
# [16:57] <TabAtkins> howcome: Weird.
# [16:57] <TabAtkins> Rossen_: In IE, we balance without the column break.
# [16:57] <TabAtkins> Rossen_: If the column break comes very late, the error accumulation gets large, and we push things around.
# [16:58] <TabAtkins> Rossen_: I'd prefer "balance" to mean "balance-all".
# [17:00] <TabAtkins> Bert and plinss seem to prefer balance == balance-last.
# [17:00] <TabAtkins> TabAtkins: I think when I've seen this in books, they balance the page, so balance == balance-all.
# [17:00] <TabAtkins> howcome: I suggest we flip a coin.
# [17:00] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [17:02] <TabAtkins> RESOLVED: Have two keywords for balancing - "balance" and either "balance-last" or "balance-all", depending on what implementions (including Prince and AH) do by default.
# [17:03] <dbaron> We don't have a resolution on any of the discussion about how balancing works.
# [17:05] <TabAtkins> RESOLVED: To balance columns, you just make the row as short as possible (honoring breaks, sizes, etc.), then flow normally into that height. No explicit "balancing" occurs (but it's a common effect).
# [17:05] <glazou> RESOLVED: Håkon to create a public, editable, full list of issues with source, reponse and resolution ; format up to him
# [17:05] <dbaron> s/breaks/breaking controls/
# [17:06] <TabAtkins> Topic: Shapes
# [17:06] <TabAtkins> astearns_: Shapes draft had a resolution a bit ago that was ??? with exclusions.
# [17:06] <TabAtkins> astearns_: It now only has shape-outside on floats.
# [17:06] <TabAtkins> astearns_: Since that WD, I've resolved all the issues.
# [17:07] <TabAtkins> astearns_: I was thinking of a WD and askign for more review, but people hav epointed out that this usually means you go to LC.
# [17:07] <TabAtkins> astearns_: So I'm requesting to do so.
# [17:07] <TabAtkins> ChrisL: Do you have a list of issues you resolved
# [17:07] <TabAtkins> astearns_: I have a change list from last draft.
# [17:07] <TabAtkins> astearns_: All of the issues were tracked in bugzilla.
# [17:07] <TabAtkins> ChrisL: Ah, yes, that's what I wanted to know.
# [17:08] <TabAtkins> ChrisL: Are there tests?
# [17:08] <TabAtkins> ChrisL: That's something we ask during the LC meeting.
# [17:08] <TabAtkins> astearns_: We have 31 tests.
# [17:08] <TabAtkins> astearns_: I expect many more.
# [17:08] <TabAtkins> ChrisL: Cool. That's a start.
# [17:09] <TabAtkins> fantasai: It would be good to have the WG review it deeply, so he doesn't have to track those as LC issues.
# [17:09] <TabAtkins> glazou: I think it's pointless - they've tracked a bunch of issues so far, and resolved them well.
# [17:09] <TabAtkins> fantasai: Right, it's just a question of if they want to do multiple WDs, or possible multiple LCs.
# [17:10] <TabAtkins> szilles: I still have more issues to bring up on the list.
# [17:10] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [17:10] * Joins: ChrisL (clilley@public.cloak)
# [17:10] <TabAtkins> chrisl: Do you already have an ED?
# [17:10] <TabAtkins> astearns_: Yes.
# [17:10] <fantasai> I think s/possible/probable/ :p
# [17:10] <TabAtkins> ChrisL: So you're really asking if you can go to LC in 1-2 weeks?
# [17:10] <TabAtkins> astearns_: Yeah.
# [17:10] <TabAtkins> ChrisL: So we can resolve that.
# [17:11] <TabAtkins> plinss: Let's call it 2 weeks.
# [17:11] <TabAtkins> astearns_: So we decide on publishing LC at the next telcon?
# [17:11] <TabAtkins> glazou: Yeah, Sep 25.
# [17:12] <TabAtkins> howcome: If you have a floated image, can you get shape-outside from itself?
# [17:13] <sgalineau> howcome: can I extract a shape from an image?
# [17:13] <sgalineau> astearns: yes, using an alpha channel threshold
# [17:13] <sgalineau> howcome: I'd rather use luminance
# [17:13] <sgalineau> astearns: maybe in level 2
# [17:14] <TabAtkins> astearns_: My strategy si that level 2 will have something for that. Right now it's just an <image> value. IN the future, you can use the element() function.
# [17:15] <TabAtkins> howcome: That's an answer, yes. Not the one I want, but...
# [17:15] <TabAtkins> fantasai: You can use attr(src url).
# [17:15] <TabAtkins> glazou: So, conditional agreement on LC, with two weeks review?
# [17:16] <glazou> YES
# [17:16] <ChrisL> (no objections)
# [17:16] <TabAtkins> RESOLVED: Conditional agreement on taking Shapes to LC; will give final yay/nay at telcon in two weeks.
# [17:16] * Bert shape-outside: image(filter(url(foo.jpg), make-white-transparent)); shape-image-threshold: 0.5;
# [17:16] <TabAtkins> astearns_: Mihai is going to be the joint test owner for Shapes.
# [17:16] * michou Mihai Balan would be me :)
# [17:17] <michou> s/Shapes/Regions
# [17:17] <TabAtkins> astearns_: I think we should have test coordinators for more specs.
# [17:17] <TabAtkins> TabAtkins: Yeah, we've said that before. ^_^
# [17:19] <fantasai> ScribeNick: fantasai
# [17:20] <fantasai> Topic: CSS Transforms Interpolation
# [17:20] <fantasai> TabAtkins: Transforms interpolation sucks right now, have a suggestion to make it better
# [17:20] <fantasai> TabAtkins: WebKit has a suggestion of how to improve it in a back-compat way as well
# [17:20] <fantasai> TabAtkins: Here's an example of badly-interpolated transform
# [17:21] <fantasai> transform: translate(100px) rotate(45deg);
# [17:21] <fantasai> transform: scale(2) translateX(200px)
# [17:21] <fantasai> TabAtkins: Right now, the spec says that because these transform lists don't match, turn it into amatrix and interpolate that
# [17:21] <fantasai> TabAtkins: In this particular case, not too terrible, but if rotate(545deg)
# [17:22] <fantasai> TabAtkins: Lose several truns, also other weird cases
# [17:22] <fantasai> TabAtkins: Want better ways to do this
# [17:22] <fantasai> TabAtkins: Shane and I were talking, came up with several alternate sugestions
# [17:22] <ChrisL> conversion to matrix gives you a rotate normalized to 0..360
# [17:22] <fantasai> TabAtkins: Suggestion now is take tranform list
# [17:23] <fantasai> Right now is <transform>+
# [17:23] <fantasai> Suggest do <transform>+#
# [17:23] <fantasai> Within a group, smart or stupid interpolation
# [17:23] <fantasai> But between groups, [do something smart]
# [17:24] <fantasai> TabAtkins: author can write
# [17:24] <fantasai> transform: translateX(100px), rotate(545deg);
# [17:24] <fantasai> transform: scale(2) translateX(200px), null;
# [17:24] <fantasai> TabAtkins: and that will interpolate sanely
# [17:25] <fantasai> TabAtkins: Also solves other issues
# [17:25] <fantasai> TabAtkins: JS has some models that are hard to do in CSS
# [17:25] * Quits: michou (~mibalan@public.cloak) (Client closed connection)
# [17:25] <fantasai> TabAtkins: E.g. GreenSock library just exposes translate, rotate, scale as separate "properties" in its animation model
# [17:25] * Joins: michou (~mibalan@public.cloak)
# [17:25] <fantasai> TabAtkins: Can't do arbitrary combinations
# [17:26] <fantasai> TabAtkins: While this is simpler than our model, can independently animate rotation or scale, without affecting other transforms
# [17:26] * Joins: israelh (~israelh@public.cloak)
# [17:26] <fantasai> TabAtkins: Very difficult in our model, because we can't modify just the scale
# [17:27] <fantasai> TabAtkins: By separating out with comma, can adopt convention to do translate,rotate,scale
# [17:27] <fantasai> TabAtkins: And then whatever generic solution we have for accessing list-valued properties will be usable for this
# [17:27] <fantasai> dbaron: What do you mean?
# [17:27] <fantasai> TabAtkins: People want to be able to modify one segment of a comma-separated list
# [17:28] <fantasai> dbaron: Have a bunch of use cases where people wnat to add to, rather than replace, a list
# [17:28] <fantasai> TabAtkins: We also have cases where one class ads a rotation, another class adds a scale, don't wnat to list all combinations
# [17:28] <dbaron> dirk: additive animations should be handled at a global level, not just for transforms
# [17:28] <dbaron> dirk: and they are complex, we should ...
# [17:28] <fantasai> krit: Animations and transforms are complex, even have issues in SVGWG
# [17:29] <fantasai> krit: Only define animations for scale, translate, etc.
# [17:29] <dbaron> I am greatly amused that both Tab and dirk have told each other w/i the last 2 minutes that the other is talking too fast!
# [17:29] <dbaron> (They're both right!)
# [17:29] * Quits: Rossen_ (~Rossen@public.cloak) (Client closed connection)
# [17:29] * fantasai agrees ;)
# [17:29] * Joins: Rossen_ (~Rossen@public.cloak)
# [17:30] <fantasai> TabAtkins: Going back to diversion about list-value properties
# [17:30] * sgalineau RESOLVED: Tab and Krit talk too effing fast
# [17:30] <fantasai> dbaron: What are other cases where people want to edit within, rather than append?
# [17:30] <fantasai> TabAtkins: background-image
# [17:30] <fantasai> dbaron: here you can divide the transforms into categories, less true of bgimage
# [17:31] <fantasai> TabAtkins: I'd have to look through for other cases, but that's the big one
# [17:31] * Quits: michou (~mibalan@public.cloak) (Client closed connection)
# [17:31] <fantasai> krit: I would like to have use cases on the ML, so can discuss on ML
# [17:31] * Joins: michou (~mibalan@public.cloak)
# [17:31] <fantasai> krit: second, comma is not a good separator, and in SVG comma and space are interchangeable
# [17:31] <fantasai> krit: We have content already that uses it
# [17:32] <fantasai> krit: Lastly, think it's a bigger change than we want to do in this level
# [17:32] <fantasai> fantasai: Totally agree it's too significant for this level
# [17:32] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [17:32] * Joins: ChrisL (clilley@public.cloak)
# [17:32] <fantasai> hober: Agree the proposal is elegant way of handling this, but not in this level
# [17:32] * Quits: Rossen_ (~Rossen@public.cloak) (Client closed connection)
# [17:33] * Joins: Rossen_ (~Rossen@public.cloak)
# [17:33] <fantasai> dbaron: Don't think this makes things that much easier for authors.
# [17:33] <fantasai> dbaron: Authors can already make their functions line up so they animate correctly.
# [17:33] <fantasai> dbaron: This is just a slightly different way of making their functions line up
# [17:33] <fantasai> dbaron: It could save you a function here or there, but doesn't seem like massive improvement to me
# [17:34] <fantasai> TabAtkins: Does mean you can do less coordinate in base case
# [17:34] <fantasai> TabAtkins: E.g. have multiple independent classes that apply some transform (rotate class, transform class, etc)
# [17:34] <fantasai> TabAtkins: In base case, need to have sufficient null transforms
# [17:35] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [17:35] <fantasai> Bert: How long will these lists get?
# [17:35] <hober> s/elegant way of handling this/kinda neat/
# [17:35] <fantasai> TabAtkins: As long as you nead to represent your intent
# [17:35] <fantasai> Bert: Why not just add identity transforms there
# [17:36] * Joins: c_palmer (~c_palmer@public.cloak)
# [17:36] <fantasai> TabAtkins: more complicated cases ...?
# [17:36] <fantasai> TabAtkins: Combinatorial problem
# [17:36] <fantasai> fantasai: But this doesn't solve that
# [17:37] <fantasai> TabAtkins: It makes it more likely to be solved when we solve this problem generally
# [17:38] <fantasai> ChrisL: Probably want null, to be consistent with "null transform" terminology commonly used elsewhere
# [17:38] <fantasai> fantasai: Also, 'none' and identiy transform are not identical
# [17:38] <fantasai> dbaron: No?
# [17:38] <fantasai> fantasai: stacking contexts and other fun things like that?
# [17:38] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [17:38] <fantasai> -> null
# [17:38] * Joins: ChrisL (clilley@public.cloak)
# [17:39] <dbaron> fantasai: think it's an interesting idea, not something we should work on right this minute. Not convinced it's a great solution to all the problems.
# [17:39] * Joins: plh (plehegar@public.cloak)
# [17:39] <fantasai> fantasai: If we have generic solution for splicing comma-separated lists, maybe revisit then because coudl be more compelling, but right now doesn't seem like enough of an improvement to be worth adding
# [17:40] <fantasai> [and solving all issues on etc.]
# [17:40] <fantasai> Bert: Adding null transform seems good enough, don't think most lists will be that long anyway
# [17:40] <fantasai> krit: Could easily just add scale(1) etc.
# [17:40] <fantasai> krit: Would really like to see use cases first, then have this discussion
# [17:41] <ChrisL> scale(1) would not match up with a rotate
# [17:41] <fantasai> TabAtkins: Another comment, if we ever do smarter fixup, this will allow us to [...]
# [17:41] <fantasai> krit: ...
# [17:41] <fantasai> krit: identity transform on second list
# [17:41] * Quits: c_palmer (~c_palmer@public.cloak) (Client closed connection)
# [17:42] <fantasai> krit: If identical except one is shorter than other
# [17:42] <fantasai> TabAtkins: Do you padd beginning? end? Something else?
# [17:43] * glazou is tempted to launch a code build from scratch to heat his hands from the laptop...
# [17:43] <fantasai> fantasai: So, do we want to add a null transform?
# [17:43] <fantasai> krit: Don't need it, just use identity transforms
# [17:44] <fantasai> TabAtkins: Then have to match up types, not just indices
# [17:44] <dbaron> s/padd/pad/
# [17:44] <fantasai> Switching topics, no conclusion
# [17:44] <fantasai> TabAtkins: Do we want to talk about list-value problem?
# [17:45] <fantasai> fantasai: Not now? Doesn't seem like that urgent
# [17:45] * SimonSapin glazou, http://xkcd.com/1172/
# [17:46] <glazou> SimonSapin, lol
# [17:47] <fantasai> Taking a photo now
# [17:47] * Quits: jet (~junglecode@public.cloak) (jet)
# [17:50] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [17:50] * Joins: ChrisL (clilley@public.cloak)
# [17:50] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
# [17:50] * Joins: ChrisL (clilley@public.cloak)
# [17:51] * Joins: jet (~junglecode@public.cloak)
# [17:52] * Joins: SteveZ (~SteveZ@public.cloak)
# [17:53] * Quits: sgalineau (~sgalineau@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [17:53] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [17:54] * Joins: rhauck (~Adium@public.cloak)
# [17:57] * Joins: lmclister (~lmclister@public.cloak)
# [17:58] * Quits: projector (~projector@public.cloak) (Ping timeout: 180 seconds)
# [18:02] * Quits: cyril (~cyril@public.cloak) (Ping timeout: 180 seconds)
# [18:03] * Joins: cabanier (~cabanier@public.cloak)
# [18:03] <zcorpan> Meeting closed
# [18:03] * Parts: glazou (~glazou@public.cloak) (glazou)
# [18:04] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [18:05] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [18:07] * Quits: michou (~mibalan@public.cloak) (Client closed connection)
# [18:07] * Quits: Koji (~Koji@public.cloak) (Client closed connection)
# [18:07] * Quits: yamamoto (~yamamoto@public.cloak) ("Page closed")
# [18:09] * Quits: shans__ (~shans_@public.cloak) (Ping timeout: 180 seconds)
# [18:09] * leaverou is now known as leaverou_away
# [18:13] * Quits: ian_ (~ian@public.cloak) (Ping timeout: 180 seconds)
# [18:13] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [18:16] * Quits: lmclister (~lmclister@public.cloak) ("")
# [18:17] * Quits: israelh (~israelh@public.cloak) ("Page closed")
# [18:18] * Joins: leif (~lastorset@public.cloak)
# [18:21] * Quits: astearns_ (~astearns@public.cloak) (Client closed connection)
# [18:22] * Joins: astearns (~astearns@public.cloak)
# [18:26] <Zakim> dbaron, you asked to be reminded at this time to go home
# [18:27] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [18:31] * Quits: astearns (~astearns@public.cloak) (Client closed connection)
# [18:32] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [18:34] * Joins: rhauck (~Adium@public.cloak)
# [18:37] * Zakim excuses himself; his presence no longer seems to be needed
# [18:37] * Parts: Zakim (zakim@public.cloak) (Zakim)
# [18:37] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [18:37] * Joins: dauwhe (~dauwhe@public.cloak)
# [18:38] * Joins: darktears (~darktears@public.cloak)
# [18:41] * Quits: rhauck (~Adium@public.cloak) ("Leaving.")
# [18:43] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [18:43] * Quits: jet (~junglecode@public.cloak) (jet)
# [18:44] * Joins: teoli (~teoli@public.cloak)
# [18:45] * Joins: teoli_ (~teoli@public.cloak)
# [18:45] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [18:46] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [18:46] * Quits: leif (~lastorset@public.cloak) ("Leaving.")
# [18:47] * Joins: myakura (~myakura@public.cloak)
# [18:54] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [19:02] * Joins: lmclister (~lmclister@public.cloak)
# [19:03] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [19:04] * Joins: zcorpan (~zcorpan@public.cloak)
# [19:06] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [19:06] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [19:08] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [19:08] * Joins: zcorpan (~zcorpan@public.cloak)
# [19:09] * Parts: oyvind (~oyvinds@public.cloak) (oyvind)
# [19:10] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
# [19:13] * Quits: kawabata (~kawabata@public.cloak) (Ping timeout: 180 seconds)
# [19:15] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [19:17] * Joins: rhauck (~Adium@public.cloak)
# [19:17] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [19:27] * Quits: tantek (~tantek@public.cloak) (tantek)
# [19:27] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [19:46] * Quits: lmclister (~lmclister@public.cloak) ("")
# [19:47] * Joins: lmclister (~lmclister@public.cloak)
# [20:28] * Quits: curvedmark (~curvedmark@public.cloak) ("My iMac has gone to sleep. ZZZzzz…")
# [20:28] * Quits: teoli_ (~teoli@public.cloak) (Client closed connection)
# [20:44] * Quits: tobie (tobie@public.cloak)
# [20:50] * Joins: cabanier (~cabanier@public.cloak)
# [20:58] * Quits: lmclister (~lmclister@public.cloak) ("")
# [20:58] * Joins: teoli (~teoli@public.cloak)
# [21:00] * Joins: lmclister (~lmclister@public.cloak)
# [21:13] * Quits: teoli (~teoli@public.cloak) (Ping timeout: 180 seconds)
# [21:15] * Joins: gsnedder1 (~gsnedders@public.cloak)
# [21:16] * Quits: gsnedders (~gsnedders@public.cloak) (Ping timeout: 180 seconds)
# [21:22] * Joins: teoli (~teoli@public.cloak)
# [21:23] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [21:23] * Joins: teoli (~teoli@public.cloak)
# [21:30] * Quits: teoli (~teoli@public.cloak) (Ping timeout: 180 seconds)
# [21:48] * Joins: tobie (tobie@public.cloak)
# [22:46] * Joins: zcorpan (~zcorpan@public.cloak)
# [22:48] * Quits: lmclister (~lmclister@public.cloak) ("")
# [22:48] * Joins: lmclister (~lmclister@public.cloak)
# [23:07] * Quits: lmclister (~lmclister@public.cloak) ("")
# [23:08] * Joins: teoli (~teoli@public.cloak)
# [23:10] * Joins: lmclister (~lmclister@public.cloak)
# [23:10] * Joins: shans__ (~shans_@public.cloak)
# [23:13] * Joins: krit (~krit@public.cloak)
# [23:13] * Joins: krit1 (~krit@public.cloak)
# [23:13] * Quits: krit (~krit@public.cloak) (Client closed connection)
# [23:14] * Joins: krit (~krit@public.cloak)
# [23:14] * Quits: krit1 (~krit@public.cloak) (Client closed connection)
# [23:15] * Joins: krit1 (~krit@public.cloak)
# [23:15] * Quits: krit (~krit@public.cloak) (Client closed connection)
# [23:17] * Quits: krit1 (~krit@public.cloak) ("Leaving.")
# [23:19] * Quits: shans__ (~shans_@public.cloak) (Ping timeout: 180 seconds)
# [23:23] * Joins: myakura (~myakura@public.cloak)
# [23:28] * leaverou_away is now known as leaverou
# [23:29] * Joins: dbaron (~dbaron@public.cloak)
# [23:44] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [23:44] * Quits: teoli (~teoli@public.cloak) (Client closed connection)
# [23:44] * Joins: teoli (~teoli@public.cloak)
# [23:46] * Quits: tobie (tobie@public.cloak)
# [23:51] * Joins: tantek (~tantek@public.cloak)
# Session Close: Thu Sep 12 00:00:00 2013

The end :)