/irc-logs / w3c / #css / 2015-08-05 / end

Options:

# Session Start: Wed Aug 05 00:00:00 2015
# Session Ident: #css
# [00:26] <TabAtkins> plinss: Not destroying the existing .html while regen is pending is *really really* important; they *keep breaking* and rendering the specs unusable.
# [00:38] <fantasai> +1 to what TabAtkins said
# [00:38] <fantasai> It's not okay for our specs to be down for significant periods of time.
# [00:39] <TabAtkins> Basically, if there's no reasonably short timeline for fixing this, I'm going to remove the .gitignore for .html files and regen/commit everything manually.
# [00:46] <fantasai> TabAtkins, write a script for it and dump it in /bin ? :)
# [00:46] <TabAtkins> No need to script it, since it'll be a one-time thing.
# [00:47] <TabAtkins> Because I wouldn't switch it back until plinss says the auto-gen works properly. ^_^
# [00:47] <fantasai> ^_^
# [00:49] <fantasai> TabAtkins : You're emitting a highlight attribute on <pre> elements which is causing validation to fail ?
# [00:49] <fantasai> Can I just remove it?
# [00:49] <TabAtkins> No, it does syntax highlighting. But I can switch it over to data-highlight.
# [00:50] <fantasai> you're already emitting class="lang-css", e.g.
# [00:50] <TabAtkins> oh wait, never mind, you can remove it.
# [00:50] <TabAtkins> And i'll strip it off in generation.
# [00:50] <fantasai> Thanks :)
# [00:51] <TabAtkins> I add a class=highlight already.
# [00:51] <fantasai> yeah
# [00:51] * fantasai wonders why we don't have lang codes for code yet
# [00:52] <fantasai> x-cpp-en-US or en-US-cpp or something
# [00:52] * Joins: jdaggett (~jdaggett@public.cloak)
# [00:53] <TabAtkins> Why make them country or human-language specific?
# [00:53] <fantasai> if you only spoke Chinese, it would be a lot harder for you to read Mozilla's source code because the variables are in English, right?
# [00:54] <fantasai> Some code isn't human-language specific, but most real-life code is
# [00:54] * heycam|away is now known as heycam
# [01:05] * Quits: hgl (~hgl@public.cloak) (Ping timeout: 180 seconds)
# [01:29] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [01:35] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [01:40] * Joins: hgl (~hgl@public.cloak)
# [01:48] <cbiesinger> TabAtkins: https://drafts.csswg.org/css-flexbox/ isn't working :(
# [01:48] <TabAtkins> cbiesinger: We know, see history an hour or so ago. :(
# [01:49] <cbiesinger> oh :)
# [01:49] <cbiesinger> should've brought my printouts to sf
# [01:57] * Joins: jdaggett (~jdaggett@public.cloak)
# [02:15] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [02:35] * Joins: Florian (~Florian@public.cloak)
# [02:36] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [02:39] * Joins: stakagi (~stakagi@public.cloak)
# [02:44] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [03:14] * heycam is now known as heycam|away
# [03:25] * Joins: stakagi_ (~stakagi@public.cloak)
# [03:29] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [03:34] * Quits: stakagi_ (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [03:36] * Quits: myles (~Adium@public.cloak) ("Leaving.")
# [03:59] <astearns> TabAtkins: I mentioned an "I contain paint!" story a while back. I found it and re-read. My recollection of it was much better than the reality
# [03:59] <astearns> so please don't hunt it down - it's not worth it
# [03:59] <TabAtkins> hahahahaha
# [03:59] <TabAtkins> ok
# [04:20] * Joins: estellevw (~estellevw@public.cloak)
# [04:44] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
# [04:57] * Joins: stakagi (~stakagi@public.cloak)
# [05:08] * Joins: estellevw (~estellevw@public.cloak)
# [05:11] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
# [05:13] * Joins: estellevw (~estellevw@public.cloak)
# [05:38] * Joins: Florian (~Florian@public.cloak)
# [05:45] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [05:48] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [05:49] * Joins: jdaggett (~jdaggett@public.cloak)
# [06:31] * heycam|away is now known as heycam
# [06:31] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [06:54] * heycam is now known as heycam|away
# [07:21] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [07:39] * heycam|away is now known as heycam
# [07:49] * Joins: antonp (~Thunderbird@public.cloak)
# [08:02] * Joins: dbaron (~dbaron@public.cloak)
# [08:02] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
# [08:02] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [08:03] * Joins: jdaggett (~jdaggett@public.cloak)
# [08:07] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [08:39] * Joins: Florian (~Florian@public.cloak)
# [08:42] * Quits: hgl (~hgl@public.cloak) (Ping timeout: 180 seconds)
# [08:44] * Joins: hgl (~hgl@public.cloak)
# [08:46] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [09:03] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [09:04] * Joins: jdaggett (~jdaggett@public.cloak)
# [09:29] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [09:30] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [09:37] * Joins: jdaggett (~jdaggett@public.cloak)
# [09:55] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [09:56] * Joins: antonp (~Thunderbird@public.cloak)
# [09:57] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [10:06] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [10:15] * heycam is now known as heycam|away
# [10:45] * Joins: antonp (~Thunderbird@public.cloak)
# [10:49] * Joins: Florian (~Florian@public.cloak)
# [10:54] * leaverou is now known as leaverou_away
# [11:10] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [11:33] * Quits: hgl (~hgl@public.cloak) (Ping timeout: 180 seconds)
# [13:14] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [13:14] * Joins: Florian (~Florian@public.cloak)
# [13:14] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [13:14] * Joins: stakagi (~stakagi@public.cloak)
# [13:15] * Joins: Florian (~Florian@public.cloak)
# [13:15] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [13:15] * Joins: Florian (~Florian@public.cloak)
# [13:22] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [13:26] * Joins: sanja (~sanja@public.cloak)
# [13:50] * Quits: stakagi (~stakagi@public.cloak) ("Leaving...")
# [13:52] * Joins: stakagi (~stakagi@public.cloak)
# [13:52] * leaverou_away is now known as leaverou
# [14:04] * Joins: Florian (~Florian@public.cloak)
# [14:27] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [14:55] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [15:22] * Joins: tgraham (~user@public.cloak)
# [15:38] * Quits: sanja (~sanja@public.cloak) (Ping timeout: 180 seconds)
# [15:55] <fantasai> plinss: I think you need to update the robots.txt ? https://drafts.csswg.org/robots.txt
# [15:56] * Joins: sanja (~sanja@public.cloak)
# [16:28] <fantasai> astearns:
# [16:29] <fantasai> astearns: I think that the forced line breaks should be unconditional, i.e. not only if this is a "valid" break point
# [16:29] <astearns> fantasai:
# [16:30] <astearns> fantasai: context?
# [16:31] <fantasai> astearns: wrap-before: line/flex
# [16:32] <fantasai> astearns: Also, I'm thinking maybe text-wrap: normal should be text-wrap: wrap, to be consistent with flex-wrap
# [16:32] <astearns> OK for line. For flex it would have to be worded to break before/after the containing flex item
# [16:33] <astearns> and I'm fine with wrap instead of normal
# [16:34] <fantasai> astearns: Ah, I see what you mean there.
# [16:35] <fantasai> astearns: I think for flex items, we don't want to propagate outward
# [16:35] <fantasai> astearns: but for inlines we do
# [16:35] <astearns> fantasai: why not propagate?
# [16:35] <fantasai> astearns: This makes sense because inlines all participate in the same formatting context
# [16:35] <fantasai> astearns: the same fragmentation context
# [16:36] <fantasai> astearns: Similarly, we propagate upward through a pagination or columnation context, but not past it
# [16:36] <fantasai> astearns: each flex container is its own fragmentation context, just like each paragraph of line boxes is
# [16:36] <fantasai> astearns: it doesn't make sense for the contents of a flex item to influence the flex item's position in its flex lines
# [16:37] <fantasai> astearns: that content is not participating in the flex line layout
# [16:37] <fantasai> astearns: It might be participating in its own flex line layout, but in that case, those flex lines should trap the break
# [16:38] <fantasai> astearns: the same way that a page break inside "overflow: paged" would not propagate outward to an outer "overflow: paged"
# [16:39] <astearns> fantasai: hmm, I guess I'm thinking of a single flex container, where contents of flex items are really only participating in one flex wrapping context
# [16:39] <fantasai> astearns: in that case, there's no need to propagate upward, right?
# [16:40] <astearns> fantasai: things get wrapped and unwrapped in markup all the time, and it would be annoying to have to change what the break is applied to every time that happens
# [16:40] <fantasai> astearns: you can set the wrap properties on the flex items just fine
# [16:40] <fantasai> astearns: you wouldn't get the effect you're thinking anyway
# [16:40] <astearns> fantasai: how so?
# [16:41] <fantasai> astearns: If I have <container><span><inner></inner></span></container>
# [16:41] <fantasai> astearns: and everything is display: flex
# [16:41] <fantasai> astearns: and let's say there's multiple children of each kind, so we have something to play with :)
# [16:41] <fantasai> astearns: If I force wrap the second <inner>, it'll wrap to a new line *within the <span>*
# [16:41] <fantasai> astearns: and the <container> will still only have one line
# [16:42] <fantasai> astearns: and the second <span> will follow the first <span>, it'll just be taller to accommodate the first <span>'s increased height
# [16:42] <fantasai> astearns: it's not at all like inline layout
# [16:43] <astearns> fantasai: the case I'm thinking of is a single two-line flex container, with one item marked as the last item in the first line
# [16:44] <astearns> fantasai: suddenly something in the design makes it necessary to wrap all of the items in an additional <div>
# [16:44] <astearns> fantasai: now I have some scutwork to do to make the line wrap at the correct place again
# [16:44] <astearns> fantasai: unless the original wrap propagates
# [16:44] <fantasai> astearns: you make the <div> a flex container
# [16:44] <astearns> no
# [16:45] <fantasai> astearns: propagating the original wrap doesn't make sense
# [16:45] <fantasai> astearns: what are you going to break?
# [16:45] <fantasai> astearns: you can't break the <div>
# [16:45] <fantasai> astearns: flex items don't break across lines
# [16:45] <astearns> <container><item><item break><item></container>
# [16:46] <fantasai> astearns: okay, so your goal is 1 and 2 on the first line, 3 on the second
# [16:46] <astearns> <container><div><item></div><div><item break></div><div><item></div></container>
# [16:46] <fantasai> astearns: okay, I see what you mean.
# [16:46] <fantasai> astearns: but now consider this:
# [16:47] <fantasai> <container><container><item><item break> <item></container><container>...</container></container>
# [16:47] <fantasai> astearns: You're saying that, if I happen to remove the third <item>, suddenly the two containers break apart
# [16:48] <astearns> fantasai: ah, I wouldn't think so. you're right that it shouldn't propagate past the flex container
# [16:48] <fantasai> :)
# [16:48] <astearns> fantasai: it should just propagate up to a flex item boundary
# [16:49] <fantasai> astearns: I don't think it should even do that.
# [16:49] <fantasai> astearns: <item>... <div>...</div> ...</item>
# [16:50] <fantasai> astearns: if I put a forced flex break on the div, it has no effect
# [16:50] <fantasai> astearns: because flex items can't fragment across flex lines
# [16:50] <fantasai> astearns: so why would it make sense that it propagates when I remove the third "..." ?
# [16:51] <astearns> fantasai: I'd want the forced flex break to affect the item with or without the third ...
# [16:51] <fantasai> astearns: I don't think that makes any sense...
# [16:51] <astearns> fantasai: :)
# [16:51] <fantasai> astearns: you're saying "div, please force a break after yourself"
# [16:52] <fantasai> astearns: and the div says, "I can't, but maybe my sibling five items back can force a break after himself, and that's kindof after me, right?"
# [16:52] <astearns> fantasai: or, "div, make your flex item break after itself"
# [16:52] <fantasai> astearns: I think you really don't want to do this
# [16:52] <fantasai> astearns: any more than you want a table cell in an inline table to be able to request a forced break after the table
# [16:53] <fantasai> astearns: that's not its job. If we want a break after the table, we ask the table for that break.
# [16:54] <astearns> fantasai: I wouldn't object to making the flex values only work on flex items
# [16:54] <astearns> fantasai: it's just not what I would expect
# [16:54] <fantasai> astearns: inline breaks only work on inline-level items
# [16:54] <fantasai> astearns: why wouldn't flex breaks only work on flex-level items?
# [16:55] <fantasai> astearns: I mean, it'd be different if flex items fragmented. If you could create a flex-level break (forced or unforced) at some midpoint in a flex item
# [16:55] <fantasai> astearns: then it would make sense for stuff inside the item to be able to force that break
# [16:55] <fantasai> astearns: but since that doesn't happen
# [16:55] <fantasai> astearns: it doesn't make sense for stuff inside the flex item to be affecting the flex item's breaking
# [16:55] <astearns> fantasai: I don't think fragmenting flex items in the inline direction makes any sense :)
# [16:56] <fantasai> astearns: it would be in the main axis
# [16:56] <fantasai> astearns: ofthe flex item
# [16:56] <fantasai> flex container, sorry
# [16:56] <astearns> fantasai: right
# [16:57] <fantasai> astearns: propagation is only because we don't want to force a break between an opening tag and its first bit of content or the closing tag and its last bit of content
# [16:57] <fantasai> astearns: that's the only reason it exists
# [16:58] <fantasai> astearns: if we can't break in the middle, then we wouldn't have that problem, so the propagation isn't necessary
# [17:00] <astearns> fantasai: I still think it would be useful to pop up to the containing flex item in my wrapper case, but as I said I won't object to restricting what the flex values apply to
# [17:00] <fantasai> astearns: I think it would be useful, but only in that one particular case
# [17:00] <fantasai> astearns: I think it introduces a lot of problems where you wouldn't expect them otherwise
# [17:01] * Joins: hgl (~hgl@public.cloak)
# [17:01] <fantasai> astearns: the only case it makes sense is "I need to wrap things in a thing, and while I moved all my other flex properties to the container, I didn't want to move the wrapping property"
# [17:02] <astearns> fantasai: fair point that the other flex properties would need to move
# [17:02] <fantasai> astearns: Like, in a case like that you *still* have to move the alignment propertis, the 'flex' property, etc. Why wouldn't you also move wrap-after?
# [17:03] <astearns> fantasai: so my case is reduced further to when you're using the flex defaults
# [17:03] <astearns> fantasai: OK, I'm convinced
# [17:03] <fantasai> ^_^
# [17:04] <astearns> afk for commute
# [17:04] <fantasai> kk
# [17:06] <fantasai> TabAtkins: Why isn't "segment break" exporting from CSS3 Text?
# [17:11] * fantasai having trouble linking to it from css-text-4
# [17:12] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [17:15] * Joins: dauwhe (~dauwhe@public.cloak)
# [17:18] <fantasai> TabAtkins: also, why are we using underscores in anchors in place of hyphens?
# [17:18] <fantasai> http://www.w3.org/TR/css-flexbox-1/#multi_line
# [17:18] <fantasai> That seems weird and unnecessary
# [17:21] * Joins: glazou (~glazou@public.cloak)
# [17:22] * glazou changes topic to 'CSS WG 20150805 conference call - https://lists.w3.org/Archives/Public/www-style/2015Aug/0025.html'
# [17:22] * Joins: RRSAgent (rrsagent@public.cloak)
# [17:22] <RRSAgent> logging to http://www.w3.org/2015/08/05-css-irc
# [17:22] <glazou> RRSAgent, make logs public
# [17:22] <RRSAgent> I have made the request, glazou
# [17:22] * Joins: Zakim (zakim@public.cloak)
# [17:22] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [17:35] * Quits: liam (liam@public.cloak) ("travel")
# [17:55] <glazou> present+ glazou
# [17:55] * Joins: adenilson (~anonymous@public.cloak)
# [17:55] * Joins: dael (~dael@public.cloak)
# [17:56] * Joins: alex_antennahouse (~458c94ae@public.cloak)
# [17:57] * Joins: antenna (~antenna@public.cloak)
# [17:57] <dauwhe> present+ dauwhe
# [17:58] <alex_antennahouse> present+ alex_antennahouse
# [17:58] <dael> present+ dael
# [17:58] <dael> ScribeNick: dael
# [17:58] <astearns> present+ astearns
# [17:59] <antenna> present+ antenna
# [17:59] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [18:00] * Joins: bkardell_ (~uid10373@public.cloak)
# [18:00] * Joins: ChrisL (clilley@public.cloak)
# [18:00] * dauwhe DPUB and annotation WG present+ with real names, CSSWG with IRC nicks. Interesting.
# [18:01] <gregwhitworth> present+ gregwhitworth
# [18:01] <plinss> present+ plinss
# [18:01] <glazou> present+ bkardell_
# [18:01] <bkardell_> present +bkardell_
# [18:01] * Joins: smfr (~smfr@public.cloak)
# [18:02] <antonp> present +antonp
# [18:02] * astearns your real name *isn't* "Dauwhe"?
# [18:02] <smfr> present+ smfr
# [18:02] * Joins: andrey-bloomberg (~andrey-bloomberg@public.cloak)
# [18:02] * dauwhe astearns: my son can now spell it :)
# [18:03] * glazou is melting ; 35° here inside the house
# [18:03] <dael> present+ andrey-bloomberg
# [18:03] * Joins: vollick (~vollick@public.cloak)
# [18:03] * dauwhe glazou: spent July in Ireland, temp was never above 20. Very nice.
# [18:03] <leaverou> present+ leaverou
# [18:03] <glazou> I saw that
# [18:03] <adenilson> present+ adenilson
# [18:04] <vollick> present+ vollick
# [18:04] * Joins: myles (~Adium@public.cloak)
# [18:04] <dael> present+ tgraham
# [18:04] * leaverou glazou A/C is a very useful invention. :)
# [18:05] <ChrisL> present+ ChrisL
# [18:05] <fantasai> present+ fantasai
# [18:05] * Joins: Florian (~Florian@public.cloak)
# [18:05] <dael> glazou: Let's start
# [18:05] <fantasai> glazou, can we add the conf call dial-in #s to the meeting announcement template?
# [18:05] <Bert> Present+ Bert
# [18:05] * fantasai thanks
# [18:05] <dael> glazou: Yes, fantasai I can do that
# [18:05] * sanja is actually present again finally, just came back from doctor who stitched up son's forehead. Doorframes should be abolished.
# [18:05] <dael> 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.
# [18:06] <dael> glazou: Before we start, I'm away the next 3 weeks, so I won'tbe at the f2f.
# [18:06] * fantasai gregwhitworth There was a proposal on how to do this while also accommodating logical values, dunno where it is, but we should put it in css-backgrounds-4
# [18:06] <dael> Topic: containment and overflow.
# [18:06] <SimonSapin> Present+ SimonSapin
# [18:06] * gregwhitworth fantasai: sounds good
# [18:06] <Florian> present+ florian
# [18:06] <dael> bkardell_: To add, I wanted to have a quick regression about has and gaging interest and feedback from MS uservoice on that.
# [18:07] <fantasai> s/gaging/gauging/
# [18:07] <dael> glazou: how much time do you need?
# [18:07] <dael> bkardell_: A minute or two.
# [18:07] * fantasai gregwhitworth pester me about it at the F2F if I haven't dug it up by then :)
# [18:07] <dael> glazou: Let's do that.
# [18:08] <dael> 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.
# [18:08] <ChrisL> the web developers HAVE SPOKEN
# [18:08] <dael> 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.
# [18:08] * gregwhitworth fantasai sure thing, are you against PRs on these? I feel bad with things like this landing on someone's place. Then you could just "spec review" and then merge
# [18:08] <dael> glazou: Comments from others? impl?
# [18:09] <dael> 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.
# [18:09] <sanja> Present+ sanja
# [18:09] <ChrisL> are the performance issues verified or just worries? ie how much are they based on testing?
# [18:10] <dael> 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.
# [18:10] <bkardell_> note it is currently in the spec only in the static profile
# [18:10] <dael> gregwhitworth: So that's where we stand.
# [18:10] <dael> glazou: Other opinions? Is that good for you bkardell_?
# [18:10] <dael> bkardell_: Yep. Other than that in the spec it's only static profile so there shouldn't be perf concern there.
# [18:11] <glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0402.html
# [18:11] <dael> Topic:containment and overflow
# [18:11] <dael> Florian: I think we spoke about that a few times and there was something tricky about the preloader.
# [18:11] <fantasai> 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
# [18:11] <dael> fantasai: What does the preloader have to do with syntax?
# [18:12] * gregwhitworth bkardell_ can we touch base sometime this week to discuss has()?
# [18:12] * Joins: bradk (~bradk@public.cloak)
# [18:12] <dael> 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...
# [18:12] * smfr is confused about the topic. can we have a url please
# [18:12] <glazou> smfr: URL above
# [18:13] <dael> 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.
# [18:13] <glazou> Topic is not containment and overflow
# [18:13] <dael> fantasai: This mail is about double parans in the @import.
# [18:13] <dael> Florian: Okay, ignore that. I'm off topic.
# [18:13] <glazou> Topic: Allowing @import to be conditional on @supports queries
# [18:13] <fantasai> in supports() in @import
# [18:13] <bkardell_> gregwhitworth for sure, hit me up on dm and we can arrange
# [18:13] <dael> glazou: So fantasai you wanted to discuss because it's the last one on the radar?
# [18:13] <fantasai> @import "url" support(<supports-condition>)
# [18:14] <fantasai> @import "url" support((display: flex) and (align-items: start))
# [18:14] <dael> 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
# [18:14] <dael> fantasai: That's fine.
# [18:14] <fantasai> @import "url" support((display: flex))
# [18:14] <fantasai> @import "url" support(display: flex)
# [18:14] <SimonSapin> sounds ok
# [18:14] <dael> fantasai: For very simple cases you end up with the double parans. Can we change the grammer to allow one set of parens.
# [18:14] <dael> glazou: For usability and readability I'd support that.
# [18:15] <dael> glazou: I'd like to hear from others. SimonSapin said okay.
# [18:15] * Joins: MaRakow (~MaRakow@public.cloak)
# [18:15] <dael> SimonSapin: Would this only be @import?
# [18:15] <dael> fantasai: Yeah, because @supports doesn't have parens in itself.
# [18:15] <dael> SimonSapin: Right. I think that's fine.
# [18:15] <fantasai> .supports("(display: flex)")
# [18:15] <dael> fantasai: We might also consider allowing it for the JS .supports
# [18:15] <dael> fantasai: It's not quite the same, but it's similar problem.
# [18:15] <dael> smfr: What would it look like with a not?
# [18:16] <dael> fantasai: You would need parens. Only in the case with just the one thing.
# [18:16] <dael> glazou: Any obj?
# [18:16] * TabAtkins Sorry for the delay, I"ll be there in a sec.
# [18:16] * fantasai is dbaron on the call?
# [18:16] <glazou> fantasai: not sure, no
# [18:16] <dael> 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?
# [18:16] <dael> fantasai: I think it's weirder when it's just in CSS
# [18:16] * Florian apologizes for confusing this topic with another one, and jumping straight in without listening first, which would have avoided wasting everybody's time.
# [18:17] <dael> glazou: It's often the case that we review something because purity and then we find it's ugly and make the change.
# [18:17] <dael> Florian: Sure.
# [18:17] <dael> glazou: So no obj?
# [18:17] * TabAtkins is in now, if someone wants to mark me as the phone that just joined.
# [18:17] <dael> RESOLVED: Default to one stack of paren in the case of one single supports query
# [18:17] * ChrisL we only add ugly things after we have built up enough guilt and missed the deployment window :)
# [18:17] <Florian> present+ TabAtkins
# [18:17] <dael> fantasai: Do we want to extend that to JS and is dbaron on the call?
# [18:18] <dael> SimonSapin: I think rather than default to, I think we want to allow both.
# [18:18] <dael> s/Default/Allow (in resolution)
# [18:18] <dael> 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.
# [18:18] * Florian TabAtkins: marked the last phone as you.
# [18:19] <dael> TabAtkins: Yeah, you can put an infinante amount of parens in a supports.
# [18:19] <dael> RESOLVED: In case of one single supports query the innermost parenthesis are optional in functional notation
# [18:19] <dael> (to take place of last resolution)
# [18:19] <dael> Topic: containment and overflow
# [18:19] * astearns notes that marking people in the WebEx interface is really only useful for force-muting. So it's especially important for Tab to identify himseld
# [18:19] <dael> Florian: We discussed last week, but there is follow-up.
# [18:19] <fantasai> Resolution applies to both JS and supports(), to clarify
# [18:19] <Florian> https://lists.w3.org/Archives/Public/www-style/2015Jul/0461.html
# [18:19] <SimonSapin> In terms of grammar: `something_something : supports_condition | declaration`
# [18:20] * fantasai thanks SimonSapin :)
# [18:20] * Joins: dbaron (~dbaron@public.cloak)
# [18:20] <dael> 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.
# [18:20] * fantasai hi dbaron! we just discussed https://lists.w3.org/Archives/Public/www-style/2015Mar/0402.html Did you have an opinion?
# [18:21] * Joins: estellevw (~estellevw@public.cloak)
# [18:21] <dael> 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?
# [18:21] * glazou smfr, I am pondering jumping to item #6 after this one
# [18:21] <dael> 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.
# [18:22] <dael> 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.
# [18:22] * smfr glazou, myles can talk about that
# [18:22] <glazou> ok
# [18:22] <myles> yes
# [18:22] <glazou> perfect
# [18:22] <dael> 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.
# [18:22] <dael> Florian: I can live with that. it was worth raisining since we're careful about disappearing content.
# [18:23] <dael> smfr: In general when one prop influsences a second prop we've avoided influencing the computed value of the second prop.
# [18:23] <dael> TabAtkins: Yeah, if it computes is a seperate thing.
# [18:23] <dbaron> Present+ dbaron
# [18:23] <dael> Florian: Yes, it's should it automatically overflow: clip or do you have to ask explicitly.
# [18:24] <dael> smfr: I'm with TabAtkins. If you say contain:paint it does everything it's supposed to do.
# [18:24] <dael> Florian: If we resolve this way, there is a follow-up.
# [18:24] <dael> Florian: So proposal, leave the spec as-is.
# [18:24] * fantasai defers to dbaron
# [18:24] <dael> glazou: Obj?
# [18:24] <dael> TabAtkins: smfr and I expressed for the resolution.
# [18:25] <dbaron> fantasai, I think going without the double-parentheses is fine
# [18:25] <dael> RESOLVED: Leave the spec as-is for contain:paint and overflow:clip
# [18:26] <dael> 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.
# [18:26] <dael> Florian: This was raised as ambig on the ML.
# [18:26] <dael> TabAtkins: I'm fine with clarifying the spec.
# [18:26] <bkardell_> +1 to clarify the spec
# [18:26] <dael> Florian: I'm not sure if it's contain or overflow that needs to clarify, but what do we clarify to?
# [18:26] * gregwhitworth I don't know how I feel about this entire spec :/
# [18:26] * glazou gregwhitworth eheh
# [18:26] <bkardell_> I think the way Florian described it makes as much sense as anything
# [18:27] <dael> Florian: The speed argument might apply here where overflow applies first.
# [18:27] <dael> TabAtkins: I'm okay with that. So it changes to auto and you get the contain effect.
# [18:27] <dael> glazou: bkardell_ loves it too. other opinions?
# [18:27] <dael> smfr: contain applies last?
# [18:27] * leaverou gregwhitworth heh, same here
# [18:27] <bkardell_> bkardell_ is ok with it - love is not a word I would use here
# [18:27] <dael> TabAtkins: Yes. If you were otherwise going to be overflow: visible your going to change, but the others would clip auto.
# [18:28] <dael> smfr: scrollbars?
# [18:28] <dael> TabAtkins: You'd still have them, yes.
# [18:28] <dael> 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.
# [18:28] <dael> dbaron: That seems reasonable assuming that we want contain: paint to be scrollable.
# [18:29] <dael> Florian: By default they're not. But if you explicitly ask for scrollbars.
# [18:29] <dbaron> ...which I'm not completely convinced about
# [18:29] <dael> 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.
# [18:29] <dael> glazou: Do we go for the suggested clairifcation?
# [18:30] <dael> TabAtkins: I can clarify contain to make sure it specifies the order of operations
# [18:30] <dael> RESOLVED: clarify contain to make sure it specifies the order of operations
# [18:30] <dael> Topic: 'system' generic font name
# [18:30] <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0169.html
# [18:30] <dael> glazou: It's been on the agenda for three weeks.
# [18:30] * Florian TabAtkins: I will need to reread the containment spec, but I think that was the end of my issues with it.
# [18:31] <dael> 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?
# [18:31] <dael> fantasai: Makes sense to me.
# [18:31] <Bert> KDE has 8 UI fonts
# [18:31] <dael> ChrisL: DO OS only have a single one? Do any have serif and sans-serif or something like that?
# [18:32] * glazou webex is so good I really feel Myles and Chris are in the next room…
# [18:32] <dael> myles: Of the OS I looked at, they have one font family for the UI elements. So this is about font families.
# [18:32] <Bert> q+
# [18:32] * Zakim sees Bert on the speaker queue
# [18:32] * glazou webex’s sound
# [18:32] <dael> 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.
# [18:32] <glazou> Zakim, ack Bert
# [18:32] <Zakim> I see no one on the speaker queue
# [18:33] <dael> 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.
# [18:33] <dael> myles: I think it's viable to not make this very complicated to support KDE.
# [18:34] <dael> 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.
# [18:34] <leaverou> 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)
# [18:34] <dael> ChrisL: I don't think the claim was that this one value would be enough to mimic the UI, just the font.
# [18:34] <bradk> 'Color:system; text-shadow: system'?
# [18:34] <dael> TabAtkins: Yes, it was to just have you mimic the UI. The font used can be jarring if you're trying to look native.
# [18:35] <ChrisL> +1 to what tab said, for spec clarity
# [18:35] <fantasai> bradk, wouldn't work, since different elements have different values for it
# [18:35] <dael> 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.
# [18:35] * gregwhitworth if you do color: system, I'm gonna have issues because we brought this up a year ago :)
# [18:35] <dael> myles: That's fine, I can write something up.
# [18:35] <dael> glazou: Can you answer dbaron proposal in a summary?
# [18:35] <leaverou> TabAtkins: Looking native takes much more than just mimicking the font or text-shadow though
# [18:35] <dael> myles: The prop was to have systme be a function so you can put system menu and get the menu font.
# [18:35] <dael> glazou: And your answer?
# [18:36] <gregwhitworth> I'm less inclined for the system function, but like the system name itself
# [18:36] <Bert> q+ to ask about answer to Nick Doty's fingerprinting issue
# [18:36] * Zakim sees Bert on the speaker queue
# [18:36] <dael> 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.
# [18:36] <dael> 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.
# [18:37] <dael> fantasai: We have this problem already. CSS 2.1 has system keywords already. This gives you less information.
# [18:37] <fantasai> s/system/system font/
# [18:37] <dael> TabAtkins: It's also almost completely subjugated...this allows for no additional entropy except for people that customize their fonts.
# [18:37] <dael> Bert: But this does effect those people.
# [18:38] <dbaron> It's a little annoying to have two different system font mechanisms that work in entirely different ways...
# [18:38] <dael> TabAtkins: Yes, but that entropy is already out there.
# [18:38] <dael> glazou: So in case we resolve on this, maybe a note summerizing Nick Dotis(sp?) message would be good.
# [18:38] <dael> Florian: The message is bringing up the fingerprinting, what does the note say?
# [18:38] <dael> glazou: At least web authors are warned.
# [18:38] <dbaron> s/Dotis(sp?)/Doty's/
# [18:38] <dael> myles: There's no note for the font keywords.
# [18:39] <dbaron> It's not authors who should be warned; it's users.
# [18:39] <dael> TabAtkins: Yes. If we're going to start marking fingerprinting vectors we can be more consistant about that and mark them elsewhere.
# [18:39] <dael> glazou: The W3C started to do more about privacy. I think it's good to have a warning.
# [18:39] <dael> myles: I'm fine with that.
# [18:39] <dael> Florian: I'm just trying to see who should be warned.
# [18:39] <dael> TabAtkins: The most useful target is people producing privacy enhnasing tools.
# [18:40] <dael> Florian: That's a good point.
# [18:40] <dael> glazou: So we accept the new value and its definition with a note in the spec.
# [18:40] <Bert> +1 to a note, even if we don't know how to solve it yet :-)
# [18:40] <dael> RESOLVED: accept the new 'system' value and its definition with a note in the spec.
# [18:40] <dael> fantasai: Who is going to edit this in? we need someone to do the editing work for this.
# [18:41] <dael> TabAtkins: I have a resonably complete fonts 3 that we can port over to fonts 4.
# [18:41] <dael> myles: So is that volunteer?
# [18:41] * gregwhitworth bkardell_ https://lists.w3.org/Archives/Public/www-style/2014Jul/0131.html
# [18:41] <dael> TabAtkins: Well...if no one else is going to do it, I'll put it on the list of specs I'm contibuting to.
# [18:41] <dael> myles: Certainly for this value I was intending on contributing prose.
# [18:42] <dael> TabAtkins: Should I take an action finishing polishing the bikeshed version and create an ED for fonts 4?
# [18:42] * gregwhitworth bkardell_ it has obvious holes that fantasai and tab pointed out
# [18:42] <dael> fantasai: Can we deal with fonts 3 not being bikeshedded?
# [18:42] <dael> ChrisL: Yeah.
# [18:42] <dael> fantasai: I think that's a good idea. Can we get a resolution?
# [18:42] <ChrisL> +1
# [18:42] <dael> Florian: Bikeshed 3, dev 4 TabAtkins as an editor?
# [18:42] <dael> glazou: Obj?
# [18:42] <dael> dbaron: I think it's worth running by jd
# [18:42] <fantasai> s/dev/diff spec/
# [18:42] <dael> s/jd/jdaggett
# [18:43] <dael> ChrisL: Would he obj?
# [18:43] <dael> TabAtkins: He's weekly objected to other things but I can try again.
# [18:43] * gregwhitworth I have to go!! Have a good one :)
# [18:43] * Bert was very confused, I thought "bikeshed" meant "rename"...
# [18:43] <dael> fantasai: Tehre's things he wanted fixed in bikeshed before porting it over.
# [18:43] <dael> glazou: OKay, let's do that.
# [18:43] <bkardell_> gregwhitworth was that meant for me? context? you linked to something about colors?
# [18:43] * dauwhe Bert: :)
# [18:43] <fantasai> fantasai^: so you two should probably coordinate on that
# [18:43] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [18:43] <dael> Topic: HCL colors
# [18:43] <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0098.html
# [18:44] <dael> 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.
# [18:44] <dael> ChrisL: I think we should, I think I have an action to do it. TabAtkins and I need to discuss it.
# [18:44] <dael> 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.
# [18:44] <dael> TabAtkins: I'm fine with that.
# [18:45] <dael> RESOLVED: Add LCH to the spec
# [18:45] <dael> action ChrisL write some language for LCH
# [18:45] * trackbot is creating a new ACTION.
# [18:45] <trackbot> Created ACTION-702 - Write some language for lch [on Chris Lilley - due 2015-08-12].
# [18:45] <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0060.html
# [18:45] <dael> Topic: writing-modes...
# [18:45] <dael> fantasai: I can summerize, but not resolve today.
# [18:46] <dael> 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.
# [18:47] <dael> 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.
# [18:47] <dael> fantasai: You can also rotate 180 in the same line which is also complex.
# [18:47] <bkardell_> gregwhitworth note I didn't comment on colors conversation :)
# [18:47] <dael> 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.
# [18:48] <dbaron> 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.
# [18:49] <dael> 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.
# [18:49] <Florian> q+
# [18:49] * Zakim sees Bert, Florian on the speaker queue
# [18:49] <dael> 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.
# [18:49] <glazou> Zakim, ack Bert
# [18:49] <Zakim> Bert, you wanted to ask about answer to Nick Doty's fingerprinting issue
# [18:49] <Bert> q-
# [18:49] <Zakim> I see Florian on the speaker queue
# [18:49] * Zakim sees Florian on the speaker queue
# [18:49] <glazou> Zakim, ack Florian
# [18:49] <Zakim> I see no one on the speaker queue
# [18:50] <dael> 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.
# [18:50] <dael> 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.
# [18:51] <dael> 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.
# [18:52] <dael> glazou: Okay. We don't have Koji so I suggest we resolve on the ML.
# [18:52] * Joins: liam (liam@public.cloak)
# [18:52] <dael> Florian: Koji is fine. I'mnot sure about jdaggett.
# [18:52] <dael> glazou: We don't have everyone around the table. Lets gather the opinions before we decide.
# [18:52] <dael> glazou: We have 8 minutes. We have Ruby issues, keyframes interaction, whitespace around and/not and max-content contribution.
# [18:53] <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0391.html
# [18:53] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
# [18:53] <dael> Topic: specifying how keyframes interact
# [18:53] <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0332.html
# [18:53] <dael> Topic: remove whitescape around and/not
# [18:54] <Bert> q+ to mention whitespace around "and" in @supports
# [18:54] * Zakim sees Bert on the speaker queue
# [18:54] <dael> 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
# [18:54] <glazou> Zakim, ack Bert
# [18:54] <Zakim> Bert, you wanted to mention whitespace around "and" in @supports
# [18:54] <Zakim> I see no one on the speaker queue
# [18:55] <dael> 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.
# [18:55] <dael> TabAtkins: Yeah, that's process. We can repub as nec.
# [18:55] <dael> glazou: Who is in favor, who objects?
# [18:56] <dael> ChrisL: Sounds good to me.
# [18:56] <fantasai> s/We use two use/We lose two use/
# [18:56] <dael> Florian: As long as @supports is in sync
# [18:56] <dael> RESOLVED: Revert the spec on the whitespace requirement
# [18:56] <glazou> https://lists.w3.org/Archives/Public/www-style/2015Jul/0391.html
# [18:56] <dael> Topic: keyframes
# [18:56] <glazou> Topic keyframes interaction
# [18:56] <fantasai> s/top to bottom left to right/top to bottom Arabic/
# [18:56] <fantasai> s/Ogham/Ogham in a CJK document/
# [18:57] <fantasai> s/Arabic/RTL/
# [18:57] <dael> 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.
# [18:57] <dael> smfr: I think the general algo is correct, but I don't like the word transition since that's a thing.
# [18:57] * glazou animationtainer
# [18:58] <dael> TabAtkins: If you can come up with a better word, that's fine, lay it on me.
# [18:58] <dael> TabAtkins: If anyone has a better name, please tell me and we'll change it.
# [18:58] <dael> TabAtkins: Otherwise, there's nothing specific for that. Review and give a stamp of approval
# [18:58] <dael> action everyone review the proposal so we can approve
# [18:58] * trackbot is creating a new ACTION.
# [18:58] <trackbot> Error finding 'everyone'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
# [18:59] <dael> glazou: There's only a minute left. Thank you everyone, have a good F2F, I'll talk to you in september.
# [18:59] * Quits: alex_antennahouse (~458c94ae@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [18:59] * Quits: glazou (~glazou@public.cloak) (glazou)
# [18:59] * Parts: MaRakow (~MaRakow@public.cloak)
# [19:00] * Quits: sanja (~sanja@public.cloak) ("Page closed")
# [19:02] * dauwhe thank goodness my irc nick isn't "everyone"
# [19:02] <fantasai> TabAtkins: IIRC, one of the issues with the fonts spec was the descriptor tables
# [19:03] * Quits: ChrisL (clilley@public.cloak) ("Client combusted")
# [19:03] <fantasai> 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
# [19:03] * Quits: bradk (~bradk@public.cloak) ("Signing Off. Buh-bye.")
# [19:04] <fantasai> TabAtkins: Where the goal was to have all the values link to their definitions
# [19:05] <TabAtkins> Hm? What's the difference in those two links?
# [19:05] <fantasai> Look carefully at what's linking
# [19:05] <TabAtkins> Yeah, one's Overview.html, the other's implied. What of it?
# [19:05] <fantasai> In the first link, each component value is linked to its definition
# [19:05] * Quits: antenna (~antenna@public.cloak) ("Leaving")
# [19:05] <TabAtkins> I think you gave the wrong links.
# [19:05] <fantasai> In ths econd link, only the <valtypes> are linked
# [19:06] <fantasai> No, I didn't. Look lcoser
# [19:06] <TabAtkins> wtf why are those two links different
# [19:06] <fantasai> Because .htaccess?
# [19:07] <TabAtkins> OH I REMEMBER the current working css-fonts is Fonts.html
# [19:07] <TabAtkins> because reasons
# [19:08] <fantasai> 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
# [19:08] <fantasai> (which you do on occasion...)
# [19:08] <fantasai> And also need to fix a few things in Bikeshed that jdaggett wants fixed
# [19:08] * Quits: smfr (~smfr@public.cloak) (smfr)
# [19:08] <fantasai> One of which is the value grammar components linking to their respective definitions
# [19:09] <fantasai> And another is fixing the descriptor index to generate correctly https://drafts.csswg.org/css-fonts/Overview.html#font-face-descriptor-table
# [19:10] <TabAtkins> Yeah, that's just a matter of marking them up differently.
# [19:10] <TabAtkins> 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.
# [19:11] <fantasai> And a third issue was the references index generating badly
# [19:11] <fantasai> e.g. https://drafts.csswg.org/css-fonts/Overview.html#references
# [19:11] <fantasai> vs.https://drafts.csswg.org/css-fonts/#references
# [19:13] <fantasai> Do Github issues have dependencies?
# [19:14] <TabAtkins> You can link to issues, and there'll be a pingback in the referenced issue.
# [19:18] <fantasai> Here ya go https://github.com/tabatkins/bikeshed/issues/455
# [19:18] <fantasai> :)
# [19:19] <TabAtkins> danke!
# [19:20] * Joins: bradk (~bradk@public.cloak)
# [19:22] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [19:22] * Quits: bradk (~bradk@public.cloak) ("Signing Off. Buh-bye.")
# [19:34] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [19:36] * Quits: dael (~dael@public.cloak) (Ping timeout: 180 seconds)
# [19:51] * Joins: adenilson (~anonymous@public.cloak)
# [20:04] * Joins: Florian (~Florian@public.cloak)
# [20:14] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [20:16] * Joins: Florian_ (~Florian@public.cloak)
# [20:21] * Quits: Florian_ (~Florian@public.cloak) (Client closed connection)
# [20:22] * Joins: Florian (~Florian@public.cloak)
# [20:23] * Quits: andrey-bloomberg (~andrey-bloomberg@public.cloak) ("Page closed")
# [20:23] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [20:24] * Joins: Florian (~Florian@public.cloak)
# [20:28] * Joins: myles1 (~Adium@public.cloak)
# [20:31] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [20:32] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [20:33] <ato> Using multi-columns, is there a way to force content to break and appear on the next column?
# [20:33] <ato> Sort of like page-break-after et al.?
# [20:36] <ato> 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.
# [20:38] * Quits: hgl (~hgl@public.cloak) (Ping timeout: 180 seconds)
# [20:45] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [20:48] * Joins: zcorpan (~zcorpan@public.cloak)
# [21:03] * Zakim excuses himself; his presence no longer seems to be needed
# [21:03] * Parts: Zakim (zakim@public.cloak)
# [21:04] * leaverou is now known as leaverou_away
# [21:04] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [21:04] * Quits: bkardell_ (~uid10373@public.cloak) ("Connection closed for inactivity")
# [21:15] * Joins: cvrebert (~cvrebert@public.cloak)
# [21:15] * Parts: cvrebert (~cvrebert@public.cloak)
# [21:39] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [21:40] * Joins: zcorpan (~zcorpan@public.cloak)
# [21:47] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [21:58] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [22:02] * Joins: dbaron (~dbaron@public.cloak)
# [22:19] <TabAtkins> Reminder to myself: have the *-content properties talk about "entire in-flow contents".
# [22:25] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [22:25] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [22:27] * Quits: vollick (~vollick@public.cloak) (Client closed connection)
# [23:01] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [23:33] * Joins: liam (liam@public.cloak)
# [23:44] * Joins: stakagi (~stakagi@public.cloak)
# [23:45] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [23:45] * Joins: dbaron (~dbaron@public.cloak)
# [23:47] * Joins: stakagi_ (~stakagi@public.cloak)
# [23:51] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# Session Close: Thu Aug 06 00:00:00 2015

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn