/irc-logs / w3c / #css / 2014-10-28 / end

Options:

# Session Start: Tue Oct 28 00:00:00 2014
# Session Ident: #css
# [00:00] <dael> Rossen_: Obviously the content will become longer and larger then what we measured inside continuous space.
# [00:00] * sgalineau drinking-game-word: fragmentainer;
# [00:00] <dael> Rossen_: We would frag the current rows and will overflow grid rows in the casse of fixed height or extend if they are auto or fragment without having to re layout the grid
# [00:00] <dael> Rossen_: Does that make sense?
# [00:01] <dael> SteveZ: The last statement of if the second column overflows, do that extend the row across?
# [00:01] <dael> Rossen_: If it's not fixed height.
# [00:01] <dael> SteveZ: So y're taking the max?
# [00:01] <dael> plinss: I think that you're saying makes sense but falls down in more complex cases. Maybe this is a non-issue. You said if a row is frag you take all the areas...
# [00:01] * Quits: vollick_ (~vollick@public.cloak) (Ping timeout: 180 seconds)
# [00:02] <dael> Rossen_: All the areas that start in that row. So what happens with the lines, the line on the row, can you align bottom in that fragment and bottom on the other.
# [00:02] <dael> plinss: Prob avail on both frag
# [00:03] <dael> plinss: So say you have a grid that's single cell and you have something that spans two lines. So the spanning cell gets split in the middle. It may get taller than it would have been and needs to behave prop to push the line down.
# [00:03] * dauwhe drinks
# [00:03] <dael> Rossen_: Yes, in step 4 we say you would not take into account spanning items.
# [00:04] <dael> Rossen_: I'm sure that we'll keep refining this as we come across more cases, but as a general intent, we want to keep grid areas as non-fragmented as poss. In the error case wehre a row has to fragment, we follow normal rules and that row may or may not extrend depending on if it's set to auto or fixed.
# [00:05] <dael> fantasai: I don't think we should push to next page if they don't fit. People want to use grid for page layout, if you have a bunch of editors and an article, you don't want a lot of blank space. Tables don't do that for that reason. If you want that behaviour you can set it, but it shouldn't be default
# [00:05] <dael> fantasai: The other comment, frag of grid layout will have sim problems to flex layout. It might make sense to uset he same spec text which is here are the general rules and not spec the algo except in an example.
# [00:06] <dael> fantasai: I think that trying to get, we don't want to push impl to impl a frag algo that isn't ideal and any we put in right now won't handle flex ideally like if you have something with a lot of flexing and pagination, you sometimes want to pull tings up to optimize space.
# [00:07] <dael> fantasai: If you're sing flex to size you have extra space on the first but not the second, if you're fixed height you want to take that space to avoid a break by pulling into the first page. I don't want to normatively requre something simple when we know people can do better.
# [00:07] <dael> fantasai: We should encourage them to do better.
# [00:07] <dael> Rossen_: I'm not opposed to it.
# [00:07] <fantasai> Flexbox: http://dev.w3.org/csswg/css-flexbox/#pagination
# [00:07] <dael> astearns: I have a question, it says th break prop don't apply to grid items. There's no way to assign a break to a grid item. If an element is assigned to a grid area and it has a break before.
# [00:08] <dael> Rossen_: It was clirfying to say youc an't apply break prop to grid areas.
# [00:08] <dael> fantasai: Flexbox propigates it out. For consistancy we should do that. Break inside should apply to all these things
# [00:08] <dael> plinss: I'm not so sure about that. If you have multi columns and have a break, do you want to break every column at the same place?
# [00:08] * Joins: vollick (~vollick@public.cloak)
# [00:09] <dael> astearns: You could have items in the same row on different pages which would be weird.
# [00:09] <dael> dbaron: I can imagine cases where pages would work badly if you don't line it up. So you have something on the side and breaks in the main content, there's an expectation that they'd line up.
# [00:10] <dael> fantasai: If yu have a forced break inside a flex item, it's basically an expanded margin. If you have something that's I'm a flex item break before me, that pushes.
# [00:10] <dael> fantasai: They just operate on the actual item.
# [00:10] <dael> Rossen_: That's the easy case.
# [00:10] <dael> plinss: Problem is you have a multi column grid. One thing in there wants to break. Does it break the entire grid?
# [00:11] <dael> fantasai: Yeah. We can't put a foced break property on.
# [00:11] <dael> plinss: I know cases where that's really bad.
# [00:11] <dael> fantasai: You can't put it on the grid row, just items in it.
# [00:11] <dael> plinss: So I have multi columns it's a magazine flow, and one has a break.
# [00:11] <dael> fantasai: It won't break, it increases the height of the item. If you say this item should start on a new page, it pushes down the whole row.
# [00:12] <dael> astearns: And you could end up in a situation where you have a row on the first page and a duplicate on the second page.
# [00:12] <dael> plinss: Authors are going to want it both ways.
# [00:12] * Joins: vollick_ (~vollick@public.cloak)
# [00:12] <dael> fantasai: If they want it just in that, they can create a wrapper item. You can work around that. You're looking at conseptually there's an item taht has stuff inside it and you're pushing stuff up or down.
# [00:13] * Joins: Cyril (~chatzilla@public.cloak)
# [00:13] <dael> fantasai: I'm having a hard time coming up with examples where this makes sense.
# [00:13] <dael> fantasai: If you're tring to get things to line up, you do that. if you don't want them to line up you should be using grid anyway. If the goal is you're using grid you want things to line up.
# [00:13] * Joins: jeff (jeff@public.cloak)
# [00:13] <dael> fantasai: If you think this is a bad idea, maybe we should revisit flex.
# [00:14] <dael> plinss: I think it makes sense for flex, bt that's one dimention and this is two.
# [00:14] <dael> Rossen_: I'm mostly modeling after table layout.
# [00:14] * Quits: emalasky (~Adium@public.cloak) (Client closed connection)
# [00:14] * Joins: emalasky1 (~Adium@public.cloak)
# [00:14] <dael> fantasai: You never have a case where a table cell starts on the next page.
# [00:14] <dael> plinss: Page break before an entire cell.
# [00:14] <dael> dbaron: I think the spec says it's not supposed to wrap.
# [00:15] <dael> dbaron: I believe Gecko has bugs saying ti doesn't work in Gecko and it does in other impl and we've pointed to te spec saying it's not supposed to work.
# [00:15] * Quits: smfr (~smfr@public.cloak) (smfr)
# [00:15] * Quits: vollick (~vollick@public.cloak) (Ping timeout: 180 seconds)
# [00:15] <dael> Rossen_: We can try a different heuristic. Going to yur ex where you used grid to create a header and content. I'm not sure pushing grid down and starting on the second page is work than breaking on the first page.
# [00:16] <dael> fantasai: I think that it's much worse. If you want that you can opt in, but if you dictate you can't do that no one will ever have a normal looking article. If we want it to replace tables and floats, we want it to look like that when we're printing. The printing should be eq.
# [00:16] <dael> Rossen_: Whichis what tables will do.
# [00:16] <dael> fantasai: They do not push. Want me to write a test case?
# [00:17] <dael> dbaron: Bigger point isn't just about eq. They'll deisgn a page and just expect printing to work. Massive gaps count as not working. So do a bunch of other things.
# [00:18] <dael> SteveZ: What I don't understand, I would like to start the next row on a new page if it's a small gap. Since that's a conditional, we could define a prop that says when to start a new page, but there's something we want to happen automatically that isn't force to a new page or break into a new cell
# [00:18] <dael> fantasai: I think it y ou want that you want that for all layout models.
# [00:18] <dael> fantasai: File a big against fragmenetation.
# [00:18] * Joins: smfr (~smfr@public.cloak)
# [00:19] <dael> plinss: You might need a presidence where you have multiple grid items and conflicting layout. You have to come up with something rational for the whole row.
# [00:19] <astearns> s/big/bug/
# [00:19] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [00:19] <dael> fantasai: For the content of a grid item, you don't have two items in the same place. If you have to do diff fragementing things, than you do that.
# [00:19] * Joins: myakura_ (~myakura@public.cloak)
# [00:19] <astearns> s/fragmenetation/fragmentainertationismflbrt/
# [00:19] <fantasai> s/in the same place/consecutively in the same row, you just have one item and content inside the item/
# [00:20] <dael> plinss: Is that it?
# [00:20] <dael> Rossen_: That's pretty much all I had.
# [00:20] <fantasai> s/than you do that/then that just effectively increases the content height of the row/
# [00:20] <fantasai> s/diff fragementing things/different fragmentation requirements/
# [00:20] <dael> Rossen_: That was the issue we addressed. We'll keep working given the feedback, but at least we don't have a big gap anymore.
# [00:20] <dael> plinss: The wiki said collapsing
# [00:20] * Quits: shepazu (schepers@public.cloak) (Ping timeout: 180 seconds)
# [00:21] <dael> gregwhitworth: We started by trying to come upw ith ways to collapse a grid. At first it seemed simple like you should be able to call an column, but than we realized that the user would want to do that based on an item, not a column.
# [00:21] <gregwhitworth> .grid::grid-row(“row-name”) {
# [00:21] <dael> gregwhitworth: We can up with a couple ways to do it. I can paste in the one that would be a pain to impl.
# [00:22] <dael> gregwhitworth: Inside that would be visability: collapse and you could declare a row name.
# [00:22] <dael> gregwhitworth: There's no way to attach to a thing, so it would end up begn quite verbose. And I would like to interact with an item and talk to it's parent.
# [00:22] <dael> plinss: The grid row solution you're using two indexes to find it. You name/ID the two lines.
# [00:22] <dael> plinss: Or use the span notation.
# [00:22] * Quits: jcraig (~jcraig@public.cloak) (Ping timeout: 180 seconds)
# [00:22] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [00:23] <dael> gregwhitworth: I think it's one we can revisit.
# [00:23] <dael> Rossen_: Let's table this.
# [00:23] <dael> plinss: But basically you're defining a new pseudo
# [00:23] <dael> Rossen_: That's one way.
# [00:23] <bkardell_> surely you mean "let's grid this"
# [00:23] <dael> gregwhitworth: It's the oly thing we came up with.
# [00:23] <bkardell_> tables are so a decade ago
# [00:23] <dael> Rossen_: Okay.
# [00:23] <dael> plinss: No other issues?
# [00:24] <dael> Rossen_: We have issues, but nothing that we've worked on.
# [00:24] <dael> fantasai: There was one. Let me find it.
# [00:24] <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Oct/0108.html
# [00:24] <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Oct/0108.html
# [00:25] <dael> SimonSapin: I sent something months ago. Grid doesn't define determining the size of the grid item which is unfortunate
# [00:25] <dael> TabAtkins: It does.
# [00:25] <dael> SimonSapin: That was fixed?
# [00:25] <dael> fantasai: I'm linking to something different.
# [00:25] <dael> TabAtkins: SimonSapin can you find the org. complaint?
# [00:26] <fantasai> https://twitter.com/AlanHogan/status/519256635911307265/photo/1
# [00:26] <dael> fantasai: The issue if you look at the second link, it's the problem.
# [00:26] <dael> fantasai: WEll, this was kinda a grid layout. To try and get that layout you can't do it right now. There's a couple of problems.
# [00:26] <dael> TabAtkins: The reason you can't do it in grid, it's not a 5 column, it's fixed width with as many as you need.
# [00:26] <dael> fantasai: We need two things to fix this, whch seems pretty reasonable.
# [00:27] <dael> fantasai: To get this towork prop you need to put as many columns as fit items of size x. What we need is a repeat function that says as many columns that will fit in the space and they're 15em wide.
# [00:28] <dael> fantasai: I think it would be useful and encourage flexable grids that look good on mulit screen sizes. I think this should be simple, but I don't have syntax yet.
# [00:28] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [00:29] <dael> fantasai: Second thing that's necesarry is you'll notice the space is just enough that the columns fill the space. We have prop in flex that give you this alignment, the simple solution is to reuse the prop and have that mean there's a gap between the columns. Once you've figured out the size, space out the gird with that amount of space.
# [00:29] <dael> fantasai: It might be tricky to define in terms of spanning, but it's a prop we have.
# [00:29] <dael> TabAtkins: We were planning to add row-gap and column-gap.
# [00:29] <dael> fantasai: This is in addition. You might want minumums. WE have basic syntax here.
# [00:30] <dael> SteveZ: If I have a span, do I assume the span covers the gap?
# [00:30] <dael> TabAtkins: So if your edge, it'll go over to the closest.
# [00:30] <dael> SteveZ: So te ends of the span line up with the ends of rows
# [00:30] <dael> TabAtkins: It's difficult to spec, but we'll handle it.
# [00:31] <dael> TabAtkins: This stuff should be first things in level 2. As sson as things start to ship, next year we can start on L2
# [00:31] <dael> fantasai: I think the repeat is almost syntatic sugar. The justify is tricky.
# [00:31] <dael> TabAtkins: You can center the whole grid or if you center each item within you can get space.
# [00:32] <dael> fantasai: Whichi s think is good enough. I think it would make people happy if we did repeat to fill.
# [00:32] <dael> TabAtkins: I'm trying to be as conservitiv as poss to get grid lvl 1 done. I want grid and flexbox to finish at the same time.
# [00:32] <dael> Rossen_: You're not alone.
# [00:33] <dael> plinss: Is that it?
# [00:33] <dael> fantasai: I think TabAtkins and I need to do a lot of editing and we'll comeback.
# [00:33] <dael> SimonSapin: I hav an issue. There was grid containers that's fixed. The only thing I can find on sizing with ident is by default they're stretched in the grid area.
# [00:33] <dael> TabAtkins: grid defines the containing block as the containing area, what else do we need?
# [00:34] * leaverou notes that the tweet fantasai linked to also demonstrates a great case for static value interpolation (that we discussed a while ago in the ML)
# [00:34] <dael> TabAtkins: The size is that of the containing block.
# [00:34] <dael> SimonSapin: You said sie is the containing block. Where is the sizing defined? Same as blocks?
# [00:34] <dael> TabAtkins: If they're a block they display as block?
# [00:35] <dael> Rossen_: This is the same as asking how the table cell size are defined by the view of table?
# [00:35] <dael> SimonSapin: That's define. What we do in the spec, the outside is defined specifically. Bllocks have their own sizing, what is the sizing of grid items inside the containing block.
# [00:35] <dael> fantasai: He has a point. They are participating in a grid layout context. What that does is not defined.
# [00:36] <dael> fantasai: You're confusing display inside and outside.
# [00:36] <dael> TabAtkins: I'm not. It doesn't have a display outside.
# [00:36] <dael> TabAtkins: once we've estabilished how big based on layout algo, it should just have a containing block.
# [00:36] * dauwhe we're back to normal sizing and fancy sizing
# [00:36] <dael> dbaron: So if a grid item is just display block...
# [00:37] <dael> TabAtkins: If it's got align self stretch, it's height will be the height of the grid area.
# [00:37] <dael> fantasai: Normally is underdefined because there's no normal. let's looka t width.
# [00:37] <dael> fantasai: If align self is start, how does it display? shrink-wrap?
# [00:37] <dael> TabAtkins: Flex says that. What needs to be defined becides the containing block.
# [00:37] * Quits: jrossi (~jrossi@public.cloak) (Ping timeout: 180 seconds)
# [00:38] <dael> fantasai: We need to say if it's start it's shrink wrapped. If it's not we should say that.
# [00:38] <dael> SimonSapin: Maybe by normally you mean like blocks. That's fine.
# [00:38] <dael> TabAtkins: But we can't because if you're a table you don't.
# [00:38] <dbaron> s/just display block.../just display block, and it has a background, the background fills the width of the grid cell but not the height?/
# [00:38] <dael> Rossen_: If your item is another grid, what do you expect?
# [00:38] <dael> TabAtkins: Certain types of things, flex puts req on how you size. But sometimes the layout says format as normal and give me your size.
# [00:39] <dael> TabAtkins: How does a block layout, it does thing sand you get a size back.
# [00:39] <dael> Rossen_: You get a grid item that is a grid. In this case normal means do your grid layout and give me back your size. If that item happens to be table, it sizes like a table, if it's block it will behave like a block.
# [00:40] <dael> TabAtkins: So you're looking for context on how blocks behave and I'm not getting what exactly you want.
# [00:40] <dael> TabAtkins: Some display models put extra constaints on how children layout, but otherwise the rules should be defined by the layout mode.
# [00:40] <dael> dbaron: It sounds like if the editors don't agree what the spec says, they should make sure there is language.
# [00:40] <dael> TabAtkins: I'd love to but I don't understand what's being asked for
# [00:40] * Quits: iank (~iank@public.cloak) (Ping timeout: 180 seconds)
# [00:41] <dael> SimonSapin: When in alignment it says that grid items stretch to fill the area what does it mean.
# [00:41] <dael> TabAtkins: The align self defines how you stretch.
# [00:41] <dael> SimonSapin: So the default is auto.
# [00:41] <dael> TabAtkins: Which is stretch for grid items.
# [00:41] <dael> TabAtkins: Chrome isn't conformant with this right now. We're in the process.
# [00:41] * Quits: Cyril (~chatzilla@public.cloak) (Client closed connection)
# [00:42] <dael> SimonSapin: Maybe add a note that says the sizing of grid items depends on the items' layout mode.
# [00:42] * Joins: Cyril (~chatzilla@public.cloak)
# [00:42] <dael> Rossen_: Do we have this text on flex?
# [00:42] * Joins: iank (~iank@public.cloak)
# [00:42] <dael> TabAtkins: Flex puts some constraints, but it just says do layout based on these things. I'll find it and if it's inconsistant, we need to fix it, but I'd like to know why it's inconsistant or incomplete.
# [00:43] <TabAtkins> Flex algo line 3E
# [00:43] <dael> TabAtkins: Is this insuffiecently specified? It's the same level as grid right now.
# [00:43] <dael> SimonSapin: Okay.
# [00:44] <dael> TabAtkins: If you can figure out what needs to be stated in those cases we can fix that.
# [00:44] <dael> Rossen_: An editorial note?
# [00:44] <dael> TabAtkins: I can't think of what it should say. If you can come up with something we'll put it in, but I think that do layout as you would normally for your display type is a thing that doesn't need more qualification.
# [00:44] <dael> SimonSapin: The thing I'm missing is for it's type.
# [00:45] * astearns Note: this step is really about ethics in game journalism
# [00:45] <dael> TabAtkins: Okay. That's also missing from flex layout right now. Okay, we can add detail as to what it means to do layout.
# [00:45] <dael> TabAtkins: Alright.
# [00:45] <dael> TabAtkins: Can you send a reminder to what wording you want in flexbox?
# [00:45] * dauwhe astearns wins IRC today
# [00:45] <dael> Rossen_: Or just put it in the minutes. We'll parse it out.
# [00:46] <dael> plinss: So is that it on grid?
# [00:46] <dael> Rossen_: We're done.
# [00:46] <dael> Topic: Flexbox
# [00:47] <dael> Rossen_: Who put flexbox?
# [00:47] <dael> fantasai: I think we were expect to have the issues in.
# [00:47] <dael> Rossen_: Can we push that to tomorrow?
# [00:47] <dael> plinss: That's the agenda for today. We should pull something from tomorrow.
# [00:47] * Quits: vollick_ (~vollick@public.cloak) (Ping timeout: 180 seconds)
# [00:48] <dael> [general mentions of brackets]
# [00:48] <dael> ArronEi: The test suite?
# [00:48] <dael> TabAtkins: We're talking about 3.1 Who put the 2.2 test suite?
# [00:48] * Joins: vollick (~vollick@public.cloak)
# [00:49] <dael> Topic: Test Suites
# [00:49] <dael> Bert: I put 2.2 We talked about pub an updated 2.1 with the errata and we decided we couldn't because we don't have a test suite.
# [00:49] * Quits: jeff (jeff@public.cloak) ("Leaving")
# [00:49] <dael> Bert: Each errata needed one or more tests and there were people supposed to write them.
# [00:49] <astearns> https://wiki.csswg.org/test/css2.1
# [00:50] * Joins: jcraig (~jcraig@public.cloak)
# [00:50] <dael> [crickets...literally]
# [00:50] <dael> astearns: There's asignments, but nothing indicates it's done.
# [00:50] * Joins: shepazu (schepers@public.cloak)
# [00:50] <dael> TabAtkins: There's reviews of changes, bt not of tests.
# [00:51] <dael> TabAtkins: ArronEi is on most of the lines.
# [00:51] <dael> ArronEi: I was surprised.
# [00:51] <dael> ArronEi: I can look at my stuff, but it won't be for a couple weeks. Maybe next conf call.
# [00:51] <dael> ArronEi: If I'm starting, I can look at them all and give an update on all of them.
# [00:52] <dael> ArronEi: The other is about the current test suites for everything in CR. I'm starting to put together a detailed doc on how to approach testing since it's been ad hoc.
# [00:52] * astearns dismally ad-hoc
# [00:53] <dael> ArronEi: I want to direct the testing a bit more so we know how to approach various tasks. I'm putting that together to get done i nthe next few weeks so we can attack specs in the same way. I'm going to test my documentation by testing it against whatever spec needs the most done.
# [00:53] <dael> ArronEi: Which one is the highest priority.
# [00:53] <dael> fantasai: B&B is almost done. It needs someone to pull it together.
# [00:53] <dael> ArronEi: That's my question. I'll create my process doc based on that and test my theories. After that's tested and can move forward I'll had it over.
# [00:54] <dael> florian: When it comes to writing tests from scratch, we also have the case of the existing mountains of unreviewed tests.
# [00:54] <dael> ArronEi: I'm going to have the review and updating of those. I know there's a lot from B&B that are coming froma lot of places.
# [00:54] <dael> florian: WE have large amounts of prob good test, but they need updates.
# [00:55] <dael> ArronEi: I'll make sure I cover something on who to contact to ask for test.
# [00:55] <dael> fantasai: B&B needs triage. There's a bug on that.
# [00:55] * Joins: plh (plehegar@public.cloak)
# [00:55] <dael> ArronEi: I don't want to create new tests until I have everything document.
# [00:55] <dael> ArronEi: This isn't the case for all specs
# [00:55] <dael> fantasai: Pretty much anything impl has a bunch of tests.
# [00:56] <dael> ArronEi: I'm trying to catch all the pieces. I'll focus on B&B and put links on the wiki. Hopefully in the next month or so we'll have a process we can hand to other people.
# [00:56] <dael> plinss: That's it on testing?
# [00:56] <dael> ArronEi: That's all I have.
# [00:56] <bkardell_> brackets? :)
# [00:56] <dael> plinss: Anything else from tomorrow?
# [00:57] <dael> plinss: the ::role() proposal?
# [00:57] * dauwhe bkardell_: don't you mean brackets? :]
# [00:57] <dael> smfr: I think that was James Craig.
# [00:57] * sgalineau Dismally Ad-Hoc is a pretty good band name, astearns
# [00:57] <dael> TabAtkins: I think it should have been a since colon and it was testing of aria roles? Let's get him in here for that one.
# [00:58] * astearns or a good description for 90% of garage bands
# [00:58] * bkardell_ dauwhe Yes, I meant that (sorry)... er... [sorry]
# [00:58] <dael> plinss: So are we done for the day?
# [00:58] <dael> plinss: I think we're done.
# [00:58] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [00:58] * Quits: glazou_ (~glazou_@public.cloak) ("")
# [00:58] <dael> [End of Day]
# [00:58] * Quits: glazou (~glazou@public.cloak) (glazou)
# [00:58] * Quits: yamamoto (~yamamoto@public.cloak) ("Page closed")
# [00:59] <bkardell_> resolved: plinss should hit the table with a hammer
# [01:00] * Quits: MaRakow (~MaRakow@public.cloak) ("Page closed")
# [01:00] * Quits: dael (~dael@public.cloak) ("Page closed")
# [01:01] * Quits: bradk (~bradk@public.cloak) ("Be back later ...")
# [01:01] * dauwhe hum if you think plenary day is a good idea
# [01:01] * Joins: myakura (~myakura@public.cloak)
# [01:01] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [01:01] * Quits: Cyril (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [01:01] * Joins: masatakayakura (~myakura@public.cloak)
# [01:02] * Joins: bradk (~bradk@public.cloak)
# [01:02] * Joins: Cyril (~chatzilla@public.cloak)
# [01:02] * Quits: myakura_ (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [01:03] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [01:03] * Joins: myakura_ (~myakura@public.cloak)
# [01:03] * Quits: emalasky1 (~Adium@public.cloak) ("Leaving.")
# [01:03] * Quits: smfr (~smfr@public.cloak) (smfr)
# [01:03] * Quits: hjlee (~hjlee@public.cloak) ("Page closed")
# [01:04] * Quits: anssik (~uid10742@public.cloak) ("Connection closed for inactivity")
# [01:05] * Quits: KeshavP (~KeshavP@public.cloak) (Ping timeout: 180 seconds)
# [01:06] * Quits: bobtung (~bobbytung@public.cloak) (bobtung)
# [01:07] * Quits: vollick (~vollick@public.cloak) (Ping timeout: 180 seconds)
# [01:07] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [01:07] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [01:08] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [01:08] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [01:08] * Quits: hiroshi_ (~hiroshi@public.cloak) (Ping timeout: 180 seconds)
# [01:08] * Quits: hiroto_ (~hiroto@public.cloak) ("Page closed")
# [01:08] * Joins: zcorpan (~zcorpan@public.cloak)
# [01:09] * Quits: bradk (~bradk@public.cloak) (Ping timeout: 180 seconds)
# [01:09] * Quits: masatakayakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [01:09] * Quits: ArronEi (~ArronEi@public.cloak) (Ping timeout: 180 seconds)
# [01:09] * Quits: babatakao (~babatakao@public.cloak) (Ping timeout: 180 seconds)
# [01:10] * Quits: Cyril (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [01:11] * Quits: iank (~iank@public.cloak) (Ping timeout: 180 seconds)
# [01:11] * Quits: nsakai2 (~nsakai2@public.cloak) (Ping timeout: 180 seconds)
# [01:12] * Quits: shans__ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [01:12] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [01:14] * Quits: florian (~Florian@public.cloak) ("Leaving.")
# [01:16] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [01:18] * Quits: Shige (~Shige@public.cloak) (Ping timeout: 180 seconds)
# [01:19] * Joins: babatakao (~babatakao@public.cloak)
# [01:20] * Quits: andreyr (~andreyr@public.cloak) (Ping timeout: 180 seconds)
# [01:22] * leaverou is now known as leaverou_away
# [01:24] * Joins: iank (~iank@public.cloak)
# [01:26] * Quits: myakura_ (~myakura@public.cloak) (Client closed connection)
# [01:26] * Quits: babatakao (~babatakao@public.cloak) (Ping timeout: 180 seconds)
# [01:29] * Joins: Cyril (~chatzilla@public.cloak)
# [01:34] * Joins: babatakao (~babatakao@public.cloak)
# [01:34] * Quits: tantek (~tantek@public.cloak) (tantek)
# [01:35] * Quits: iank (~iank@public.cloak) (Ping timeout: 180 seconds)
# [01:35] * Joins: emalasky (~Adium@public.cloak)
# [01:40] * Joins: jdaggett (~jdaggett@public.cloak)
# [01:41] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [01:41] * Quits: babatakao (~babatakao@public.cloak) (Ping timeout: 180 seconds)
# [01:48] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
# [01:49] * Joins: babatakao (~babatakao@public.cloak)
# [01:52] * Joins: tantek (~tantek@public.cloak)
# [01:53] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [01:53] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [01:54] * Quits: glenn_ (~gadams@public.cloak) (Client closed connection)
# [01:56] * Quits: babatakao (~babatakao@public.cloak) (Ping timeout: 180 seconds)
# [01:57] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [01:57] * Quits: song__ (~song@public.cloak) (Ping timeout: 180 seconds)
# [02:01] * Quits: Cyril (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [02:02] * Quits: tantek (~tantek@public.cloak) (tantek)
# [02:03] * Joins: liam (liam@public.cloak)
# [02:05] * Joins: babatakao (~babatakao@public.cloak)
# [02:06] * Joins: tantek (~tpod@public.cloak)
# [02:07] * Quits: estellevw (~estellewyel@public.cloak) (estellevw)
# [02:07] * Joins: dauwhe (~dauwhe@public.cloak)
# [02:08] * Quits: kangil (~kangil@public.cloak) (Client closed connection)
# [02:10] * Quits: tantek (~tpod@public.cloak) ("Colloquy for iPod touch - http://colloquy.mobi")
# [02:11] * Joins: kangil (~kangil@public.cloak)
# [02:11] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [02:11] * Joins: estellevw (~estellewyel@public.cloak)
# [02:12] * Quits: babatakao (~babatakao@public.cloak) (Ping timeout: 180 seconds)
# [02:12] * Joins: tantek (~tpod@public.cloak)
# [02:14] * leaverou_away is now known as leaverou
# [02:15] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [02:15] * Quits: tantek (~tpod@public.cloak) ("Colloquy for iPod touch - http://colloquy.mobi")
# [02:20] * Joins: babatakao (~babatakao@public.cloak)
# [02:23] * leaverou is now known as leaverou_away
# [02:25] * Joins: iank (~iank@public.cloak)
# [02:27] * Quits: babatakao (~babatakao@public.cloak) (Ping timeout: 180 seconds)
# [02:35] * Joins: babatakao (~babatakao@public.cloak)
# [02:42] * Quits: babatakao (~babatakao@public.cloak) (Ping timeout: 180 seconds)
# [02:43] * Quits: abinader (~sid21713@public.cloak) ("")
# [02:46] * Quits: estellevw (~estellewyel@public.cloak) (estellevw)
# [02:52] * Quits: iank (~iank@public.cloak) (Ping timeout: 180 seconds)
# [03:08] * Joins: dauwhe (~dauwhe@public.cloak)
# [03:14] * leaverou_away is now known as leaverou
# [03:15] * Joins: smfr (~smfr@public.cloak)
# [03:15] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [03:22] * Quits: smfr (~smfr@public.cloak) (Ping timeout: 180 seconds)
# [03:23] * leaverou is now known as leaverou_away
# [03:26] * Joins: smfr (~smfr@public.cloak)
# [03:29] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [03:45] * Joins: myakura (~myakura@public.cloak)
# [03:54] * Quits: smfr (~smfr@public.cloak) (smfr)
# [04:08] * Joins: dauwhe (~dauwhe@public.cloak)
# [04:12] * Joins: florian (~Florian@public.cloak)
# [04:13] <florian> I heard someone was looking for me, but not who was. Anybody knows?
# [04:15] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [04:17] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [04:21] * Quits: bkardell_ (~uid10373@public.cloak) ("Connection closed for inactivity")
# [04:25] * Quits: florian (~Florian@public.cloak) ("Leaving.")
# [04:28] * Joins: florian (~Florian@public.cloak)
# [04:34] * Quits: florian (~Florian@public.cloak) ("Leaving.")
# [04:36] * Joins: florian (~Florian@public.cloak)
# [04:41] * Quits: dholbert (~dholbert@public.cloak) ("dholbert")
# [04:46] * Joins: bradk (~bradk@public.cloak)
# [04:49] * Joins: dholbert (~dholbert@public.cloak)
# [04:51] * Joins: dholbert_ (~ade4375a@public.cloak)
# [04:53] * Joins: bobtung (~bobbytung@public.cloak)
# [04:55] * Quits: bobtung (~bobbytung@public.cloak) (bobtung)
# [05:00] * Joins: zcorpan (~zcorpan@public.cloak)
# [05:03] * Quits: dholbert_ (~ade4375a@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [05:07] * Quits: bradk (~bradk@public.cloak) (Client closed connection)
# [05:08] * Quits: paul___irish (~paul___irish@public.cloak) ("ZNC - http://znc.sourceforge.net")
# [05:08] * Joins: dauwhe (~dauwhe@public.cloak)
# [05:09] * Joins: paul___irish (~paul___irish@public.cloak)
# [05:11] * Joins: jdaggett (~jdaggett@public.cloak)
# [05:14] * leaverou_away is now known as leaverou
# [05:15] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [05:18] * Quits: darktears (~darktears@public.cloak) (Ping timeout: 180 seconds)
# [05:23] * leaverou is now known as leaverou_away
# [05:25] * leaverou_away is now known as leaverou
# [05:30] * Joins: jrossi (~jrossi@public.cloak)
# [05:34] * Quits: florian (~Florian@public.cloak) ("Leaving.")
# [05:36] * Joins: dauwhe (~dauwhe@public.cloak)
# [05:42] * Joins: florian (~Florian@public.cloak)
# [05:44] * leaverou is now known as leaverou_away
# [05:52] * Joins: masatakayakura (~myakura@public.cloak)
# [05:56] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [05:58] * leaverou_away is now known as leaverou
# [06:04] * Joins: iank (~iank@public.cloak)
# [06:09] * Joins: jcraig (~jcraig@public.cloak)
# [06:10] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [06:14] * Joins: dbaron (~dbaron@public.cloak)
# [06:17] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [06:23] * Joins: jcraig (~jcraig@public.cloak)
# [06:32] * Quits: florian (~Florian@public.cloak) ("Leaving.")
# [06:32] * Joins: florian (~Florian@public.cloak)
# [06:45] * Joins: tantek (~tantek@public.cloak)
# [06:49] * Quits: masatakayakura (~myakura@public.cloak) (Client closed connection)
# [06:52] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [06:52] * Joins: shans__ (~shans@public.cloak)
# [06:56] * Joins: myakura (~myakura@public.cloak)
# [06:59] * Quits: shans__ (~shans@public.cloak) (Client closed connection)
# [07:01] * Joins: liam (liam@public.cloak)
# [07:03] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [07:12] * Joins: myakura (~myakura@public.cloak)
# [07:12] * Quits: iank (~iank@public.cloak) (Ping timeout: 180 seconds)
# [07:14] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [07:20] * Joins: stakagi (~stakagi@public.cloak)
# [07:23] * Quits: jrossi (~jrossi@public.cloak) (Ping timeout: 180 seconds)
# [07:28] * Joins: florian1 (~Florian@public.cloak)
# [07:34] * Quits: florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [07:45] * Quits: stakagi (~stakagi@public.cloak) ("Leaving...")
# [07:45] * Joins: stakagi (~stakagi@public.cloak)
# [07:48] * Quits: stakagi (~stakagi@public.cloak) ("Leaving...")
# [07:48] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [07:50] * Quits: florian1 (~Florian@public.cloak) ("Leaving.")
# [07:52] * Quits: dauwhe (~dauwhe@public.cloak) ("")
# [08:01] * Joins: florian (~Florian@public.cloak)
# [08:01] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [08:06] * leaverou is now known as leaverou_away
# [08:15] * Quits: florian (~Florian@public.cloak) ("Leaving.")
# [08:32] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [08:32] * Quits: tantek (~tantek@public.cloak) (tantek)
# [08:41] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [08:41] * Joins: anssik (~uid10742@public.cloak)
# [08:45] * Joins: ArronEi (~ArronEi@public.cloak)
# [09:04] * Quits: ArronEi (~ArronEi@public.cloak) (Ping timeout: 180 seconds)
# [09:05] * Joins: jdaggett (~jdaggett@public.cloak)
# [09:18] * leaverou_away is now known as leaverou
# [09:33] * Joins: babatakao (~babatakao@public.cloak)
# [09:36] * leaverou is now known as leaverou_away
# [09:49] * Quits: babatakao (~babatakao@public.cloak) (Ping timeout: 180 seconds)
# [09:55] * Quits: dholbert (~dholbert@public.cloak) (Ping timeout: 180 seconds)
# [09:58] * Joins: dholbert (~dholbert@public.cloak)
# [09:59] * Joins: lajava (~javi@public.cloak)
# [10:00] * Joins: Ms2ger` (~Ms2ger@public.cloak)
# [10:04] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [10:26] * leaverou_away is now known as leaverou
# [10:43] * leaverou is now known as leaverou_away
# [10:55] * Quits: Ms2ger` (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [11:04] * Joins: Ms2ger` (~Ms2ger@public.cloak)
# [11:21] * Joins: Cyril (~chatzilla@public.cloak)
# [11:26] * Quits: Ms2ger` (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [11:34] * leaverou_away is now known as leaverou
# [11:37] * Joins: Ms2ger` (~Ms2ger@public.cloak)
# [11:43] * leaverou is now known as leaverou_away
# [11:59] * Quits: Ms2ger` (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [12:03] * Joins: zcorpan (~zcorpan@public.cloak)
# [12:03] * Quits: Cyril (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [12:08] * Quits: lajava (~javi@public.cloak) (Client closed connection)
# [12:09] * leaverou_away is now known as leaverou
# [12:09] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [12:14] * Joins: lajava (~javi@public.cloak)
# [12:36] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [12:46] * Joins: Ms2ger` (~Ms2ger@public.cloak)
# [12:48] * Joins: darktears (~darktears@public.cloak)
# [12:51] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [12:53] * Joins: Cyril (~chatzilla@public.cloak)
# [13:02] * Joins: tantek (~tantek@public.cloak)
# [13:09] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [13:21] * Quits: dholbert (~dholbert@public.cloak) (Ping timeout: 180 seconds)
# [13:24] * Joins: dholbert (~dholbert@public.cloak)
# [13:24] * Quits: anssik (~uid10742@public.cloak) ("Connection closed for inactivity")
# [13:42] * leaverou is now known as leaverou_away
# [13:52] * Joins: myakura (~myakura@public.cloak)
# [13:59] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [14:03] * leaverou_away is now known as leaverou
# [14:12] * leaverou is now known as leaverou_away
# [14:23] * Quits: Ms2ger` (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [14:30] * Joins: Ms2ger` (~Ms2ger@public.cloak)
# [14:41] * Joins: vollick (~vollick@public.cloak)
# [14:42] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [14:52] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [14:56] * Joins: lajava (~javi@public.cloak)
# [15:00] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [15:18] * Parts: rbyers (~sid31141@public.cloak)
# [15:18] * Joins: rbyers (~sid31141@public.cloak)
# [15:39] * Quits: vollick (~vollick@public.cloak) (Ping timeout: 180 seconds)
# [15:40] * Joins: florian (~Florian@public.cloak)
# [15:42] * Joins: iank (~iank@public.cloak)
# [15:47] * Joins: florian1 (~Florian@public.cloak)
# [15:47] * Quits: florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [15:49] * Quits: iank (~iank@public.cloak) (Ping timeout: 180 seconds)
# [15:55] * Quits: Cyril (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [16:01] * Joins: myakura (~myakura@public.cloak)
# [16:01] * Joins: iank (~iank@public.cloak)
# [16:04] * leaverou_away is now known as leaverou
# [16:05] * Joins: emalasky (~Adium@public.cloak)
# [16:07] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [16:14] * Quits: florian1 (~Florian@public.cloak) ("Leaving.")
# [16:14] * leaverou is now known as leaverou_away
# [16:16] * Quits: iank (~iank@public.cloak) (Ping timeout: 180 seconds)
# [16:18] * Joins: nsakai2 (~nsakai2@public.cloak)
# [16:19] * Joins: kurosawa (~chatzilla@public.cloak)
# [16:21] * Joins: babatakao (~babatakao@public.cloak)
# [16:25] * Quits: nsakai2 (~nsakai2@public.cloak) (Ping timeout: 180 seconds)
# [16:25] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [16:26] * Joins: Cyril (~chatzilla@public.cloak)
# [16:27] * Joins: ArronEi (~ArronEi@public.cloak)
# [16:31] * Joins: dbaron (~dbaron@public.cloak)
# [16:31] * Joins: emalasky (~Adium@public.cloak)
# [16:32] * Quits: babatakao (~babatakao@public.cloak) (Ping timeout: 180 seconds)
# [16:32] * Joins: babatakao (~babatakao@public.cloak)
# [16:32] * Quits: emalasky (~Adium@public.cloak) (Client closed connection)
# [16:32] * Joins: emalasky (~Adium@public.cloak)
# [16:32] * leaverou_away is now known as leaverou
# [16:34] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [16:36] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [16:36] * Joins: dbaron (~dbaron@public.cloak)
# [16:38] * Joins: shepazu (schepers@public.cloak)
# [16:41] * Quits: babatakao (~babatakao@public.cloak) (Ping timeout: 180 seconds)
# [16:42] * leaverou is now known as leaverou_away
# [16:42] * Joins: babatakao (~babatakao@public.cloak)
# [16:44] * Quits: kurosawa (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [16:45] * Joins: hiroto (~hiroto@public.cloak)
# [16:46] * Joins: kurosawa (~chatzilla@public.cloak)
# [16:47] * Joins: stakagi (~stakagi@public.cloak)
# [16:49] * Quits: stakagi (~stakagi@public.cloak) ("Leaving...")
# [16:49] * Joins: stakagi (~stakagi@public.cloak)
# [16:49] * Joins: KeshavP (~KeshavP@public.cloak)
# [16:50] * Quits: Ms2ger` (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [16:53] * Joins: dael (~dael@public.cloak)
# [16:53] <dael> ScribeNick: dael
# [16:53] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [16:56] * Joins: dauwhe (~dauwhe@public.cloak)
# [16:58] * Joins: vollick (~vollick@public.cloak)
# [17:01] * Joins: glenn (~gadams@public.cloak)
# [17:01] * Joins: vollick_ (~vollick@public.cloak)
# [17:01] * Joins: hiroshi (~hiroshi@public.cloak)
# [17:01] * Quits: hiroshi (~hiroshi@public.cloak) ("Leaving...")
# [17:02] * Joins: glazou (~glazou@public.cloak)
# [17:02] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [17:03] * Joins: zcorpan (~zcorpan@public.cloak)
# [17:03] * Joins: bobtung (~bobbytung@public.cloak)
# [17:03] * Joins: andreyr (~andreyr@public.cloak)
# [17:04] * Joins: myakura (~myakura@public.cloak)
# [17:05] * Joins: yamamoto (~yamamoto@public.cloak)
# [17:05] * Joins: anssik (~uid10742@public.cloak)
# [17:05] * Joins: hyojin (~hyojin@public.cloak)
# [17:06] * TabAtkins is running a little late, but will be there in a few.
# [17:06] * Quits: vollick (~vollick@public.cloak) (Ping timeout: 180 seconds)
# [17:07] * ArronEi I will be a little late, I'll be there after the first break
# [17:07] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:08] * Joins: smfr (~smfr@public.cloak)
# [17:08] * Joins: bradk (~bradk@public.cloak)
# [17:08] * Quits: hiroto (~hiroto@public.cloak) (Ping timeout: 180 seconds)
# [17:08] * Joins: plh (plehegar@public.cloak)
# [17:10] * Quits: bradk (~bradk@public.cloak) ("Lingo: www.lingoirc.com")
# [17:10] * Joins: bradk (~bradk@public.cloak)
# [17:10] * Joins: hiroto (~hiroto@public.cloak)
# [17:10] * Joins: adenilson (~anonymous@public.cloak)
# [17:11] <dael> glazou: Welcome tot he second day of the CSS meeting.
# [17:11] * TabAtkins And of course, the morning I run late, there's also a major accident outside my complex.
# [17:11] * Joins: nsakai2 (~nsakai2@public.cloak)
# [17:11] <dael> glenn: We have a few things for today. The wiki says animation behaviour, but that's this afternoon. We have flexbox issues, layout.
# [17:11] <dael> s/glenn/glazou
# [17:11] * Joins: florian (~Florian@public.cloak)
# [17:12] <dael> glazou: There's the AC meeting from 11-3, I will be there, plinss will chair until 2. Bert will chair for the 2-3 hour, thank you bert.
# [17:12] <dael> glazou: So we have flexbox issues?
# [17:13] * Joins: murakami (~murakami@public.cloak)
# [17:13] <smfr> Simon Fraser
# [17:13] <vollick_> Ian Vollick, Google.
# [17:13] <SimonSapin> Simon Sapin, Mozilla
# [17:13] <Bert> Bert Bos, W3C
# [17:13] <florian> Florian Rivoal, Invited Expert
# [17:13] <dauwhe> Dave Cramer, Hachette Livre
# [17:13] <krit> Dirk Schulze, Adobe
# [17:13] <dbaron> David Baron, Mozilla
# [17:13] <zcorpan> Simon Pieters
# [17:13] <andreyr> Andrey Rybka, Bloomberg
# [17:13] * Joins: alant (~alant@public.cloak)
# [17:13] <astearns> Alan Stearns, Adobe
# [17:13] <bobtung> Bobby Tung, Invited Expert
# [17:13] * Joins: shans__ (~shans@public.cloak)
# [17:13] <bradk> Brad Kemper, Invited Expert
# [17:13] <alant> Alan Turransky, IAB
# [17:13] <dael> MaRakow: do you mind if I present?
# [17:13] <shans__> Shane Stephens, Google
# [17:13] <dael> Topic: Discuss split layout/visual viewport and zoom types
# [17:14] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [17:14] * Joins: iank (~iank@public.cloak)
# [17:14] <iank> Ian Kilpatrick, Google
# [17:14] * Joins: adenilson (~anonymous@public.cloak)
# [17:14] <murakami> Shinyu Murakami, Vivliostyle/AntennaHouse
# [17:14] <dael> maRakow: I want to talk about what's missing from specs as they stand.
# [17:14] <dael> maRakow: The behaviours are for zooming in various ways and how we think about the viewport in various situations.
# [17:15] <hiroshi2> Hiroshi Sakakibara, Beyond Perspective Solutions, Japan
# [17:15] <dael> maRakow: There's a couple current discriptions that we have. In CSS OM we have page and pinch zoom.
# [17:15] <plinss> Peter Linss, HP
# [17:15] <yamamoto> Kazutaka Yamamoto, NTT
# [17:15] <glazou> Daniel Glazman, Disruptive Innovations, Co-chair
# [17:15] <dael> maRakow: And device adaptation actual viewport is the viewport used.
# [17:16] <dael> maRakow: First thing is why don't we have one zoom type. I'll go through this fast to ensure same page.
# [17:16] * Joins: dino_ (~textual@public.cloak)
# [17:16] <dael> maRakow: If we have a page content and we want to zoom there's two ways. Layout zoom where we inc size of content and everything rewraps within the viewport.
# [17:16] <dael> maRakow: WE do this for consistant zooms. This is something the user doesn't have negative issues of zoom in.
# [17:17] <dael> maRakow: The intention of the second type is less about reflowing the content and more about keeping it consistant.
# [17:17] <dael> maRakow: If it's more of a temp zoom you may just want a piece of content
# [17:17] <dael> maRakow: In this situation we call the area you can see as the visual viewport which is distint from layout viewport
# [17:18] <dael> maRakow: This isn't reflected in spec text. They're talking about inital viewport and that's important to the layout, but there's no text about the visual viewport
# [17:18] <dael> maRakow: One reason it's important is pinched zoom and fixed elements. Fixed is desc as attached to a sing viewport
# [17:18] <dael> maRakow: Do you attach fixed to visual, layout, both?
# [17:18] * Joins: antonp (~Thunderbird@public.cloak)
# [17:19] <dael> maRakow: [shows an example on the screen]
# [17:19] * Joins: AH_Miller (~mike@public.cloak)
# [17:19] * Quits: AH_Miller (~mike@public.cloak) ("")
# [17:19] * Joins: glazou_ (~glazou_@public.cloak)
# [17:19] * Joins: AH_Miller (~mike@public.cloak)
# [17:20] <dael> maRakow: The two top fixed elements are meant to travel with you on the page. Side nav is supposed to align nicely witht he right content. That's a problem where fixed are imune to scrolling, but whent he doc only expects one direction of scroll they align to one side and zoom starts to overlap the content.
# [17:20] <dael> maRakow: When the non-fixed content is zoomed it will overlap
# [17:20] * leaverou_away is now known as leaverou
# [17:20] * Joins: notbenjamin (~textual@public.cloak)
# [17:20] <AH_Miller> Michael Miller, Antenna House
# [17:20] <dael> maRakow: [shows and example on Gizmodo] On this page there's a side navagation aligned on the left side.
# [17:21] <dael> maRakow: What we do instead is fix to the layout viewport so it stays when you pinch zoom b/c the layout viewport is stationary.
# [17:21] <dael> maRakow: If you attach instead to visual, the content starts to crossover
# [17:21] <dael> maRakow: There's a couple way you can do this.
# [17:22] <dael> maRakow: Otehr scenarios are bars at the top and bottom, content scrolling on left/right side of content (ie ads) and also full page overlays.
# [17:22] <dael> maRakow: If you pinch zoom and attached to upper left corner, it's hard to pinch zoom in.
# [17:22] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [17:23] <dael> maRakow: A page we use a lot is Atlantis World Fair.
# [17:23] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [17:23] <dael> maRakow: It's an ex of fixed content that expects to align with non-fixed content.
# [17:23] * Joins: Mike_Miller (~mike@public.cloak)
# [17:23] <dael> maRakow: Chrome has been doing a lot of work on this. It's similar to what we're doing, they keep content aligned left/right with fixed and not fixed.
# [17:24] * Joins: bkardell_ (~uid10373@public.cloak)
# [17:24] <dael> maRakow: This is a sort of thing we'd like to see desc in some spec in terms of how the viewports interact, how do the types of zoom interact, and defining the types of zoom.
# [17:25] <dael> maRakow: There's a lot of words that get thrown around. base-zoom, layout-zoon, and base-zoom are used interchangeably for things that change inside initail containing
# [17:25] <dael> maRakow: There's also visual-zoom and pinch-zoom. The ones we favor are base and visual zoom since the terms often don't describe all the ways the zoom can occur.
# [17:26] <dael> maRakow: My thoughts are we need to put through the existing spec and spec what each spec is referring to as well as getting good definitions
# [17:26] <dael> krit: Do you expose any of these as APIs?
# [17:26] <krit> s/krit:/dino:/
# [17:26] <dael> maRakow: In part thats were some of the props for the client with client height are defined, They refer to a viewport. mostly we spec the prop hanging off the doc layout with the client height viewport.
# [17:27] <dael> dino: So the user can know they're pinched in two times?
# [17:27] <dael> maRakow: We have a prop that reveals that.
# [17:27] <dael> maRakow: We've talked about wanting a more explicit API.
# [17:27] * Quits: AH_Miller (~mike@public.cloak) (Ping timeout: 180 seconds)
# [17:27] <dael> dino: Do you ever expect the user or allow layout to happen as the pinch zoom changes. Someone wants a legend on the map and remain 1 to 1
# [17:28] <dael> maRakow: We don't. We have a few other things like touch keyboard where when we resize we allow scrolling to the bottom with keyboard up. We have a positioning type where you fix an item to the visual viewport, but that's the only case.
# [17:28] <dael> dbaron: My assumption is every spec is referring to a layout viewport b/c I think most were written before visual viewport existed.
# [17:29] <dael> dbaron: I think...there was talk about the lack of interop of all this that's interesting. I know of one place there the video is online.
# [17:29] <dael> dbaron: I'm inclined to think that it ought not be nec to go through every ast spec, though it would be nice as we revise for clarity.
# [17:30] * Joins: liam (liam@public.cloak)
# [17:30] <dael> maRakow: I spent some time making a list and for the most part it's swapping a word, but there were places where clarifying text would be helpful. As I finish the list I can send it to the ML
# [17:30] <dael> smfr: When I was talking to rossen he desc the model where when you're panning the layout viewport isn't moving, but when you hit the edge you start scrolling. Can you clarify when the scroll events fire?
# [17:30] <dino_> http://lanyrd.com/profile/ppk/
# [17:30] * leaverou is now known as leaverou_away
# [17:31] <dino_> http://www.youtube.com/watch?v=TF9ID1xwxno
# [17:31] <dino_> Presentation on Mobile Viewports
# [17:31] <dael> maRakow: We do fire scroll events. the model we have to interact two viewports, one req is that if you pinch zoom in, scroll down, inch out and scroll up you should be in the same place, so we need to make sure the viewports travel together. They're a box withing a box.
# [17:31] <astearns> also: http://www.smashingmagazine.com/2014/04/29/meet-mobile-web-handbook-new-smashing-book-peter-paul-koch/
# [17:31] <dael> maRakow: So as you go down you drag both viewports with you.
# [17:31] <bradk> http://www.quirksmode.org/mobile/viewports2.html
# [17:32] <dael> maRakow: So if I pinch zoom in and pan up/down he fixed element is aligned to the fixed element. When you hit the edge of the layout port, that's when you start to drag the other viewport.
# [17:32] <dael> maRakow: All the fixed elements are where you expect
# [17:32] <dael> smfr: And if you zoom and scroll sideways
# [17:33] <dael> maRakow: It'll stay consent here since this page doesn't have hor scroll available, but it should.
# [17:33] <dael> smfr: One issue I have is the pos of fixed opbjects depends on how you got to that state. We don't have that in iOS model.
# [17:33] <dael> maRakow: You mean like state pool?
# [17:33] * Joins: Shige (~Shige@public.cloak)
# [17:33] <dael> smfr: You're dragging the layout viewport around. If you came back to that same page, but arriv through diff scrolling action, you could end up in a diff place.
# [17:34] <dael> dbaron: What does iOS model do diff?
# [17:34] <dael> smfr: Can I project?
# [17:34] * Joins: nikos_ (~nikos@public.cloak)
# [17:34] * dino_ was mistaken for krit. I think that's a first for both of us.
# [17:35] * dael 's fingers typed d and tried to autofill
# [17:35] * Quits: dino (~textual@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [17:35] * dino_ is now known as dino
# [17:35] <dael> smfr: This is a page with four fixed elements, bars across the top and bottom.
# [17:35] * krit is good with british AND australian dialects
# [17:35] * dino - no worries dael!!
# [17:36] <dael> smfr: This is zoomed out. When I zoom in we keep fixed things relative to physical viewport so bars at 100% width layout to a narrow witdh. If you follow that model and zoom in enough fixed thigns crowd so we start pushing off screen by interpolating between the two viweports so you scoll around and see the edge of the fixed things.
# [17:36] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [17:37] <dael> smfr: That gives weird drifting behaviour, but ameliorates the probelm where things get in your way. The layout of fixed position doesn't have any difference.
# [17:37] <dael> ??: the IOS moble website when you're targeting, it wasn't defined for that.
# [17:37] <dael> krit: Would the elevator model work on yours?
# [17:37] <dael> smfr: No.
# [17:37] <dino> s/??/BenPoulain/
# [17:38] <dael> smfr: One thing I'd like to see is web authors express how fixed should zoom. People layout fixed and leave the left or top auto. I'd like them to be able to express that they always want it at the top but it's okay to move it.
# [17:38] <dael> smfr: I've tried keying it off and it doesn't always work.
# [17:39] <dael> maRakow: We're trying to find compat for desktop. We handle fixed so at any point in pinch zoom you see everything when you scroll. WE tackled keeping content on screen at all times with a new prop which is device-fixed which attaches to visual viewport.
# [17:39] <dael> maRakow: It's opt-in, but it seemed dangerious to do that by default
# [17:39] <dael> smfr: And that gives you diff zooming? Doesn't scalle w/ page?
# [17:39] <dael> maRakow: Correct. If an author uses it they should already think of it.
# [17:40] <dael> florian: Both behaviours make sense. Seems we need an author level way of picking which they want.
# [17:40] <dael> dbaron: Some of this is more about adopting desktop to mobile, not really about content made for smaller.
# [17:40] <dael> ???: Not quite. I have a touch screen, but sometimes I want to zoom. I'm not trying to pidgen hole
# [17:41] <dael> dbaron: Keying off auto seems like the wrong thing to me.
# [17:41] <dael> maRakow: It works well with content aligned with non-fixed content. If you leave the top/left on auto you don't have to do resizing logic, it's always just aligned since it's pos as absolute.
# [17:42] <dael> maRakow: In the gizmodo case, if you have a two column layout and then position the fixed as top/bottom/left/right auto as you resize you don't have to say change te left to make it stayed aligned.
# [17:42] <dael> dbaron: Ast he user resizes?
# [17:42] <dael> maRakow: Corrent.
# [17:42] <dael> maRakow: Just resizing. As the margin is reduced by shrinking the window, this pages will have a resize handler that changes left if they're spec finding left. If it's auto that'll auto be repos alongthe content.
# [17:43] <dael> smfr: Auto changes the fixed element relative to te right place.
# [17:43] <dael> dbaron: Based on the assumption it's scrolled to inital scrolling positiong.
# [17:43] * Quits: vollick_ (~vollick@public.cloak) (Ping timeout: 180 seconds)
# [17:43] <dael> smfr: I think it's indep.
# [17:43] <dael> dbaron: It matches the original position.
# [17:43] <dael> smfr: It's kinda like using auto, you use it where it is. Anyway, authors do this.
# [17:44] <dael> maRakow: I don't exect a conclusion today, I wanted to socialize the problem. We can con't on the mailing list.
# [17:44] * Joins: MaRakow (~MaRakow@public.cloak)
# [17:44] <dael> smfr: I'm hesitant to say...to spec the zooming viewport behav in such a way that all UAs need to conform and can't innovate, but I'd like to see ways for authors to express what they want and we can converge on behaviour.
# [17:45] <dael> BenPoulain: And think about when you layout in the port.
# [17:45] <MaRakow> http://gizmodo.com/
# [17:45] <dael> maRakow: I think this is a good start.
# [17:45] <MaRakow> https://www.flickr.com/photos/34654941@N02/8560297430/in/photolist-8MXZUM-2nF5aq-baAvmM-fTMsFJ-e3rLc1-hVcTTe-ncLVr5-egjd34-mJuvoW-dDwovw-4aeSwh-6mC7FC-48nagT-bRgbVB-azj7AV-e1Ci8t-9bLLEJ-69489U-dk6EgQ-bXqvdN/lightbox/
# [17:45] <MaRakow> http://www.lostworldsfairs.com/atlantis/
# [17:45] <dael> glazou: Okay, so, nothing else on this?
# [17:46] * dael MaRakow Do you have your presentation online anywhere so I can link to that in the minutes?
# [17:46] <dael> glazou: Thank you very much.
# [17:46] <dael> Topic: Flexbox issues
# [17:46] * Joins: vollick (~vollick@public.cloak)
# [17:47] * MaRakow not yet, but I can post it
# [17:47] * dael MaRakow Thank you!
# [17:47] <dael> fantasai: I think we gotbasically 3 issues
# [17:47] <dael> fantasai: One of them, well 4.
# [17:47] <dael> fantasai: one was something TabAtkins and I have to work out and might not be quite ready.
# [17:48] <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Oct/0489.html
# [17:48] <dael> fantasai: 2nd was alinement diff should depend on if the flexbox wraps, not the # of lines it happens to wrap to.
# [17:48] <dael> fantasai: The spec says that if there is one line of flex content than the align content prop is not used. If there's more than one we use align content to figure out how it fits.
# [17:49] <dael> fantasai: The prop is in a flex container that has wrapping the alignment dep on # of lines, so if my screen is wider than test they'll get unexpected behaviour
# [17:49] <dael> fantasai: This should dep on if the flexbox is wrappable, not on if it has more than one line
# [17:49] <dael> TabAtkins: The spec orig behaved like this and Alex Goblieski(?) requested the change
# [17:49] <TabAtkins> s/Goblieski(?)/Mogilevski/
# [17:50] <dael> fantasai: I think is is more likely to give unexpected behaviour. So say I want to base-align to itself and center in theb ox and you don't get that because it falls on one line.
# [17:50] <dael> fantasai: So I thinkw e should change to just dep on flex wrap prop. People responded it makes sense.
# [17:50] <dael> TabAtkins: He did respond and say it was fine.
# [17:50] <dael> fantasai: Other comments?
# [17:51] <dael> TabAtkins: I think we need a Rossen okay and we're fine.
# [17:51] <glazou_> rrsagent, this meeting spans midnight
# [17:51] <RRSAgent> ok, glazou_; I will not start a new log at midnight
# [17:51] <dael> fantasai: How do we dial someone in?
# [17:51] <fantasai> zakim, code
# [17:51] <dael> dbaron: They call Zakim and Zakim calls this number.
# [17:51] <dbaron> Zakim, code?
# [17:51] <plinss> zakim, room for 3?
# [17:51] * Joins: Zakim (zakim@public.cloak)
# [17:51] <dbaron> Zakim, code?
# [17:51] <Zakim> sorry, dbaron, I don't know what conference this is
# [17:51] <plinss> zakim, room for 3?
# [17:51] <Zakim> ok, plinss; conference Team_(css)16:51Z scheduled with code 26634 (CONF4) for 60 minutes until 1751Z
# [17:52] <plinss> zakim, call SantaBarbara
# [17:52] <Zakim> ok, plinss; the call is being made
# [17:52] <Zakim> Team_(css)16:51Z has now started
# [17:52] <Zakim> +SantaBarbara
# [17:52] * plinss changes topic to 'https://wiki.csswg.org/planning/tpac-2014#agenda - Zakim code 26634#'
# [17:52] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [17:53] <dael> plinss: So we're waiting for a call?
# [17:53] * Joins: jcraig (~jcraig@public.cloak)
# [17:53] <dael> fantasai: He says he'll call in a minute.
# [17:54] <Zakim> +[Mozilla]
# [17:54] <dbaron> Zakim, [Mozilla] is dholbert
# [17:54] <Zakim> +dholbert; got it
# [17:55] <dael> TabAtkins: Did elika give you context?
# [17:55] <dael> dholbert: I was folling in IRC.
# [17:55] <fantasai> s/elika/fantasai/g
# [17:55] <glazou_> s/folling/following
# [17:55] <dael> TabAtkins: Comments? Yea/Nay?
# [17:55] <dael> dholbert: Yes. The align content change makes sense to me.
# [17:55] <dael> fantasai: There's one more issue Roseen was going to talk about.
# [17:55] * Joins: jrossi (~jrossi@public.cloak)
# [17:55] <dael> TabAtkins: He's not here.
# [17:56] <shans__> s/Roseen/Rossen/
# [17:56] <dael> fantasai: Okay. In that case maybe we can ask dholbert to call back when he's here.
# [17:56] <Zakim> -dholbert
# [17:56] <dael> dholbert: Bye, talk to you soon.
# [17:56] <dael> dbaron: If there were enough to justify it dholbert could drive here.
# [17:56] * dholbert doesn't have a car today, but does have stupid amounts of uber credits to spend, & could easily uber there
# [17:56] <dael> fantasai: I thinkw e have 3 issues total, so I think TabAtkins and I should work on one over th break, but I don't think it's a WG issue. I think we'll all get confused.
# [17:57] <Zakim> -SantaBarbara
# [17:57] <dael> fantasai: That's all for now, we can come back with rossen.
# [17:57] <Zakim> Team_(css)16:51Z has ended
# [17:57] <Zakim> Attendees were SantaBarbara, dholbert
# [17:57] * Joins: jet (~uid49872@public.cloak)
# [17:57] * Quits: bradk (~bradk@public.cloak) ("Be back later ...")
# [17:57] <dael> glazou_: I suggest a 15 minute coffee break and that will allow rossen to arrive.
# [17:57] <dael> [Break]
# [17:57] * Joins: bradk (~bradk@public.cloak)
# [17:57] * Quits: bobtung (~bobbytung@public.cloak) (bobtung)
# [17:57] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [17:58] * Joins: liam (liam@public.cloak)
# [18:02] * Quits: vollick (~vollick@public.cloak) (Ping timeout: 180 seconds)
# [18:02] * Joins: tantek (~tantek@public.cloak)
# [18:04] * Quits: bradk (~bradk@public.cloak) (Ping timeout: 180 seconds)
# [18:05] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [18:06] * Quits: Shige (~Shige@public.cloak) (Ping timeout: 180 seconds)
# [18:08] * Parts: nikos_ (~nikos@public.cloak)
# [18:11] * Quits: florian (~Florian@public.cloak) ("Leaving.")
# [18:12] * Joins: bobtung (~bobbytung@public.cloak)
# [18:12] * Joins: Shige (~Shige@public.cloak)
# [18:15] * Quits: shans__ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [18:16] * Quits: jrossi (~jrossi@public.cloak) (Ping timeout: 180 seconds)
# [18:16] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [18:19] * Joins: dauwhe (~dauwhe@public.cloak)
# [18:19] * Joins: bradk (~bradk@public.cloak)
# [18:21] * Joins: bradk_ (~bradk@public.cloak)
# [18:21] * Quits: bradk (~bradk@public.cloak) (Client closed connection)
# [18:21] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [18:21] * Quits: iank (~iank@public.cloak) (Ping timeout: 180 seconds)
# [18:21] * leaverou_away is now known as leaverou
# [18:22] * Quits: nsakai2 (~nsakai2@public.cloak) (Ping timeout: 180 seconds)
# [18:22] <dael> glazou_: Let's restart
# [18:22] * Joins: florian (~Florian@public.cloak)
# [18:23] * TabAtkins Reminder: here's the wiki page for lunch https://wiki.csswg.org/planning/tpac-2014#social
# [18:23] <dael> glazou_: Since everyone is in the room and we have rossen, let's do flexbox
# [18:23] * Joins: nsakai2 (~nsakai2@public.cloak)
# [18:23] * Joins: iank (~iank@public.cloak)
# [18:23] <dael> fantasai: He's waiting on feedback, so we only have one issue. The total DoC will be 3 comments and we'll have to go through the last one, maybe later.
# [18:24] <dael> rossen: If we get news, they should have had numbers by now. If I get it we'll maybe take 15 minutes.
# [18:24] * Joins: shans__ (~shans@public.cloak)
# [18:24] <dael> glazou_: So I suggest taking things from the afternoon.
# [18:24] <dael> glazou_: Can we do ::role()?
# [18:24] * Joins: Rossen_ (~Rossen@public.cloak)
# [18:24] <dael> Topic: ::role()
# [18:25] * Joins: song (~song@public.cloak)
# [18:25] <dael> TabAtkins: jcraig suggested a ::role pseduo
# [18:25] * Quits: hyojin (~hyojin@public.cloak) (Ping timeout: 180 seconds)
# [18:25] <TabAtkins> s/::role/:role/
# [18:25] <dael> hober: There's a few problem. One is the impl RA roles on the elements. When you have multi roles on one element, you get all of them.
# [18:25] <dael> hober: For styling you may want to style that as a switch or a checkbox. Right now that's difficult in CSS.
# [18:26] <dael> hober: THere's also the case of wanting to simply style all the buttons on the page
# [18:26] <dael> hober: You want to be able to say :role() and be done.
# [18:26] <dael> TabAtkins: That's convincing. Is there anything outside that?
# [18:26] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [18:26] <dael> hober: WE can always add more.
# [18:26] * Joins: jrossi (~jrossi@public.cloak)
# [18:26] <dael> glazou_: You mentioned implied role. So some won't need an assigned role. WE'll need to refer to HTML.
# [18:27] <dael> hober: In CSS we say the host language has that.
# [18:27] <dael> dbaron: It's :: or :
# [18:27] <dael> TabAtkins: It's a functional class. It should be an ident.
# [18:27] <dael> glazou_: Can you have multi roles?
# [18:27] <dael> hober: Syntatically you can.
# [18:27] <dbaron> hober: but only one is active
# [18:27] <dael> glazou_: So if you have multi roles on one ident it's whitespace broken?
# [18:28] <dael> dino: So if you do colen role
# [18:28] <dael> hober: You can do :role button and :role super button. Or we seperate in the list itself.
# [18:28] <dael> glazou_: So the role attr is multi but the role pseudo is only one?
# [18:28] <smfr> s/colen/colon/
# [18:28] * Joins: jcraig (~jcraig@public.cloak)
# [18:28] <dael> hober: Yeah.
# [18:29] <dael> dauwhe: dpub is working on adding things for role attr.
# [18:29] <dael> TabAtkins: Do you know if it will be consistent with this?
# [18:29] <dael> dauwhe: They haven't said. I'll raise that with them.
# [18:29] <dael> TabAtkins: So I guess that's simple. obj to adding :role() to selectors?
# [18:30] <dael> TabAtkins: So :role(button) would target anything thatha s a button accoring to aria rules.
# [18:30] <dael> hober: It wouldn't match button role = checkbox or something crazy
# [18:30] <dael> dbaron: So people are okay with agreeing CSS won't do future things to influence what the aria role is.
# [18:30] <dael> hober: It should be defined by pointing overthere.
# [18:31] <dael> fantasai: We need to have another language that has CSS language. OUr stuff should be about styling.
# [18:31] <dael> TabAtkins: If someone would like to impl cascading attr selectors in a browser *shrug*
# [18:31] <dael> dbaron: Having CSS do this side makes sense, but we can't do both.
# [18:31] <dael> hober: Should we have a note in the spec saying "you may be confused"
# [18:31] <dael> glazou_: When we had selectors we didn't have a note. I'm not sure we need a note.
# [18:31] <dael> hober: Okay.
# [18:32] <dael> glazou_: So not obj
# [18:32] <fantasai> fantasai^: People keep asking us to put things in CSS that belong in the DOM, because they want to use CSS selectors and cascading to attach it to the tree.
# [18:32] <dael> RESOLVED: add :role() to selectors
# [18:32] <dael> glazou_: who is going prose?
# [18:32] * MaRakow dael, link to slide deck from viewport discussion is here: http://1drv.ms/1xAK9Hd
# [18:32] <dael> TabAtkins: I will.
# [18:32] <dael> Topic: Status of selectors 4
# [18:32] * bkardell_ did https://github.com/bkardell/cas :-p
# [18:33] <dael> dbaron: I stuck this on the agenda because I want to get to some things. At some point we should stop adding features and advance it
# [18:33] <dael> fantasai: I think I want to trim it to the thigns that will go to CR when I have time. Make a cut and put everything else in level 5. That was my goal last year, so I don't know if it will happen.
# [18:33] * Joins: vollick (~vollick@public.cloak)
# [18:33] <dael> fantasai: I would be happy to take a resolution that :dir should be unprefixed.
# [18:33] <dael> glazou_: So to do that, does the WG think it's stable enough ot do it and 2nd are all impl okay?
# [18:34] <dael> glazou_: So object to it being stable?
# [18:34] <dael> fantasai: :dir and :lang are quite stable, the syntax is obvious, they fall in the level 3 template.
# [18:34] <dael> SimonSapin: Do you think the complex lang matching is ready?
# [18:34] <dael> fantasai: We're just point ing to it. I think Microsoft impl that.
# [18:35] <dael> glazou_: There were bugs in browser impl about :lang where one rendering language wasn't parsing more than one dash.
# [18:35] <dael> glazou_: It was a bit back. Make sure it was fixed.
# [18:35] <dael> glazou_: 2nd question, impl you okay with unprefixed :dir?
# [18:36] <dael> RESOLVED: unprefix :dir and :lang
# [18:36] <dael> florian: Do we have a test suite?
# [18:36] <dael> fantasai: I think Micrsoft does.
# [18:36] <dael> florian: It would be good to share so people who were prefixed get it right.
# [18:36] <ArronEi> There are very few test cases
# [18:36] <fantasai> s/Micrsoft/Mozilla/
# [18:37] <bradk_> :dur? collender?
# [18:37] <dael> glazou_: Anything else on Selectors 4? Test suite? Very few cases, can we have more?
# [18:37] <dael> fantasai: Mozilla impl so I'm sure they have a bunch of test cases. I'm not sure where.
# [18:37] <ArronEi> I will put the selectors 4 on my list
# [18:37] <ArronEi> ... for more cases
# [18:37] <dael> dino: Has there ever been a prop for an OM API to be able to set a pseudo class on something? Like if you want to set the initial-letter on a div.
# [18:38] <dael> TabAtkins: That's a pseudo element.
# [18:38] <dael> glazou_: So ArronEi suggested an API a way to create programmatically two elements. I'm not sure it got consensus, but I think it should happen.
# [18:38] <astearns> s/ArronEi/astearns/
# [18:38] * Joins: adenilson_ (~anonymous@public.cloak)
# [18:39] <glazou> s/astearns/astearns and I/
# [18:39] <TabAtkins> s/two /pseudo-/
# [18:39] <dael> florian: On this topic it doesn't look like the test stask from Opera will help. I went through the repo and they're barely there.
# [18:39] <dael> glazou: It would be good to have more tests. Anything else on Selectors 4 dbaron ?
# [18:40] <dael> dbaron: That's it. We have a bunch of JS scripts that would need to be rewritten, but they're straightforward.
# [18:40] <florian> s/stack/stash/
# [18:40] <dael> Topic: Rossen_ 's extra item
# [18:40] <dael> Rossen_: fantasai and I spent time cleaning up. We think we figured out the outstanding issues and cleaning up the lang.
# [18:40] <dael> fantasai: There's one issue open, let me pull it up.
# [18:41] <dael> dbaron: What's the next level?
# [18:41] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [18:41] <dael> fantasai: I think we need to repub WD, ask for review, go to CR
# [18:41] <dael> fantasai: WE say that if you have something you can't fragment, for ex some inline blocks, there's no line break opp possble within a line box
# [18:41] * smfr wants a url for this issue
# [18:42] <dael> fantasai: You have an inline block on a line box, it happens to be 1 1/2 pages. You can't fit it on one page. We have lang that says if you're printing and have a thing that doesn't have breaks and will not fit, you can break whereever you want so the content doesn't disappear.
# [18:42] <dael> fantasai: The issue was do we want this for other frag such as Regions and multi-col
# [18:42] <astearns> issue in this section: http://dev.w3.org/csswg/css-break/#possible-breaks
# [18:42] * trackbot doesn't understand that ISSUE command.
# [18:43] <dael> fantasai: The default is no data loss for printing. For regions and multi-col you might be able to scroll to see it another way, but it's prob easier from impl to only have one way to fragment so we were thinking for this level we should be consistant
# [18:43] <dael> fantasai: That was our prop for closing this. Is there a diff perspective?
# [18:43] * Quits: adenilson (~anonymous@public.cloak) (Ping timeout: 180 seconds)
# [18:43] * adenilson_ is now known as adenilson
# [18:43] <dael> dbaron: I'm fine with it, though I don't think slightly different printing rules is that big a deal.
# [18:44] <fantasai> http://dev.w3.org/csswg/css-break-3/#possible-breaks
# [18:44] <dael> astearns: We need something saying what happens with other fragmentainers and the printing models is a good starting default. If we need something else we can add.
# [18:44] <dael> florian: Given that the prop is do what you need to to make it fit, we can check again later.
# [18:44] <dael> florian: It gives room to play around.
# [18:45] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [18:45] <dael> fantasai: So we'll close as apply to all fragmentainers. I think that's all the fragmentation issues. Anything else let us know. We'd like a resolution to pub a new WD with 6 weeks for review and than pub CR
# [18:45] <dael> dbaron: What's in the draft for new features
# [18:45] <dbaron> ... as opposed to just specifying things better
# [18:46] <dael> fantasai: We changed break-before and break-after prop. We have new values for force break, always and any. We have the rectoverso (?) values.
# [18:46] * Quits: Cyril (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [18:46] <dael> fantasai: Always forces a break through all the levels, so if you have a region in a pagination etc you break through all the things.
# [18:47] <dael> fantasai: We also have some values for regions spec things in addition to column and page spec. They're going to be at risk b/c it depends on where regions goes. I think that's it for new features.
# [18:47] <dael> Bert: A float is a fragmentainer?
# [18:47] <dael> fantasai: It's not.
# [18:47] <dael> fantasai: Unless it's a region.
# [18:48] <dael> Bert: Yeah. I was wondering if it's a useful case to include
# [18:48] <dael> fantasai: Technically a line box is a fragmentainer, but we put it out of scope.
# [18:48] <dael> Bert: I can imagine someone doing a three column layout and want a break mid-float.
# [18:48] <dael> astearns: Unless there's somewhere else for the content to go.
# [18:48] <dael> Rossen_: You can make a region inside a float.
# [18:49] <dael> Rossen_: If you have a region inside your float, sure you can have three floats and call yoru content trhough there. Then you'd be frag context in a region in a float.
# [18:49] <dael> Bert: So I can page break in a void, but I can't use page break for any inside a float. So it would break over two pages, but I don't have full control as to where. I can suppress a break, but not force a break.
# [18:50] <dael> Bert: Seems asymetric. I can do that with a region, I assume, but not a float.
# [18:50] <dael> Bert: Sounded like the extra keyword of any would do it.
# [18:50] <dael> Bert: I have to think more about that. I'm wondering why float isn't fragmentainer.
# [18:51] <dael> fantasai: Because it doesn't cause fragmentionation. A fragmentainer is a page, column, or region
# [18:51] <dael> Rossen_: It's what happens inside, not outside.
# [18:51] <dael> Bert: A page break can occur mid-float.
# [18:51] <dael> Rossen_: It's the content inside a float
# [18:51] <dael> fantasai: If you force a page break inside a float, the fragmentainer that's important is the page, not the float. You can do a page break inside a float. We define how that works, but the page isn't a fragmentainer, it's a containing block.
# [18:51] <dael> Bert: The floar has a flow.
# [18:52] <dael> Rossen_: Just like a table cell
# [18:52] <dael> fantasai: It doesn't make it a fragementainer, just a containing block.
# [18:52] <dael> Bert: It would still be useful to indicate where in the float I want to break it.
# [18:52] <dael> fantasai: Use page-break.
# [18:53] <dael> florian: You don't want floats to break across a page. That's not what we're doing, you can't split the flaot in half without splitting the page in half. Floats don't break without being in the page
# [18:53] * bkardell_ rolling on the floar laughing
# [18:53] <dael> Bert: If you break before always, any content after the float is on the current page.
# [18:53] <dael> fantasai: affect of the page break is only on the paralel flow
# [18:53] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [18:53] <dael> Bert: So it is for a float. So fragmentainer isn't the word I was looking for.
# [18:53] <dael> Bert: OKay. That's what I wanted.
# [18:54] <dael> fantasai: Alright.
# [18:54] * Joins: Nishanth_IA (~Nishanth_IA@public.cloak)
# [18:54] <dael> Rossen_: Publish a WD of fragmentation and give 6 weeks for feedback before CR?
# [18:54] <bkardell_> +1
# [18:54] <dael> glazou: Obj?
# [18:54] <dael> RESOLVED: Publish a WD of fragmentation and give 6 weeks for feedback before CR
# [18:55] <dael> glazou: I have to leave for the AC meeting.
# [18:55] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [18:55] * Quits: glazou (~glazou@public.cloak) (glazou)
# [18:55] <dael> plinss: Media transforms next?
# [18:55] <plinss> s/Media//
# [18:56] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [18:56] <dael> Topic: Transforms
# [18:57] <dael> smfr: I recently updated the ED of transforms to contain new text the desc rendering of 3D transforms
# [18:57] <dael> smfr: This section on transform rendering is rewritten
# [18:57] <dael> smfr: The first part is 2D transforms which we're clear on. 3D is the new
# [18:58] <dael> smfr: Initially it talks about perspective. 6.1.2 desc how 3D trans elements are rendered, how they interweave and intersect with non-transformed elements. This was unclear before so this is making it good enough to impl
# [18:58] <dael> florian: Was it unclear or unintent ambig?
# [18:59] <dael> smfr: Unclear. I added a 3D rengering context. analigous to CSS stacking. It's a set of elements inside of which the 3 transformed elements are altered and can intersect, but are then flattened into a plane, just as stacking is flattened
# [18:59] <dael> smfr: the way I spec'ed it here I mirrored the behaviour of stacking context in that an element with z-inder -1 will go behind the content and other decendants
# [19:00] <dael> smfr: Let me show you pictures. This is on the wiki and I have a link from transforms as the first issue
# [19:00] * Quits: tantek (~tantek@public.cloak) (tantek)
# [19:00] <dael> smfr: if you look at the blue box and compare to pale blue box, you'll see it's behind and that's the CSS2.1 order
# [19:00] * Quits: ArronEi (~ArronEi@public.cloak) (Ping timeout: 180 seconds)
# [19:00] <dael> smfr: Now and element with a neg z-translate will go behind and a positive will go in front.
# [19:01] * Joins: ArronEi (~ArronEi@public.cloak)
# [19:01] <dael> smfr: This is the rendering the spec prop where the order is the B&B. Where the z = 0 plane it's the stanadard rengering. On top of that is the positive translated content.
# [19:01] * Joins: jcraig (~jcraig@public.cloak)
# [19:01] <dael> smfr: This is the idea behavior that the spec desc.
# [19:01] <dael> smfr: A consiquence is it's poss to intersect tranlasted with the untranslated element.
# [19:02] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [19:02] <dael> smfr: One of the issues is that this spec requires UA to basically render the root at two planes so it can do intersections.
# [19:02] * Quits: glazou_ (~glazou_@public.cloak) (Ping timeout: 180 seconds)
# [19:02] <dael> smfr: The problem is it could force UAs to allocated tqice as much memeory for some elements, so I have some concerns, but it is basically the ideal behaviour.
# [19:03] * Joins: Cyril (~chatzilla@public.cloak)
# [19:03] <dael> smfr: On the ML Robert O'Callahan prop an altertantive where translate z-1 on top and if you rotate it wouldn't intersect. It's a bit more special case, but would allow browsers not to allocated twice as much memory.
# [19:03] <dael> smfr: One consiquence is what happens...let me go back to the spec
# [19:03] <dael> smfr: The issue we desc is issue 3.
# [19:04] <dael> smfr: There's more subtile ones about UA impl details and if you intersect z=0 planes sometimes.
# [19:04] <dael> smfr: krit asked if this is flattening. In the spec we have 3 values for transform style prop.
# [19:04] <dael> smfr: There's a new auto which is the default. It means ignore this forthe purpose of computing 3D
# [19:04] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [19:04] <dael> smfr: flat is make it flattening and it's a 3D rendering context ancestor.
# [19:05] <dael> smfr: preserve 3D is the specil on where allow decendants to live in the same 3D space.
# [19:05] <dael> smfr: So the default is auto which lets them live in the same space and maybe intersect.
# [19:06] <dael> smfr: There's things that req flatten, like clipping, opacity. Byt default tranform and perspective also cause flattening. With transforms people want to build 3D hiraracy. If an element has a tranform the author can override the flattening.
# [19:06] <dael> smfr: The role of transform style is controlling if transforms in perspective cause flattening. The root flattens by default which is simple.
# [19:06] <dael> smfr: The previous had woring as to if elements belongs to 3D context, now it says every element belongs, like stacking.
# [19:07] * Joins: glazou (~glazou@public.cloak)
# [19:07] <dael> smfr: The main issue to discuss is the one I showed you because that influences..before I can write test cases
# [19:07] <dael> smfr: Robert proposed the second.
# [19:07] <dael> krit: Resonaing?
# [19:07] <dael> smfr: My efficent for UA.
# [19:07] <dael> bkardell_: So it's possible to have a bunch of 3D sorting at the same time
# [19:08] <dael> smfr: You do it in the 3D rendering context you belong to. It has access to 3D rendering context. That happens no matter which model.
# [19:08] <astearns> s/bkardell_ /vollick/
# [19:08] <dael> smfr: One impact of Robert's model is position fixed won't intersect 3D transformed. So a position fixedw ould like in the z=0 frame. I think that's a downside of this model.
# [19:09] <dael> smfr: It would be possble to have a combo, it's not impossible, it's just in some config.
# [19:09] <dael> MaRakow: Can you talk about how the new values would be used. If I have an item with preserve 3D
# [19:10] <dael> smfr: That was a mis-nomer. Preserve prevents flatting, not creates it. They would prob set preserve 3D flat, though that would likely be the default. It's only used if you want to override the default.
# [19:10] * Joins: nvdbleek3 (~nvdbleek@public.cloak)
# [19:10] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [19:10] <dael> MaRakow: So every element would have auto except the root of the scene.
# [19:10] * Quits: Cyril (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [19:10] <dael> smfr: Preserve would only be used on transformed elements that want to live in the same 3D space.
# [19:10] <dael> MaRakow: I'm trying to figure out how it's diff from inheritence.
# [19:11] <dael> smfr: It's been suggested transform should inherit. I didn't do that b/c it would cause flattening in places we don't.
# [19:11] <dael> MaRakow: What's an example?
# [19:11] * Joins: kip (~kip@public.cloak)
# [19:11] <dael> smfr: webkit if you have a perspective element and then a div, in most cases transform respects perspective.
# [19:11] <dael> MaRakow: Is the middle div already transform style flat?
# [19:11] <dael> smfr: It's more like auto.
# [19:11] <dael> smfr: I think we may be willing to make it inherited. It simplifies.
# [19:11] * Joins: Cyril (~chatzilla@public.cloak)
# [19:12] <dael> MaRakow: That seems like a more existing concept as opposed to the children behaviour.
# [19:12] * Quits: nvdbleek (~nvdbleek@public.cloak) (Ping timeout: 180 seconds)
# [19:12] * nvdbleek3 is now known as nvdbleek
# [19:12] <dael> MaRakow: Going back to z index, I think the neg Z index would be a pain point.
# [19:12] <dael> smfr: So you favor Robert's behav
# [19:12] <dael> krit: There's interop for that.
# [19:13] * Quits: vollick (~vollick@public.cloak) (Ping timeout: 180 seconds)
# [19:13] <dael> smfr: It has weaknesses. If it had a 2D transform it wouldn't interweave with a 3d. The spec would have to have special language saying it pops to the front. We would have to actively prevent interweaving.
# [19:13] <dael> MaRakow: The 3D rendering context is gone?
# [19:13] <dael> smfr: It's there, but morphed into an ex
# [19:13] * Joins: tantek (~tantek@public.cloak)
# [19:13] <dael> MaRakow: Because they're in the same 3D rendering context you have to have the 3D?
# [19:13] * Joins: vollick (~vollick@public.cloak)
# [19:14] * Joins: dbaron (~dbaron@public.cloak)
# [19:14] <dael> smfr: In this ex everything is in the same context. I guess the nautual is by mirroring is the left, but the one on the right is Roberts, where anything with 3D pops tot he front. I think it's weird because anything that's 2D isn't part of that set of depth
# [19:14] * Joins: glazou_ (~glazou@public.cloak)
# [19:14] * dbaron Zakim, pointer?
# [19:14] * Zakim I don't understand your question, dbaron.
# [19:14] * dbaron RRSAgent, pointer?
# [19:14] * RRSAgent See http://www.w3.org/2014/10/28-css-irc#T18-14-17-1
# [19:14] * Quits: glazou (~glazou@public.cloak) (Ping timeout: 180 seconds)
# [19:14] * glazou_ is now known as glazou
# [19:14] * Joins: lajava (~javi@public.cloak)
# [19:14] <dael> plinss: Also if you're 3D into the Z plane you'd expect behind. I accept it's easier to impl, but is it rational? Does it give expeted?
# [19:15] <dael> MaRakow: What seems to me is the scenario between the text and bg where it's splitting.
# [19:15] <dael> smfr: But you have to impl that.
# [19:15] <dael> MaRakow: I wouldn't say we enjoy that.
# [19:15] * dbaron notes RRSAgent logging appears to be broken
# [19:15] <dael> florian: TabAtkins any thoughts from google?
# [19:15] <dael> vollick: I have a preference to the proposal from smfr.
# [19:16] <dael> krit: That proposal is more what users would expect if they understand Z index.
# [19:16] <dael> smfr: WE may have to do impl experements and come back.
# [19:16] <dael> krit: So does he obj to your model?
# [19:16] * plinss csswg_logbot, pointer?
# [19:16] * CSSWG_LogBot http://log.csswg.org/irc.w3.org/css/2014-10-28/#e486422
# [19:16] <dael> smfr: He agreed with my comment where it wuld force impl to output more memory.
# [19:16] <dael> smfr: Maybe impl can be smart and know if they won't intersect.
# [19:17] <dael> smfr: I guess with animations it's hard.
# [19:17] <dael> MaRakow: Does this do that much if everything is in the same 3d rendering context?
# [19:17] <dael> smfr: It's hard to know compat risk b/c impl are different. For webkit I intend to only do this for unprefixed, but other browsers don't have that luxury.
# [19:18] <dael> krit: WE created a lot of tests to observe behavior and for many tests, each browser was completely different. Current can't align.
# [19:18] <dael> MaRakow: Previous design that required you to declare here's where the content is, I'm hesitant to give that aspect up because it makes it easier to think of 3D and makes it more backage.
# [19:19] <dael> smfr: It's easy in current but existing conent might have issues. Making transform style inherit might solve.
# [19:19] <dael> MaRakow: In the new model you might have to wrap in a container div
# [19:19] <dael> smfr: The perspective prop calls it flatting too so you end up with three contexts. I don't think compat risk is too bad
# [19:19] <dael> MaRakow: I'd like to explore inheritence more.
# [19:19] <dael> smfr: Okay.
# [19:19] <dael> smfr: Other feedback?
# [19:20] * Quits: alant (~alant@public.cloak) (Ping timeout: 180 seconds)
# [19:20] * Joins: Rossen_ (~Rossen@public.cloak)
# [19:20] <dael> Bert: It's complex. I've given tutorials, but perspective is weird. What I never succeed is transform style. ou try it and it doesn't work the expected way.
# [19:20] <dael> smfr: That's b/c existing impl isn't constant. The new spec is more specific and the scope is limited.
# [19:20] <dael> Bert: Why do I need it
# [19:21] <dael> smfr: Hirearcies of elemnts with 3D elements. YOu often do syblins and you don't need transform style. If you want a decendant of a face of a cube to have it's own transform you need it.
# [19:21] * Quits: Nishanth_IA (~Nishanth_IA@public.cloak) (Ping timeout: 180 seconds)
# [19:21] <dael> smfr: If you think of it like CSS Stacking, a transform is like z-index 0 it causes flattening, but you can override with preserve 3d.
# [19:21] <dael> Bert: So if you take a cube and make it roate, the cube disappears.
# [19:22] <dael> smfr: You'd want preserve 3d on the container. There's subtilty, it's about making an element not flatten. It allows its decendants to share the 3d space it lives in.
# [19:22] <dael> smfr: There's a lot of content about preserve 3d for perspective, but you oly need it on decendants.
# [19:23] <dael> smfr: You don't need preserve 3d on the root of a 3d scene.
# [19:23] <dael> plinss: If I have a minor compent and I want to to participate and it has a random ancestor, I need to set the perserve on the ancestor, not the child. I get technically why, but as an author you want the other way around.
# [19:24] <dael> smfr: We have the opacity prop that forces stacking b/c the way it's speced you ender the decendants opaquely. Preseve 3d is render with the opacity and then combine. We don't have that for opacity, but that's the equivellen.
# [19:24] * Quits: bobtung (~bobbytung@public.cloak) (bobtung)
# [19:24] <dael> plinss: That's the way it should have worked, bt the other is cheaper.
# [19:24] <dael> MaRakow: From the author perspective, I think they're used to it being 2D and when your'e 3D you're asking to flatten at a certain point.
# [19:25] <plinss> s/author you want/author you may want/
# [19:25] <dael> smfr: IN the new sib transforms will intersect. I think it's the correct behaviour. It's a change, but I found it hard to write text to formalize the other behaior
# [19:26] <dael> MaRakow: I think that's true for members of the same scene from an author perspective. I think it makes sense for those to intersect.
# [19:26] * Joins: glenn (~gadams@public.cloak)
# [19:26] <dael> MaRakow: That's weirder is the cases where they intent to isolate and it happens it's near other content that they thought of as 2D, but now it intersects.
# [19:26] <dael> smfr: So you're concerned about intersection with?
# [19:26] <dael> MaRakow: I thinkt he author doesn't tink of the non 3d section being part of the transform.
# [19:27] <dael> smfr: So you'd prefer the 2nd?
# [19:27] <dael> MaRakow: I think they should be capable of intersecting, but that's not te default expectation.
# [19:28] <dael> smfr: I think the choice between the two of if you get depth sorting by default, the pro is it's more like z-inder and more consistent of a default, but it's more resource requiring and may have unexpected intersect. Also 2D transforms don't interact in the same way as 3D.
# [19:28] <dael> smfr: IN our impl some decendant with something special wills tart intersecting and we'll have to turn it off in a funny way
# [19:28] <dael> MaRakow: I don't have a strong opinion, ut if the feedback is I'm not sure which, I think we should avoid the intersection.
# [19:28] <dael> smfr: I think the feedback will go away.
# [19:29] <dael> smfr: Other comments?
# [19:29] <dael> krit: In this case you spec on the container itself. I think I would expect it to intersect the text by default
# [19:29] * sgalineau is behind on quite a few fragmentainer shots
# [19:29] <dael> plinss: It seems like a reasonable default. I think you should let the author opt,bti u t makes sense.
# [19:30] <dael> smfr: I think flippers and stuff will still work as expected.
# [19:30] <smfr> https://wiki.csswg.org/spec/intersection-of-transformed-and-untransformed-elements
# [19:30] <dael> krit: You're unsure if an author thinks it's better to have intersection?
# [19:30] <dael> MaRakow: I think the main thing is as an author I don't expect everything in my page to participate in 3D.
# [19:30] <dael> krit: In this case?
# [19:30] <dael> MaRakow: I'm not sure. I have to go figure out.
# [19:31] <dael> smfr: We've seen people put perspective on the body, but mostly they want a 3d scene.
# [19:31] <dael> MaRakow: It's hard to think about it in terms of test cases because I'm not sure about more active applications. Have you guys impl this?
# [19:31] <dael> smfr: I've done part. transform style auto value, but not the intersection.
# [19:31] <dael> MaRakow: Feedback?
# [19:31] <dael> smfr: Great.
# [19:31] <dael> plinss: So are you looking for a resolution?
# [19:32] <dael> smfr: Looking for impl and author feedback.
# [19:32] <dael> krit: MaRakow do you want to look at it again?
# [19:32] <dael> MaRakow: Sure. It's like to see what your results are.
# [19:32] <dael> plinss: More transforms?
# [19:33] * Joins: tantek_ (~tantek@public.cloak)
# [19:33] <dael> plinss: Everything else folks wanted in the afternoon.
# [19:33] <dael> plinss: What about animations?
# [19:33] <dael> Rossen_: sylvaing wanted that.
# [19:33] <dael> smfr: I think we wanted to do that at 3pm.
# [19:33] <dael> fantasai: Text?
# [19:33] <dael> Topic: Text
# [19:33] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [19:34] <dael> fantasai: Let me pull up notes. The main issue was the justification where' I'd want koji.
# [19:34] <dael> fantasai: Other stuff is as I was cleaning handling of Korean, I noticed we have text saying just method depends on lang conventions. We need to havei t say writing system and convention.
# [19:35] <dael> fantasai: Many languages can be written in multiple writing systems. The correct layout isn't only language. Mongolian, Japanese, Turkish.
# [19:35] <dael> fantasai: So if anyone has comments or concerns about that let me know, if not I'll take a resolution to update the spec.
# [19:36] <fantasai> s/only language/only language-dependent/
# [19:36] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [19:37] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [19:37] * Joins: Cyril_ (~chatzilla@public.cloak)
# [19:37] <dael> morimoto: For korean and hangul, all the text didn't have word spacing. and it's not sufienct to distinguish modern and older hangul text. And the lang attr cannot be used. I think the text justify property is needed for distingushing modern and older style hangul.
# [19:37] * Joins: emalasky (~Adium@public.cloak)
# [19:37] <dael> fantasai: I think old style hangul is only hangul, correct? Doesn't include latin?
# [19:37] * Joins: tantek (~tantek@public.cloak)
# [19:37] <SimonSapin> s/morimoto/murakami/
# [19:38] <dael> murakami: I don't think too much hangul, but I think the word text was used in 1896. Before then, Hangul text did not have word spacing.
# [19:38] <dael> fantasai: If the text does not inc latin, then inter-character is suffiecent. If we need to worry about lating, we need inter-idiographic.
# [19:39] <dael> murakami: I think it's needed.
# [19:39] <dael> fantasai: I think for right now it's enough of an edge case we should address it in the next level. IN general it can be worked around with intercharacter value unless it's mixed script. In that case we'd need to look at reintroducing interidiograph
# [19:40] <dael> murakami: INtercharacter isn't good for all hangul. The latin letters may be included in all hangul text.
# [19:40] <dael> TabAtkins: Is ther much old hangul on the web?
# [19:40] * Joins: bobtung (~bobbytung@public.cloak)
# [19:40] <dael> murakami: I don't know very much, but some examples I posted on the ML.
# [19:41] <dael> murakami: Not I. Someone else.
# [19:41] * Quits: Cyril (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [19:41] * Cyril_ is now known as Cyril
# [19:41] <dael> fantasai: I think someone said they were wrong.
# [19:41] <dael> TabAtkins: The KL examples were pretty wrong.
# [19:42] * Quits: tantek_ (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [19:42] <dael> fantasai: I don't have a trong opinion, but I think jdagget does. I think we should take justification up when he calls later today.
# [19:43] <dael> fantasai: I think we should come back to this and resolve on effects being writing system and language dependant.
# [19:43] <dael> fantasai: Any concerns with that issue?
# [19:43] <dael> RESOLVED: layout method should depend on writing system in addition to language convention
# [19:43] <dael> fantasai: The rest needs to be afternoon.
# [19:44] * Quits: jrossi (~jrossi@public.cloak) (Ping timeout: 180 seconds)
# [19:44] <dael> fantasai: I think andreyr had a selection issue?
# [19:44] <dael> Topic: Selection issue
# [19:44] <dael> andreyr: WE discussed in France, but fantasai put together the spec. The grammer and spelling squiggly lines, we wanted to control that color.
# [19:45] <dael> andreyr: We asked to add it to the spec. Andy objections or opinions?
# [19:45] <dael> florian: It was mentioned that there are security concerns, but it can be handled as long as we're careful
# [19:45] <dael> TabAtkins: You're limited to only color prop. things that don't affect layout.
# [19:46] <dael> fantasai: Add ::spelling-error and ::grammar-error and have it follow restrictions in layout model of ::selection and add additional security verbage
# [19:46] <dael> plinss: Do we want distinct pseudo-element or a functional one?
# [19:46] <dael> plinss: I'm just curios
# [19:46] <dael> andreyr: I don't have an opinion
# [19:46] <dael> fantasai: I don't have much of one. We already have selection.
# [19:46] * Joins: murakami (~murakami@public.cloak)
# [19:47] * Quits: iank (~iank@public.cloak) (Ping timeout: 180 seconds)
# [19:47] <liam> [ is the squiggly line already a text-decoration value? ]
# [19:47] <dael> plinss: I'm thinking of other uses like annotations. I'm wondering if it's extensibility point, or do we add more names?
# [19:47] <dael> fantasai: I think we're anames either way.
# [19:47] <dael> plinss: Is it the full scope or a limited scope. It's something to consider.
# [19:47] * Quits: Shige (~Shige@public.cloak) (Ping timeout: 180 seconds)
# [19:48] <astearns> liam: yes. wavy: http://www.w3.org/TR/css-text-decor-3/#text-decoration-style-property
# [19:48] <SimonSapin> liam, yes, 'wavy' http://dev.w3.org/csswg/css-text-decor/#propdef-text-decoration-style
# [19:48] * liam :)
# [19:48] <dael> fantasai: Full pseudo-element space for now. If we find a need to abstract it we have time. There was discussion of having custom, that would need to be encapsulated. For these in the browser they won'tbe customer. Having the outlined not in that scope is a good idea.
# [19:48] <liam> [ thanks, slthough does this let you colour it differently from the text?? ]
# [19:48] <dael> fantasai: WE won't be mixing custom and pseudo which is a good idea.
# [19:48] <dael> plinss: Adding to what?
# [19:48] <dael> TabAtkins: pseduo-elements
# [19:48] <SimonSapin> liam, text-decoration-color
# [19:49] <dael> plinss: Wasn't pseduo-elements abandoned for a while?
# [19:49] <dael> TabAtkins: Didn't we just revive it?
# [19:49] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [19:49] * liam ah, with text-decoration-color, ok
# [19:49] <dael> fantasai: Yes. the plan is work in the meeting, do more testing, then post to www-style, ask for reviews, and then ask for FPWD
# [19:49] <dael> SimonSapin: What are the security issues?
# [19:49] * liam thanks
# [19:49] <dael> fantasai: That exposes history, this exposes your dictionary.
# [19:50] <dael> TabAtkins: It' a fingerprinting link.
# [19:50] <dael> plinss: WE need to care about thos. Also in thing like OSX your address book gets added to your dictionary, so it's def a security thing.
# [19:50] <dael> plinss: Even if you want to say fingerprinting is a lost cause, you don't want to open the surface error. You don't want to say I don't care about fingerprinting.
# [19:50] <SimonSapin> s/That/:visited/
# [19:51] <dael> TabAtkins: But once I can be fingerprinted more doesn't hurt.
# [19:51] <dael> plinss: It's a different set of values. And there are folks working on fingerprinting.
# [19:52] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [19:52] <dael> florian: It was pointed out yesterday we made a resolution on elipsisw ith two values we said start/end instead of left right, given that a fairly reasonable useage is arrows, we may want direction.
# [19:52] * Joins: iank (~iank@public.cloak)
# [19:52] <dael> fantasai: That's why the spec currently has left/right
# [19:52] <dael> florian: The other arguement is there are some things that do flip
# [19:52] * Joins: jrossi (~jrossi@public.cloak)
# [19:53] <dael> fantasai: We have line-left and line-right. It should be physical and mozilla impl that.
# [19:53] <dael> florian: It's that or let the author pick what he needs.
# [19:53] <dael> plinss: Are there use cases in both ways?
# [19:53] <dael> fantasai: I've seen elipsis and arrow, I haven't seen start and end different
# [19:53] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [19:54] <dael> florian: If you go with parens they mirror, but you prob don't want to. The reasonable use cases don't need that and we could later have a syntax to let you say start/end.
# [19:54] * Joins: jcraig (~jcraig@public.cloak)
# [19:54] * Joins: dauwhe (~dauwhe@public.cloak)
# [19:54] <dael> florian: We also pointed out that it was inconsistant, but when you have a value it applying to end makes sense.
# [19:54] <dael> florian: So it stays inconsistant. It's not clean but sounds practical.
# [19:54] <dael> plinss: In my mind i'm thinking when it shows up is logical, but which one we choose is phsyical.
# [19:55] <dael> fantasai: It depends on scroll position. Initial scroll state is logical.
# [19:55] <dael> TabAtkins: It depends on if it's overflowing this end.
# [19:55] <dael> plinss: In the single value case you're not spec the end, it's just a value with whereever there's ovrflow.
# [19:55] <dael> florian: I think you spec end. I'm not sure you should, but that's what it says.
# [19:56] <dael> plinss: So you explicitly don't get an elipsis on the other side if you only have one value. You never get one on the start end.
# [19:56] <dael> florian: If there is one value it only applies to end line edge.
# [19:56] <dael> fantasai: Whatever is there is prob right.
# [19:56] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [19:56] <dael> plinss: Is that what we want?
# [19:56] * Joins: dauwhe (~dauwhe@public.cloak)
# [19:56] <dael> fantasai: Given that the one value has a lot of use, we can't change a whole lot. There's silliness already like you have to spec overflow not visiable. That's the behavior we're stuck with.
# [19:57] <dael> florian: So do we agree to replace yesterday's resolution with line-left and line-right?
# [19:57] <dael> RESOLVED: replace yesterday's resolution for start/end with line-left and line-right
# [19:57] <dael> Topic: Counter Styles
# [19:57] <dael> fantasai: It's in LC. Any open issues? If not, lets go to CR?
# [19:58] <dael> TabAtkins: One issue was about a handful of styles that browsers have impl but weren't in the draft since we cut it down. I add the ones with high interop.
# [19:58] <dael> TabAtkins: About 20 styles that are impl since they are dependable for authors
# [19:58] <dael> TabAtkins: The ones that aren't clear is the Tamil style is only FF.
# [19:59] <TabAtkins> afar, oromo, sidama, tigre
# [19:59] <dael> florian: For the 20 you talked about, you said reasonable, is that 2 or more?
# [19:59] <dael> TabAtkins: 2 or more.
# [19:59] <dael> TabAtkins: The list above is supported by the browsers with roots in webki.
# [20:00] <dael> TabAtkins: My opinion is to not put them and recommend that they're removed for consistancy. It's still in the original document. So, yea or nay on that. Keep the ones that are impl my more than one browser.
# [20:00] <dael> TabAtkins: I'll ask for removal with bugs.
# [20:00] * Quits: ArronEi (~ArronEi@public.cloak) (Ping timeout: 180 seconds)
# [20:00] * Joins: Cyril_ (~chatzilla@public.cloak)
# [20:00] <dael> plinss: Is that what we want?
# [20:00] <dael> TabAtkins: Yeah. If you do the author definition, you don't need the one ot be in FF
# [20:00] <dael> plinss: Other opinions?
# [20:01] <dael> Bert: Can you repeat the ones you keep?
# [20:01] <dael> TabAtkins: It's long. If you find the list in the archives there's a list from Richard Ishida of the additional values supported by FF and webkit derived.
# [20:01] * Joins: iank_ (~iank@public.cloak)
# [20:01] <dael> TabAtkins: All the values are in the spec right now.
# [20:02] <dael> TabAtkins: The ones that are one browser are in the minutes above.
# [20:02] <dael> florian: Are we confident they're right?
# [20:02] <dael> TabAtkins: Richard has been testing and he's confident.
# [20:02] * Joins: glenn (~gadams@public.cloak)
# [20:02] <dael> florian: We pushed them our because we aren't sure. HOpefully the match what speakers would expect. If that's true I'm happy witht he spec.
# [20:02] * Joins: koji (~koji@public.cloak)
# [20:03] <dael> TabAtkins: It's just listing them. They can be fixed in the future.
# [20:03] <dael> florian: One reason we're pushing in this direction is to avoid time discussing languages we don't udnerstand.
# [20:03] * Quits: iank (~iank@public.cloak) (Ping timeout: 180 seconds)
# [20:03] <dael> plinss: But it's not all browsers.
# [20:03] * Quits: vollick (~vollick@public.cloak) (Ping timeout: 180 seconds)
# [20:03] <dael> TabAtkins: Everybody by IE which is pretty close
# [20:04] <bradk_> "Archived-At" header shows where an e-mail is archived for Web access
# [20:04] <dael> TabAtkins: If no one objects we can keep the list of 2+ browser supported languages and not have the 1 browser suppoted.
# [20:04] <TabAtkins> RESOLVED: Add to Counter Styles the additional styles supported by 2+ browsers (per r12a's email), do not add the styles supported by only one browser.
# [20:04] <dael> TabAtkins: That's the only e-mail from counter styles since the LC announcement.
# [20:05] <dael> TabAtkins: So given that I've made the change in the ED can we go to CR?
# [20:05] * Joins: vollick (~vollick@public.cloak)
# [20:05] <dael> Bert: Go for it!
# [20:05] * Quits: notbenjamin (~textual@public.cloak) ("My MacBook Pro has gone to sleep. ZZZzzz…")
# [20:05] <dael> TabAtkins: This has to be old process CR.
# [20:05] * Quits: Cyril (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [20:05] <dael> fantasai: I think you should be able to go into the new.
# [20:05] <dael> florian: We siad it wasn't clear if you can do it with this.
# [20:05] <dael> TabAtkins: I think we can just do it.
# [20:05] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [20:05] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [20:06] <dael> plinss: I think the doc says if you're in LC you cannot switch tot he new process.
# [20:06] <dael> fantasai: We've fulfilled the old process req.
# [20:06] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [20:06] <dael> plinss: Let's resolved to take counter styles to CR and go to the new process if we can.
# [20:06] <dael> TabAtkins: So obj to pub under some form of CR?
# [20:07] <dael> RESOLVED: take counter styles to CR and go to the new process if we can.
# [20:07] <dael> plinss: I propose we break until 2pm.
# [20:07] <murakami> s/all hangul/old hangul/
# [20:07] <dael> [lunch break until 2pm]
# [20:07] * Quits: bobtung (~bobbytung@public.cloak) (bobtung)
# [20:07] * Quits: smfr (~smfr@public.cloak) (smfr)
# [20:07] * Quits: florian (~Florian@public.cloak) ("Leaving.")
# [20:07] * Quits: dael (~dael@public.cloak) ("Page closed")
# [20:08] * Joins: jcraig_ (~jcraig@public.cloak)
# [20:08] * Quits: dino (~textual@public.cloak) ("My MacBook Pro has gone to sleep. ZZZzzz…")
# [20:08] * Quits: bradk_ (~bradk@public.cloak) ("Be back later ...")
# [20:08] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [20:08] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [20:08] * Quits: MaRakow (~MaRakow@public.cloak) ("Page closed")
# [20:09] * Joins: nvdbleek3 (~nvdbleek@public.cloak)
# [20:10] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [20:10] * Joins: zcorpan (~zcorpan@public.cloak)
# [20:11] * Quits: Cyril_ (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [20:12] * Joins: ChrisL (clilley@public.cloak)
# [20:12] * Quits: vollick (~vollick@public.cloak) (Ping timeout: 180 seconds)
# [20:12] * Quits: iank_ (~iank@public.cloak) (Ping timeout: 180 seconds)
# [20:12] * Quits: jcraig (~jcraig@public.cloak) (Ping timeout: 180 seconds)
# [20:12] * jcraig_ is now known as jcraig
# [20:13] * Quits: nsakai2 (~nsakai2@public.cloak) (Ping timeout: 180 seconds)
# [20:13] * Quits: nvdbleek (~nvdbleek@public.cloak) (Ping timeout: 180 seconds)
# [20:13] * nvdbleek3 is now known as nvdbleek
# [20:13] * Quits: Mike_Miller (~mike@public.cloak) (Ping timeout: 180 seconds)
# [20:14] * Quits: hiroto (~hiroto@public.cloak) (Ping timeout: 180 seconds)
# [20:14] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [20:15] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [20:15] * Quits: shans__ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [20:16] * Quits: song (~song@public.cloak) (Ping timeout: 180 seconds)
# [20:17] * leaverou is now known as leaverou_away
# [20:17] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [20:19] * Quits: andreyr (~andreyr@public.cloak) (Ping timeout: 180 seconds)
# [20:19] * Quits: jrossi (~jrossi@public.cloak) (Ping timeout: 180 seconds)
# [20:22] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [20:24] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [20:25] * Quits: KeshavP (~KeshavP@public.cloak) (Ping timeout: 180 seconds)
# [20:26] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [20:27] * Quits: shepazu (schepers@public.cloak) ("is sleepy")
# [20:27] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [20:29] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [20:30] * Quits: glazou (~glazou@public.cloak) (glazou)
# [20:32] * Quits: tantek (~tantek@public.cloak) (tantek)
# [20:34] * Quits: kurosawa (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [20:36] * Quits: emalasky (~Adium@public.cloak) ("Leaving.")
# [20:44] * Joins: glenn (~gadams@public.cloak)
# [20:45] * Joins: florian (~Florian@public.cloak)
# [20:46] * Joins: smfr (~smfr@public.cloak)
# [20:48] * Quits: smfr (~smfr@public.cloak) (smfr)
# [20:52] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [20:52] * Parts: ChrisL (clilley@public.cloak) (Leaving)
# [20:57] * Joins: glenn (~gadams@public.cloak)
# [20:58] * Joins: jrossi (~jrossi@public.cloak)
# [21:03] * Joins: KeshavP (~KeshavP@public.cloak)
# [21:03] * Quits: kip (~kip@public.cloak) (Client closed connection)
# [21:03] * Joins: emalasky (~Adium@public.cloak)
# [21:03] * Joins: kip (~kip@public.cloak)
# [21:04] * Quits: florian (~Florian@public.cloak) ("Leaving.")
# [21:07] * Joins: jdaggett (~jdaggett@public.cloak)
# [21:07] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [21:08] * Joins: jdaggett (~jdaggett@public.cloak)
# [21:08] * leaverou_away is now known as leaverou
# [21:08] * Joins: dauwhe (~dauwhe@public.cloak)
# [21:10] * Joins: notbenjamin (~textual@public.cloak)
# [21:10] * Quits: kip (~kip@public.cloak) (Ping timeout: 180 seconds)
# [21:10] * Quits: notbenjamin (~textual@public.cloak) ("My MacBook Pro has gone to sleep. ZZZzzz…")
# [21:11] <jdaggett> what time are things scheduled to start again?
# [21:11] * Joins: emalasky1 (~Adium@public.cloak)
# [21:12] * Joins: smfr (~smfr@public.cloak)
# [21:15] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [21:16] * jdaggett goes back to musing about ancient hangul on the web
# [21:16] * Joins: myakura (~myakura@public.cloak)
# [21:17] * Joins: emalasky2 (~Adium@public.cloak)
# [21:17] * Quits: emalasky1 (~Adium@public.cloak) (Client closed connection)
# [21:17] * Quits: emalasky (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [21:18] * leaverou is now known as leaverou_away
# [21:18] * Joins: florian (~Florian@public.cloak)
# [21:19] * Joins: bradk_ (~bradk@public.cloak)
# [21:19] * Joins: stakagi (~stakagi@public.cloak)
# [21:22] <SimonSapin> jdaggett: 2 pm, in ~40 minutes
# [21:22] <jdaggett> ok, cool, thanks!
# [21:22] <jdaggett> got up at 5am for nothing... :P
# [21:23] * Joins: KeshavP_ (~KeshavP@public.cloak)
# [21:24] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [21:24] <dholbert> jdaggett, got up at 5am for musing about ancient hangul!
# [21:24] <jdaggett> dholbert: got i hate those mornings...
# [21:25] <jdaggett> s/got/god/
# [21:25] * Joins: jcraig (~jcraig@public.cloak)
# [21:26] * Quits: bradk_ (~bradk@public.cloak) (Ping timeout: 180 seconds)
# [21:26] * Quits: KeshavP (~KeshavP@public.cloak) (Ping timeout: 180 seconds)
# [21:27] * Joins: bobtung (~bobbytung@public.cloak)
# [21:29] * Joins: glazou (~glazou@public.cloak)
# [21:29] * Quits: glazou (~glazou@public.cloak) (glazou)
# [21:31] * Joins: glazou (~glazou@public.cloak)
# [21:31] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [21:31] * Joins: kurosawa (~chatzilla@public.cloak)
# [21:32] * Joins: iank (~iank@public.cloak)
# [21:32] * Quits: bobtung (~bobbytung@public.cloak) (bobtung)
# [21:32] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [21:33] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [21:34] * Zakim excuses himself; his presence no longer seems to be needed
# [21:34] * Parts: Zakim (zakim@public.cloak) (Zakim)
# [21:34] * Joins: dauwhe (~dauwhe@public.cloak)
# [21:34] * Joins: bradk_ (~bradk@public.cloak)
# [21:35] * Joins: kip (~kip@public.cloak)
# [21:36] * Quits: kip (~kip@public.cloak) (Client closed connection)
# [21:36] * Joins: kip (~kip@public.cloak)
# [21:36] * Quits: emalasky2 (~Adium@public.cloak) (Client closed connection)
# [21:36] * Joins: emalasky (~Adium@public.cloak)
# [21:36] * Joins: tantek (~tantek@public.cloak)
# [21:37] * Joins: jcraig (~jcraig@public.cloak)
# [21:39] * Joins: stakagi (~stakagi@public.cloak)
# [21:42] * Joins: emalasky1 (~Adium@public.cloak)
# [21:42] * Quits: emalasky (~Adium@public.cloak) (Client closed connection)
# [21:42] * Joins: zcorpan (~zcorpan@public.cloak)
# [21:43] * Joins: Cyril (~chatzilla@public.cloak)
# [21:44] * Joins: andreyr (~andreyr@public.cloak)
# [21:45] * Joins: shepazu (schepers@public.cloak)
# [21:45] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [21:46] * Joins: tantek (~tantek@public.cloak)
# [21:46] * Joins: murakami (~murakami@public.cloak)
# [21:47] * Quits: florian (~Florian@public.cloak) ("Leaving.")
# [21:47] * Parts: emalasky1 (~Adium@public.cloak) (emalasky1)
# [21:48] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [21:48] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [21:49] * Joins: ArronEi (~ArronEi@public.cloak)
# [21:50] * Joins: hiroto_ (~hiroto@public.cloak)
# [21:52] * Joins: dael (~dael@public.cloak)
# [21:52] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [21:53] * Quits: jrossi (~jrossi@public.cloak) (Ping timeout: 180 seconds)
# [21:54] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [21:56] * Joins: shepazutu (schepers@public.cloak)
# [21:57] * Joins: shans__ (~shans@public.cloak)
# [21:58] * fantasai isn't sure what to do about ancient Hangul
# [21:58] * Joins: florian (~Florian@public.cloak)
# [21:59] * Joins: stakagi (~stakagi@public.cloak)
# [22:01] <jdaggett> leave it for the ancients?
# [22:01] * Joins: bobtung (~bobbytung@public.cloak)
# [22:01] * Joins: adenilson (~anonymous@public.cloak)
# [22:02] * Joins: stakagi_ (~stakagi@public.cloak)
# [22:02] * Joins: nsakai2 (~nsakai2@public.cloak)
# [22:02] * Joins: jrossi (~jrossi@public.cloak)
# [22:02] * Quits: shepazu (schepers@public.cloak) (Ping timeout: 180 seconds)
# [22:02] * shepazutu is now known as shepazu
# [22:03] * Quits: andreyr (~andreyr@public.cloak) (Ping timeout: 180 seconds)
# [22:03] * Joins: andreyr (~andreyr@public.cloak)
# [22:04] <fantasai> jdaggett: works for me
# [22:04] <jdaggett> :P
# [22:04] * Joins: song (~song@public.cloak)
# [22:05] <fantasai> I think what we're looking at is, if you want to handle such documents, either we need to add back 'inter-ideograph' or 'inter-cluster', or they have to use 'inter-character'
# [22:05] <fantasai> well, actually, nevermind
# [22:05] <glazou> jdaggett: rofl
# [22:05] <fantasai> if there's no spaces, they'll space out
# [22:05] * Joins: dbaron (~dbaron@public.cloak)
# [22:06] <dael> Bert: Is everyone here, shall we start?
# [22:06] * fantasai wonders what jdaggett thinks about default justification
# [22:06] * fantasai for untagged content
# [22:06] * dauwhe http://dev.w3.org/csswg/css-text-1896/
# [22:06] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [22:06] <dael> Topic: Fonts
# [22:06] <dael> Bert: I guess we need jdaggett. Can someone ping him to call?
# [22:06] <dbaron> Zakim, room for 3?
# [22:06] <jdaggett> need to dial in
# [22:07] * Joins: Zakim (zakim@public.cloak)
# [22:07] * Joins: dino (~textual@public.cloak)
# [22:07] <dbaron> Zakim, room for 3?
# [22:07] <Zakim> ok, dbaron; conference Team_(css)21:06Z scheduled with code 26633 (CONF3) for 60 minutes until 2206Z
# [22:07] <dbaron> Zakim, call SantaBarbara
# [22:07] <Zakim> ok, dbaron; the call is being made
# [22:07] <Zakim> Team_(css)21:06Z has now started
# [22:07] <Zakim> +SantaBarbara
# [22:07] * Joins: ChrisL (clilley@public.cloak)
# [22:07] <dael> TabAtkins: While we wait, richard pointed out we didn't create a time for CR for counter styles.
# [22:07] <dael> Bert: What time? We do 6 or 3 months
# [22:07] <dael> TabAtkins: 3 months?
# [22:07] <dael> ChrisL: You can always take longer.
# [22:07] <jdaggett> so dial into zakim and do what?
# [22:07] <dbaron> Zakim, code?
# [22:07] <Zakim> the conference code is 26633 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), dbaron
# [22:07] <dbaron> jdaggett, ^
# [22:08] <dael> RESOLVED: 3 months for counter styles CR
# [22:08] <Zakim> +[IPcaller]
# [22:08] <bradk_> http://tldr.someecards.com/wiki/gavel/
# [22:08] <dbaron> Zakim, [IPcaller] is jdaggett
# [22:08] <Zakim> +jdaggett; got it
# [22:08] <dael> Bert: So fonts. First subtopic...
# [22:09] * leaverou_away is now known as leaverou
# [22:09] <dael> ChrisL: It's osmething jdaggett thought we didn't need to.
# [22:09] <dael> Bert: Classification of Kai as cursive.
# [22:09] <dael> jdaggett: I took it out of the draft
# [22:09] <dael> fantasai: I think they'd like it to be reliably returned.
# [22:09] * Joins: kuettel (~kuettel@public.cloak)
# [22:09] <dael> jdaggett: I had some people say serif too. It'snot an interesting debate for CSS.
# [22:09] <dael> Bert: What are the downsides of leaving it out.
# [22:10] <dael> jdaggett: I took any reference out and I don't think we should delare it either way. The spec was just listing examples and if there's controversy we should leave it out.
# [22:10] <dael> ChrisL: I agree. If there's differences it shouldn't be an example.
# [22:10] <dael> jdaggett: Okay.
# [22:11] * Joins: plh (plehegar@public.cloak)
# [22:11] <dael> rbyers: My understanding is that the Chinese wanted to get to somewhere when it would give you something like Kai if you select cursive. They'd like to know a way to influence it to get the correct font.
# [22:11] <Bert> s/rbyers/r12a/
# [22:12] <dael> jdaggett: Stepping away from Chinese, the generic cursive is somewhat useless because i can be all manner of things. It's prob not used that much. It's a random font that looks scripty.
# [22:12] <dael> ChrisL: Good examples?
# [22:12] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [22:12] * Joins: myakura (~myakura@public.cloak)
# [22:13] <dael> fantasai: Problem is Chinese use things like a Kai font in a similar was to a roman font vs an italic. WE need a generic way for the distintion where you don't lose the semantic. They need a way to switch without providing their own font. It's about I need to express stylistic difference.
# [22:13] * Joins: notbenjamin (~textual@public.cloak)
# [22:13] <dael> jdaggett: The underlying problem is we don't have availability on, you don't have kai style font on every system. These sorts aren't available across platforms so as a generic it's not useful.
# [22:14] * Joins: dbaron (~dbaron@public.cloak)
# [22:14] <dael> ??: There's Kai on Microsoft on iOS, it's Android that doesn't have Kai or Ming. It's important in ebooks, such as Chinese. We usually use the Kai for citations, quotations, and dialog.
# [22:14] <dauwhe> s/??/bobtung/
# [22:14] <dael> florian: And you're saying it might not be universal, but it's common.
# [22:14] <dael> bobtung: Many of them.
# [22:14] <dael> Bert: I'm not hearing progress.
# [22:15] <dael> fantasai: I think it comes down ot we say either we don't care about your problem, or we say we'll classify Kai as cursive and use cursive vs serif as a way to switch. Or we decide we'll do something with font style and add a kai keyword.
# [22:15] <dael> fantasai: I'm inclined to not do the first option. It should be expessible in a generic way.
# [22:15] <dael> florian: What's wrong with creating a Kai catagory.
# [22:16] <dael> ChrisL: You have to decide what happens when you use it for another language.
# [22:16] <dael> jdaggett: To put this in a diff context, I think every script has a diff set of typographic decisions. There are broad catagories to classify fonts. I think it's not really helpful for CSS to try and use generics to classify.
# [22:16] * Joins: Rossen_ (~Rossen@public.cloak)
# [22:17] <dael> jdaggett: The idea of a generic is you can use it across systems and it's consistent. I don't think in this case or any of the other cases, like flatserif.
# [22:17] * Joins: weinig (~weinig@public.cloak)
# [22:17] <ChrisL> s/flats/slabs/
# [22:17] <dael> fantasai: I'm not in favor of inc # of generics. I think we need the very broad catagories we have and they serve as a generic fallback font family. I think we should solve this specific problem by classifying it as cursive or italic or making it a new font style value.
# [22:18] <dael> r12a: So you're saying you'd take Kai out of the serif?
# [22:18] * Quits: jrossi (~jrossi@public.cloak) (jrossi)
# [22:18] * leaverou is now known as leaverou_away
# [22:18] <dael> jdaggett: I don't think CSS is the right place to make this decision. It doesn't make sense for us to enter this debate.
# [22:19] <dael> r12a: The proposal was from a Chinese group for pub industry was that Kai was in the wrong place. I'm asking do you want to keep Kai under serif catagory or will you take it out?
# [22:19] <dael> fantasai: He's already done that.
# [22:19] <dael> r12a: That's fine.
# [22:19] <dael> fantasai: That doesn't solve the publishing industry's problem.
# [22:19] <dael> jdaggett: I think you need font availability consistent across platforms and you don't have that, particularly on mobile.
# [22:20] * Joins: jrossi (~jrossi@public.cloak)
# [22:20] <dael> florian: I don't think this group should go with a large effort, but if it's not done here, where?
# [22:20] <dael> Bert: We had two options, a new generic family of Kai wasn't popular. Another option was a font style. Is that reasonable?
# [22:20] <dael> Bert: What would be the downside of that?
# [22:20] <dael> Bert: We're not making progress.
# [22:20] * Joins: patrick_h_lauke (~redux@public.cloak)
# [22:21] <dael> jdaggett: I think this is better on the list with a wider audience that might have knowedlge that applies.
# [22:21] <dael> Bert: No new ideas?
# [22:21] <dael> fantasai: One thing we migh want to resolve is if we're going to address the issue. If we're not we should resolve it now. If we're going to find a solution, then the list is going to be charged with finding a solution
# [22:21] <dael> Bert: So should we try and come up with a solution, or say it's not our business?
# [22:22] <dael> Bert: fantasai says we should solve it.
# [22:22] <dael> bradk_: If we don't solve it will impl do different things?
# [22:22] <dael> fantasai: Or no one doing anything.
# [22:22] <dael> dbaron: So what is the issue? Allowing authors to choose a Kai font?
# [22:22] <dael> ChrisL: Allowing them to say I want two types of fonts, A or B, and they're distinct and it should work for more than Chinese.
# [22:23] <dael> fantasai: That's really vague. I don't think anyone will be satisfied.
# [22:23] <dael> ChrisL: If not that, we should be providing fonts. We're moving that way.
# [22:23] <dael> fantasai: ereaders don't hvae that option. Lots of devices don't so looking at system fonts is a thing.
# [22:24] <dael> fantasai: Chinese is also a pretty big download. If it's generic enough that most Chinese ereaders would have it.
# [22:24] <dael> jdaggett: I think this requires extra knowledge that's not in the room, so I think we should defer to the list.
# [22:24] <dael> Bert: I think we can conclude we won't solve it here, but I want to ask are we going to try and solve it at all or give up.
# [22:25] * ChrisL maybe we could deprecate "fantasy" at the same time
# [22:25] <dael> jdaggett: one condition to solve this, a generic requires common support across devices. If there is common support then having a CSS solution for a generic makes sense, but if you don't have a common support there's not much you can do.
# [22:25] <dael> Bert: And how will we find that out?
# [22:25] <dael> jdaggett: I don't know. Maybe people in the Chinese pub group can come up wtih a list of fonts?
# [22:26] <dael> r12a: We can take this back to the group of publishers who brought this up in Bejing.
# [22:26] <dael> fantasai: We might find the nec fonts won't be on all devices, for EX my windows computer will only likely have one.
# [22:26] <dael> jdaggett: It's more android that you'd worry about.
# [22:26] <dael> fantasai: If it's not targetted at the Chinese market, it won't likely have more than one. If we limit to the Chinese market we might find the availability.
# [22:27] <dael> jdaggett: Hong Kong too or just mainland?
# [22:27] <dael> fantasai: All of them. If you're looking across the world the answer will be no. Will it be on all systems in the target audience, we might get a yes, though maybe a no. If your criteria is all systems everywhere needs to have these fonts, we won't have that.
# [22:28] <dael> Bert: I think we've discussed enough.
# [22:28] * Quits: iank (~iank@public.cloak) (Ping timeout: 180 seconds)
# [22:28] <dael> r12a: bobtung is here and he has a table taht shows the major systems have Kai, serif, an sansserif, but lets go back to the list.
# [22:28] <dael> Bert: So the question is do we want this to go back to the list?
# [22:28] <dael> florian: So list or never or...?
# [22:29] <dael> Bert: Back tot he ML and try and solve it, or should we not try. We won't have a solution right now. Anyone thinking we shouldn't move this to the ML?
# [22:29] <dael> Bert: No one objects, so back to the list ofr a solution.
# [22:29] <dael> fantasai: So the goal is the list will come up with a solution and not entertain not having a solution unless we discover it's intractable.
# [22:29] * Joins: xiaoqian (xiaoqian@public.cloak)
# [22:29] <dael> Bert: Yes. Okay with you jdaggett?
# [22:29] <dael> jdaggett: I'm not really comfortable with it, but we can deal on the ML.
# [22:30] <dael> RESOLVED: Topic goes back to the mailing list
# [22:30] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2014Oct/0472.html
# [22:30] <dael> Topic: Unicode-range issues
# [22:30] * Joins: r12a (rishida@public.cloak)
# [22:30] <dael> jdaggett: This is small impl details about unicode range. Can someone project the link?
# [22:30] <dael> [Trying to find someoe to project]
# [22:31] <dael> jdaggett: If people bring up the link in IRC, unicode-range allows you to say for spec fonts, only download if you're using it for this set of char. Sometiems you're pulling down a font for non-specific character list and instead are pulling down the line metric. So we have 3 fonts we can download, which do we choose
# [22:32] <dael> jdaggett: You can solve this many ways. You can decide on a specific character, on the last font defined, any choice is arbitraty. Chrome looks for the first font that defines a space character.
# [22:32] <dael> jdaggett: Safari and IE claim to support, but their impl pulls down the whole font no matter what so that's not close to spec. Does it make sense to do thiso r is there a better way?
# [22:33] <dael> ChrisL: I agree it's arbitrary and it's more important that we pick something. The space thing is as good as any.
# [22:33] <dael> TabAtkins: Ditto.
# [22:33] * Joins: iank (~iank@public.cloak)
# [22:33] <dael> dbaron: I think it's fine. Some units do depend on a particular character. The x unit can depend on characters, the ch depends on 0. So maybe it should be a 0 character for the ch and space for everything.
# [22:33] <dael> ChrisL: If we're doing arbitrary, why not 0 for everything?
# [22:34] <dael> TabAtkins: I doubt we thought this through much when impl but if you have spaces, you have 0s likely.
# [22:34] <dael> fantasai: Another consideration was one use case you want numbers to line up. 0 will always have the width of the number. Numbers typically are things you want to line up so we wanted to pick from there.
# [22:35] * plinss changes topic to 'https://wiki.csswg.org/planning/tpac-2014#agenda - Zakim code 26633#'
# [22:35] * Joins: kuettel_ (~kuettel@public.cloak)
# [22:35] <dael> jdaggett: Within a font there are a set of non-glyph specific metrics. What I'm getting at is the only thing needed is the general font metrics to pick up a font.
# [22:35] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [22:35] <dael> jdaggett: For fonts that depend ona measurement for a glyph it should be more specific.
# [22:35] <dael> Bert: I'm hearing any character is fine.
# [22:36] <dael> ChrisL: Given that one thing requires 0, I think we should use that.
# [22:36] <dael> dbaron: But if you're doing a thing using actual font metrics, you do this.
# [22:36] <dael> fantasai: WE do use the space to measure how it's tagged.
# [22:36] <dael> ChrisL: Okay. I withdraw that.
# [22:36] <dael> dbaron: I think it's not the question of if it has a space, but if the unicode range for the @font includes a space.
# [22:37] * Joins: iank_ (~iank@public.cloak)
# [22:37] <dael> dbaron: If you were looking for a space and the space was in the unicode range and the font didn't have it you would continue to fall back.
# [22:37] <dael> Bert: So does that give you enough information jdaggett ?
# [22:37] <dael> jdaggett: It seems we can use the space character to use which fonts to look up and I can post the wording change.
# [22:38] <dael> jdaggett: 2nd issue in that e-mail, in situtations with overlapping unicode-ranges, the spec needs to be more specific about loading behavior where you don't want to load all fonts in that family that havea code point. You only want to load one at a time.
# [22:39] * Quits: andreyr (~andreyr@public.cloak) (Ping timeout: 180 seconds)
# [22:39] <dael> jdaggett: If there's some character in the unicode range of two different fonts, you want to pull the first font and test before pulling the second.
# [22:39] <ChrisL> I support the proposed restriction on one concurrent download per font family
# [22:39] <dael> ChrisL: I was about to agree, but what if you have bold, itla and roman.
# [22:40] <dael> jdaggett: No, no. If you look at the match algo where this would go is set 5 where you've already matched to a specific.
# [22:40] * Quits: song (~song@public.cloak) (Ping timeout: 180 seconds)
# [22:40] <dael> ChrisL: that's fine.
# [22:40] * Joins: andreyr (~andreyr@public.cloak)
# [22:40] <dael> Bert: Thoughts on impl? If you're serializing things may slow down
# [22:40] <dael> ChrisL: If you initiate a download of a larger font you'd have o throw it away, so this is saving time
# [22:40] * Quits: iank (~iank@public.cloak) (Ping timeout: 180 seconds)
# [22:40] * Quits: kuettel (~kuettel@public.cloak) (Ping timeout: 180 seconds)
# [22:40] <dael> jdaggett: In the ex you've got a latin and a fallback and you don't want to load fallback unless you really have to.
# [22:40] <dael> Bert: Okay. Different opinions?
# [22:41] <dael> Bert: I see thumbs up.
# [22:41] <jdaggett> resolved: only download a single font per family when unicode-range values overlap
# [22:42] * Quits: hiroto_ (~hiroto@public.cloak) (Ping timeout: 180 seconds)
# [22:42] <dael> jdaggett: Next issue is the proposal from Google.
# [22:42] * Quits: murakami (~murakami@public.cloak) (Ping timeout: 180 seconds)
# [22:42] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2014Oct/0434.html
# [22:42] <jdaggett> https://github.com/igrigorik/css-font-timeout/blob/patch-1/README.md
# [22:42] <dael> TabAtkins: Yes. I will link to...
# [22:42] <dael> Bert: jdaggett did.
# [22:42] <dael> jdaggett: That's the post and the proposal.
# [22:42] * Joins: MaRakow (~MaRakow@public.cloak)
# [22:43] <dael> TabAtkins: Right now browsers do different things handling a font download that's taking a long time. FF and Chrome will display nothing for 3 sec and use the fallback until it comes in. Microsoft immediatly does fallback, Safari shows nothing until the font comes in
# [22:43] <dael> TabAtkins: These are all geared to when text was the only thing. This is for a font-rendering descriptor that lets authors control font fallback behaviour. These are all variants on the manditory requirement
# [22:44] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [22:44] <dael> TabAtkins: If you have a less nec font and are okay witht he user seeing a fallback, you can use swap or optional which only uses the font if it's downloaded.
# [22:44] <dael> jdaggett: What happens on reflow?
# [22:44] <dael> jdaggett: Lets say you hover over an element that changes the style, what happens? Do you continue to use the non-downloaded font or?
# [22:45] <dael> TabAtkins: For consistancy, for optional or swap if you hit the case where you're sticking with fallback for page lifetime, you're staying with it.
# [22:45] <dael> fantasai: What about resize?
# [22:45] <dael> TabAtkins: Maybe you won't reflow.
# [22:45] <dael> jdaggett: This font made it or didn't and then it's like a state that's maintained? If I add elements what happens?
# [22:46] <dael> TabAtkins: The name resolves to a particular font at a particular time.
# [22:46] <dael> jdaggett: So even if I download the font it'll never appear on that page?
# [22:46] <dael> TabAtkins: Yes.
# [22:46] <dael> jdaggett: Why is this necessary?
# [22:47] <dael> TabAtkins: The prop version isn't as necessary. It can be left off. The property is if all you know is that a given element is important and needs to be displayed you can set that at the element level instead of tagging each font face.
# [22:47] <dael> TabAtkins: It means thatf some elements show up some times you might not trigger the font download manditorily.
# [22:47] <dael> jdaggett: So if I set one option and one manditory on a different element, what happens to the other element?
# [22:48] <dael> TabAtkins: That don't delare rendering?
# [22:48] <dael> jdaggett: Or additional section. You're saving a piece of state and I'm not sure which one.
# [22:48] * fantasai suggests renaming font-rendering to font-loading
# [22:49] <dael> TabAtkins: On a per element basis you would override a piece of state. So you're okay with your header reflowing, but you don't care about using the fallback on small pieces of text.
# [22:49] <dael> TabAtkins: In the example the header always gets the branding it wants.
# [22:49] <dael> jdaggett: Why can't this be with script?
# [22:49] <dael> florian: As a user I don't like the manditory and I want swap and I'll put that in my user stylesheet and I can't do that if it's script.
# [22:49] <dael> jdaggett: You want this in the user stylesheet?
# [22:50] <dael> florian: I do.
# [22:50] * ChrisL body {font-family: ahem; font-rendering: optional} //make reloads illegible
# [22:50] * fantasai also wondering if we can have per-document styles rather than only per-element ones, because this and ink-saving mode seem better as per-document
# [22:50] <dael> TabAtkins: The manditory strategy is pretty easy to do, the others are a more involved piece of code, especially the optional value.
# [22:50] <dael> TabAtkins: Using the font loading API for the more optional ones is more difficult that it might look
# [22:50] <dael> jdaggett: What's the default?
# [22:50] <dael> TabAtkins: We're not sure.
# [22:51] <dael> TabAtkins: It would be UA defined.
# [22:51] <dael> fantasai: I think it should be auto. The UA should be able to come up with other ideas. If we say the current manditory of 3 s it doesn't let them come up with something thatsn' ot a timeout.
# [22:52] <dael> jdaggett: And FF isn't a straight 3 sec timeout. We check to see if it's progressed about the first 3s and if it has we wait another 3 s before fallback. So you have to be careful not to block.
# [22:52] <dael> TabAtkins: So that seems like it should be UA defined.
# [22:52] <dael> fantasai: Do you have another name becides auto?
# [22:52] <dael> TabAtkins: Yeah, sure auto than
# [22:52] <dael> Bert: Other opinions?
# [22:52] * ChrisL this property intentionally left blank
# [22:52] <dael> MaRakow: Is anyone asking for optional? When they never get the right font?
# [22:53] <fantasai> TabAtkins^: Sometimes we just say it's UA-defined
# [22:53] <dael> TabAtkins: I'll have to ask for more examples.
# [22:53] <fantasai> fantasai^: Yeah, and that has to map to one of the other options.
# [22:53] <dael> jdaggett: I think the timeout needs to have a definition. Like starting when?
# [22:53] <dael> TabAtkins: When the CSS is seen more or less.
# [22:53] <fantasai> s/auto than/auto then/
# [22:53] <dael> jdaggett: One of the problems is downloadable fonts have a lot of content and we only look once layout starts we tend to not get into a good position in the queue.
# [22:54] * Quits: iank_ (~iank@public.cloak) (Ping timeout: 180 seconds)
# [22:54] <dael> jdaggett: Optional will fail a lot of times.
# [22:54] <dael> florian: It fails on first load.
# [22:54] <dael> TabAtkins: Optional is for fonts nice to have but not required.
# [22:54] <dael> jdaggett: I think some of the resource based is better than CSS
# [22:54] <dael> TabAtkins: I'd like examples.
# [22:54] <dael> jdaggett: It's like you're loading the resource here for use in another page.
# [22:55] <dael> TabAtkins: Sure, yes.
# [22:55] <dael> fantasai: That doesn't make sense.
# [22:55] <dael> TabAtkins: You're loading for other pages in the domain.
# [22:55] <dael> fantasai: What happens with frames?
# [22:55] <astearns> s/frames/iframes/
# [22:55] * Joins: hiroto (~hiroto@public.cloak)
# [22:55] <dael> TabAtkins: They're a new page. They're a weird element, seperate.
# [22:55] * Quits: plh (plehegar@public.cloak) (Ping timeout: 180 seconds)
# [22:55] <dael> Bert: So do we continue working, or think it's a bad idea.
# [22:56] * Quits: jcraig (~jcraig@public.cloak) (jcraig)
# [22:56] <dael> jdaggett: I think tehre's useful stuff, but I'm not sure this finegrained stuff is useful to give to authors. The timeout may be something a user wants to set? It's like anti-aliasing. I think the swapping in and out is, well, does the user want to see the text. I don't really care and want to wait before seeing the text.
# [22:56] <dael> jdaggett: You're making it an author preference.
# [22:56] <fantasai> s/set?/set./
# [22:56] <dael> TabAtkins: The property value exists to override that.
# [22:56] <fantasai> s/anti-aliasing/anti-aliasing, it's a preference/
# [22:56] <dael> jdaggett: As a user I couldn't override.
# [22:57] <dael> TabAtkins: You could apply it to the user style sheet and who cares what the author says.
# [22:57] <fantasai> s/I don't/When I'm on mobile Safari I don't/
# [22:57] <dael> florian: And if your browser doesn't allow user stylesheets, get another one.
# [22:57] <fantasai> s/care/care about loading the font for 60 seconds/
# [22:57] <fantasai> s/and want/I just want/
# [22:57] <dael> bradk_: Another case for manditory is if you have icon fonts.
# [22:58] <dael> florian: Manditory is relevent on icon fonts so it's useful to have in the hands of authors. that's the reason why.
# [22:58] <dael> jdaggett: We created font loading to give authors this level of control. They should decide how they want to introduce it or not. I don't think this has to be encapsulated as a CSS property
# [22:59] <dael> TabAtkins: You can use font loading for loading behaviours you'd want, but making the common cases simple, the non-defaults and better for users. The defaults are hostile because they're trying to be conservitive.
# [22:59] <dael> fantasai: It's user preference.
# [22:59] <dael> TabAtkins: It's per font. You don't want icon fonts to shwo with fallback.
# [22:59] * Joins: kurosawa_ (~chatzilla@public.cloak)
# [22:59] <dael> fantasai: Are icon fonts the ones that change letters into pictures?
# [23:00] <dael> TabAtkins: Yes. The default is tuned for that kind of usage instead of fonts that render text. The don't show anything until the font is loaded is bad. We should preserve that ability, but being able to do this is better.
# [23:00] <dael> fantasai: How did we end up in this mess? We've optimized for the stupidity. The people that want the right thing now have to learn more CSS prop to make your page nice for the user.
# [23:00] <dael> TabAtkins: You've described CSS. Yes.
# [23:01] <dael> jdaggett: Instead of using icon fonts, if you use an icon image you have the same problem.
# [23:01] * Quits: florian (~Florian@public.cloak) ("Leaving.")
# [23:01] <dael> fantasai: Use emoji.
# [23:01] * Joins: florian (~Florian@public.cloak)
# [23:01] <dael> TabAtkins: Remember we didn't have emoji when we made this.
# [23:01] <dael> florian: I think this needs tweeking, but I think it's worth persuing.
# [23:02] <dael> Bert: I heard looking into resource hints should be looked into, can it be done with API, though user stylesheets can't. Other things to look into?
# [23:02] <dael> bradk_: Defining when timeout starts.
# [23:02] <dael> Bert: I didn't hear full opposition or support so it needs futher study.
# [23:02] <dael> TabAtkins: If we're okay on the mailing list.
# [23:02] * Joins: iank (~iank@public.cloak)
# [23:02] * leaverou_away is now known as leaverou
# [23:03] <dael> fantasai: I say we call it font loading instead
# [23:03] <dael> Bert: There's one more issue on fonts?
# [23:03] <fantasai> jdaggett: font-rendering is a terrible name
# [23:03] <dael> jdaggett: Last thing I wanted approval on was I wanted a CSS4 fonts so when people have new ideas we have a placeholder.
# [23:03] <fantasai> +1
# [23:03] <dael> fantasai: +1
# [23:04] <dael> TabAtkins: Given my experience, I recommend we make this a delta spec and whenever you want to publish it's much easier to keep error from creaping in.
# [23:04] <dael> jdaggett: Hopefully everything will be fixed.
# [23:04] <dael> TabAtkins: I hoped that too.
# [23:04] <dael> Bert: So you can work on CSS4 Fonts.
# [23:04] <dael> Bert: Okay, back to plinss
# [23:04] <dael> jdaggett: I have to go.
# [23:04] <dael> fantasai: Can you be back?
# [23:05] <dael> jdaggett: After 5pm your time
# [23:05] <Zakim> -jdaggett
# [23:05] <dael> fantasai: We'll save it for you.
# [23:05] <fantasai> jdaggett: Thanks. :/
# [23:05] * plinss changes topic to 'https://wiki.csswg.org/planning/tpac-2014#agenda'
# [23:05] <dael> Topic: Animation
# [23:05] * Quits: kurosawa (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [23:05] * kurosawa_ is now known as kurosawa
# [23:05] * Quits: smfr (~smfr@public.cloak) (smfr)
# [23:05] <dael> dino: If we're going to break soon, this might take an hour or more.
# [23:06] * dauwhe dael: very good :)
# [23:06] <dael> dino: We could briefly talk about which we have krit...the filters proposal? Or is something more important?
# [23:06] <dael> dino: Scrolling and animations is all one thing.
# [23:06] <dael> plinss: So break and get back to that.
# [23:06] * Quits: notbenjamin (~textual@public.cloak) ("My MacBook Pro has gone to sleep. ZZZzzz…")
# [23:06] <dael> [15 min break]
# [23:06] * Quits: florian (~Florian@public.cloak) ("Leaving.")
# [23:07] * Joins: notbenjamin (~textual@public.cloak)
# [23:07] * Quits: glazou (~glazou@public.cloak) (glazou)
# [23:08] * Quits: ChrisL (clilley@public.cloak) ("Client combusted")
# [23:08] * Quits: bradk_ (~bradk@public.cloak) ("Be back later ...")
# [23:09] * Joins: AH_Miller (~mike@public.cloak)
# [23:11] * Quits: kuettel_ (~kuettel@public.cloak) (Ping timeout: 180 seconds)
# [23:11] <Zakim> disconnecting the lone participant, SantaBarbara, in Team_(css)21:06Z
# [23:11] <Zakim> Team_(css)21:06Z has ended
# [23:11] <Zakim> Attendees were SantaBarbara, jdaggett
# [23:11] * Quits: shans__ (~shans@public.cloak) (Client closed connection)
# [23:12] * Quits: bobtung (~bobbytung@public.cloak) (bobtung)
# [23:13] * Quits: ArronEi (~ArronEi@public.cloak) (Ping timeout: 180 seconds)
# [23:13] * Joins: kurosawa_ (~chatzilla@public.cloak)
# [23:13] * Quits: notbenjamin (~textual@public.cloak) ("My MacBook Pro has gone to sleep. ZZZzzz…")
# [23:13] * Quits: iank (~iank@public.cloak) (Ping timeout: 180 seconds)
# [23:14] * Quits: tantek (~tantek@public.cloak) (tantek)
# [23:15] * Quits: weinig (~weinig@public.cloak) (weinig)
# [23:15] * Quits: jrossi (~jrossi@public.cloak) (Ping timeout: 180 seconds)
# [23:16] * Quits: stakagi_ (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [23:16] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [23:16] * Quits: AH_Miller (~mike@public.cloak) (Ping timeout: 180 seconds)
# [23:16] * Quits: Rossen_ (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [23:16] * Joins: nick (~nick@public.cloak)
# [23:18] * Joins: ArronEi (~ArronEi@public.cloak)
# [23:18] * Quits: kurosawa (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [23:18] * Quits: nsakai2 (~nsakai2@public.cloak) ("Page closed")
# [23:19] * Joins: nsakai2 (~nsakai2@public.cloak)
# [23:22] * Quits: kurosawa_ (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [23:22] * Joins: plh (plehegar@public.cloak)
# [23:23] * Joins: ArronEi_ (~ArronEi@public.cloak)
# [23:23] * Joins: bradk_ (~bradk@public.cloak)
# [23:24] * Joins: tantek (~tantek@public.cloak)
# [23:24] * Joins: dbaron (~dbaron@public.cloak)
# [23:25] * Quits: ArronEi (~ArronEi@public.cloak) (Ping timeout: 180 seconds)
# [23:25] <dbaron> Zakim, room for 3?
# [23:25] <Zakim> ok, dbaron; conference Team_(css)22:25Z scheduled with code 26631 (CONF1) for 60 minutes until 2325Z
# [23:25] <dael> plinss: Let's get started.
# [23:25] <dbaron> Zakim, call SantaBarbara
# [23:25] <Zakim> ok, dbaron; the call is being made
# [23:25] <Zakim> Team_(css)22:25Z has now started
# [23:25] <Zakim> +SantaBarbara
# [23:26] * plinss changes topic to 'https://wiki.csswg.org/planning/tpac-2014#agenda -Zakim 26631#'
# [23:26] * Joins: bobtung (~bobbytung@public.cloak)
# [23:26] * Joins: florian (~Florian@public.cloak)
# [23:26] * Joins: smfr (~smfr@public.cloak)
# [23:27] <dael> dino: The topics we had discussed in this section were some animation features related to scroll, the before scroll event, and the scroll snap points.
# [23:27] * Joins: jcraig (~jcraig@public.cloak)
# [23:27] * Joins: iank (~iank@public.cloak)
# [23:27] * Joins: Rossen_ (~Rossen@public.cloak)
# [23:27] <dael> dino: WE can go through in order. From the CSS wiki is the proposal of three things related to animations. I don't have a demo for animation behavior so we can start with that.
# [23:27] * Quits: tantek (~tantek@public.cloak) (tantek)
# [23:27] * Joins: dbaron_ (~dbaron@public.cloak)
# [23:28] <dael> dino: If someone can paste the link in IRC. This is adding what's called addidtive animations to CSS animations
# [23:28] * Joins: jrossi (~jrossi@public.cloak)
# [23:28] * Joins: bradk__ (~bradk@public.cloak)
# [23:28] <astearns> http://lists.w3.org/Archives/Public/www-style/2014Sep/0135.html
# [23:28] <dael> dino: If you have an animation on a transform and a second on that transform, it overrides the first animation and the element. So this prop is it replaces or adds. So if there's a rotation animations and yadd enough it would combine.
# [23:28] <astearns> (animation-behavior: add)
# [23:29] <dael> dino: There was a proposal for cumulative and additive.
# [23:29] <dael> bkardell_: The cumulative is if it adds and repeats on itself.
# [23:29] <Zakim> + +1.778.785.aaaa
# [23:29] <dbaron_> Zakim, aaaa is kgilbert
# [23:29] <Zakim> +kgilbert; got it
# [23:29] <dael> dino: So like a bouncing ball where you'd like it to bounce and then contniue.
# [23:29] <dael> smfr: Does this mean we have to spec which properties are additive
# [23:29] <dael> dino: Yes. Web animations has done a good job of that. Most aren't additive.
# [23:30] <dael> bkardell_: Or it's just replace.
# [23:30] <dael> smfr: So if it's absolute 10 pixels, can you add less?
# [23:30] <astearns> s/bkardell_ /birtles/
# [23:30] <dael> dino: If it's al enght they add, color adds componantwise. If it's a transform they multi the matrix
# [23:30] <fantasai> I'd like to suggest animation-behavior -> animation-combine
# [23:30] <dael> dino: I guess the q to the group is this in animations level 2?
# [23:30] * Joins: kurosawa (~chatzilla@public.cloak)
# [23:31] <dael> dbaron_: One thought is we have had other caes where we want additive cascading. I don't htink that's an obj but it's related.
# [23:31] <dael> TabAtkins: I think that falls to a different spot unless it's addition over lists. I can't think of additive values where you have two lists and you add to append.
# [23:31] <dael> dbaron_: Filters and transforms.
# [23:32] <dael> birtles: The other feedback was the name.
# [23:32] <dael> dino: I shouldc are all my proposals I don't care about name. It should be animation composit.
# [23:32] * Quits: bradk_ (~bradk@public.cloak) (Ping timeout: 180 seconds)
# [23:32] * Joins: tantek (~tantek@public.cloak)
# [23:32] * Joins: bobtung_ (~bobbytung@public.cloak)
# [23:32] <dael> dino: So the scrolling part. Part of the e-mail had a proposal for 2 prop one that's when the animation starts. the default is it starts when it's applied. I called that animation trigger. The other was the time base.
# [23:32] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [23:33] <dael> dino: One of the major performance things is to make scrolling as smooth as possible. The current web trend is to do fancy scroll things and that makes pages scroll slowly. They do this by making JS that listens to every scroll.
# [23:34] <dael> dino: Doing something by anmation delay you have to know when a user gets there. I added this one prop, animation trigger, when you scroll to this value, but it could take other values.
# [23:34] <dael> dino: So as the target element hits the top of the page, an animatio happens. It's the beginning of the animation and runs like normal. You can animation any old thing.
# [23:35] <dael> dino: Once you have the idea of being able to map an animation to start at a scroll point, you can take the time domain and map to the physical cdomain, so I've got a start and end value and as I scroll up and down I'm going through time. I can do that with different keyframes or different mappings.
# [23:35] <dael> dino: You can get nice timing function on scroll. Once you have this you can animation any prop. I've got a target that's alignd with the top of the element.
# [23:36] <dael> dino: One of the awesome things is b/c we know what'soin gg to happen in advance we can do this in the compositing threat.
# [23:36] <dael> dino: If you look at the apple.com website on the new imac you hit a point where it scrolls and then becomes mostly sticky, but drifts a bit.
# [23:36] <dael> dino: So the e-mail has better specifics.
# [23:37] <dael> florian: What I've seen is you scroll to apoint there is scrolling to a time mapping, but until you hit the end of the animation you disable scrolling.
# [23:37] <dael> dino: I want to add the minimum # of properties to get as many cases as possible.
# [23:37] * Quits: bobtung (~bobbytung@public.cloak) (Ping timeout: 180 seconds)
# [23:37] * bobtung_ is now known as bobtung
# [23:38] <dael> dino: You might have 2 animations, both triggered at this point, one which allows you to scrub through time with scroll and one that switches to sticky.
# [23:38] * Quits: r12a (rishida@public.cloak) (Client closed connection)
# [23:38] <dael> dino: The common one is when things fly in, you don't want the to fly out when you scroll up.
# [23:38] <jcraig> q+ to discuss Element.computedRole() and Element.computedLabel()
# [23:38] * Zakim sees jcraig on the speaker queue
# [23:39] <dael> dino: So common is you want to run each time and what happens when you skip over the trigger, like a scroll to. I think it addresses a lot of the common things. It should be completely compat with web animations. I don't think it conflicts.
# [23:39] <hober> q-
# [23:39] * Zakim sees jcraig on the speaker queue
# [23:39] <hober> q- jcraig
# [23:39] * Zakim sees no one on the speaker queue
# [23:39] * hober jcraig: wrong channel
# [23:39] * jcraig sorry. thanks
# [23:39] <dael> dino: In the proposal I said this is mapping the animations timeline to scroll, but you could map to a media element. Or a more common is you have a live stream that stops with hang.
# [23:40] <dael> dino: Another thing I put on the lsit was the onion's where it says how far in the document you've progressed. We'd be able to do that with this script by saying the animation runs from 0 to 100 and it's body start and body end.
# [23:40] <dael> shans: What kind of prop can you animate when you use this?
# [23:41] <dael> dino: There is a big issue. This could have animations trigger themselves. If you animate the size of the object it's annoying, but we have that already on hover.
# [23:41] <dael> shans: That means you can animate the margins.
# [23:41] <dael> florian: It's not slower than in script
# [23:41] <dael> dino: Or animations already.
# [23:41] <dael> shans: So here the animation is synced.
# [23:41] <dael> dino: There are things we could do in advance that we could sync.
# [23:41] <dael> shans: But no guar this would sync
# [23:42] <dael> dino: Yes.
# [23:42] <dael> shans: Scroll with one value starts an animation, scroll with two doesn't.
# [23:42] <dael> dino: I think I need a prop that has a lot more detail. A syntax proposal with different options.
# [23:42] <dael> dbaron_: I like the way you do it in the e-mail better than the visual.
# [23:43] <dael> dbaron_: What you have in the e-mail isn't clear how you map the duriation to the scroll.
# [23:43] <dael> dino: The animation runs from 0 progress to 1 progress. If the begin and endof my scroll is 100 pixels it's percentages.
# [23:43] <dael> dbaron_: The e-mail can't spec lengths in the scroll.
# [23:44] <dael> dino: Right. The trigger does. You're right. It's a mistake.
# [23:44] <dael> dbaron_: It should have scroll start/end.
# [23:44] <dael> plinss: So it should be on a time base.
# [23:44] <dael> TabAtkins: There has been discussion on this about 2 years ago. We're totally cool with this.
# [23:44] <dael> dino: I expect there will be a lot of itteration on syntax.
# [23:44] <plinss> s/a time base/timebase/
# [23:45] <dael> zcorpan: Is it useful to have a scroll offset, or is it more useful to refer to an element.
# [23:45] <dael> dino: It should accept the same as scroll elements and the calc mode. You don't want somethig to happen when the element hits the top of the screen because you don't know the height.
# [23:45] <dael> plinss: What about 5%. I want to make sure pixels isn't the default. It's a good usecase, but it's bad for dependant.
# [23:45] <dael> dino: Yeah.
# [23:46] <dael> zcorpan_: this seems to only handle scrolling in one direction
# [23:46] <dael> dino: It should be scrolling both directions. Your first question reminded me, at the moment the scroll position is to always scroll in it's current frame. So if you're in an iframe you don't want to be able to determine the position for scroll based on your document.
# [23:47] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [23:47] * Quits: Cyril (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [23:47] <dael> dino: You can imagine like light buttons where it could work, the syntax can get confusing. We might want to start small. I'm not trying to deal with every paralyx effect, but if we can do some things faster, that's great.
# [23:47] <kip> dino: Would it be possible to trigger based on direction + velocity? (Or is this best done another way?)
# [23:48] <dael> plinss: Common use case is like when the next button only lights up when you hit the next button
# [23:48] <dael> shans: As a request can we run this with JS.
# [23:48] <dael> dino: In animations, yes.
# [23:48] <dael> plinss: The time base could be user defined.
# [23:48] <dael> dino: It would drop you into slow scrolling.
# [23:48] <dael> plinss: Here's something we're defining in CSS and you can define it within CSS script.
# [23:49] <kip> dino: Use case would be a search bar that animates away when you scroll quickly downwards
# [23:49] <dael> plinss: Another use case is an animation with media and pauses when the media is buffering or the opposite.
# [23:49] <dael> dino: And you might want to sync the time base to an animation
# [23:49] <dael> dino: Another part of the prop once you have triggers you can add the ability to trigger an aniation from another animation
# [23:49] <dael> dino: Without editing many many keyframes.
# [23:50] <dael> dino: The trigger's function syntax is good.
# [23:50] <leaverou> s/aniation/animation/
# [23:50] <dael> hober: Prior to going into animation trigger, you said something about behavior, was there supposed to be a resolution recorded.
# [23:50] <dael> RESOLVED: start work on Animations 2
# [23:51] <dael> zcorpan_: So the directions should be x and y?
# [23:51] <dael> dino: Yes, it's logical.
# [23:51] * dbaron_ is now known as dbaron
# [23:51] <dael> plinss: We need to make sense with overflow and scroll behavior.
# [23:51] * Joins: glazou (~glazou@public.cloak)
# [23:51] <dbaron> s/x and y/x and y, or inline and block/
# [23:52] <dael> ??: Probibly logical for it to start as you pass
# [23:52] <dael> plinss: I'm thinking block and inline ifyou're specifying y you might not want to say animation block. We just want to make sure it makes sense when we're done.
# [23:52] <dael> Bert: So how do I turn it off? What's the shortest way to disconnect
# [23:52] <dael> Bert: Maybe time base auto?
# [23:53] <dael> dino: It's common. People don't like these pages. First they hate having so much happen on scroll, then they hate scrolling disappearing.
# [23:53] <dael> plinss: The discontinuity is annoying.
# [23:54] <dael> dino: I do not like it when I'm scrolling vertical and things move horizontal. Web authors do this stuff either way.
# [23:54] <dael> plinss: WE shouldn't make bad things easier.
# [23:54] <dael> ??: I disagree wtih that. I think you should give authors all the power.
# [23:54] <dael> Bert: I'm fine adding it as long as there's an easy way to turn it off.
# [23:54] <dael> dino: It's easy to turn it off.
# [23:54] <astearns> s/??/slightlyoff/
# [23:55] <dael> plinss: I'm with you giving power and apability, but there's a fundimental part of CSS to giving the user the end power.
# [23:55] <dael> rick: Before we do specifics, a general. Over the last 6 months we've been talking to people about why they're making mobile native apps.
# [23:56] <dael> rbyers: one thing we've hear is that they can get a lot more touch sensitive effects. Can I project?
# [23:56] <dael> s/rick/rbyers
# [23:56] <dael> rbyers: So starting with scroll linked effects. People have been doing this forever, but it's urgent for us because some of our design requires this and we're having to tell people you can't do this on the web.
# [23:57] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [23:59] <rbyers> https://www.polymer-project.org/components/core-scroll-header-panel/demo.html
# [23:59] <dael> rbyers: This is the simpliest example. This is a simple effect with a fade and header and I think dino prop can do this. We impl today based on scroll events. A lot of demos you wouldn't notice if you weren't but on a slow device you'd notice that the scrolling isn't sync witht he effect.
# Session Close: Wed Oct 29 00:00:00 2014

The end :)