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