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

Options:

# Session Start: Wed May 20 00:00:00 2015
# Session Ident: #css
# [00:02] * Quits: bcampbell (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [00:03] * heycam is now known as heycam|away
# [00:15] * Joins: myakura (~myakura@public.cloak)
# [00:21] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [00:22] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [00:45] * heycam|away is now known as heycam
# [01:19] * Joins: tantek (~tantek@public.cloak)
# [01:28] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [02:04] * Joins: myakura (~myakura@public.cloak)
# [02:11] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [02:34] * Joins: jdaggett (~jdaggett@public.cloak)
# [03:08] * Joins: glazou (~glazou@public.cloak)
# [03:08] * Joins: kwkbtr (~kwkbtr@public.cloak)
# [03:26] * heycam is now known as heycam|away
# [03:30] * Quits: glazou (~glazou@public.cloak) (glazou)
# [03:37] * heycam|away is now known as heycam
# [03:49] * Joins: Florian (~Florian@public.cloak)
# [03:52] * Joins: myakura (~myakura@public.cloak)
# [03:59] * Joins: johanneswilm (~johannes@public.cloak)
# [04:00] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
# [04:04] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [04:07] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [04:13] * leaverou_away is now known as leaverou
# [04:17] * Quits: presenter (~presentation-pc@public.cloak) (Ping timeout: 180 seconds)
# [04:27] * heycam is now known as heycam|away
# [04:30] * Quits: myles (~Adium@public.cloak) ("Leaving.")
# [04:35] * Joins: dauwhe (~dauwhe@public.cloak)
# [04:44] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [04:52] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [04:57] * Joins: shepazu (schepers@public.cloak)
# [05:06] * leaverou is now known as leaverou_away
# [05:20] * Joins: myakura (~myakura@public.cloak)
# [05:33] * heycam|away is now known as heycam
# [05:42] * Quits: myakura (~myakura@public.cloak) ("Leaving...")
# [05:46] * Joins: dauwhe (~dauwhe@public.cloak)
# [05:53] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [06:46] * Joins: dauwhe (~dauwhe@public.cloak)
# [06:54] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [07:09] * Quits: routed (~user@public.cloak) (Client closed connection)
# [07:47] * Joins: dauwhe (~dauwhe@public.cloak)
# [07:54] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [07:58] * Quits: renoirb (renoirb@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [08:48] * Joins: dauwhe (~dauwhe@public.cloak)
# [08:55] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [09:01] * heycam is now known as heycam|away
# [09:03] * Joins: antonp (~Thunderbird@public.cloak)
# [09:06] * Joins: anssik (~uid10742@public.cloak)
# [09:48] * Joins: dauwhe (~dauwhe@public.cloak)
# [09:56] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [09:56] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [09:59] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [10:24] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [10:42] * Joins: lajava (~javi@public.cloak)
# [10:50] * Joins: dauwhe (~dauwhe@public.cloak)
# [10:57] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [11:16] * Joins: johanneswilm (~johannes@public.cloak)
# [11:28] * Joins: hyojin (~hyojin@public.cloak)
# [11:39] * Quits: hyojin (~hyojin@public.cloak) (Ping timeout: 180 seconds)
# [11:50] * Joins: dauwhe (~dauwhe@public.cloak)
# [11:57] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [12:24] * Quits: lajava (~javi@public.cloak) (Client closed connection)
# [12:40] * Joins: webuser (~webuser@public.cloak)
# [12:42] * Joins: jdaggett (~jdaggett@public.cloak)
# [12:44] * Joins: quadcore (~user@public.cloak)
# [12:45] * Joins: kiwiuser (~kiwiuser@public.cloak)
# [12:51] * Joins: dauwhe (~dauwhe@public.cloak)
# [12:58] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [13:20] * Joins: plh (plehegar@public.cloak)
# [13:32] * Quits: quadcore (~user@public.cloak) ("")
# [13:34] * Joins: quadcore (~user@public.cloak)
# [13:43] * Joins: Florian (~Florian@public.cloak)
# [13:51] * Joins: dauwhe (~dauwhe@public.cloak)
# [13:55] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [13:56] * Quits: shepazu (schepers@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
# [13:59] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [14:23] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [14:25] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [14:26] * Joins: Florian (~Florian@public.cloak)
# [14:33] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [14:46] * Quits: anssik (~uid10742@public.cloak) ("Connection closed for inactivity")
# [14:52] * Joins: dauwhe (~dauwhe@public.cloak)
# [14:56] * Joins: dauwhe_ (~dauwhe@public.cloak)
# [14:56] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [15:00] * Joins: tantek (~tantek@public.cloak)
# [15:00] <tantek> running just a bit late - hope to get to Bloomberg by ~9:15-9:20
# [15:01] <tantek> in other news, happy to report that http://www.w3.org/TR/css3-ui/ as of today finally has the draft we resolved to publish 2 weeks ago
# [15:01] * Quits: tantek (~tantek@public.cloak) (tantek)
# [15:06] * Joins: glazou (~glazou@public.cloak)
# [15:12] * Parts: kiwiuser (~kiwiuser@public.cloak)
# [15:17] * Parts: webuser (~webuser@public.cloak)
# [15:19] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [15:24] * Parts: quadcore (~user@public.cloak)
# [15:30] * Joins: Florian (~Florian@public.cloak)
# [15:32] * Joins: johanneswilm (~johannes@public.cloak)
# [15:34] * gsnedder1 is now known as gsnedders
# [15:42] * leaverou_away is now known as leaverou
# [15:43] <TabAtkins> ScribeNick: TabAtkins
# [15:44] <TabAtkins> Topic: UI 3
# [15:44] <TabAtkins> Florian: All recorded issues are closed.
# [15:44] <TabAtkins> Florian: By my own review, there shouldn't be any new issue raised.
# [15:45] <TabAtkins> Florian: We have made a pub request a while ago, it just came in.
# [15:45] * Joins: dbaron (~dbaron@public.cloak)
# [15:45] <TabAtkins> Florian: So this is the stable draft we'd like to take to CR. Tantek and I will send mail to relevant WGs, and we should look at is as a group too.
# [15:45] <TabAtkins> Florian: I don't have any specific points for this spec, unless people would like a tour.
# [15:46] * Joins: bcampbell (~chatzilla@public.cloak)
# [15:46] <TabAtkins> tantek: The bug fixes and issues have been relatively minor, with the exception of box-sizing which got a lot of spec text. It's been reviewed, but if you focus on one piece, take a look at it.
# [15:46] * Joins: renoirb (renoirb@public.cloak)
# [15:47] <TabAtkins> tantek: I think that we're in good shape to go to CR quickly.
# [15:47] <TabAtkins> tantek: So maybe take a week or two to take a look at this, and see if there's anything to raise before we go to CR.
# [15:47] <TabAtkins> fantasai: I'd leave at least 4-6 weeks after you post the announcement before you try to advance.
# [15:48] <TabAtkins> [process wanking]
# [15:49] * Joins: c_palmer (~c_palmer@public.cloak)
# [15:50] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [15:51] <TabAtkins> [intensifies]
# [15:51] <TabAtkins> szilles: Ostensibly the goal was to start negotiating with other groups early.
# [15:51] <fantasai> szilles^: You're assuming people are tracking your draft closely. This isn't necessarily true, especially for peripheral groups.
# [15:52] <TabAtkins> szilles: They dont' want to do multiple reviews, but we don't want to wait until CR, as it's too late to do changes.
# [15:52] <TabAtkins> tantek: We've gone to CR before.
# [15:52] * Quits: c_palmer (~c_palmer@public.cloak) ("Page closed")
# [15:52] * Joins: andrey-bloomberg (~andrey-bloomberg@public.cloak)
# [15:52] <TabAtkins> szilles: But it needs wide review and interest from a11y, as it's UI.
# [15:52] * Joins: c_palmer (~c_palmer@public.cloak)
# [15:52] <TabAtkins> tantek: Right. Most of the draft has already been through CR and thus wide review. Only real new thing is the new box-sizing text.
# [15:53] <TabAtkins> glazou: Point: Leonie Watson joined the group to do a11y review, she should be pinged.
# [15:53] <TabAtkins> florian: I'd just be in favor of four week delay.
# [15:53] <TabAtkins> glazou: Yeah, and I don't think she could do a UI review in two weeks.
# [15:53] <TabAtkins> tantek: Okay.
# [15:54] * Joins: Florian (~Florian@public.cloak)
# [15:54] <TabAtkins> proposed resolution: ping the other WGs; unless there's problematic feedback, go to CR for UI 3 in 4 weeks
# [15:55] <TabAtkins> tantek: Ping www-style, subset of working groups, and Leonie specifically.
# [15:55] <TabAtkins> action tantek to ping groups and Leonie about UI 3 review
# [15:55] * trackbot is creating a new ACTION.
# [15:55] <trackbot> Created ACTION-689 - Ping groups and leonie about ui 3 review [on Tantek Çelik - due 2015-05-27].
# [15:55] <TabAtkins> RESOLVED: ping the other WGs; unless there's problematic feedback, go to CR for UI 3 in 4 weeks
# [15:55] <TabAtkins> SimonSapin: I think box-sizing:padding-box is only in Firefox.
# [15:55] <TabAtkins> tantek: That's why it's at risk.
# [15:56] <TabAtkins> TabAtkins: Afaik, we have no interest in it.
# [15:56] <TabAtkins> Rossen_away: Same.
# [15:56] <TabAtkins> SimonSapin: We have a patch for it in Servo, and was wondering if it should be behind a flag.
# [15:57] <TabAtkins> tantek: We can keep it in CR until we decide to drop it; that's what at-risk is for.
# [15:57] <TabAtkins> fantasai: We shouldn't be encouraging people to implement something that we don't have use-cases for.
# [15:57] <TabAtkins> SimonSapin: That's the issue in Servo, yeah, someone saw it wasn't implemented and wrote a patch.
# [15:58] <TabAtkins> dbaron: Not sure why we implemented it in Gecko.
# [15:58] <TabAtkins> plinss: For completeness. box-sizing was for border-box.
# [15:58] <TabAtkins> TabAtkins: So let's just drop it.
# [15:59] * Quits: andrey-bloomberg (~andrey-bloomberg@public.cloak) (Ping timeout: 180 seconds)
# [15:59] <TabAtkins> 10 for / 0 against / 7 abstain
# [15:59] <TabAtkins> RESOLVED: Drop box-sizing:padding-box
# [16:00] <TabAtkins> SimonSapin: So should we drop it from our impl?
# [16:00] <TabAtkins> dbaron: Maybe, it's used in a few internal places. We can just review and see what they mean, and if they can be replaced.
# [16:00] <TabAtkins> dbaron: I suspect we can remove it.
# [16:00] <TabAtkins> dbaron: NetError page and PrivateBrowsing page, and SearchBar CSS
# [16:01] <TabAtkins> tantek: Drop at CR?
# [16:02] <TabAtkins> fantasai: You're always use-cases, use-cases, use-cases, but here you can't even come up with a theoretical use-case!
# [16:02] <TabAtkins> dbaron: There's two sets of uses. ONe is on an element with padding but no border, so we can just switch to border-box
# [16:03] <TabAtkins> dbaron: The other one might be border but no padding, so it can switch to content-box.
# [16:03] * glazou « You're always use-cases, use-cases, use-cases, but here you can't even come up with a theoretical use-case » sounds like a song, we should write one :-)
# [16:03] * TabAtkins Let's shop it to Tay, see what she can come up with.
# [16:05] <TabAtkins> tantek: I'm okay with dropping it from the draft before we publish in four weeks.
# [16:05] * Joins: Zakim (zakim@public.cloak)
# [16:06] <TabAtkins> fantasai: While on the topic of publishing, Tantek has run into the problem of needing numerous people's approvals to get UI published, because it uses UI props that make the validator unhappy.
# [16:07] <TabAtkins> fantasai: So we should get a resolution that specs can use their own properties in examples.
# [16:07] <TabAtkins> Bert: We can only use properties from CR drafts.
# [16:07] <TabAtkins> tantek: I mean just in examples.
# [16:08] <TabAtkins> fantasai: This is in live examples: here's some code, here's what it should look like, here's what it looks like in your browser.
# [16:08] * glazou well hello Zakim
# [16:08] <TabAtkins> Florian: UI has a lot of images of the desired rendering.
# [16:09] * Joins: SteveZ (~SteveZ@public.cloak)
# [16:09] <TabAtkins> tantek: As an ex-implementor, this was very useful to have them all around.
# [16:09] <TabAtkins> tantek: We've been doing this for years. I think it's accepted and useful.
# [16:09] <TabAtkins> Bert: Can we put the examples somewhere else, not on /TR?
# [16:09] <TabAtkins> TabAtkins: No, the point is inline.
# [16:10] <TabAtkins> tantek: Having them right inline is good for implementors and users.
# [16:10] <TabAtkins> plinss: What does it hurt?
# [16:11] <TabAtkins> tantek: So there's a proposal I've put up; if we want to scope it to live examples rather than spec text, we can go with either.
# [16:11] <Florian> PROPOSAL: “The CSSWG produces drafts that often use new CSS features for live examples, and thus such CSS Validator errors MUST NOT block publishing of such drafts.” The hope is that by resolving on this publicly as a group, we can reduce some of the human-to-human bottleneck in getting drafts published using the current process, and provide a strong case for Echidna dropping or modifying its automatic requirement for CSS validation.
# [16:12] <TabAtkins> plinss: As long as it's forward-compatible, and we don't require it for the correct rendering of the spec.
# [16:13] <TabAtkins> Bert: Maybe I could ask for specially-marked examples that aren't validated...
# [16:13] <TabAtkins> glazou: Let's not ask. We should resolve as a WG.
# [16:13] <TabAtkins> tantek: Resolutions from WGs are great input into the process.
# [16:14] <TabAtkins> fantasai: From what I understand, the webmaster has said to PLH "Hey, this isn't validating. What do?" and PLH says "Is the WG okay with publishing it? If so, go ahead."
# [16:14] <TabAtkins> Bert: PLH isn't in charge of publishing.
# [16:14] <plh> I am
# [16:14] <glazou> thanks plh
# [16:14] <plh> at least, the webmaster comes to me with those questions
# [16:14] <TabAtkins> tantek: This currently adds 48 hours to every publication.
# [16:15] <TabAtkins> glazou: I guess the question is resolved, thanks Philippe.
# [16:15] <TabAtkins> tantek: And this resolution gives PLH better power to say "go ahead" immediately.
# [16:16] <TabAtkins> glazou: How many messages did we exchange about UI publication? 7? 8? It's completely broken.
# [16:16] * Rossen_away is now known as Rossen
# [16:16] <TabAtkins> Bert: If you can get this into the automated process, then it'll take 5 minutes to publish.
# [16:16] <TabAtkins> tantek: Right. And this is step 1. I'll be pushing this further.
# [16:16] * Joins: tantek (~tantek@public.cloak)
# [16:17] <TabAtkins> 13 in favor / 1 object / 2 abstain
# [16:17] <TabAtkins> glazou: Proposal is accepted.
# [16:17] <TabAtkins> RESOLVED: The CSSWG produces drafts that often use new CSS features for live examples, and thus such CSS Validator errors MUST NOT block publishing of such drafts.
# [16:20] <TabAtkins> SimonSapin: When we have things marked at-risk, they're marked in the status section, but not in the feature section. Pretty sure person who implemented box-sizing in Servo didn't see that padding-box was at-risk.
# [16:20] <TabAtkins> SimonSapin: Can we add a note down by where things are defined?
# [16:20] <TabAtkins> TabAtkins: I can probably make this easier in bikeshed, so you can mark a definition as at-risk and it'll notate the status section for you automatically.
# [16:20] <TabAtkins> Topic: CSS UI 4
# [16:20] <Florian> http://dev.w3.org/csswg/css-ui-4/#content-selection
# [16:20] <SimonSapin> SimonSapin: I’ll file an issue on Bikeshed
# [16:20] <TabAtkins> Florian: Starting with user-select.
# [16:20] <TabAtkins> Florian: This existed a long time ago, in precursors of UI.
# [16:20] <TabAtkins> Florian: It disappeared, but got implemented anywhere. There's a fair amount of interop, but not complete, and this spec is trying to work out the details.
# [16:20] <TabAtkins> Florian: Several values, some of which have near-universal agreement, some less so.
# [16:21] <TabAtkins> Florian: Basically everyone supports "text" and "none" with close agreement.
# [16:21] <TabAtkins> Florian: "all" is also widely supported, maybe not all browsers.
# [16:21] <TabAtkins> Florian: "element" is supported in IE, but everyone shows "element'-like behavior when selecting things inside of an editable area.
# [16:21] <TabAtkins> Florian: "element" means if you start a selection inside the element, it'll be trapped to inside of it. This is standard <input> behavior.
# [16:22] * tantek looks for last time user-select was in a TR draft
# [16:22] <TabAtkins> glazou: There's an issue before issue 20.
# [16:22] <TabAtkins> Florian: Says that if a descendant of user-select:none is not user-select:none, it should be selectable. This is tremendously important for template-based editting.
# [16:22] <TabAtkins> s/Florian/glazou/
# [16:22] <TabAtkins> glazou: I'd like it to be marked with a note giving this as the use-case.
# [16:22] <leaverou> Another use case is to prevent user selection interfere with dragging.
# [16:23] <TabAtkins> action Florian to add a note to user-select:none about it's use in template-based editting.
# [16:23] * trackbot is creating a new ACTION.
# [16:23] <trackbot> Created ACTION-690 - Add a note to user-select:none about it's use in template-based editting. [on Florian Rivoal - due 2015-05-27].
# [16:23] <TabAtkins> Florian: "auto" is also interesting. In IE, property isn't inherited, but in most cases, "auto" resolves to inheriting. Some cases it doesn't, like if parent is "element".
# [16:23] <TabAtkins> Florian: Similarly, Moz doesn't inherit this into abspos elements, presumably because they're significantly out-of-flow.
# [16:23] <dbaron> tantek, http://www.w3.org/TR/2000/WD-css3-userint-20000216#dynamic
# [16:23] <TabAtkins> Florian: But it lets floats inherit.
# [16:24] <tantek> dbaron wow that old
# [16:24] <tantek> I thought it made it further
# [16:24] <TabAtkins> Florian: So I've currently specified this as non-inheriting, with "auto" most of the time causing inheritance except for some exceptions explicitly listed.
# [16:24] <TabAtkins> Florian: This is a mix of IE and Firefox behavior.
# [16:24] <TabAtkins> Florian: Next issue - "text" value is strangely named. It doesn't restrict you to selecting text.
# [16:24] <TabAtkins> Florian: It just lets you select anything.
# [16:25] <TabAtkins> Florian: The WK docs say that "text" only selects text, and "auto" selects everything, but that's not true - "auto" computes to "text".
# [16:25] <TabAtkins> Florian: So it's confusing enough to confuse doc writers. But it seems like it's probably too old to change the name.
# [16:25] <TabAtkins> tantek: That's my fault. I gave it a bad name.
# [16:26] <TabAtkins> [CSSWG takes a break to distribute drugs]
# [16:26] <TabAtkins> Florian: So even though the name is unfortunate, I'd like to resolve on keeping it.
# [16:26] <TabAtkins> glazou: You can just turn the issue into a note.
# [16:26] <TabAtkins> tantek: You can add an alias.
# [16:26] <TabAtkins> Rossen: I dont' think the alias will really help anything.
# [16:26] * glazou if I start seeing dancing pink elephants, blame fantasai please
# [16:27] * glazou notes TabAtkins has a rounded display watch… ahem.
# [16:27] <TabAtkins> tantek: One benefit of an alias is that we might be able to compute the old value to the new one, so we only expose the better name.
# [16:27] <TabAtkins> Florian: Maybe, depends on how much script is already depending on it.
# [16:28] <TabAtkins> tantek: We could have it select text, and "may" select otherwise.
# [16:28] <TabAtkins> TabAtkins: No.
# [16:29] <TabAtkins> fantasai: Let's not introduce ambiguity for a naming dispute.
# [16:29] <TabAtkins> RESOLVED: Keep the name "text"
# [16:29] <TabAtkins> Florian: Next value is "none".
# [16:29] <TabAtkins> Florian: Everyone agrees if you start inside the element - don't select.
# [16:29] <TabAtkins> Florian: We disagree if you start outside.
# [16:29] <TabAtkins> Florian: First is start outside, drag into it.
# [16:30] <TabAtkins> Florian: My proposal is to stop at the boundary of the element.
# [16:30] <TabAtkins> Florian: I think this is Firefox's behavior, and Chrome's behavior half of the time.
# [16:30] <TabAtkins> glazou: I think this matches what the user expects.
# [16:31] <TabAtkins> RESOLVED: Selection stops at the end of the user-select:none element, when dragging from outside to inside.
# [16:32] <TabAtkins> glazou: Imagine you click on the inside of the user-select:none, and you drag outside. Do you select the stuff outside?
# [16:32] * SimonSapin Bikeshed issue for at-risk notes next to dfns: https://github.com/tabatkins/bikeshed/issues/410
# [16:32] <TabAtkins> tantek: That drag-out won't every do anything; like clicking down on a button and then dragging out.
# [16:33] <TabAtkins> RESOLVED: Previous resolution means: "if you start outside the user-select:none, and end inside it, the selection stops at the boundary of the user-select:none"
# [16:33] <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Aspan%20%7B%20-moz-user-select%3A%20none%20%7D%0A%3C%2Fstyle%3E%0A%3Cp%3EThis%20is%20%3Cspan%3Esome%3C%2Fspan%3E%20text.%3C%2Fp%3E
# [16:33] <dbaron> (or change to -moz-)
# [16:34] <dbaron> or, better:
# [16:34] <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Aspan%20%7B%20-webkit-user-select%3A%20none%3B%20-moz-user-select%3A%20none%20%7D%0A%3C%2Fstyle%3E%0A%3Cp%3EThis%20is%20%3Cspan%3Esome%3C%2Fspan%3E%20text.%3C%2Fp%3E
# [16:34] <TabAtkins> Florian: When selecting across, this is more complex. Some browsers support multi-ranges, some doesn't. Moz does, WK/Blink doesn't.
# [16:34] <TabAtkins> Rossen: I think IE does.
# [16:35] <TabAtkins> Florian: But the HTML Editing spec (by Aryeh) specifically forbids multi-ranges.
# [16:35] <TabAtkins> Florian: So my proposal is that if you support multi-ranges, and drag across, the selection skips the "none".
# [16:35] <dbaron> (I'm seeing Gecko and Blink match on that testcase.)
# [16:35] <TabAtkins> Florian: If you don't support multi-ranges, the selection includes the "none" when you select across.
# [16:36] <TabAtkins> glazou: I think I commented on that draft a while ago. You need multi-selection for editors.
# [16:36] <TabAtkins> Florian: Agree, but this spec isn't taking a stance.
# [16:37] <TabAtkins> tantek: I think as long as we specify what happens when you have multi-ranges, we're okay.
# [16:37] <TabAtkins> glazou: Agreed.
# [16:37] <TabAtkins> Florian: Subtlety: selections and copying might be different. A single-range selection might not copy the "none" text; at least, it's possible.
# [16:38] <TabAtkins> TabAtkins: I'm also seeing Chrome implement the same as Firefox.
# [16:39] <dbaron> Florian: But in Chrome the part in the middle is in the selection, it's just not highlighted
# [16:39] <TabAtkins> Florian: The visible selection doesn't cover the "none" in Chrome, but if you copy the whole thing shows up.
# [16:39] <dbaron> [Tantek and glazou disagree about which behavior is better]
# [16:39] <TabAtkins> tantek: That's intentional. I wrote "none" to support the ability to select across a "none".
# [16:39] <TabAtkins> glazou: I disagree. As an editor author, I prefer something that actually skips the "none" content.
# [16:40] <TabAtkins> Rossen: Maybe a second value, so both are possible.
# [16:40] <TabAtkins> glazou: That sounds good to me.
# [16:40] <TabAtkins> tantek: I'm okay with that. I think "none" should keep the current behavior, where selecting across a "none" does copy things.
# [16:41] <TabAtkins> dbaron: There's been enough requests, and moz has "none", "all", "-moz-none", and "-moz-all", and they're four different things.
# [16:41] <TabAtkins> Florian: I think "none" and "-moz-none" used to be different, but they've since merged.
# [16:41] <TabAtkins> glazou: So do you agree to investigate the possibility of a second value that actually skips elements?
# [16:42] <TabAtkins> Florian: Where the new value acts the same as "none" in single-range browsers?
# [16:42] <TabAtkins> glazou: Yeah.
# [16:42] <tantek> glazou, I am ok with an additional value that means don't include user-select:none elements inside the selection range.
# [16:42] <TabAtkins> Rossen: Why this exception?
# [16:42] <TabAtkins> Florian: Because it's impossible for a single-select browser to implement it properly.
# [16:42] <dbaron> -moz-user-select: none and -moz-none differ in whether they can be overridden by other values on descendants
# [16:44] <TabAtkins> RESOLVED: selecting across a user-select:none actually does select the contents. Add another value that actually excludes the content, in browsers that support multi-selections.
# [16:45] <TabAtkins> tantek: I think it makes more sense for the split to be at "text" vs "all-text", which controls whether "none" gets skipped or not inside of it.
# [16:46] <TabAtkins> glazou: I can live with that.
# [16:46] <TabAtkins> Florian: So I suggest we don't resolve on the names, you just action me to figure this out.
# [16:46] <TabAtkins> RESOLVED: Rescind previous resolution.
# [16:47] <TabAtkins> action Florian to come up with a resolution for user-select:none being included or not when selecting across.
# [16:47] * trackbot is creating a new ACTION.
# [16:47] <trackbot> Created ACTION-691 - Come up with a resolution for user-select:none being included or not when selecting across. [on Florian Rivoal - due 2015-05-27].
# [16:47] <TabAtkins> Florian: Next is about user-select:element
# [16:47] <TabAtkins> Florian: First is bikeshedding - "element" might not have a lot of usage, so maybe changeable, and I hate "element". Maybe "contain" or "inside"?
# [16:48] <TabAtkins> tantek: Note that all impls are prefixed, so we're probably okay with changing anything.
# [16:49] <TabAtkins> Florian: Maybe, maybe not. Might be a unprefixed "future proofing" in use. But I think it might be okay.
# [16:50] <fantasai> Florian: Firefox parses it, but doesn't do anything with it.
# [16:50] <tantek> unlikely that autoprefixers are being used with this - as this property was DROPPED over 15 years ago
# [16:50] <TabAtkins> Florian: But I don't want to spend a lot of time bikeshedding. Let's move on.
# [16:51] <tantek> before any autoprefixers were even a gleam in anyone's eye
# [16:51] <TabAtkins> Florian: Same issue as "none" applies here. When selecting out->in, or across.
# [16:51] <TabAtkins> TabAtkins: Just do the same as <input> currently.
# [16:51] <leaverou> tantek: Autoprefixers generally work with what browsers support, not what's in the spec. Some of them don't even use a list of properties, they directly get them from the CSSOM.
# [16:52] <tantek> leaverou: autoprefixers DID NOT exist when this property was dropped
# [16:53] <TabAtkins> Florian: I think some browsers differ on whether they select the element as soon as you move in, or wait until you select completely across.
# [16:53] * Joins: anssik (~uid10742@public.cloak)
# [16:53] <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0Afoooooo%3Cinput%20value%3D%22some%20text%22%3Ebarrrrrrrr
# [16:53] <leaverou> tantek: Dropped from *where*? It is supported today, by several UAs and has been for quite some time.
# [16:53] <TabAtkins> TabAtkins: Chrome, at least ChromeOS, doesn't select until you go across.
# [16:54] <TabAtkins> Florian: I think I've specced that behavior.
# [16:54] <tantek> leaverou: from any visible spec
# [16:54] <tantek> you have to work hard to find it anywhere
# [16:54] <leaverou> tantek: Exactly. I’m telling you that as far as most autoprefixers are concerned, this doesn't matter.
# [16:55] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [16:55] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [16:55] <TabAtkins> Looks like IE agrees with Chrome.
# [16:56] <Florian> Proposed resolution: keep the spec as it is
# [16:56] * glazou heard music and it was not the drugs
# [16:56] * shane isn't sure it wasn't the drugs
# [16:57] <TabAtkins> RESOLVED: Keep spec-text for user-select:element as is, unless we uncover platform differences.
# [16:57] * Rossen you guys heard music?
# [16:57] * shane who said that?!
# [16:57] <TabAtkins> glazou: A while ago, user-select:none on an element inside user-select:all wasn't working.
# [16:57] * Joins: andrey-bbg (~andrey-bbg@public.cloak)
# [16:58] <TabAtkins> Florian: I think I'm actioned to figure this out, per tantek's suggestion.
# [16:58] <TabAtkins> Florian: What did you suggest?
# [16:58] <TabAtkins> glazou: It shouldn't select.
# [16:58] <TabAtkins> dbaron: This is actually what none vs -moz-none is for; whether it can override a parent selection mode.
# [16:58] <dbaron> and all vs. -moz-all
# [16:58] <TabAtkins> Florian: I'll keep it in mind when drafting a proposal.
# [16:58] <dbaron> I think
# [16:58] <glazou> right
# [16:59] * Quits: alexmog (~alexmog@public.cloak) ("ZNC - http://znc.in")
# [16:59] <TabAtkins> <br dur=15m>
# [16:59] <leaverou> tantek: Autoprefixer prefixes all values it seems. Check this out: http://codepen.io/leaverou/pen/aOmvJx (inspect <body>)
# [17:01] * Joins: ChrisL (clilley@public.cloak)
# [17:03] * Quits: c_palmer (~c_palmer@public.cloak) (Ping timeout: 180 seconds)
# [17:04] * Joins: vollick (~vollick@public.cloak)
# [17:11] * Rossen is now known as Rossen_away
# [17:12] * Joins: vollick_ (~vollick@public.cloak)
# [17:12] * Quits: vollick_ (~vollick@public.cloak) ("Page closed")
# [17:13] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [17:16] * Joins: tommyjtl (~tommyjtl@public.cloak)
# [17:16] * Quits: tommyjtl (~tommyjtl@public.cloak) ("brb")
# [17:20] * Joins: hyojin_ (~hyojin@public.cloak)
# [17:21] * leaverou is now known as leaverou_away
# [17:25] * Rossen_away is now known as Rossen
# [17:26] * Joins: gregwhitworth_ (~gregwhitworth@public.cloak)
# [17:26] <fantasai> ScribeNick: fantasai
# [17:26] <fantasai> Topic: position: fragment
# [17:26] * leaverou_away is now known as leaverou
# [17:27] <fantasai> Topic: CSS4 UI
# [17:27] * Joins: johanneswilm (~johannes@public.cloak)
# [17:27] <fantasai> leaverou: caret-color in CSS UI
# [17:27] <fantasai> leaverou: many more properties in L4
# [17:27] <fantasai> Florian: 2
# [17:27] <fantasai> leaverou: caret-shape and caret-blink-time
# [17:27] <ChrisL> Carrot colors http://www.sensationalcolor.com/color-for-your-home/gourmet-color/rainbow-carrots-746#.VVynIEZmUgI
# [17:28] <fantasai> leaverou: Rigtht now, authors need to learn another thing for blink time.
# [17:28] <fantasai> leaverou: But for more control, need to set it to zero and use caret-color
# [17:28] <fantasai> leaverou: Would prefer not to learn more properties
# [17:28] <fantasai> leaverou: So suggest a pseudo-element
# [17:28] * glazou ChrisL I often buy such carrots on my town’s market
# [17:28] <fantasai> leaverou: Use CSS Animations in the UA stylesheet
# [17:28] <fantasai> leaverou: Instead of using entirely different mechanism for animation
# [17:28] <fantasai> leaverou: Can't do that without a pseudo-element
# [17:29] <fantasai> leaverou: because if there's an animation in the UA style sheet that controls how the caret animates, then any author animations will override that
# [17:29] <fantasai> leaverou: and the caret will stop animating
# [17:29] * Quits: gregwhitworth (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
# [17:29] <fantasai> leaverou: but with a pseudo-element, wouldn't have that problem
# [17:29] <fantasai> leaverou: Caret is in the paint tree, not in the DOM
# [17:29] <fantasai> leaverou: So could be a problem to have pseudo-element
# [17:30] <fantasai> leaverou: I don't think from author's perspective, they don't care
# [17:30] <Rossen> carrot blink http://gifsanimados.de/img-gifsanimados.de/z/zanahorias/baby-carrot-blinking-md-wht.gif
# [17:30] <fantasai> leaverou: for them it's a separate visual element
# [17:30] <fantasai> leaverou: so better to have as a pseudo-element
# [17:30] <Florian> q+
# [17:30] * Zakim sees Florian on the speaker queue
# [17:30] <fantasai> TabAtkins: What element would it be attached to?
# [17:30] <fantasai> leaverou: The element that ...?
# [17:30] <fantasai> dbaron: Caret is special in a bunch of ways
# [17:30] <fantasai> dbaron: Fits into CSS painting model very oddly
# [17:31] <fantasai> leaverou: Authors don't see/care about that. Just syntax
# [17:31] <fantasai> Florian: Been thinking about this a bit
# [17:31] <fantasai> Florian: I agree with your general statement about animations. Learning multiple ways to animate something is unfortunate.
# [17:31] <fantasai> Florian: And we can't use animations in the UA style sheet unless we have a pseudo-element
# [17:31] * Joins: lajava (~javi@public.cloak)
# [17:31] <fantasai> leaverou: Also, if we add more things to control, don't have to have separate properties
# [17:32] <fantasai> Florian: However, some of these other things can't be done with regular properties
# [17:32] <fantasai> Florian: Color of the caret can't be expressed
# [17:32] <fantasai> Florian: Shape of caret is its own thing
# [17:32] <fantasai> Florian: Interaction is complicated
# [17:33] <fantasai> Florian: Initial value of caret is "give me good contrast", not necessarily currentColor
# [17:33] <fantasai> Florian: color/background-color do not have this value
# [17:33] <fantasai> leaverou: There's a CSS4 color modifier that gets you sufficient contrast
# [17:34] <fantasai> Florian: Can't ask for sufficient contrast with bg and fg
# [17:34] <fantasai> Florian: Case that's important is block caret
# [17:34] <fantasai> Florian: Don't want the caret to disappear
# [17:34] <fantasai> Florian: Presto and IE do color inversion.
# [17:34] <fantasai> Florian: Don't expect that for all browsers, but should be possible.
# [17:35] <fantasai> dbaron: Gecko used to implement, but no longer made sense innew graphics architecture.
# [17:35] <fantasai> leaverou: For block caret, width auto will adjust the width
# [17:35] <fantasai> leaverou: There are 3 shapes in UI4 - auto (usually bar), bar, block
# [17:36] <fantasai> Florian: auto allows flipping into block for insertion mode, e.g.
# [17:36] <fantasai> leaverou: Could make the bar thicker if you want it thicker
# [17:36] <ChrisL> 4 values - auto, bar, block, underline
# [17:36] <fantasai> Florian: The only use case I've seen for setting width explicitly is trying ot get a block.
# [17:37] <fantasai> ...
# [17:37] <fantasai> leaverou: Don't think it's wise to add more if we can use existing CSS properties
# [17:37] <fantasai> Florian: There are properties are close, but not quite. Color is close, but not quite. Shape cant be done.
# [17:38] <fantasai> fantasai: blink time
# [17:38] <fantasai> fantasai: What values does blink time take?
# [17:38] <fantasai> Florian: Only useful values are auto and 0 (don't blink)
# [17:38] <fantasai> Florian: If you want to adjust, use animations
# [17:38] <Florian> s/Only/Mostly/
# [17:39] <fantasai> fantasai: What animations are needed?
# [17:39] <fantasai> Florian: Color fading between light / dark blue
# [17:39] <fantasai> Florian: appear/fade-away
# [17:39] <fantasai> Florian: Can do all of that with animations
# [17:39] <fantasai> leaverou: Would need to reinvent animations
# [17:40] <fantasai> ...
# [17:40] * Joins: smfr (~smfr@public.cloak)
# [17:40] <fantasai> leaverou: Also confusing that the blink is turned off, and some other code turns it on
# [17:40] <fantasai> leaverou: Doesn't seem very usable to me
# [17:40] <fantasai> TabAtkins: In at least IE and probably Chrome our cursor is OS-drawn, so amount of control we have is fairly limited.
# [17:41] <fantasai> TabAtkins: Can change color, can change blink frequency, can only swap between the shapes that are allowed by OS
# [17:41] <tantek> TabAtkins said cursor but meant caret
# [17:41] <fantasai> TabAtkins: So the properties here are as much as we can do
# [17:41] <fantasai> Florian: I've tried to define shape, specifically block and underscore shape, to do something sane wrt the glyph size
# [17:41] <fantasai> Florian: Might not be possible. Could put as should rather than must.
# [17:42] <fantasai> Florian: Requirement to match OS controls is also a reason for this definition.
# [17:42] * smfr questions the sanity of allowing authors to change the caret from something that users recognize
# [17:42] <fantasai> TabAtkins: Even color and width might not be able to fully apply
# [17:42] * astearns IRCCloud yells at me that people are talking about shapes. Oh, never mind.
# [17:44] <fantasai> fantasai: I agree with having just the limited set of properties.
# [17:44] <fantasai> fantasai: Because of the OS integration, the difference in values, all the reasons mentioned
# [17:45] <fantasai> fantasai: Also because pseudo-elements add a lot of complexity, and I don't think it's worth it in this case.
# [17:45] <fantasai> fantasai: I do think the blink-time property needs improvement.
# [17:45] * tantek astearns we've been talking CSS Shapes for years http://tantek.com/CSS/Examples/polygons.html
# [17:45] <smfr> blink time is system-controlled. why should auathors be able to change it?
# [17:45] <fantasai> fantasai: The only thing you can animate is the color, really. I would suggest defining the animation using the standard animations syntax, but invoke it with a special caret-animation property
# [17:46] <leaverou> s/But for more control, need to set it to zero and use caret-color/But for more control, you need to set it to zero and use a CSS animation over caret-color/
# [17:46] <fantasai> fantasai: That way it won't interfere with regular animations, you won't have the cascading problem, but you can still use the standard animation syntax.
# [17:46] * astearns tantek I'm not sure any of those are good for caret rendering
# [17:46] <leaverou> s/Would prefer not to learn more properties/Would prefer authors didn’t have to learn more properties that duplicate existing functionality/
# [17:46] <fantasai> fantasai: and we have keywords for the common cases
# [17:46] <fantasai> fantasai: That would allow both contorlling the blink time, also animating between blue and dark blue, as mentioned.
# [17:47] <leaverou> s/The element that ...?/The element that is being edited/
# [17:47] <fantasai> Florian: I'm happy to explore something along the lines of what fantasai said.
# [17:47] <fantasai> Florian: Before we move on to next topic, want to draw implementers attention to another point:
# [17:47] <fantasai> Florian: I'm specifying how painting can work.
# [17:47] * tantek astearns true, I'll have to see if I can find a triangular caret
# [17:47] <fantasai> Florian: Since there are system-specific restraints, not being super precise
# [17:47] <fantasai> Florian: But trying to define in a way that's not useless
# [17:47] <fantasai> Florian: Please look at spec and tell me if you can do that.
# [17:48] <fantasai> Bert: Doesn't say what caret looks like when not focused
# [17:48] <leaverou> s/Also, if we add more things to control, don't have to have separate properties/Also, if in the future we want to add more things to control, with a pseudo-element we wouldn’t need to add even more properties/
# [17:48] <fantasai> Bert: Might be same color but not blink, or less bright color, or something like that.
# [17:48] <fantasai> Florian: I went with assumption that if not focused, don't show caret.
# [17:48] * Joins: tgraham (~user@public.cloak)
# [17:48] <leaverou> s/There are 3 shapes in UI4 - auto (usually bar), bar, block/There are 3 shapes in UI4 - auto (usually bar), bar, block, underline/
# [17:49] <fantasai> Bert: Want to show where you were typing before in unfocused window, but should still show some shape
# [17:49] <fantasai> plinss: In OS X the terminal window will change from solid box to open box.
# [17:49] <fantasai> Florian: Will look into existing behavior, bring up to group
# [17:50] <fantasai> plinss: Concerns me that we're adding more and more things that would be trivial by adding pseudo-element
# [17:50] <fantasai> Florian: I'm not sure pseudo-element is so trivial
# [17:50] <fantasai> Florian: Unless we want to go into 'appearance', that's it for UI4
# [17:51] <fantasai> Florian: So far I've been speccing things I've wanted, and things people have asked for.
# [17:51] <fantasai> Florian: Not at FPWD yet, but getting coser
# [17:51] <fantasai> Florian: If something else should be in here, let me know
# [17:51] <fantasai> Florian: I might add a focusable property
# [17:51] <fantasai> Florian: This relates to directional nav-up/down etc.
# [17:52] <fantasai> Florian: If you say next item in navigation is an unfocusable item, then it becomes focusable
# [17:52] <fantasai> Florian: You might want to target that element, but focus the next (in dom depth traversal) focusable element
# [17:52] <dbaron> https://wiki.csswg.org/planning
# [17:52] <fantasai> TabAtkins: Investigating similar things with Shadow DOM
# [17:52] <fantasai> Topic: Next meeting
# [17:53] <fantasai> glazou: For next meeting, suggest you book your flight asap
# [17:53] <fantasai> Rossen: Houdini is also confirmed for 2 days after CSSWG meeting
# [17:53] <fantasai> SimonSapin: Please add your name if you are coming
# [17:53] <fantasai> SimonSapin: On both wikis if you are coming to both
# [17:54] <fantasai> glazou: Next meeting after is Sapporo in Japan
# [17:54] <fantasai> glazou: There are plenty of small AirBnB flats nearby, found one for ~30 euros per night.
# [17:54] <fantasai> glazou: walking distance from venue
# [17:55] <fantasai> glazou: In terms of flying to Sapporo, you will have two choices
# [17:55] <fantasai> glazou: Buy tickets through large airlines, or choice of low-cost airlines within Japan
# [17:55] <fantasai> glazou: But hard to find if you try to find through regular reservation search
# [17:56] <fantasai> plinss: Group of ppl arranging a road trip. Also pre-TPAC scuba diving in Okinawa. So if interested, let me know.
# [17:56] <fantasai> Florian: I suggest considering also the train
# [17:56] <fantasai> Florian: Great ticket you can only buy from outside Japan that gives you unlimited rides in Japan
# [17:56] <fantasai> glazou: Going to meet first days of the week: Mon-Tues
# [17:56] <fantasai> glazou: Plenary meeting on Wednesday
# [17:56] <fantasai> glazou: Originally scheduled to have 30 seats only
# [17:57] <fantasai> glazou: Suggested that 30 is probably not enough, if we include observers. Closer to 35/40.
# [17:57] <fantasai> glazou: They will try to change the room if possible
# [17:57] <fantasai> Rossen: FX meeting?
# [17:57] <Florian> "Japan Rail Pass" gives you unlimited train for a set period of time for a good price (Including all but the fastest shinkansen).
# [17:57] <fantasai> ChrisL requests during thursday-frid
# [17:58] <fantasai> glazou: Next meeting proposal is for Sydney
# [17:58] <fantasai> shane: There were some concerns about prices of lodging in Sydney
# [17:58] <fantasai> shane: The suggested hotels were quite expensive
# [17:58] <fantasai> shane: I wanted to share research with you
# [17:59] <fantasai> shane: Flights to/from Sydney from SF stopping in Fiji ~$1200/$1300
# [17:59] <fantasai> shane: from Paris ~ 800 euros
# [17:59] <fantasai> shane: If we resolve on dates, and price-sensitive ppl book soon, should be affordable
# [17:59] <fantasai> shane: wrt accommodation, booking.com has hotels for as low as $60/night
# [17:59] <fantasai> shane: USD
# [18:00] <fantasai> shane: Not super-close to venue, but in the city, so easy to get transport
# [18:00] <fantasai> shane: Also lots of deals on AirBnB places.
# [18:00] <fantasai> shane: 3-bed range from $250/night up
# [18:00] <fantasai> TabAtkins: Place we stayed is now $600
# [18:00] * Joins: AH_Miller (~mike@public.cloak)
# [18:00] <fantasai> SteveZ: We used a serviced apartment near the park
# [18:01] <fantasai> SteveZ: It was really nice. 44th floor, looking at city
# [18:01] <fantasai> shane: I can't do anything about the length of time to get there
# [18:01] <fantasai> shane: or about the jet lag
# [18:01] <fantasai> iank: But we have lots of caffeine. Would make everyone coffee
# [18:01] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [18:01] <fantasai> glazou: Okay, let's look at dates
# [18:02] <fantasai> [discussion of dates]
# [18:02] <fantasai> SimonSapin: FOSDEM is first week of February
# [18:02] * Quits: vollick (~vollick@public.cloak) (Ping timeout: 180 seconds)
# [18:03] * Joins: webuser (~webuser@public.cloak)
# [18:04] <fantasai> [discussion of when FOSDEM might be]
# [18:05] * Quits: andrey-bbg (~andrey-bbg@public.cloak) (Ping timeout: 180 seconds)
# [18:05] * tantek notes that Super Bowl 50, and Huntington Beach Surf City Half Marathon, and likely Kaiser Half Marathon, are all on Sunday February 7th.
# [18:08] * tantek that is 2016-02-07
# [18:08] <fantasai> [juggling dates]
# [18:08] <ChrisL> Resolved: Valentine's day more important to @csswg than FOSDEM
# [18:08] <tantek> wow
# [18:08] <dbaron> plinss, when is the TAG meeting around then?
# [18:08] <fantasai> Proposal:
# [18:08] * plinss jan 19-21
# [18:08] <fantasai> CSSWG Feb 1-3 (M-W)
# [18:08] <fantasai> Houdinin Jan 30-31 (Sat Sun)
# [18:08] * dauwhe_ ChrisL: LOL
# [18:08] <fantasai> SVG Feb 6-8 (W-F)
# [18:09] <dbaron> https://wiki.csswg.org/planning/sydney-2016
# [18:09] <fantasai> s/6-8/3-5/
# [18:09] <fantasai> FOSDEM expected on the 6th/7th
# [18:10] <fantasai> shane: also possible to shift forward by 1 day
# [18:10] <glazou> PROPOSAL is Houdini 30/31-jan, CSS WG 1/3-feb, SVG 4/5-feb
# [18:11] <fantasai> glazou: Next meeting after that...
# [18:11] <fantasai> glazou: TPAC was US West Coast
# [18:11] * Quits: hyojin_ (~hyojin@public.cloak) (Ping timeout: 180 seconds)
# [18:11] <fantasai> glazou: Then we didt Australia
# [18:11] <fantasai> glazou: US East Coast
# [18:11] <fantasai> glazou: Paris
# [18:11] <fantasai> glazou: Japan
# [18:11] <fantasai> glazou: Australia
# [18:11] <fantasai> dbaron: TPAC 2016 likely to be Europe
# [18:12] <fantasai> glazou: Likely to have one of the meetings in between Australia and TPAC 2016 to be US West Coast
# [18:13] <fantasai> proposal for San Diego
# [18:13] <fantasai> in May
# [18:13] <fantasai> SteveZ: Adobe can also host in San Jose or SF
# [18:13] <liam> [if anyone is interested in meeting alongside libregraphicsmeeting.org in London next May there's aparrently meeting space]
# [18:14] <tantek> SF is preferred by SF residents :)
# [18:14] * Quits: smfr (~smfr@public.cloak) (smfr)
# [18:14] <fantasai> dbaron: Probably want to wait on solving dates, to sort out AC meeting etc.
# [18:14] * Joins: smfr (~smfr@public.cloak)
# [18:14] <astearns> SF is preferred by non-SF residents
# [18:14] <glazou> SD is preferred by some non-US residents too
# [18:15] <fantasai> Aiming for May, details later
# [18:15] * astearns SF over SJ, that is
# [18:16] <tantek> astearns: yes, SF > SJ
# [18:16] <fantasai> [discussing locations for August]
# [18:16] <tantek> but we're ok with SD
# [18:16] <tantek> might even prefer SD
# [18:16] <fantasai> If TPAC is in Europe, then maybe move West Coast to August and West Coast in May
# [18:16] <fantasai> dbaron: Suggest waiting for locations of AC meetings
# [18:17] <fantasai> dbaron: Also other conferences in May, may or may not have dates for those yet
# [18:18] * Rossen is now known as Rossen_away
# [18:21] * Quits: gregwhitworth_ (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
# [18:21] * Parts: webuser (~webuser@public.cloak)
# [18:23] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [18:25] * Quits: AH_Miller (~mike@public.cloak) ("")
# [18:25] * Joins: AH_Miller (~mike@public.cloak)
# [18:29] * Quits: AH_Miller (~mike@public.cloak) ("")
# [18:30] * Quits: smfr (~smfr@public.cloak) (smfr)
# [18:30] * Joins: AH_Miller (~mike@public.cloak)
# [18:30] * Joins: dael (~dael@public.cloak)
# [18:45] * Quits: dael (~dael@public.cloak) (Ping timeout: 180 seconds)
# [18:54] * Quits: AH_Miller (~mike@public.cloak) ("")
# [18:55] * Joins: vollick (~vollick@public.cloak)
# [18:56] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [18:56] * Joins: Florian (~Florian@public.cloak)
# [18:57] * Quits: robertknight_clo (~sid15951@public.cloak) ("")
# [18:57] * Joins: robertknight_clo (~sid15951@public.cloak)
# [19:03] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [19:04] * Joins: Florian (~Florian@public.cloak)
# [19:05] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [19:05] * Joins: Florian (~Florian@public.cloak)
# [19:12] * Quits: Bert (bbos@public.cloak) (Client closed connection)
# [19:12] * Joins: Bert (bbos@public.cloak)
# [19:15] * Joins: jcraig (~jcraig@public.cloak)
# [19:16] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [19:18] * plinss changes topic to 'CSS WG ftf, hosted by Bloomberg in NYC ; https://wiki.csswg.org/planning/new-york-2015#agenda'
# [19:19] * Rossen_away is now known as Rossen
# [19:19] <fantasai> ScribeNick: fantasai
# [19:19] <fantasai> Topic: position: fragment
# [19:22] <fantasai> Rossen: This was a discussion on position: fragment.
# [19:23] <fantasai> Rossen: fantasai pointed out that when I published the FPWD of the Positioning draft, I left in the position: page feature that the WG had required to leave out
# [19:24] <fantasai> Rossen: Going back to this feature, and why it's useful
# [19:24] <fantasai> Rossen: When we proposed the position: paged value
# [19:24] <fantasai> Rossen: We didn't have fragmentation spec
# [19:24] <fantasai> Rossen: We didn't at the time have the notion of overflow: fragments
# [19:24] <fantasai> Rossen: and [...]
# [19:25] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [19:25] <fantasai> Rossen: I created one example
# [19:25] <fantasai> [Shows example of an article about New York]
# [19:26] <fantasai> Rossen: One use case was people trying to either annotate or put some kind of marking with the content that they have that flows through some potentially fragments
# [19:26] <fantasai> [example has first paragraph in one big block, then a narrow column next to a wide column
# [19:28] <fantasai> Rossen: Only thing that I added, was to mark some section of the text
# [19:28] <fantasai> Rossen: with a marker element
# [19:28] <fantasai> Rossen shows a little triangle on top of the word "With" in a random position in the paragraph
# [19:29] <fantasai> Rossen: We have two markers that are inline with the text
# [19:29] <fantasai> Rossen: One of the use cases that we got requested at the time
# [19:29] <fantasai> Rossen: was that people wanted to, besides having markers inline, wanted to position those with respect to the fragment that they happen to be in
# [19:29] <fantasai> Rossen: If I position the marker left, just with left: 0
# [19:30] * Quits: mihnea_____ (~sid16310@public.cloak) ("")
# [19:30] <fantasai> Rossen: Because the top position will be taken from the static inline position, will be in the same line of text
# [19:30] * Joins: mihnea_____ (~sid16310@public.cloak)
# [19:30] <fantasai> Rossen: but shifted to the start of the line
# [19:30] * TabAtkins is in his way back now
# [19:30] <fantasai> Rossen: Problem becomes when we try to position the top
# [19:30] <fantasai> Rossen: Position: absolute says that you have to find the nearest abspos containing block
# [19:30] <fantasai> Rossen: Since there are no such, it's the initial containing block
# [19:30] <fantasai> Rossen: which is the first region
# [19:31] <fantasai> Rossen: So both markers end up overlapping on top of each other
# [19:31] <fantasai> Rossen: This is why we want to position relative to the nearest fragmentainer
# [19:31] <fantasai> Rossen: Previously we had this name, that I didn't like, position: page.
# [19:31] <fantasai> Rossen: Prefer it to be called position: fragment
# [19:31] * Zakim excuses himself; his presence no longer seems to be needed
# [19:31] * Parts: Zakim (zakim@public.cloak)
# [19:31] <fantasai> Rossen: Both markers positioned with respect to their own fragmentainer
# [19:32] * Joins: johanneswilm (~johannes@public.cloak)
# [19:32] <fantasai> Rossen: Two markers show up wherever the containg fragmentainer of the marker is
# [19:32] * fantasai invite Zakim
# [19:32] <Florian> q+
# [19:33] * Joins: Zakim (zakim@public.cloak)
# [19:33] <fantasai> Rossen: If I change my template to be a multicolumn, same thing should apply
# [19:33] <fantasai> Rossen: Stay in the corresponding column
# [19:34] <fantasai> Rossen shows a different article
# [19:34] <fantasai> It has four columns
# [19:34] <fantasai> Title and header spans two columns
# [19:34] <fantasai> Rossen: They used position: fragment for the ads
# [19:35] <fantasai> Rossen: This is only about positioning, nothing to do with exclusions
# [19:35] <fantasai> Rossen: Wanted to resume the discussion about this feature
# [19:35] <fantasai> Rossen: And pursue a route where we can re-add it to the positioning spec
# [19:35] <Florian> q-
# [19:35] * Zakim sees no one on the speaker queue
# [19:36] <fantasai> Florian: I completely agree with you on the use cases.
# [19:36] <fantasai> Florian: However, I disagree with you that treating this and exclusions and collisions as separate topics is a good idea
# [19:36] <fantasai> Florian: If you have two markers in the same column, they are going to overlap with each other.
# [19:36] <fantasai> Florian: This is not very robust
# [19:36] <fantasai> Florian: It's especially a problem because the author may look in iPad screen size and it's fine
# [19:36] <fantasai> Florian: But on a different device, it overlaps
# [19:37] <fantasai> Florian: Page floats, which are also poorly named, aim to solve the same problem
# [19:37] <fantasai> Florian: While dealing with exclusions and collisions at the same time
# [19:37] <fantasai> Florian: Admittedly the page floats spec is not yet very mature
# [19:37] <fantasai> Florian: But I think it is a better approach to solving these problems.
# [19:37] <fantasai> Florian: Also works better with column span
# [19:38] <fantasai> Florian: Spanning 2 columns is reasonably common
# [19:38] <fantasai> Florian: This feature needs more work, but I think it's a more promising approach.
# [19:38] <fantasai> Florian: That said, I really agree with the use cases, and we should solve them.
# [19:38] <fantasai> Florian: So I'm not saying we don't work on this topic
# [19:38] <fantasai> Florian: Just a question of which approach we take to deal with that.
# [19:38] <fantasai> fantasai: I'm 100% in support of what Florian said
# [19:38] <fantasai> Rossen: So you're saying there are no use cases for abspos
# [19:39] <fantasai> Florian: I'm not saying there are no use case for abspos
# [19:39] <fantasai> Florian: But there are use cases that you will try to solve with abspos
# [19:39] <fantasai> Florian: But would be beter solved with page floats
# [19:39] <fantasai> Florian: More robust, that is, better handled in variable environments
# [19:40] <fantasai> Rossen: Page floats is combination of two features, positioning with respect to fragment, and exclusion
# [19:40] <fantasai> Florian: Three features: also collision avoidance. That's an important feature.
# [19:40] <fantasai> Rossen: If we agree that there are use cases and need to have these as three separate features
# [19:40] <fantasai> Rossen: Being able to position something wrt fragment, and it not necessarily being an exclusion
# [19:41] <fantasai> Rossen: This is a marker, but could easily be a menu
# [19:41] <fantasai> Rossen: Gets tagged along in the appropriate fragment
# [19:41] <fantasai> Rossen: Usable without affecting the content
# [19:41] <fantasai> Rossen: Which is an ebook reader that does this for annotations and note taking
# [19:41] <fantasai> Rossen: You want to keep your notes relative to where you took the notes
# [19:41] <fantasai> Rossen: And you want to present the menu without destroying the content
# [19:41] * fantasai points out that two menus on top of each other is not smart either
# [19:41] <fantasai> Rossen: You want to keep it in the fragmentainer it appears in
# [19:42] <fantasai> Rossen: Not necessarily affecting the content.
# [19:42] <fantasai> Florian: I would agree that this use case exists
# [19:42] <ChrisL> so it is for a popover (that does not cause reflow)
# [19:42] <fantasai> Florian: But what I'm concerned about is the exclusions and collision-avoidance being opt-in rather than opt-out
# [19:42] <fantasai> Florian: By default, you have exclusion and collision-avoidance. And if you really want to not have those, you turn them off.
# [19:43] <fantasai> Florian: Otherwise authors will create layouts that work on their own screens, and don't work on others
# [19:43] <fantasai> Florian: Absolute positioning is useful and dangerous
# [19:43] <fantasai> Florian: If we can make a positioning system that is not dangerous by default
# [19:43] <fantasai> dbaron: I worry less about things with exclusions but not collision-handling, than things that have neither.
# [19:44] <fantasai> dbaron: Since exclusions appear to avoid collisions, but don't.
# [19:44] <fantasai> Florian: I would much rather solve page floats, and have a property that lets you opt out of exclusions, than the other way around.
# [19:45] <fantasai> plinss: I want to build page floats out of primitives
# [19:45] <fantasai> plinss: Explain floating before we add new types of floating
# [19:45] <fantasai> Florian: Problem if we do it this way is that the simple way of using it will not be the safe way of using it
# [19:45] <liam> [note from IRC, exclusions/intrusions, floats, spanning & stacking is one of the hardest problems in layout & it really does help to view them all together]
# [19:45] * ChrisL spec for new, unsafe ways of floating. shortname: css-sinking-1
# [19:46] <fantasai> Florian: You will get all the problems authors have with unanticipated collisions would still be there
# [19:46] <fantasai> ...
# [19:46] <fantasai> Florian: In the other example, what happens if both images end up in the same colum ('cuz your screen is taller than you expected, or whatever)
# [19:47] <fantasai> Rossen shows an example
# [19:47] <fantasai> Florian: This example only has one image
# [19:48] <fantasai> ...
# [19:49] * Quits: birtles (~sid16523@public.cloak) ("")
# [19:49] * Joins: birtles (~sid16523@public.cloak)
# [19:49] <fantasai> fantasai: <gives an example>
# [19:49] <fantasai> Rossen: I'm not talking about abspos
# [19:49] <fantasai> fantasai: Neither am I
# [19:49] <fantasai> Rossen tells fantasai that she's complaining about abspos and he's not talking about abspos
# [19:50] <Florian> q+
# [19:50] * Zakim sees Florian on the speaker queue
# [19:50] * glazou and all WG hides
# [19:50] <fantasai> s/<gives an example>/Your menu example is also broken. Say you wanted the menu at the top of each section. You use position: fragment to put it there. If on my screen both sections end up on the same page, because my screen is taller than yours (e.g. I use portrait and you use landscape), then the menus will end up both at zero coord in the same fragmentainer, and thus lay on top of each other. And one menu is thus unusable/
# [19:51] <fantasai> [room shuts up while fantasai updates the minutes]
# [19:51] <fantasai> Rossen: You can fix the problem by using Javascript
# [19:52] <fantasai> johanneswilm: Wrt primitives, I can see the point that page float is a lot of very complex things, and you would want something that is simpler and you use JavaScript on top of that
# [19:52] <fantasai> johanneswilm: But I don't see how this would help me in doing that.
# [19:53] <fantasai> johanneswilm: I could place the things manually with JS anyway.
# [19:53] * Bert thinks the problem is that people have a model in mind to solve a use case and are unable to see that there are other models, in this case e.g., float or (foot)notes or transformations with JS or XSLT, instead of abspos.)
# [19:53] <fantasai> Rossen: How would you place things at the top left of the region
# [19:54] <fantasai> johanneswilm: I would figure out what region I'm in, figure out what the coordinates are, then I would create a new region flow for this one element, I then put it in the place where I need to put the piece of content that I want to put at the top of this fragment
# [19:54] <fantasai> johanneswilm: I put it there, maybe make it an exclusion, maybe change its coordinates to avoid overflow
# [19:54] <fantasai> Rossen: You would break region chain to make this work
# [19:54] <fantasai> johanneswilm: It can be done
# [19:54] <fantasai> Rossen: How would you do it with columns or pages
# [19:54] <fantasai> johanneswilm: Don't know about the APIs for columns or pages, I'd use regions
# [19:55] <fantasai> johanneswilm: I would create a new flow for things I took out of flow, then place those with javascript
# [19:55] <fantasai> johanneswilm: Can be done that way today
# [19:55] * astearns s/Can/Has/
# [19:55] <fantasai> johanneswilm: If this does not exist for columns so far, don't see why you wouldn't just add that to columns
# [19:55] <ChrisL> multiple named flows, aka "how FrameMaker did it"
# [19:55] <fantasai> johanneswilm: Rather than create something new that you can't actually use in a production environment without a ton of JS to manage collisions
# [19:56] <fantasai> Florian: I agree that you're not creating something totally new,
# [19:56] <fantasai> Florian: But you are addressing a new use case by extending the reach of abspos to do things it couldn't do before
# [19:56] <fantasai> Florian: And it would solve these use cases, but not particularly well, and require JS
# [19:56] <fantasai> Florian: We have the ability to address these use cases without these problems.
# [19:57] <fantasai> Florian: So I'm in favor of doing it there.
# [19:57] <fantasai> Bert: This use case is the same use case as footnotes
# [19:57] <fantasai> Bert: You want something at the edge of the region
# [19:57] <fantasai> Bert: Goes into a special region, if that special region is empty, it disappears
# [19:58] <fantasai> Bert: So here you have a region dedicated to an image. If there's an image you put it there. if not there's no such region
# [19:58] <fantasai> johanneswilm: For footnotes, you want the footnote on the same place as the marker
# [19:58] <astearns> solving a use case with an integrated system that doesn't require javascript usually results in a dead-end that cannot be extended to more use cases
# [19:58] <fantasai> s/place/fragmentainer/
# [19:58] <fantasai> johanneswilm: There's much more complexity in making sure the markers fit on same page as footnote
# [19:59] <fantasai> johanneswilm: Footnotes are different than page floats
# [19:59] <fantasai> leaverou: What I don't understand about this discussion is why we can't just do ::region { position: relative }
# [19:59] <fantasai> leaverou: That would solve that use case, unless I misunderstood what the issue is.
# [19:59] <fantasai> dbaron: Two comments
# [20:00] <fantasai> dbaron: To respond to Lea, one of the issues with making abspos relative to the first fragment
# [20:00] <fantasai> leaverou: Didn't suggest that, it's terrible
# [20:00] <astearns> we should certainly consider positioning, wrap and avoidance together, but we should provide primitives for each separately that are manipulable by javascript
# [20:00] <fantasai> dbaron: One of the issues is what happens to pages where the user prints, but the author didn't think about printing when they designed the page?
# [20:01] <fantasai> leaverou: Many use cases for positioning, many for page floats.
# [20:01] <fantasai> leaverou: But abspos already exists
# [20:01] <fantasai> leaverou: Should spec something that does the reasonable thing
# [20:01] <fantasai> leaverou: All abspos things going ot the first fragment makes no sense
# [20:01] <fantasai> dbaron: The use case of printing stuff when author wasn't thinking about printing is probably a significant chunk of the printing that happens on the Web
# [20:01] <fantasai> leaverou: Very small segment of printing in the publishing industry
# [20:02] <fantasai> leaverou: who print sweb pages
# [20:02] * dauwhe_ lots of use cases for collision avoidance, too. Common problem when trying to do interesting things in Prince.
# [20:02] <fantasai> plinss: Last time I saw stats form HP, over 50% of things coming out of HP printers was a web page
# [20:02] * astearns so we just need to fix that web page to print properly
# [20:03] <fantasai> dbaron: Second comment I have is in reply to Florian, who said something about how this wasn't introducing new problems with abspos
# [20:03] <dauwhe_> s/print sweb/prints web/
# [20:03] * glazou and HP thanks the french government surveillance law for its stats :-)
# [20:03] <fantasai> dbaron: One thing it does introduce that's different is problem fantsai is worried about
# [20:03] * tantek glazou SMH
# [20:03] * Joins: BradK (~bradk@public.cloak)
# [20:03] <Florian> q+
# [20:03] * Zakim sees Florian on the speaker queue
# [20:03] <fantasai> dbaron: What happens if author designs it and it works, and then user's display fragments them both
# [20:04] <fantasai> s/both/differently, resulting in two things that were on separate pages appearing on the same page/
# [20:04] <fantasai> dbaron: These are two separate problem
# [20:04] * tantek glazou http://www.urbandictionary.com/define.php?term=smh
# [20:05] <fantasai> dbaron: One of my comments is about why abspos associated with first fragment
# [20:05] * tantek glazou what time is the break?
# [20:05] * tantek needs to get some serious espresso
# [20:05] <fantasai> dbaron: And one is about why we want collision-avoidance should be built in by default
# [20:06] * glazou tantek aren’t we discussing breaks right now?-)
# [20:06] * tantek glazou we are discussing broken breaks now.
# [20:06] * glazou tantek that will be funnier the day we discuss unbroken breaks :-D
# [20:06] <fantasai> leaverou: I think page floats should exist and abspos should exist
# [20:07] <fantasai> Rossen: I didn't say that page floats shouldn't exist
# [20:07] * glazou can’t wait for negative zero breaks
# [20:07] * tantek glazou br {display:none}
# [20:07] <fantasai> Florian: Because you are trying to use this mechanism to address use cases that are better solved with page floats
# [20:07] <fantasai> Florian: This will solve those cases poorly and get implemented fast because it's easier
# [20:07] <leaverou> s/Very small segment of printing in the publishing industry/Very large segment of printing in the publishing industry/
# [20:07] <fantasai> Florian: And then we have these problems, and lose incentives for implementing page floats
# [20:08] <leaverou> s/leaverou: who print sweb pages/leaverou: but few users print web pages/
# [20:08] <fantasai> Florian: If we want to try to solve these use cases, we shouldn't solve them with this.
# [20:08] <fantasai> Florian: Would prefer to solve page floats first.
# [20:08] * tantek glazou playing violin = time for break
# [20:08] * ChrisL pistols at dawn
# [20:09] * glazou tomahawks forbidden, guys
# [20:09] <fantasai> [argument over whether page floats is relevant to this discussion. Rossen says they're irrelevant to this discussion. Florian says that they're relevant because the use cases Rossen is bringing up as a justification are better solved by page floats]
# [20:09] <fantasai> dbaron: I don't think this is a realistic use case
# [20:09] * astearns break-avoid: filibuster
# [20:09] <fantasai> dbaron: You need to have realistic use cases for people to understand what you want
# [20:09] <fantasai> leaverou: Here's a case
# [20:09] <fantasai> leaverou: In my book, I have code areas that have a page background
# [20:10] <fantasai> leaverou draws a box with some text inside
# [20:10] <fantasai> leaverou: I wanted when they were broken across pages to have a zigzag top edge, zigzag bottom edge
# [20:10] <fantasai> leaverou: I used box-decoration-break: clone
# [20:10] * glazou smells the break-style property arriving :-)
# [20:11] <fantasai> leaverou: In my use, there can only be two fragments total, so doesn't scale
# [20:11] <fantasai> leaverou: use pseudo elements
# [20:11] <fantasai> leaverou: to hide the zigzag border on the first and last boxes
# [20:11] <fantasai> dbaron: What we want to do for satisfying case of printing ...
# [20:12] * glazou AFAIC, this is the first time we draw the waves from the Knossos palace during a CSS ftf meeting :-)
# [20:12] <ChrisL> the hiding is a workaround. It would be better to specify styling of broken edges directly
# [20:12] <fantasai> dbaron: The behavior you want for printing in order to print ...
# [20:13] <fantasai> dbaron: The problem is we don't have a name for this thing
# [20:13] * fantasai agrees with ChrisL
# [20:13] <fantasai> dbaron: The goal is we want web pages that were not designed for printing to print reasonably
# [20:13] * glazou ChrisL: what I said, break-style
# [20:13] <fantasai> dbaron: The way to handle abspos to solve that goal
# [20:13] * ChrisL should maybe say it, then.
# [20:13] <fantasai> dbaron: Is that top is relative to the top fragment, and bottom is relative to the bottom fragment
# [20:14] * Joins: dael (~dael@public.cloak)
# [20:14] <fantasai> dbaron: so that still works
# [20:14] <fantasai> Oh, yeah. There's totally buggy abspos printing behavior
# [20:14] <fantasai> leaverou: Might want pseudo-elements to target fragments
# [20:14] <fantasai> ChrisL: I would characterize what you did ther eas a workaround.
# [20:14] <fantasai> ChrisL: If we wanted to solve that use case, we would style top breaks and bottom breaks differently
# [20:15] <fantasai> leaverou: Or just target the fragments to style differently, not targetting the breaks
# [20:16] <fantasai> Rossen: If you specify top: 0; bottom: 0; top 0 shoudl attach to the top of the first fragment, and bottom should apply tot the bottom of the last fragment
# [20:16] <dbaron> (I *think* Gecko only has the bug fantasai is thinking about when the bottom is a large enough number to push something back to an earlier page.)
# [20:16] <fantasai> Rossen: I'm still not able to work within a single fragment
# [20:16] * Quits: anssik (~uid10742@public.cloak) ("Connection closed for inactivity")
# [20:16] <fantasai> Florian: This ties into page floats
# [20:16] <fantasai> Rossen: If you want something attached to the bottom of your fragmentainer, then you can float it
# [20:16] <fantasai> s/Rossen/Florain
# [20:17] <fantasai> Florian: You get additional things with the page floats approach
# [20:17] <fantasai> Florian: Ability to float to the right or left, next column, avoid colliding when both at the top of the same fragmentainer, float left on odd pages, right on even pages
# [20:17] <fantasai> Florian: We et all of these with page floats
# [20:17] <fantasai> Florian: On the author side, if they use position: fragment, they will think they solved the problem when really they didn't
# [20:18] <fantasai> Florian: And on the implementer, same thing, they will think they solved the use cases when really they didn't
# [20:18] <fantasai> [discussion of use cases]
# [20:18] * glazou if we ever write that « Use Cases » song, it’s going to be main hit of 2015 :-D
# [20:19] * leaverou please do it glazou!!
# [20:19] <fantasai> Florian: Of these markers you have, what happens if they're on the same page? Theyll overlap
# [20:19] <fantasai> Rossen: Same problem you have with abspos
# [20:19] <fantasai> Florian: Sure, but the author sees that problem as well
# [20:19] <fantasai> Florian: In this case, author might not see the problem, but user sees the problem.
# [20:19] <fantasai> Florian: We should design systems that avoid this problem: where the author sees the result they want and it breaks on the user's computer
# [20:20] * glazou leaverou I could reuse a Tom Jones’ music
# [20:20] <fantasai> Florian: Also, we have opt-in exclusions, but we don't have opt-in collision-avoidance
# [20:20] <leaverou> s/ Might want pseudo-elements to target fragments/ Might want pseudo-elements to target fragments and a :fragments pseudo-class for elements that are fragmented, perhaps with an optional an+b parameter for number of fragments (e.g. :fragments(n+3))/
# [20:21] <fantasai> fantasai: Ok, now that we've repeated the arugment we had last time we discussed this, do we have any conclusions?
# [20:21] * glazou the music of « sex bomb » by Tom Jones would be perfect
# [20:22] <fantasai> leaverou: So if by default, abspos are psotioned like dbaron suggested, why can't we just apply position relative to the fragment?
# [20:22] <fantasai> leaverou: This would be opt-in behavior.
# [20:22] * glazou maybe we need another round of this morning’s drugs ?-)
# [20:24] <fantasai> fantasai explains the issue to leaverou again, but forgets what she said
# [20:24] <fantasai> fantasai: So could have e.g. page floats, with a switch that turns off exclusion and/or collision-avoidance behavior
# [20:25] <fantasai> fantasai: Which would have the default behavior to avoid overlap
# [20:25] <fantasai> fantasai: And only has overlap if specificaly requested
# [20:25] <fantasai> Rossen: That seems reasonable to me
# [20:25] <fantasai> Rossen: seems smiliar
# [20:25] <fantasai> Florian: Difference is defaults
# [20:26] <fantasai> Rossen: ...
# [20:26] <fantasai> Florian: I think you mischaracterized what I' mproposing
# [20:26] <fantasai> Florian: Idea is to have a switch that applies to page floats, to turn off exlcusions/avoidance
# [20:26] <fantasai> Florian: Page floats have a definition for exclusions, have a definition for avoidance
# [20:26] * Joins: myles (~Adium@public.cloak)
# [20:26] <fantasai> Florian: You can turn them off. But they exist already
# [20:27] <fantasai> Florian: But if you have a generic switch, like you're proposing, have to define how they work for everything
# [20:27] <fantasai> Florian: I tried to define a generic collision-avoidance property that works for everything. And that's hard.
# [20:27] <fantasai> Florian: But floats have that
# [20:27] <fantasai> Rossen: Because they have a very simple model
# [20:27] <fantasai> Rossen: Exclusions can apply to other layout models, too, though.
# [20:27] <fantasai> Rossen: Not always bound to page or fragment
# [20:27] <fantasai> Rossen: Can create templates that have nothing to do with ...
# [20:28] <fantasai> Rossen: I get what you're saying. You want to restrict feature so only used on fragmentainers
# [20:28] <fantasai> s/feature/page floats/
# [20:28] <fantasai> Florian: page floats work [on all these things]
# [20:28] <fantasai> Rossen: What about on grid?
# [20:28] <fantasai> Rossen: Exlcusions work on everything
# [20:29] <fantasai> Florian: This is also a discussion we had when we discussed exclusions
# [20:29] <astearns> page floats haven't yet been defined well enough to say whether they work [on all these things] or not
# [20:29] <fantasai> Florian: There were significant negative feedback on exclusions. Not because of exlcusions themselves, but because they made it more tempting to use abspos in cases where you would not have used abspos before
# [20:29] <fantasai> Rossen: Almost everyone uses exclusions on top of grid
# [20:30] <fantasai> ...
# [20:30] <fantasai> johanneswilm: The reason that the page floats spec only talks about the fragmentation is that we tried to keep it as simple as possible
# [20:30] <fantasai> johanneswilm: And we thought there might not be much reason to doing more than that
# [20:30] <astearns> grid positioning can end up with some of the same collision problems people see with abspos
# [20:30] <fantasai> johanneswilm: But no opposition to doing it for more
# [20:30] * fantasai yes, but again, you'll see it in all cases, not sensitive to resizing
# [20:31] <fantasai> Bert: You might want to float something, e.g. a callout, only if there isn't already one
# [20:31] <fantasai> Bert: If I have place for two, float both. Otherwise float one, don't do second one.
# [20:31] <fantasai> Bert: Conditional float or something
# [20:31] <fantasai> Bert: This seems to be what you'd want to do with your marker
# [20:31] <fantasai> Bert: Similar to how running headers are done.
# [20:31] <fantasai> Bert: You put current title at the top
# [20:31] <fantasai> Bert: If two sections start on this page, you don't put the second one in the running header
# [20:32] * glazou would love to have conditional air conditioning too…
# [20:32] * astearns fantasai - so if it's a problem, you can fix it with either changing the grid positioning or by opting in to wrap with exclusions. I do not think people will want to solve grid collisions with automatic collision avoidance
# [20:34] <fantasai> Rossen: What now? fantasai: There's no consensus, so we don't move forward
# [20:34] * Quits: BradK (~bradk@public.cloak) ("Buh bye")
# [20:34] <fantasai> fantasai: I think if you want to bring this up again, you need use cases for your solution that aren't problematic with your solution (and better solved with page floats)
# [20:34] <fantasai> fantasai: If there's a use case where the problematic behaviors of this solutions are stregths for that use case, then that'd be convincing.
# [20:35] <fantasai> fantasai: But if you only have use cases for which your solution is problematic, then we'd want a better solution
# [20:35] <fantasai> plinss: page floats on its own is violating the extensible web principles
# [20:35] <fantasai> plinss: I'd much rather have the primitives to build page floats than to have page floats
# [20:36] <astearns> I'd like to have both: page floats built on top of those primitives
# [20:36] <fantasai> Florian: My reservation with this approach is that primitives are problematic when using them indpeendetly is borken, and must only be used in combination
# [20:36] <fantasai> plinss: It's a power tool
# [20:36] <fantasai> plinss: Can do cool new wonderful things
# [20:36] <fantasai> plinss: that we don't come up with
# [20:36] <astearns> and I disagree that using them independently is broken
# [20:36] <fantasai> johanneswilm: is that what the definition is for primitives?
# [20:37] <fantasai> johanneswilm: I think all you need is exclusions, and ability to position things in Javascript
# [20:37] <fantasai> Rossen: And C, collision-avoidance if needed
# [20:37] <fantasai> Rossen: I say yes to all of them
# [20:37] <astearns> collision avoidance can be scripted
# [20:37] <fantasai> plinss: Giving them primitives doesn't mean they have to be JS
# [20:37] <fantasai> plinss: page floats can be a shorthand for these other properties
# [20:38] <fantasai> fantasai: ...
# [20:39] <fantasai> Rossen: I can have collision-avoidance in 2 months
# [20:39] <fantasai> fantasai: Great, bring up your proposal.
# [20:39] <fantasai> dbaron: When you talk about primitives, I'm not sure that the primitives that we want to describe CSS on top of are also CSS.
# [20:39] <fantasai> plinss: I think primitives are conceptually CSS. Not necessarily switches exposed through CSS properties and values
# [20:39] * dauwhe_ is now known as dauwhe
# [20:39] <fantasai> plinss: Should be conceivable as properties, even if we don't expose
# [20:40] <fantasai> dbaron: Yes, and I'm not convinced that absolute positioning is the primitive we want
# [20:40] * Joins: gregwhitworth_ (~gregwhitworth@public.cloak)
# [20:40] <fantasai> plinss: We all dislike floats, they're weird in their interactions.
# [20:40] <fantasai> plinss: Why are we building on top of floats?
# [20:40] <fantasai> plinss: Want it to be predictable
# [20:41] * tantek likes rootbeer floats.
# [20:41] * tantek especially likes espresso floats, AKA affogattos.
# [20:41] <fantasai> Florian: Wrt primitives, I think it would be good to have exclusions and collisions (which we don't have)
# [20:42] <fantasai> Florian: and they're auto
# [20:42] <fantasai> Florian: floats have them, and abspos don't
# [20:42] <fantasai> Florian: I think we should be careful about the order we add these in, and we should be careful in defining auto
# [20:42] * Rossen is now known as Rossen_away
# [20:43] <fantasai> Florian: We agree on the end result, but we don't agree on the path, and don't agree on auto
# [20:43] <fantasai> Florian: I would rather have page floats, explained through auto value of these properties, and you can turn it off
# [20:44] <fantasai> plinss: If the idea is do X before Y then let's not decide on "don't do Y"
# [20:44] <fantasai> Florian: It's not obvious that what's proposed today is necessary, if we solve page floats
# [20:44] <fantasai> Florian: Majority of the use cases discussed here are solved by page floats
# [20:44] * Quits: gregwhitworth (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
# [20:45] <fantasai> Florian: If page floats ends up solving all of them, then this switch doesn't need to exist
# [20:45] <fantasai> Florian: We're not done exploring page floats, we should do that.
# [20:45] * glazou notes the oldest float is Noah’s arch
# [20:46] <fantasai> fantasai: Ok, so how do we wrap up this discussion?
# [20:46] * Bert : The primitives would be things like: position A near B, position A not before B, position A near the top, position no more that X things of type A on the same page, position A at least Y em from B, etc. display A, do not display A and B in the same region...
# [20:46] <fantasai> plinss: Doesn't seem like continuing the discussion is the right way to go
# [20:46] <fantasai> plinss: I would like to hear more ways this proposal could move forward.
# [20:46] * liam +1 to Bert's examples
# [20:46] <fantasai> Florian: For me, I would like to see that there are use cases that are *better* solved with this than with page floats
# [20:47] <fantasai> Florian: Otherwise I am not convinced.
# [20:47] <fantasai> gregwhitworth_: If I want to put at the bottom, and not exclude, then what?
# [20:47] <fantasai> johanneswilm: Turn off exclusions
# [20:48] <fantasai> plinss: I want page floats explained exactly how it works
# [20:48] <fantasai> plinss: If all we have is page floats property, but explained very clearly in terms of the concepts building it up
# [20:48] <fantasai> plinss: and even don't have switches for these things, but could add them later
# [20:48] <fantasai> plinss: Then that's fine
# [20:49] <fantasai> plinss: I want to see it explained in terms of CSS primitives, basic concepts, that are generic that can explain other aspects of CSS layout
# [20:49] <fantasai> fantasai, florian, johanneswilm all 100% in favor of this
# [20:49] <fantasai> Florian: ...
# [20:50] <fantasai> plinss: If we have use cases to have a switch, yes, we add it
# [20:50] <fantasai> Florian: We don't know whether the switch is useful or not
# [20:50] <fantasai> Florian: if it is we expose it
# [20:50] <fantasai> plinss: Rossen, that works for you?
# [20:51] <fantasai> RESOLVED: Page floats way better defined, less magic, potential switches (even if not exposed)
# [20:51] <fantasai> s/potential/as potential/
# [20:51] <fantasai> johanneswilm: I didn't bring up page floats at this meeting is exactly because it's not precise enough yet
# [20:51] <fantasai> Topic: flexbox order a11y
# [20:52] <fantasai> Bo: There's an a11y concern with Flexbox, wrt WCAG 1.2 and meaningful sequence
# [20:52] <fantasai> Bo: I've learned a bit since then
# [20:52] <fantasai> Bo: Focus is more specific
# [20:52] <fantasai> Bo: when we were talking about holy grail layout with flexbox
# [20:52] <ChrisL> http://www.w3.org/TR/WCAG20/#content-structure-separation
# [20:52] <fantasai> Bo: Being able to reorder things visually without changing logical order
# [20:52] * Quits: kwkbtr (~kwkbtr@public.cloak) ("")
# [20:52] <ChrisL> Guideline 1.3 Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
# [20:52] <fantasai> Bo: All fine, until you change a visual sequence that's meaningful to the reader
# [20:52] <fantasai> Bo: e.g. you chang eheader and nav of a page
# [20:52] <fantasai> Bo: and you move those around
# [20:52] <ChrisL> 1.3.2 Meaningful Sequence: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. (Level A)
# [20:53] <fantasai> Bo: The sequence doesn't matter
# [20:53] * Quits: dael (~dael@public.cloak) (Ping timeout: 180 seconds)
# [20:53] <fantasai> Bo: It does cause problems with person using keyboard + magnifier
# [20:53] <fantasai> Bo: I think we're overlooking that
# [20:53] <fantasai> Bo: Key issue is that within one of these sections
# [20:53] <fantasai> Bo: If you have nested flexbox in there, and sequence of items in there, logical order is important
# [20:53] <fantasai> Bo: And you have flipped them with flexbox 'order'
# [20:53] <fantasai> s/flipped/rearranged/
# [20:54] <fantasai> Bo: As I understand it, reverse is still reading in logical order
# [20:54] <fantasai> Bo: For 'order', Firefox uses visual order right now
# [20:54] <fantasai> Bo: We like that
# [20:55] <fantasai> Bo: Proposal is really about, discussion about, the option for an author to say that "I'm changing the order of a meaningful sequence, and ..."
# [20:55] <fantasai> Bo: If I'm using flexbox to reorder something visually, and the sequence in the DOM no longer makes sense (e.g. to screen reader)
# [20:55] <fantasai> Bo: Then there should be an option to say that this is a meaningful sequence, let's go through the visual order
# [20:56] <fantasai> ChrisL: I heard you say you wanted two things: read through DOM sequence and read through visual sequence
# [20:56] <fantasai> ChrisL: And the trigger for that is when the DOM sequence no longer makes sense
# [20:56] <fantasai> ChrisL: When the visual order has changed, in a way that changes the meaning
# [20:56] <fantasai> Bo: The example I use when teaching designers is "how to use a defibrillator" in 4 steps
# [20:57] <fantasai> ChrisL: But what you said is that "order in the DOM no longer makes sense"
# [20:57] <fantasai> ChrisL: I can't imagine anyone making a How to use defibrillator with DOM in the incorrect order
# [20:57] <fantasai> ChrisL: Why wouldn't you just put it in the right order in the DOM?
# [20:58] <fantasai> plinss: Maybe ad-injection?
# [20:58] <fantasai> ChrisL: Yeah, there's content you need and content you unfortunately get.
# [20:58] <fantasai> leaverou: You have a list of topics in a forum
# [20:59] <fantasai> leaverou: Some have class=stick, cuz you want them pinned at the top
# [20:59] <fantasai> leaverou: posts are in the chronological order
# [20:59] <fantasai> leaverou: Use order: 1 to move to the top
# [20:59] <tantek> e.g. pinned posts, http://indiewebcamp.com/pinned
# [20:59] * Quits: gregwhitworth_ (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
# [20:59] <fantasai> Bo: ... more examples
# [20:59] <fantasai> Bo: What we're forcing authors to do, if we say in the spec, you have to follow meaningful sequence
# [20:59] <fantasai> Bo: And you have an entire page with flexbox in the middle of another section, and need to rearrange that
# [20:59] <leaverou> s/Some have class=stick, cuz you want them pinned at the top/Some have class="sticky" or "pinned", cause you want them pinned to the top/
# [21:00] <fantasai> Bo: Forced to use tabindex through your entire page
# [21:00] <fantasai> Bo: No easy solution to make the page accesible
# [21:00] <fantasai> Bo: Spec says you need to use tabindex
# [21:00] <fantasai> fantasai: What? No...
# [21:01] <fantasai> ChrisL: What it's saying is, for an a11y tool which is not reading the style sheet but which wants to get the same reading order that would get using a style sheet
# [21:01] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [21:01] <fantasai> ChrisL: Suggestion is to redundantly encode using taborder
# [21:02] <fantasai> fantasai: That sounds terrible
# [21:02] <tantek> tantek: it's a classic example of DRY violation
# [21:02] <tantek> (DRY) http://indiewebcamp.com/DRY
# [21:03] <fantasai> fantasai: The spec says if the sequence change is meaningful, the DOM should be reordered
# [21:03] <dbaron> http://dev.w3.org/csswg/css-flexbox-1/#order-accessibility
# [21:03] <fantasai> Bo: Authors are doing this for perf reasons, in order to not update the DOM
# [21:03] <fantasai> Florian: I think that's the critical point
# [21:04] <fantasai> Florian: a) Authors are writing incorrect order for various reasons, and then correcting with flexbox.
# [21:04] <ChrisL> yeah I was arguing that it was terrible (in case my comments could be read the other way)
# [21:04] * Rossen_away is now known as Rossen
# [21:04] <fantasai> Florian: We should not fix flexbox, shouldn't try to make a right out of a double-wrong, when flexbox can be used correctly.
# [21:05] * ChrisL you can't make a silk purse from a sow's ear
# [21:05] * glazou tantek I need an espresso too I think
# [21:05] <fantasai> Florian: b) There are two valid meaningful orders, one which is in the DOM, and which is correct (if was incorrect, reorder DOM). But *another* meaningful order is expressed in stylesheet
# [21:05] <fantasai> Florian: and want to be able to follow that ordering
# [21:06] <fantasai> fantasai: Closest case for b is I think leaverou's example
# [21:06] <fantasai> tantek: This presentation order vs. dom order issue isn't new to flexbox
# [21:06] <fantasai> tantek: Every layout mechanism allows you to do this.
# [21:06] <fantasai> tantek: What's the general approach, rather than picking out Flexbox?
# [21:07] * Quits: bcampbell (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [21:07] <fantasai> [ppl list various layout modes]
# [21:07] <fantasai> tantek: Happening for decades.
# [21:07] <fantasai> fantasai: They've been complaining for decades
# [21:07] <fantasai> tantek: How do we solve this *class* of problems?
# [21:08] <fantasai> tantek: I could recreate this problem in many different ways
# [21:09] <fantasai> fantasai: Tantek is saying, we should address this problem as a class.
# [21:09] <fantasai> fantasai: 'order' is just the most staightforward expression of this problem. Makes it seem simple to solve because it's an explicit control, but can get the same problem as implict result of layout calculations
# [21:10] <fantasai> tantek: There's more examples of this problem with float than flexbox, given its legacy
# [21:10] <fantasai> tantek: If you're trying to solve presentation order vs dom reading order, those examples are worth looking at more.
# [21:11] <fantasai> Bo: Those are also inaccessible. It's against the WCAG
# [21:11] <fantasai> ChrisL: You're both saying the same thing
# [21:11] <fantasai> Rossen: Why only fix for flexbox?
# [21:11] <fantasai> Bo: Possible to do that, would be great
# [21:12] <fantasai> fantasai: There's two classes of authors here
# [21:13] <fantasai> fantasai: First class follows best practices, keeps DOM in logical order, might use CSS to reorder visually in cases wher evisual order and reading order should differ
# [21:13] <fantasai> fantasai: Second class is authors who use whatever tool in front of them, don't think about a11y or DOM order
# [21:14] <fantasai> fantasai: In the first case, we *want* to give them the ability reorder only at the visual layer. Otherwise they reorder everything to get correct visual order correct, and logical order ends up wrong.
# [21:14] * Rossen is now known as Rossen_away
# [21:14] * Joins: lajava (~javi@public.cloak)
# [21:14] <fantasai> fantasai: In the second case, you want to follow the visual order, because that's most likely to be correct; DOM could be completely random
# [21:15] <fantasai> fantasai: For the second group of authors, we need to have the most easily-used tool to be the one that reorders also the speech order
# [21:16] <fantasai> fantasai: For the first group of authors, we need to make it possible to do visual-layer reordreing, but to keep away from first group, need to make it a very specific thing they have to choose
# [21:17] <fantasai> greg: [something about a11y tools looking at DOM tree vs visual tree]
# [21:17] * Joins: bcampbell (~chatzilla@public.cloak)
# [21:17] <fantasai> Bert: Early a11y tools looked at visual output rather than DOM, not very useful
# [21:18] <fantasai> fantasai: I think this might be a navigation problem for a11y tools for people who use both sight and speech
# [21:18] <fantasai> fantasai: Might want ability to navigate visually as well as logically
# [21:20] <fantasai> fantasai: but that's for a well-designed page
# [21:20] <fantasai> fantasai: For a badly-designed page, we have a problem
# [21:20] <fantasai> greg: depends on a11y tools they're using, what a11y issues they have, plus how author designed the site... depends on all kinds of things
# [21:23] <fantasai> fantasai: One very concrete problem we have is people using 'order' for performance reasons, 'cuz faster than DOM, and trash a11y
# [21:23] <fantasai> plinss: So we should make 'order' slower :)
# [21:23] <fantasai> greg: With perf, can only go so far, but then have to teach authors better a11y
# [21:23] <fantasai> Bert: If we could come up with a way for users to get visual order, and also express why they chose that order, would give you information
# [21:23] <fantasai> fantasai: The problem is for authors who don't think about a11y and therefore don't care
# [21:24] <fantasai> ...
# [21:24] <fantasai> fantasai: The DOM order should be the order that I, as the page author, sitting next to you, woudl read it out to you as
# [21:24] <fantasai> greg: Comes back to perf issues
# [21:25] <fantasai> Bo: My problem is people coming back to me that situation is bad, what can we do
# [21:25] <fantasai> Bo: People come to me using performance as an excluse for having things in the wrong order
# [21:26] <fantasai> fantasai: So can we do something about making the DOM faster to do this reordering?
# [21:27] <fantasai> greg: We're pushing perf already
# [21:27] <fantasai> fantasai: Maybe have an API that's closer to order's API, does the reordering in one step?
# [21:28] <fantasai> TabAtkins: DOM reordering has strictly more work to do. have to not only reflow, but also adjust DOM and rerun selectors
# [21:29] <fantasai> TabAtkins: So will always be slower
# [21:29] <fantasai> Rossen_away: Would like to see exactly the use cases that are problems
# [21:29] <fantasai> Rossen_away: Nobody ever disagrees with "things should be faster"
# [21:29] <fantasai> Rossen_away: But would have a hard time, esp for flexbox when I don't expect so many items, why is DOM so much more beneficial for authors
# [21:30] <fantasai> ...
# [21:30] * glazou suggests a break
# [21:30] <fantasai> greg: Also useful to find use cases.. some do visual order, some do dom order, but suppose e.g. login is abspos to the top
# [21:31] <fantasai> greg: because injected via script
# [21:31] <fantasai> greg: how do we solve this problem in general?
# [21:31] <fantasai> greg: Technically, they would probably want the login first
# [21:31] <fantasai> greg: worth solving that generic case
# [21:32] <fantasai> fantasai: Actually, you could optimize aaway lot of the selector matching, if you knew that you were moving within the sibling chain
# [21:33] <fantasai> Bert: A sort function would be nice. Sort according to some criteria
# [21:34] <fantasai> fantasai: Yeah, that'd be useful, e.g. for leaverou's pinned posts case. Could sort all things with .pinned selector to the front of the list
# [21:35] <fantasai> fantasai: Don't have to have separate calls for removal, insertion, can optimize selectors, possibly even reflow
# [21:35] <fantasai> TabAtkins: Reordering for perf?
# [21:35] <fantasai> fantasai: Yeah, Bo is giving us that feedback
# [21:36] <fantasai> greg: Even if reordering for convenience, it would be good to have some use cases where that causes a11 issue because meaning has changed
# [21:36] <fantasai> if using 'order' for convenience, better API for reordering would also solve the laziness problem :)
# [21:36] <fantasai> TabAtkins: Maybe need a property that says whether to pay attention to visual order or DOM order
# [21:38] <fantasai> tantek: Problem is that the authors who have this problem are the ones who don't care (so won't do anything about it)
# [21:39] <fantasai> plinss: So what do we do?
# [21:39] <fantasai> fantasai: So one thing is find real-world cases where we have a problem, so we can understand better where the problems are
# [21:40] <fantasai> plinss: What about work for other WGs?
# [21:40] <ChrisL> element.pivotChildren(2,3);
# [21:40] <fantasai> fantasai: yeah, should ask ppl to look into better API for sibling reordering
# [21:40] <fantasai> fantasai: Solves two problems
# [21:41] <fantasai> fantasai: One, 'order' is a really simple, easy, lazy way to do this kind of reordering. So having an equally simple API in the DOM would solve the "this is just easier for me to do in CSS than fussing with the DOM"
# [21:41] <fantasai> fantasai: Secondly, creates opportunities for UA to optimize a lot of things
# [21:41] <fantasai> fantasai: Not as fast as 'order', since as Tab says, that's a strict subset of the work
# [21:42] <fantasai> fantasai: But having invariants and keeping in the tree will allow for more optimizations
# [21:42] <fantasai> TabAtkins: Maybe look at a switch for informed author...
# [21:43] <fantasai> fantasai: If you're an informed author, wouldn't you be doing things correctly in the first place?
# [21:44] <fantasai> fantasai: Should also try to find examples of pages which are correclty authored -- meaningful sequence is in the DOM, but visual order is different -- and a11y user wants it in the visual order
# [21:46] <fantasai> Bo: Don't know that that's a real problem
# [21:47] * ChrisL no-one wants to see 5,4,3,2,1. Unless you are launching a rocket, of course.
# [21:47] <fantasai> fantasai: We were discussing this case before, where people wanted visual order despite meaningful order in DOM
# [21:47] <fantasai> ...
# [21:47] <fantasai> [examples\
# [21:47] <fantasai> Bert: Suppose I have some text that explains something
# [21:47] <fantasai> Bert: Section at the end says "for further info, see x, y ,z"
# [21:48] <fantasai> Bert: I put it in the logical order in the DOM
# [21:48] <fantasai> Bert: but on the screen, I put the "for further info" on the left
# [21:48] <fantasai> Bo: That's considered complementary information
# [21:48] <fantasai> Bo: That's not important enough of a sequence to fall into this category
# [21:49] <fantasai> fantasai: Okay
# [21:49] <fantasai> fantasai: So to summarize
# [21:50] <fantasai> ACTION: bcampbell Get examples of broken pages
# [21:50] * trackbot is creating a new ACTION.
# [21:50] * RRSAgent records action 2
# [21:50] <trackbot> Error finding 'bcampbell'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
# [21:50] <fantasai> ACTION: TabAtkins Talk with WebApps about a reordering API
# [21:50] * trackbot is creating a new ACTION.
# [21:50] * RRSAgent records action 3
# [21:50] <trackbot> Created ACTION-692 - Talk with webapps about a reordering api [on Tab Atkins Jr. - due 2015-05-27].
# [21:51] <fantasai> TabAtkins: Possibility of a DOM switch?
# [21:52] * Rossen_away is now known as Rossen
# [21:52] <fantasai> fantasai: I don't think that would help. People that would be aware enough / care enough to use it should be aware enough to do things right in the first place
# [21:52] <fantasai> Topic closed
# [21:52] <fantasai> <br duration=15min>
# [21:56] * Joins: BradK (~bradk@public.cloak)
# [21:57] * Joins: dael (~dael@public.cloak)
# [22:00] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [22:01] * Rossen is now known as Rossen_away
# [22:06] <BradK> Where can I see transcripts of the IRC channel?
# [22:08] <dael> BradK: I use http://logs.csswg.org/irc.w3.org/css/ or http://krijnhoetmer.nl/irc-logs/ to view them.
# [22:08] <BradK> OK, thanks!
# [22:08] <dael> Welcome!
# [22:09] * Quits: bcampbell (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [22:13] * Joins: bcampbell (~chatzilla@public.cloak)
# [22:16] * Joins: johanneswilm (~johannes@public.cloak)
# [22:16] * Rossen_away is now known as Rossen
# [22:16] <fantasai> sylvaing: yt?
# [22:18] <fantasai> Topic: font-loading-whatever
# [22:18] <fantasai> TabAtkins: Basic idea is that font, once you request it, goes through two period
# [22:18] <fantasai> TabAtkins: One is the "blank" period from 0s, which is when you don't show anything
# [22:19] <fantasai> TabAtkins: Then the "swap period", which is when you show the font if it's loaded
# [22:19] <fantasai> TabAtkins: And lastly the "screw it" period, which is when you no longer try to show the font, even if it's loaded
# [22:20] <fantasai> TabAtkins: Question was, do you relayout at the end of the blank period?
# [22:20] <fantasai> TabAtkins: Yes
# [22:20] <fantasai> fantasai: No
# [22:21] <fantasai> fantasai: You lay out the blank page with the fallback font metrics. If the real font hasn't loaded yet, the swap period is also using the fallback font, so no layout change (just visiblity of the font change).
# [22:21] <fantasai> fantasai: Relayout happens when the real font gets used.
# [22:21] <fantasai> ChrisL: What's the value of having the blank period
# [22:21] <fantasai> ?
# [22:21] <fantasai> TabAtkins: 2 use cases. One is not good, but ppl do anyway
# [22:22] <fantasai> TabAtkins: Using icon fonts. Good icon fonts are ligatures, no problem with fallback font. But bad icon fonts, using pictures for arbitrary letters, those ones shouldn't show anything
# [22:22] <fantasai> TabAtkins: because otherwise show random letters
# [22:22] <fantasai> TabAtkins: The ther use case is where the particular font is important, and it's better to show nothing for a little bit, rather than showing anything
# [22:23] <fantasai> ChrisL: That second case is very rare. SVG had ppl arguing that way, and 10 years later isn't not significant.
# [22:23] <fantasai> Florian: I think it's the default because of icon fonts
# [22:23] <BradK> Like with a Klingon font?
# [22:23] <fantasai> iank: There's also a case where you know it's going to load in a reasonable amount of time, so you don't want to show anything in the meantime
# [22:23] <fantasai> plinss: wrt icon fonts, that's the case of you never want to fall back ever
# [22:24] <fantasai> TabAtkins: Not sure about that
# [22:24] <BradK> "isn't not significant"?
# [22:24] <fantasai> ChrisL: Why not have a 'none' generic font family? You can put font-family: Icon Font, none;
# [22:25] <fantasai> TabAtkins: I kinda disagree because if the icon never shows up, at least there's a visible something that you can learn means "log out" or whatever
# [22:25] <fantasai> ChrisL: Couldn't you learn about a magic blank space?
# [22:26] <fantasai> TabAtkins: If you limit the blank phase for a small amount of time, the user is assessing the page, but hasn't begun really interacting with it yet
# [22:26] <fantasai> iank: This is what we did in ?, just showing the basic structure even before we show the content has a huge user benefit
# [22:26] <fantasai> iank: Facebook does this, for example
# [22:26] <fantasai> TabAtkins: You get a much better perceived load time
# [22:27] <fantasai> TabAtkins: Keywords in question
# [22:27] <fantasai> TabAtkins: Under my proposal we have block , swap, optional
# [22:27] <fantasai> TabAtkins: block sets the thresholds at 3s and infinity -- you really want that font
# [22:28] <fantasai> TabAtkins: after 3s show fallback rather than blank, but always swap in font once it loads
# [22:28] <fantasai> TabAtkins: swap sets the thresholds at 0s and 3s -- you show the fallback font immediately, and don't swap the real font if it shows up after 3s
# [22:29] <fantasai> TabAtkins: Assume user has started interacting with page, so it shouldn't relayout
# [22:29] <fantasai> TabAtkins: optional sets the thresholds at 0s and epsilon
# [22:29] <fantasai> TabAtkins: Basically only show the real font if it's locally available (or loaded lightning fast)
# [22:30] <fantasai> TabAtkins: John's proposal had some other keywords
# [22:30] * Quits: abucur___ (~sid19072@public.cloak) ("")
# [22:30] * Joins: abucur___ (~sid19072@public.cloak)
# [22:30] <fantasai> TabAtkins: fallback sets the thresholds at 0s and infinity -- use the fallback, swap in the real font at any point in time
# [22:30] * Parts: dael (~dael@public.cloak)
# [22:31] <fantasai> ChrisL: Why epsilon?
# [22:31] <fantasai> TabAtkins: Because you'll immediately fall into "screw it" and never show the font. It still takes *some* amount of time to check the cache
# [22:31] <fantasai> TabAtkins: optional is "Nice font if you have it, not a big deal if it doesn't show"
# [22:32] <fantasai> TabAtkins: ? mentioned that you could simply not download the font
# [22:32] <fantasai> TabAtkins: mobile's are most likely to fail epsilon
# [22:32] <fantasai> TabAtkins: continually
# [22:32] <fantasai> TabAtkins: So never show the font
# [22:32] * Zakim excuses himself; his presence no longer seems to be needed
# [22:32] * Parts: Zakim (zakim@public.cloak)
# [22:32] <fantasai> TabAtkins: So might be useful to have it mean "loading the font is optional"
# [22:33] <fantasai> plinss: For "screw it" phase, might want to also say "abort the download"
# [22:34] <fantasai> TabAtkins adds a column for the four values titled "download", with checkmarks on blank, swap, fallback, and abort/cancel for optional"
# [22:34] <fantasai> ChrisL: So, which of those should you use in the case where you have a font for a language which you expect the fallback font not to have any glyphs?
# [22:34] * Joins: andrey-bbg (~andrey-bbg@public.cloak)
# [22:34] <fantasai> TabAtkins: I think you'd use 'block'.
# [22:34] <fantasai> TabAtkins: Unicode "can't find the glyph" blocks aren't particularly useful, so showing blank is fine, possibly better
# [22:35] <fantasai> TabAtkins: And then you're treating it as a required font
# [22:35] <fantasai> TabAtkins: So these are block = "super-needed", fallback = "pretty needed", swap = "kinda needed", optional = "meh"
# [22:36] <fantasai> ChrisL: Essential, important, preferable, and meh
# [22:36] <fantasai> leaverou: I think we have consensus on "meh"
# [22:36] <fantasai> Florian: We have two more rows on this table. Not necessarily desirable, but discussed
# [22:36] <fantasai> Florian: Safari had an infinite blank period
# [22:37] <fantasai> Florian: safari sets thresholds at infinity, infinity, yes download
# [22:37] <fantasai> Florian: John had another bad proposal which was
# [22:37] <fantasai> s/bad/slightly less bad proposal/
# [22:38] <fantasai> Florian: Which had very long but not infinite timeout on blank
# [22:38] <fantasai> TabAtkins: jdaggett's 'blank' keyword is my 'block' keyword
# [22:39] <fantasai> TabAtkins completes the table with jdaggett's variant of safari's behavior
# [22:40] <fantasai> block: 3s | infinity | yes
# [22:40] <fantasai> fallback: 0s | infinity | yes
# [22:40] <fantasai> swap: 0s | 3s | yes
# [22:41] <fantasai> optional: 0s | epsilons | abort
# [22:41] <fantasai> -----
# [22:41] <fantasai> Apple: infinite | lol | yes
# [22:41] <fantasai> really-blank: ~60s | infinite | yes
# [22:42] <fantasai> fantasai: I think swap should be called 'fallback'
# [22:43] <fantasai> fantasai: For fallback, if we want to keep it, that should be called 'swap', because you can swap forever
# [22:43] <fantasai> Florian: 'optional' is a good name
# [22:43] <fantasai> TabAtkins: Our proposed name... we proposed font-display
# [22:43] <fantasai> TabAtkins: That seems to go along with Chris's names
# [22:44] <fantasai> Florian: jdaggett had font-display-loading (or font-loading-display)
# [22:44] * Joins: vollick_ (~vollick@public.cloak)
# [22:44] <fantasai> TabAtkins: auto is whatever default you feel like
# [22:44] <fantasai> fantasai: Could just put your preference in the UA stylesheet
# [22:44] <fantasai> TabAtkins: auto allows more sophisticated heuristics
# [22:45] <fantasai> fantasai: ok, that's fair
# [22:45] <fantasai> fantasai: So, swap and fallback should swap names
# [22:45] <fantasai> fantasai: I think 'block' is not a great name
# [22:46] <fantasai> discussion that ChrisL's naming captures use cases beter
# [22:47] <fantasai> fantasai points out that understanding what the values do is valuable
# [22:47] <fantasai> Florian: We should definitely have swap & fallback in the first level
# [22:47] <andrey-bbg> I like fallback
# [22:47] <fantasai> Florian: block I guess we need, too
# [22:47] * Quits: amtiskaw (~sid19262@public.cloak) ("")
# [22:47] <fantasai> Florian: optional could defer
# [22:47] * Joins: amtiskaw (~sid19262@public.cloak)
# [22:47] <fantasai> ChrisL: Don't see the benefit
# [22:48] <fantasai> leaverou: Are we only going to have keywords, not timeouts?
# [22:48] <fantasai> leaverou: What about other countries?
# [22:48] <fantasai> TabAtkins: 3s is just "a reasonable time"
# [22:49] <fantasai> Florian: If you're making a mobile browser for crappy networks, you can set it to 10
# [22:49] <fantasai> leaverou: But if you're shipping for desktop browsers, will ship the same hard-coded default everywhere
# [22:49] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [22:49] <fantasai> [discussion of setting this as a UA pref]
# [22:50] * Joins: dauwhe (~dauwhe@public.cloak)
# [22:50] <fantasai> plinss: I have a fundamental moral objection to this entire thing because it's taking what is fundamentally a user preference and putting it in the hands of the author
# [22:50] <fantasai> plinss: I'm cool as long as the UA is allowed to ignore the author's rules on behalf of the user
# [22:50] <fantasai> plinss: Want to make sure it's clear in the spec that this is a hint
# [22:50] <fantasai> TabAtkins: font-hinting! :D
# [22:51] <fantasai> plinss: Even if we give authors the actual timeouts, the UA could decide to multiply all timeouts by 10
# [22:51] <fantasai> TabAtkins: I kinda prefer the intentional keywords (ChrisL's list)
# [22:51] <fantasai> TabAtkins: Rather than the behaviorial ones
# [22:51] <fantasai> TabAtkins: And e.g. not block, not treat as mandatory
# [22:52] <fantasai> TabAtkins: Hierarchy of levels allows you to do some amount of discrimination
# [22:52] <fantasai> Florian: Make everything should
# [22:52] <fantasai> TabAtkins: Would rather be must, with exception for exceptional network conditions
# [22:52] <fantasai> Florian: And you can limit the scope of the exception
# [22:53] <fantasai> fantasai: I think we should have a note about networks speeds and the timeout
# [22:54] <fantasai> Discussion of ChrisL's keywords
# [22:54] <fantasai> should avoid 'important' because of !important
# [22:55] <fantasai> ChrisL's keywords = essential, important, preferable, optional
# [22:55] * heycam|away is now known as heycam
# [22:55] <fantasai> Florian: Wrt property vs descriptor
# [22:55] <fantasai> Florian: smfr didn't want a property
# [22:56] <fantasai> Florian: Only having a descriptor does not limit the use cases. If needed you can create two different fonts via @font-face, use as you want.
# [22:56] <fantasai> RESOLVED: font-loading control is only an @font-face descriptor, not a property
# [22:57] <fantasai> ChrisL: Swapping out font in some elements not in others is really weird
# [22:57] <fantasai> fantasai: Possible but annoying via descriptor
# [22:57] <fantasai> plinss: There are use cases for it
# [22:58] <fantasai> plinss: E.g. navigation you want to never be blank, but other parts allow to be blank for awhile
# [22:58] <fantasai> fantasai: We're missing smfr, who might be arguing for blank
# [22:58] <Bert> (Some people name their fonts by their function, such as "body font", "button font", etc, so it's easy to have different policies for each, even if they are actually the same font face.)
# [22:58] <fantasai> fantasai: but Safari could do that via auto
# [22:59] <fantasai> Florian: This isn't something we want authors to opt into
# [22:59] <fantasai> Florian: So, do we want to resolve on the first four values, modulo bikeshedding?
# [23:00] <fantasai> fantasai: yeah, block is not a great name
# [23:00] * Joins: dael (~dael@public.cloak)
# [23:00] * glazou Bikeshedibus Unum ?
# [23:00] * dauwhe text-align: center !meh;
# [23:00] <fantasai> fantasai: I kinda prefer the functional names to the importance ones
# [23:01] <fantasai> fantasai: I would want to know if you are going to swap the font at any point in the future vs. within a timeout
# [23:01] <fantasai> tantek: UA could do anything
# [23:01] <fantasai> ?: Only for exceptional cases
# [23:01] <fantasai> Florian: Timeout varies, but behavior unlikely to
# [23:01] * heycam waves hello; what's the call in details again?
# [23:01] * glazou reminds dauwhe that the CSS mascot is a sheep so that would be « center ! beh »
# [23:02] <plinss> heycam +1-212-617-1960 for New York, +44-20-7330-7700 for London, +81-3-3201-7040 for Tokyo. PIN 295109
# [23:02] <tantek> s/tantek/???
# [23:02] <tantek> s/tantek:/TabAtkins:
# [23:03] * Joins: jdaggett (~jdaggett@public.cloak)
# [23:03] <heycam> plinss, is there a new pin for today?
# [23:03] <TabAtkins> should be same?
# [23:03] * plinss should be the same
# [23:03] <heycam> I got told that that pin was for yesterday, and couldn't get in
# [23:04] * ChrisL ah but here it is still yesterday
# [23:04] * heycam :)
# [23:04] <TabAtkins> we're working on this
# [23:04] <heycam> cheers
# [23:04] <ChrisL> rrsagent, this meeting spans midnight
# [23:04] <RRSAgent> ok, ChrisL; I will not start a new log at midnight
# [23:05] <fantasai> Proposed resolution: have 4 values for font-loading-display-whatever: block-essential | fallback-important | swap-preferable | optional
# [23:05] <fantasai> Waiting for jdaggett and heycame to dial in and catch up before resolving
# [23:05] <jdaggett> explanation of values?
# [23:06] * fantasai RRSAgent pointer
# [23:06] <jdaggett> block-essential == sort of like safari now?
# [23:06] <fantasai> no
# [23:06] <fantasai> :)
# [23:06] * fantasai looks up logs
# [23:06] * Quits: jcraig (~jcraig@public.cloak) (Ping timeout: 180 seconds)
# [23:06] <plinss> csswg_logbot, pointer?
# [23:06] <CSSWG_LogBot> http://log.csswg.org/irc.w3.org/css/2015-05-20/#e556910
# [23:06] * fantasai made a table in the minutes
# [23:06] * fantasai just got to find it
# [23:06] * ChrisL heycam, john - the operator appears to be non responsive
# [23:07] <fantasai> jdaggett: http://log.csswg.org/irc.w3.org/css/2015-05-20/#e556805
# [23:07] * heycam :(
# [23:07] * heycam ChrisL is this the operator at the end of that NY phone number? I spoke to her just before
# [23:07] <fantasai> That's the table, the columns are
# [23:07] <fantasai> name of value
# [23:08] <fantasai> Timeout for showing fallback instead of blank
# [23:08] <fantasai> Timeout for no longer accepting the real font as a swap-in
# [23:08] <fantasai> Whether or not to complete the download
# [23:08] * Joins: jcraig (~jcraig@public.cloak)
# [23:08] <fantasai> (if the download has timed out)
# [23:08] * Joins: Zakim (zakim@public.cloak)
# [23:09] <fantasai> Note proposed resolution there is pre-bikeshedding (in case that wasn't obvious from the ridiculous)
# [23:09] <plinss> new conference PIN: 205187
# [23:09] * heycam tries
# [23:10] <Florian> John: in terms of your proposal, we're taking blank-fallback and fallback, rejecting blank, and adding optional and swap from Tab's proposal
# [23:10] * Quits: andrey-bbg (~andrey-bbg@public.cloak) (Ping timeout: 180 seconds)
# [23:11] <Florian> John: and want to bikeshed everything
# [23:11] * Ms2ger suggests blink-fallback
# [23:12] <fantasai> TabAtkins: Every keyword controls how long you blank for, how long you swap for, and then you're stuck in permanent fallback
# [23:12] <fantasai> TabAtkins: block-essential does 3s blank, and swaps in until infinity
# [23:13] <fantasai> TabAtkins: swap-important does fallback immediately, swaps until infinity~
# [23:14] <fantasai> TabAtkins: fallback-preferable does fallback immediately, swaps only up to 3s
# [23:14] <fantasai> TabAtkins: optional falls back immediately, swaps if it shows up fast, and could be ditched if it doesn't load quickly
# [23:14] <fantasai> jdaggett expresses concerns wrt epsilon
# [23:15] <fantasai> TabAtkins: You give it enough time to at least load from cache
# [23:15] <fantasai> TabAtkins: But if you're in an exceptionally slow network, or otherwise resource-constrianed, you can say "screw it" and not load the font
# [23:15] <fantasai> TabAtkins: This sets up 4 preference levels for how important the font is to the page
# [23:15] <fantasai> TabAtkins: from "you need to display this font, otherwise everything is terrible" down to "it'd be nice, but it's okay if not"
# [23:16] <fantasai> jdaggett: optional will always display the fallback
# [23:16] <fantasai> TabAtkins: No, it has an effect. If the font has not yet loaded, optional is basically guaranteed to show the fallback
# [23:16] <fantasai> TabAtkins: If the font has downloaded and is in the cache, then you'll use it successfully
# [23:16] <fantasai> TabAtkins: On devices too slow to load from cache in a reasonable amount of time, it won't be used
# [23:17] <fantasai> jdaggett: Ppl who are demanding optional are asking for a ????
# [23:17] <fantasai> s/????/no-reflow solution/
# [23:17] <jdaggett> the people who are asking for optional are looking for a "no reflow" use of fonts
# [23:17] <fantasai> TabAtkins: That's very nearly what you get. The only exception is if you start trying to render text, but the font comes in, then you rerender
# [23:17] <jdaggett> i.e. either the font is *immediately* available or it's not
# [23:18] <dbaron> Yeah, if the people who want 'optional' actually want "no reflow", then they're not going to get it with this definition.
# [23:18] <fantasai> yeah
# [23:18] <dbaron> Is that the main use case?
# [23:18] <fantasai> jdaggett: dbaron's point is my question
# [23:18] <fantasai> jdaggett: [...]
# [23:18] * fantasai needs to move closer to speaker
# [23:19] <fantasai> dbaron: Do ppl who want optional because they want no reflow, because want to avoid perf cost of reflow?
# [23:19] <fantasai> several ppl say no
# [23:19] <fantasai> Florian: No, I want it for.. It's a font, if you have it, would be nice
# [23:19] <fantasai> Florian: In my mind epsilon is ~ 100ms
# [23:19] <fantasai> Florian: I'm not looking for entirely no reflow at all
# [23:19] <fantasai> Florian: looking for, if there is a reflow, it should happen so early in the page that the user hasn't started reading
# [23:20] <fantasai> Florian: Which is not what would happen with swap
# [23:20] <fantasai> Florian: After 3 seconds or so, user might hhave started reading, then text moves around
# [23:20] <fantasai> Florian: If font is sufficiently unimportant, as soon as user has started reading I no longer want to disturb the content
# [23:20] <fantasai> Florian: 100ms or so, nobody has got far with reading. But if you have the font available, I'd prefer that
# [23:20] <fantasai> Florian: If you reflow a little bit, I won't mind.
# [23:21] <fantasai> TabAtkins: You probably won't notice the reflow during that portion of the load time
# [23:21] <fantasai> plinss: If the UA has eye-tracking, can even tell whether the user is reading or not :)
# [23:21] <fantasai> jdaggett: What Florian's describing... I'm not really sure
# [23:22] <fantasai> jdaggett: if it helps what Google ppl are looking for
# [23:22] <fantasai> jdaggett: I think they're looking for no flash ever
# [23:22] <fantasai> TabAtkins: I don't think that's what they were looking for, but if it would help I can ask them about it when I get back to work
# [23:22] <fantasai> q+
# [23:22] * Zakim sees fantasai on the speaker queue
# [23:22] <fantasai> jdaggett: Discussion with google ppl would be nice if not in various google forums
# [23:22] * fantasai unsure
# [23:22] <fantasai> TabAtkins: it generally was, mostly in github for original proposal
# [23:23] <dbaron> fantasai: interesting thing that was discussed for optional was, with limited network, just not even bother trying to load the font
# [23:23] <jdaggett> it would help if the discussion by google people was in public forums like www-style and not within github issues for example
# [23:23] <dbaron> Florian: also low memory
# [23:23] <dbaron> fantasai: and bandwidth constraint
# [23:24] <fantasai> heycam: ...
# [23:24] <fantasai> heycam: in terms of bandwidth constraint
# [23:24] <fantasai> heycam: Aren't you going to do the same kind of loading?
# [23:24] <fantasai> heycam: I'm not sure how optional helps with bandwidth constrained situations
# [23:24] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [23:24] <fantasai> heycam: Aren't you just going to do the same loading?
# [23:25] <fantasai> fantasai: We had discussed making 'optional' make the loading optional entirely
# [23:25] <fantasai> fantasai: So a device that knew it was constrained could opt to not download the font
# [23:25] <fantasai> jdaggett: I'm not sure if optional is being imagined in this context
# [23:26] <fantasai> jdaggett: On a certain device you have an idea of your max bandwidth
# [23:26] <fantasai> jdaggett: You can guess whether going to make it within a certain timeout value
# [23:26] <fantasai> jdaggett: There's sort of a multiple-page ...
# [23:26] <fantasai> jdaggett: How are you imaginign the font ever gets down to the UA unless you've got something that says "here's when a load happens"?
# [23:26] <fantasai> jdaggett: This gets into resource hints
# [23:26] <fantasai> TabAtkins: When the font is marked optional?
# [23:26] <fantasai> jdaggett: If it's marked optional, how is it ever getting downloaded?
# [23:27] <fantasai> jdaggett: UA knows it can't download within the timeout, so wouldn't bother downloading
# [23:27] <fantasai> jdaggett: Would need some language, something like a resource hint
# [23:27] <fantasai> TabAtkins: Yes
# [23:27] <fantasai> TabAtkins: Point is, optional is the least necessary font
# [23:27] <fantasai> TabAtkins: If UA determines that it will never be able to pull down reasonably, fine
# [23:27] <fantasai> TabAtkins: If doesn't have it yet, but bandwidth is fine, then could continue downloading even though not using it
# [23:28] <fantasai> jdaggett: Then need a normative definition of whether loading follows through
# [23:28] <fantasai> jdaggett: or treated as something that can be ignored
# [23:28] <fantasai> fantasai: He wants the last column in the table normatively
# [23:28] <fantasai> TabAtkins: Yes, that would be in the normative definition
# [23:28] <fantasai> (last column is whether to download or not)
# [23:28] <fantasai> jdaggett: Need to say whether fetch continually or fetch never happens
# [23:29] <fantasai> TabAtkins: It might continue or might never happen, depending on UA
# [23:29] <fantasai> plinss: I'm questioning how this interacts with service workers
# [23:29] <fantasai> jdaggett: If different UAs are making different decisions
# [23:29] <fantasai> jdaggett: optional will be either never use this font or use in a blue moon
# [23:29] <fantasai> TabAtkins: Yes
# [23:29] <fantasai> TabAtkins: If font was important, you'd use a higher-preference keyword
# [23:30] <fantasai> TabAtkins: You can just use sans-serif, it's fine
# [23:30] <fantasai> fantasai: Might want continue through and download the font a separate switch from the timeout?
# [23:30] <fantasai> TabAtkins: If the font is at all important, so continue downloading
# [23:31] <fantasai> plinss: ... service workers could abort the load, or fetch for next time.
# [23:31] <fantasai> TabAtkins: Would have to talk to other engineers, but this might have useful conceptual overlap with client hints
# [23:31] <fantasai> TabAtkins: Could say that optional request is tagged with a particular client hin
# [23:31] <fantasai> *hint
# [23:31] <fantasai> plinss: In general, we want to try to explain these behaviors in terms of other api
# [23:32] <fantasai> fantasai: I suppose might want a user pref to choose not to download preferable or optional fonts, but download essential ones
# [23:32] * jdaggett other than tab it basically sounds like all others in the room are talking through a cup
# [23:33] <fantasai> jdaggett: Don't think I can follow the description
# [23:33] <fantasai> TabAtkins: Proposal is just your proposal, minus blank, plus my swap and optional keywords values
# [23:34] <fantasai> plinss: John, we were very close to accepting this proposal with strong consensus in the room. Held off because wanted to give you a chance to object
# [23:34] <fantasai> plinss: Suggest, if it's okay with jdaggett, that we resolve to accept this and you can suggest improvements
# [23:35] <fantasai> s/this/this, let Tab write it up as spec prose,
# [23:35] <fantasai> s/improvements/improvements, and we will revisit/
# [23:35] <Florian> +1 to plinss
# [23:35] <fantasai> jdaggett: I don't know what the proposal is, can't hear anything to what Tab says
# [23:35] * ChrisL https://pbs.twimg.com/media/CFejzOTWoAA9mMT.jpg:large
# [23:35] <fantasai> jdaggett: I'm fine with Tab writing it up, resolving to move forward can't tell one way or another
# [23:35] <BradK> What about a descriptor that says what the average character width and extent is, so that reflow will be minimal when the font does load?
# [23:36] <fantasai> RESOLVED: accept font-display-thing-whatever-loading properyt with four values to be renamed later: block | swap | fallback | optional
# [23:37] <fantasai> block shows blank, swaps in fallback at 3s, swaps in real font whenever it loads
# [23:37] <fantasai> swap shows fallback, swaps in real font whenever it loads
# [23:37] <ChrisL> bradk, we tried that with css2 (not 2.1) and dropped in for css3
# [23:37] <fantasai> fallback shows fallback, swaps in real font if it loads before 3s
# [23:38] * Florian stop!
# [23:38] <jdaggett> ouch
# [23:39] <ChrisL> bradk - see http://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#synthesizing
# [23:39] <fantasai> optional shows real font if it loads from cache (very short timeout), otherwise shows fallback
# [23:39] <fantasai> optional allows UA to not continue loading the font for the next time
# [23:39] <ChrisL> topic: new
# [23:39] <fantasai> Topic: load/check FontFaceSet
# [23:39] * jdaggett bradk: better way is to use font-size-adjust since this will push the fallback font to be close to the downloaded one
# [23:40] <fantasai> heycam: Think the spec is in reasonably good shape
# [23:40] <fantasai> heycam: l... behavior of check method
# [23:40] <fantasai> heycam: Fundamentally unclear to me what the intent of having check method is for
# [23:40] <fantasai> heycam: Not clear to me from description in the spec what it's meant to do at a high level
# [23:40] <fantasai> heycam: also not sure what it's intended to do to solve a use case
# [23:40] <fantasai> heycam: would be helpful to see some code snippets that use check to accomplish some particular thing
# [23:41] <fantasai> heycam: so I can evaluate whether the particular behavior in the spec is useful or needs tweaking
# [23:41] <fantasai> TabAtkins: I can always put in better introductions
# [23:41] <fantasai> TabAtkins: Intent of check method is, e.g. you want to render in to canvas, ask each font you want to use, if it's good
# [23:41] <fantasai> jdaggett: That's not what actually happens
# [23:41] <BradK> jdaggett: yes, I'do like something like font-size-adjust for widths, so that when I have a very condensed font, the fallback don't won't be huge looking.
# [23:41] <fantasai> jdaggett: Given a font list, never guaranteed that all the text will be rendered with that font
# [23:42] <fantasai> jdaggett: This will only tell, if there's a load... [can't hear]
# [23:42] <fantasai> TabAtkins: No that' snot right, because gives you bad behavior in a corner case
# [23:42] <fantasai> TabAtkins: You've mispelled one of the font faces
# [23:42] <fantasai> TabAtkins: ...
# [23:42] <fantasai> TabAtkins: Getting a no there, yeah check method just fine, it's a bad confusing behavior
# [23:42] <fantasai> TabAtkins: Semantic of "can I render with this font" works here
# [23:43] <fantasai> TabAtkins: It'll return "No" for the typoed font, because it doesn't exist
# [23:43] <BradK> ChrisL: dropped because to complex? I was think of a single width (average of all characters), and assuming an ascender and descender's effect on height, if any.
# [23:43] <fantasai> jdaggett: Don't understand why misspelling has to do with return value on a method
# [23:43] <fantasai> jdaggett: Want to flag a developer that there's no font that you specified in this list, that's a dev tool feature
# [23:43] <fantasai> jdaggett: This introduces inconsitency, has side-effect of making ideal API for font fingerprinting
# [23:43] <fantasai> jdaggett: That's especially bad
# [23:44] <fantasai> TabAtkins: We're not disagreeing on basic behavior
# [23:44] <fantasai> TabAtkins: All but trivial case is easily define
# [23:44] <fantasai> TabAtkins: The case is none of the fonts can render the string you describe
# [23:44] <ChrisL> bradk - even the more complex one was not enough to prevent reflow. and that was before opentype features meant that reflow was even less predictable just from individual widths
# [23:44] <fantasai> jdaggett: The trivial case isn't whether font can render a piece of text
# [23:44] <fantasai> jdaggett: There's about whether there are no fonts that result in the font list
# [23:44] * fantasai ??????
# [23:44] <ChrisL> ... a single average width will not be enough to avoid reflow
# [23:44] <fantasai> jdaggett: The wording you're using you're proving fonts for all possible strings, which you're not
# [23:45] <fantasai> TabAtkins: The only case we're disagreeong on is if you call check() with a font listing and a sample string of characters you're going ot use
# [23:45] <BradK> ChrisL: didn't mean to synthesize, just as a hint for reserving space. But OK, I see your next comment there
# [23:45] <fantasai> TabAtkins: If it can't render all chars in the sample string, drops font from the list
# [23:45] <jdaggett> check("calibri") ==> returns true on windows, false elsewhere
# [23:45] <fantasai> TabAtkins: At the end, whatever fonts are left, get them back. Check method returns true or false
# [23:45] <fantasai> TabAtkins: Only disagreeing if the list is empty, do you return true or false
# [23:46] <jdaggett> check("calibri,sans-serif") ==> returns true always
# [23:46] <fantasai> TabAtkins: true is if you can render all the characters with the font you gave, false otherwise
# [23:46] <jdaggett> you're making check into an existence check
# [23:46] <jdaggett> which is *not* the use case
# [23:46] * fantasai is confused what jdaggett is saying
# [23:47] <fantasai> jdaggett: It says, let's check this font list, and if not true, then I need to call mode on the font list
# [23:47] * fantasai sure that's wrong
# [23:47] <fantasai> jdaggett: call load, and the promise will immediately resolve if the font list is already loaded
# [23:47] <jdaggett> er, no...
# [23:47] * fantasai pls fix, so confused
# [23:48] <jdaggett> if (!check(fontlist)) load(fontlist)
# [23:48] <dbaron> anyway, heading out... see you in Paris
# [23:48] <fantasai> jdaggett: Having this behavior that's inconsistent across font lists, and behavior that's different from the way load works and check works
# [23:48] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [23:48] <fantasai> jdaggett: Those are really bad inconsistencies
# [23:49] <fantasai> heycam: From a different direction
# [23:49] <fantasai> heycam: Looking at what the limit value is as you reduce the number of font faces in the fontFaceSet
# [23:49] <fantasai> heycam: If you have a bunch of matching fonts
# [23:49] <fantasai> heycam: As you remove fonts, you are more likely to return true because more and more likely to have error case
# [23:50] <fantasai> heycam: But when you remove the last one, suddenly return false
# [23:50] <fantasai> heycam: It adds another .. for what the check method is doing
# [23:50] <fantasai> heycam: Are all of the things in this list ready?
# [23:50] <fantasai> heycam: And do we have no font faces at all?
# [23:50] <fantasai> heycam: Complicates what we're looking for
# [23:51] <fantasai> heycam: Those make me want to return a true value
# [23:51] <fantasai> TabAtkins: I'm willing to provisionally change it, until/unless I revisit the arguments for changing it
# [23:51] <fantasai> heycam: Agree it's kindof a corner case
# [23:52] <fantasai> heycam: As an author probably know what fonts you added to set
# [23:52] <fantasai> heycam: Why would you do checks and loads not in the set
# [23:52] <fantasai> heycam: But would want consistent with load's behavior and [?]
# [23:52] <fantasai> TabAtkins: Okay, let's do that, that's fine
# [23:52] <fantasai> heycam: Another aspect of this, which I think we have different opinions on
# [23:52] <fantasai> heycam: Looking up the list
# [23:52] <fantasai> heycam: system fonts
# [23:52] <fantasai> heycam: whether they should influence the return value of check()
# [23:53] <fantasai> heycam: In my mind, check() is like a very close counterpart to load()
# [23:53] <fantasai> heycam: Where it's telling you, are things going to load
# [23:53] <fantasai> heycam: Same set of font faces as load
# [23:53] <fantasai> heycam: It tells me if you call load, that promise is going to be resolved straightaway or not
# [23:53] <fantasai> heycam: Looking up system fonts, influencing value of check() doesn't fit in with that
# [23:53] * Quits: dael (~dael@public.cloak) ("Page closed")
# [23:53] <fantasai> TabAtkins: can't seem to find thread that convinced me on this....
# [23:54] <fantasai> jdaggett: I don't really remember seeing a thread on the list about this
# [23:56] <fantasai> TabAtkins trying to find emails
# [23:56] <fantasai> TabAtkins: Don't want to make a resolution until I find the logic that caused this change in the first place
# [23:57] <fantasai> ACTION TabAtkins Find out why including system fonts behavior of check and trivial case behavior of check
# [23:57] * trackbot is creating a new ACTION.
# [23:57] <trackbot> Created ACTION-693 - Find out why including system fonts behavior of check and trivial case behavior of check [on Tab Atkins Jr. - due 2015-05-27].
# [23:57] <fantasai> jdaggett: Whether check returns true or false when no fonts are found in the font list
# [23:58] <fantasai> plinss: Anything else on this topic?
# [23:58] <fantasai> TabAtkins: Found the thread!
# [23:58] <fantasai> TabAtkins: Either I wrote the algo slightly wrong, or you're reading slightly wrong
# [23:59] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [23:59] <fantasai> TabAtkins: The idea for returning false if you have only one mispelled font
# [23:59] <fantasai> TabAtkins: True should look nice
# [23:59] <BradK> Heisenberg font loading uncertainty principle
# [23:59] <fantasai> TabAtkins: Added systemwide keywords, because before they could write 'Arial' and it would return false, because 'Arial' is a system font, not an @font-face rule
# [23:59] <fantasai> jdaggett: check should return whether a font should be loaded or not
# [23:59] <fantasai> jdaggett: If it's a system font, doesn't need to be loaded
# Session Close: Thu May 21 00:00:00 2015

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