15:22:23 RRSAgent has joined #css 15:22:23 logging to http://www.w3.org/2015/08/05-css-irc 15:22:29 RRSAgent, make logs public 15:22:42 Zakim has joined #css 15:22:44 Ms2ger has joined #css 15:54:55 present+ glazou 15:55:29 adenilson has joined #css 15:55:49 dael has joined #css 15:56:47 alex_antennahouse has joined #css 15:57:01 antenna has joined #css 15:57:15 present+ dauwhe 15:58:05 present+ alex_antennahouse 15:58:34 present+ dael 15:58:40 ScribeNick: dael 15:58:52 present+ astearns 15:59:40 present+ antenna 15:59:48 gregwhitworth has joined #css 16:00:25 bkardell_ has joined #css 16:00:49 ChrisL has joined #css 16:01:10 present+ gregwhitworth 16:01:15 present+ plinss 16:01:22 present+ bkardell_ 16:01:25 present +bkardell_ 16:01:38 smfr has joined #css 16:02:00 present +antonp 16:02:16 present+ smfr 16:02:46 andrey-bloomberg has joined #css 16:03:03 present+ andrey-bloomberg 16:03:06 vollick has joined #css 16:03:40 present+ leaverou 16:03:40 I saw that 16:03:46 present+ adenilson 16:04:03 present+ vollick 16:04:23 myles has joined #css 16:04:37 present+ tgraham 16:04:54 present+ ChrisL 16:04:59 present+ fantasai 16:05:07 Florian has joined #css 16:05:09 glazou: Let's start 16:05:11 glazou, can we add the conf call dial-in #s to the meeting announcement template? 16:05:17 Present+ Bert 16:05:25 glazou: Yes, fantasai I can do that 16:05:45 glazou: First thing, any extra items? I saw one from fantasai on the WG list and a mention from greg that BG item isn't to be discussed. 16:06:11 glazou: Before we start, I'm away the next 3 weeks, so I won'tbe at the f2f. 16:06:19 Topic: containment and overflow. 16:06:24 Present+ SimonSapin 16:06:39 present+ florian 16:06:47 bkardell_: To add, I wanted to have a quick regression about has and gaging interest and feedback from MS uservoice on that. 16:06:53 s/gaging/gauging/ 16:07:04 glazou: how much time do you need? 16:07:09 bkardell_: A minute or two. 16:07:12 glazou: Let's do that. 16:07:56 bkardell_: Two weeks ago during WG when we were discussing as to if we should punt has and if devs wanted it and if impl will impl. We stuck it onto uservoice. uservoice has about 500 features that devs can go spend points to prioritize. 16:08:17 the web developers HAVE SPOKEN 16:08:26 bkardell_: In the two weeks it's in the top 10% of requested features. I think it's clear that there's a big want. I think we should take that feedback to our respective impl and advocate that it get impl. 16:08:36 glazou: Comments from others? impl? 16:09:40 gregwhitworth: We glanced at it here. Last time we talked about it. We discussed it with 5 or 6 of us and we like what it offers for devs. We've disucced with engineers at other UAs and they're concerned about performance. I'm starting convos about how it's utaiitzed to see if we can scope down to remove the concerns a bit. 16:09:44 Present+ sanja 16:09:51 are the performance issues verified or just worries? ie how much are they based on testing? 16:10:02 gregwhitworth: I think it's worth keeping in the spec to say there are issues raised and lets deal with them. The devs are already doing it with JS. 16:10:06 note it is currently in the spec only in the static profile 16:10:14 gregwhitworth: So that's where we stand. 16:10:25 glazou: Other opinions? Is that good for you bkardell_? 16:10:42 bkardell_: Yep. Other than that in the spec it's only static profile so there shouldn't be perf concern there. 16:10:57 https://lists.w3.org/Archives/Public/www-style/2015Mar/0402.html 16:11:11 Topic:containment and overflow 16:11:24 Florian: I think we spoke about that a few times and there was something tricky about the preloader. 16:11:40 bkardell, the concern I have with :has() is various proposals to change its syntax in order to make it restricted enough for the dynamic profile 16:11:46 fantasai: What does the preloader have to do with syntax? 16:12:17 bradk has joined #css 16:12:21 Florian: There was a bigger discussion about @supports and general MQ and the interaction with @viewport. If you start to do things like this you end up with the whole thing. While it sounds okay at the syntax level, you get surprising performance... 16:12:49 smfr: URL above 16:12:58 Florian: The advantage of @import only being at the top, the preloader can support that without complex syntax. So it can load, but not preload. Personally I don't care all that much, but last time we talked there were big concerns. 16:13:01 Topic is not containment and overflow 16:13:10 fantasai: This mail is about double parans in the @import. 16:13:18 Florian: Okay, ignore that. I'm off topic. 16:13:20 Topic: Allowing @import to be conditional on @supports queries 16:13:21 in supports() in @import 16:13:30 gregwhitworth for sure, hit me up on dm and we can arrange 16:13:30 glazou: So fantasai you wanted to discuss because it's the last one on the radar? 16:13:39 @import "url" support() 16:13:59 @import "url" support((display: flex) and (align-items: start)) 16:14:01 fantasai: Right now we have @import and a URL and @supports whre you can put a condition. It was pointed out where if you just have one condition...if you have two conditions it makes sense 16:14:05 fantasai: That's fine. 16:14:08 @import "url" support((display: flex)) 16:14:15 @import "url" support(display: flex) 16:14:35 sounds ok 16:14:35 fantasai: For very simple cases you end up with the double parans. Can we change the grammer to allow one set of parens. 16:14:44 glazou: For usability and readability I'd support that. 16:14:53 glazou: I'd like to hear from others. SimonSapin said okay. 16:14:57 MaRakow has joined #CSS 16:15:01 SimonSapin: Would this only be @import? 16:15:13 fantasai: Yeah, because @supports doesn't have parens in itself. 16:15:17 SimonSapin: Right. I think that's fine. 16:15:28 .supports("(display: flex)") 16:15:29 fantasai: We might also consider allowing it for the JS .supports 16:15:38 fantasai: It's not quite the same, but it's similar problem. 16:15:50 smfr: What would it look like with a not? 16:16:01 fantasai: You would need parens. Only in the case with just the one thing. 16:16:09 glazou: Any obj? 16:16:24 fantasai: not sure, no 16:16:42 Florian: I think a long time ago we resolved in the other direction for JS. I don't strongly care either way, but given that we did resolve the other direction, is there something we're not considering this time? 16:16:51 fantasai: I think it's weirder when it's just in CSS 16:17:11 glazou: It's often the case that we review something because purity and then we find it's ugly and make the change. 16:17:13 Florian: Sure. 16:17:17 glazou: So no obj? 16:17:35 RESOLVED: Default to one stack of paren in the case of one single supports query 16:17:46 present+ TabAtkins 16:17:51 fantasai: Do we want to extend that to JS and is dbaron on the call? 16:18:01 SimonSapin: I think rather than default to, I think we want to allow both. 16:18:14 s/Default/Allow (in resolution) 16:18:39 glazou: Let's imagine you have an @import with two, you remove one, and than you end up with two stacks, we want to allow that. 16:18:53 TabAtkins: Yeah, you can put an infinante amount of parens in a supports. 16:19:15 RESOLVED: In case of one single supports query the innermost parenthesis are optional in functional notation 16:19:23 (to take place of last resolution) 16:19:31 Topic: containment and overflow 16:19:43 Florian: We discussed last week, but there is follow-up. 16:19:43 Resolution applies to both JS and supports(), to clarify 16:19:49 https://lists.w3.org/Archives/Public/www-style/2015Jul/0461.html 16:19:50 In terms of grammar: `something_something : supports_condition | declaration` 16:20:01 dbaron has joined #css 16:20:22 Florian: Quick summary, we had discussions as to if overflow:clip should stay with different semantics and we agreed we'd keep the old functionality. We're open to bikeshedding the name. 16:21:08 estellevw has joined #css 16:21:13 Florian: The follow-up is, we're all clear where if you do containment:paint and overflow:clip you get the ideal situation. But if you don't specify overflow:clip and you do visiable, should overflow:paint force it to compute to clip? Or are we in one of those cases where the author didn't consider he might overflow? 16:21:38 TabAtkins: I believe we should stick with contain:paint auto clips. That's so authos don't have to do a bunch of prop to get containment. 16:22:03 Florian: I initially agreed, my only doubt was the extra thing you need to flip causes content to disappear. If you didn't consider that, you drop content. 16:22:12 ok 16:22:24 yes 16:22:28 perfect 16:22:33 TabAtkins: The containment prop in general, all can do bad things if you use them unwisely. WE don't have to safeguard this one in particular. 16:22:52 Florian: I can live with that. it was worth raisining since we're careful about disappearing content. 16:23:15 smfr: In general when one prop influsences a second prop we've avoided influencing the computed value of the second prop. 16:23:25 TabAtkins: Yeah, if it computes is a seperate thing. 16:23:28 Present+ dbaron 16:23:41 Florian: Yes, it's should it automatically overflow: clip or do you have to ask explicitly. 16:23:58 smfr: I'm with TabAtkins. If you say contain:paint it does everything it's supposed to do. 16:24:07 Florian: If we resolve this way, there is a follow-up. 16:24:21 Florian: So proposal, leave the spec as-is. 16:24:23 glazou: Obj? 16:24:52 TabAtkins: smfr and I expressed for the resolution. 16:24:56 fantasai, I think going without the double-parentheses is fine 16:24:57 RESOLVED: Leave the spec as-is for contain:paint and overflow:clip 16:25:59 Florian: The follow-up, if you're not using overflow, but overflow-x and overflow-y and than you contain: paint. If you're visible in one direction and not the other the visible goes to auto. The contain:paint says it goes to clip. When I wrote this with TabAtkins the intent was the overflow prop would apply first. So you have auto and then the contain doesn't apply. 16:26:07 Florian: This was raised as ambig on the ML. 16:26:21 TabAtkins: I'm fine with clarifying the spec. 16:26:25 +1 to clarify the spec 16:26:36 Florian: I'm not sure if it's contain or overflow that needs to clarify, but what do we clarify to? 16:26:50 I think the way Florian described it makes as much sense as anything 16:27:00 Florian: The speed argument might apply here where overflow applies first. 16:27:11 TabAtkins: I'm okay with that. So it changes to auto and you get the contain effect. 16:27:19 glazou: bkardell_ loves it too. other opinions? 16:27:25 smfr: contain applies last? 16:27:51 bkardell_ is ok with it - love is not a word I would use here 16:27:51 TabAtkins: Yes. If you were otherwise going to be overflow: visible your going to change, but the others would clip auto. 16:27:56 smfr: scrollbars? 16:28:00 TabAtkins: You'd still have them, yes. 16:28:31 Florian: You do the computed value rules first. Then you look at contain:paint and you compute to clip if you need to, but otherwise you leave it as is. 16:28:45 dbaron: That seems reasonable assuming that we want contain: paint to be scrollable. 16:28:56 Florian: By default they're not. But if you explicitly ask for scrollbars. 16:29:00 ...which I'm not completely convinced about 16:29:27 TabAtkins: I see no reason why it would have to have anything to do with scrolling. The elements can do whatever they want. If you don't want scrollable, contain:paint will do that for you. 16:29:41 glazou: Do we go for the suggested clairifcation? 16:29:56 TabAtkins: I can clarify contain to make sure it specifies the order of operations 16:30:02 RESOLVED: clarify contain to make sure it specifies the order of operations 16:30:13 Topic: 'system' generic font name 16:30:20 https://lists.w3.org/Archives/Public/www-style/2015Jul/0169.html 16:30:23 glazou: It's been on the agenda for three weeks. 16:31:19 myles: There's...at Apple we've gotten a fair number of requests for people to style contents so it fits with the UI. The proposal is to create a font family generic font name so that it matches the UI of the OS. It seems Andriod, iOS and Windows 10 have a relevent font family that this would use. What are your thoughts? 16:31:24 fantasai: Makes sense to me. 16:31:45 KDE has 8 UI fonts 16:31:46 ChrisL: DO OS only have a single one? Do any have serif and sans-serif or something like that? 16:32:09 myles: Of the OS I looked at, they have one font family for the UI elements. So this is about font families. 16:32:11 q+ 16:32:39 Florian: IN theory they could be all over the place, but in practice there aren't. Generally there is one font family, but there could be more so we should spec properly for that. 16:32:40 Zakim, ack Bert 16:32:40 I see no one on the speaker queue 16:33:16 Bert: The system I'm using has by default its UI fonts, but I noticed that knowing the family and size isn't enough if you want to mimic the normal look. YOu need the color and if they use shadows. It's rather more complex. 16:33:30 myles: I think it's viable to not make this very complicated to support KDE. 16:34:06 Bert: I have no conclusion, I was looking at the question and since you asked about the families, at the momemt my system is using the same family but with differen weights and sizes. If you want to look the same, knowing the family isn't enough. 16:34:20 Is there a use case of mimicking the default typography of an OS, without mimicking any other part of its UI? (since we have no access to anything else) 16:34:20 ChrisL: I don't think the claim was that this one value would be enough to mimic the UI, just the font. 16:34:38 'Color:system; text-shadow: system'? 16:34:40 TabAtkins: Yes, it was to just have you mimic the UI. The font used can be jarring if you're trying to look native. 16:34:58 +1 to what tab said, for spec clarity 16:35:09 bradk, wouldn't work, since different elements have different values for it 16:35:12 TabAtkins: We should specify at least suggestions on how to choose a system font for things that have multiple fonts. So those of us that have browsers that run on linux need to know what to use. 16:35:20 myles: That's fine, I can write something up. 16:35:30 glazou: Can you answer dbaron proposal in a summary? 16:35:38 TabAtkins: Looking native takes much more than just mimicking the font or text-shadow though 16:35:44 myles: The prop was to have systme be a function so you can put system menu and get the menu font. 16:35:49 glazou: And your answer? 16:36:04 I'm less inclined for the system function, but like the system name itself 16:36:04 q+ to ask about answer to Nick Doty's fingerprinting issue 16:36:10 myles: The answer is that this is what I desc before where for the OS I looked at there's only one so it seemed needlessly complicated. 16:36:51 Bert: One other issue that Nick brought up. If you allow an app to ask what the system UI font is, you have an extra surface for fingerprinting. If there's a way to make the surver not know what's being displayed. 16:37:08 fantasai: We have this problem already. CSS 2.1 has system keywords already. This gives you less information. 16:37:15 s/system/system font/ 16:37:39 TabAtkins: It's also almost completely subjugated...this allows for no additional entropy except for people that customize their fonts. 16:37:48 Bert: But this does effect those people. 16:37:56 It's a little annoying to have two different system font mechanisms that work in entirely different ways... 16:38:00 TabAtkins: Yes, but that entropy is already out there. 16:38:21 glazou: So in case we resolve on this, maybe a note summerizing Nick Dotis(sp?) message would be good. 16:38:35 Florian: The message is bringing up the fingerprinting, what does the note say? 16:38:43 glazou: At least web authors are warned. 16:38:47 s/Dotis(sp?)/Doty's/ 16:38:51 myles: There's no note for the font keywords. 16:39:10 It's not authors who should be warned; it's users. 16:39:11 TabAtkins: Yes. If we're going to start marking fingerprinting vectors we can be more consistant about that and mark them elsewhere. 16:39:26 glazou: The W3C started to do more about privacy. I think it's good to have a warning. 16:39:29 myles: I'm fine with that. 16:39:35 Florian: I'm just trying to see who should be warned. 16:39:51 TabAtkins: The most useful target is people producing privacy enhnasing tools. 16:39:55 Florian: That's a good point. 16:40:10 glazou: So we accept the new value and its definition with a note in the spec. 16:40:18 +1 to a note, even if we don't know how to solve it yet :-) 16:40:25 RESOLVED: accept the new 'system' value and its definition with a note in the spec. 16:40:42 fantasai: Who is going to edit this in? we need someone to do the editing work for this. 16:40:56 TabAtkins: I have a resonably complete fonts 3 that we can port over to fonts 4. 16:41:02 myles: So is that volunteer? 16:41:18 TabAtkins: Well...if no one else is going to do it, I'll put it on the list of specs I'm contibuting to. 16:41:31 myles: Certainly for this value I was intending on contributing prose. 16:41:54 TabAtkins: Should I take an action finishing polishing the bikeshed version and create an ED for fonts 4? 16:42:05 fantasai: Can we deal with fonts 3 not being bikeshedded? 16:42:13 ChrisL: Yeah. 16:42:21 fantasai: I think that's a good idea. Can we get a resolution? 16:42:25 +1 16:42:31 Florian: Bikeshed 3, dev 4 TabAtkins as an editor? 16:42:33 glazou: Obj? 16:42:43 dbaron: I think it's worth running by jd 16:42:45 s/dev/diff spec/ 16:42:52 s/jd/jdaggett 16:42:57 ChrisL: Would he obj? 16:43:07 TabAtkins: He's weekly objected to other things but I can try again. 16:43:18 fantasai: Tehre's things he wanted fixed in bikeshed before porting it over. 16:43:23 glazou: OKay, let's do that. 16:43:24 gregwhitworth was that meant for me? context? you linked to something about colors? 16:43:32 fantasai^: so you two should probably coordinate on that 16:43:36 Topic: HCL colors 16:43:38 https://lists.w3.org/Archives/Public/www-style/2015Jul/0098.html 16:44:05 ChrisL: The thing that may have confused people, it's normally called LCH and discussed with LAB because two identical forms. This is asking if we should add these to the spec. 16:44:18 ChrisL: I think we should, I think I have an action to do it. TabAtkins and I need to discuss it. 16:44:44 ChrisL: This used to be SVG and was moved to colors 4. I think I'm ready to add spec text. I think we should close with we should add it. 16:44:47 TabAtkins: I'm fine with that. 16:44:58 RESOLVED: Add LCH to the spec 16:45:07 action ChrisL write some language for LCH 16:45:08 Created ACTION-702 - Write some language for lch [on Chris Lilley - due 2015-08-12]. 16:45:34 https://lists.w3.org/Archives/Public/www-style/2015Jul/0060.html 16:45:34 Topic: writing-modes... 16:45:41 fantasai: I can summerize, but not resolve today. 16:46:33 fantasai: We have a writing-mode prop that says if you're LTR or RTL or Top to Bottom and we also have text orientation that says how that line of text is roated in that original box. Do you rotate clockwise or anti-clockwise. To do something like a book spine you would use these things in combo. 16:46:55 fantasai: The problem with the design is you can end uo witht he left size on the top or bottom or both in the same BFC. 16:47:10 fantasai: You can also rotate 180 in the same line which is also complex. 16:47:44 gregwhitworth note I didn't comment on colors conversation :) 16:47:49 fantasai: There was a request to simplify what can be done. There was discussion on how to do this and this prop is to change...instead of having the text orientation give all the possible orientations, we move somet o writing-more. 16:47:55 I don't think it's actually that hard from an implementation perspective, although it does require some work; I think the main difficulty is specifying it correctly. 16:49:01 fantasai: It would add sideway-lr and sideways-rl which would rotate the entire block. Anything that's not CJK would use that to turn the text sideways and that would ignore the text-orientation. If you're trying to do upright you would use vertical-lr and poss text orientation to tweek that. 16:49:16 q+ 16:49:36 fantasai: We use two use cases if we switch to this model. It's top to bottom left to right in a CJK doc whichi s rare. or Ogram which is also wierd and rare. 16:49:42 Zakim, ack Bert 16:49:42 Bert, you wanted to ask about answer to Nick Doty's fingerprinting issue 16:49:42 q- 16:49:44 I see Florian on the speaker queue 16:49:49 Zakim, ack Florian 16:49:49 I see no one on the speaker queue 16:50:03 Florian: Two comments. I spent a bit of time offlist with Koji discussing this. We independantly landed on this solution so we're both in favor. 16:50:43 Florian: One downside of what we had previously is that it's biased to CJK. The new proposal the simple use cases are just the writing-mode prop. Both for CJK and English users. 16:51:44 Florian: The other point, for the use case we're using, if you have Arabic inside Japanese, we can no longer do this inline. I did some research to see if that case existed. I reached out to academics and librarians and no one could point out a use case. It's extremely rare if it exists. We're not losing anything. 16:52:00 glazou: Okay. We don't have Koji so I suggest we resolve on the ML. 16:52:09 liam has joined #css 16:52:10 Florian: Koji is fine. I'mnot sure about jdaggett. 16:52:24 glazou: We don't have everyone around the table. Lets gather the opinions before we decide. 16:52:50 glazou: We have 8 minutes. We have Ruby issues, keyframes interaction, whitespace around and/not and max-content contribution. 16:52:54 https://lists.w3.org/Archives/Public/www-style/2015Jul/0391.html 16:53:05 Topic: specifying how keyframes interact 16:53:19 https://lists.w3.org/Archives/Public/www-style/2015Jul/0332.html 16:53:21 Topic: remove whitescape around and/not 16:54:17 q+ to mention whitespace around "and" in @supports 16:54:48 TabAtkins: Several F2F ago we talked about whitespace in regards to syntax. We decided that there should be whitespace on both sides or and, or, and not. Turns out this breaks things. There's at least one MS minifier that removes the space before the and. SO requiring that space breaks all the code using that minifier. So I suggest we drop that requirement and rec the whitespace, but not require it as long as you do something to have it parse into keywords 16:54:51 Zakim, ack Bert 16:54:51 Bert, you wanted to mention whitespace around "and" in @supports 16:54:52 I see no one on the speaker queue 16:55:24 Bert: I'm in favor. For MQ it's quite simple since it's WD. The problem with be with @supports. We have a CR that req spaces. We'll have to pull that back to WD. I'm in favor of doing it, but it is some work to do. 16:55:35 TabAtkins: Yeah, that's process. We can repub as nec. 16:55:51 glazou: Who is in favor, who objects? 16:55:56 ChrisL: Sounds good to me. 16:56:02 s/We use two use/We lose two use/ 16:56:03 Florian: As long as @supports is in sync 16:56:17 RESOLVED: Revert the spec on the whitespace requirement 16:56:22 https://lists.w3.org/Archives/Public/www-style/2015Jul/0391.html 16:56:26 Topic: keyframes 16:56:28 Topic keyframes interaction 16:56:28 s/top to bottom left to right/top to bottom Arabic/ 16:56:35 s/Ogham/Ogham in a CJK document/ 16:56:53 s/Arabic/RTL/ 16:57:22 TabAtkins: How animations interact with eachother when one has an animation timing function and others don't, that's not well defined. I wrote an e-mail alogrizing the thing. This needs review and someone saying it matches up. INternally it's correct as far as we know. As long as people are okay with it, that's great. Review on the ML. 16:57:38 smfr: I think the general algo is correct, but I don't like the word transition since that's a thing. 16:57:53 TabAtkins: If you can come up with a better word, that's fine, lay it on me. 16:58:08 TabAtkins: If anyone has a better name, please tell me and we'll change it. 16:58:27 TabAtkins: Otherwise, there's nothing specific for that. Review and give a stamp of approval 16:58:35 action everyone review the proposal so we can approve 16:58:35 Error finding 'everyone'. You can review and register nicknames at . 16:58:54 glazou: There's only a minute left. Thank you everyone, have a good F2F, I'll talk to you in september. 16:59:37 MaRakow has left #css 17:01:47 TabAtkins: IIRC, one of the issues with the fonts spec was the descriptor tables 17:03:30 TabAtkins: Another one was http://dev.w3.org/csswg/css-fonts/#font-variant-prop vs http://dev.w3.org/csswg/css-fonts/Overview.html#font-variant-prop 17:04:35 TabAtkins: Where the goal was to have all the values link to their definitions 17:05:04 Hm? What's the difference in those two links? 17:05:11 Look carefully at what's linking 17:05:28 Yeah, one's Overview.html, the other's implied. What of it? 17:05:29 In the first link, each component value is linked to its definition 17:05:48 I think you gave the wrong links. 17:05:48 In ths econd link, only the are linked 17:06:09 No, I didn't. Look lcoser 17:06:14 wtf why are those two links different 17:06:31 Because .htaccess? 17:07:06 OH I REMEMBER the current working css-fonts is Fonts.html 17:07:09 because reasons 17:08:02 Yeah, so, I think you'll want to do a "select all text in the HTML, paste into a text file, diff" operation to check that you didn't break any normative text 17:08:12 (which you do on occasion...) 17:08:26 And also need to fix a few things in Bikeshed that jdaggett wants fixed 17:08:47 One of which is the value grammar components linking to their respective definitions 17:09:47 And another is fixing the descriptor index to generate correctly https://drafts.csswg.org/css-fonts/Overview.html#font-face-descriptor-table 17:09:54 Yeah, that's just a matter of marking them up differently. 17:10:50 And it looks like the index is also a markup thing? Or a bug. It might be a bug due to same-name props and descs. 17:11:19 And a third issue was the references index generating badly 17:11:22 e.g. https://drafts.csswg.org/css-fonts/Overview.html#references 17:11:27 vs.https://drafts.csswg.org/css-fonts/#references 17:12:54 Do Github issues have dependencies? 17:14:30 You can link to issues, and there'll be a pingback in the referenced issue. 17:18:46 Here ya go https://github.com/tabatkins/bikeshed/issues/455 17:18:51 :) 17:18:58 danke! 17:20:11 bradk has joined #css 17:50:58 adenilson has joined #css 18:04:42 Florian has joined #css 18:15:56 Florian_ has joined #css 18:22:51 Florian has joined #css 18:24:02 Florian has joined #css 18:28:49 myles1 has joined #css 18:33:25 Using multi-columns, is there a way to force content to break and appear on the next column? 18:33:33 Sort of like page-break-after et al.? 18:36:46 Oh I see there is http://www.w3.org/TR/css3-multicol/#break-before-break-after-break-inside but it hasn't been implemented in Gecko. 18:48:07 zcorpan has joined #css 19:03:25 Zakim has left #css 19:14:30 cvrebert has joined #css 19:15:04 cvrebert has left #css 19:39:57 zcorpan has joined #css 20:02:46 dbaron has joined #css 20:19:15 Reminder to myself: have the *-content properties talk about "entire in-flow contents". 20:25:00 dauwhe_ has joined #css 21:33:29 liam has joined #css 21:44:09 stakagi has joined #css 21:45:50 dbaron has joined #css 21:46:58 stakagi_ has joined #css 22:32:53 liam has joined #css 22:37:05 tgraham` has joined #css