| 06:56 | <tobie> | annevk: re for attribute for DFNs: Bikeshed doesn't pick it up for dfns of type dfn. |
| 06:57 | <annevk> | tobie: it does |
| 06:57 | <tobie> | annevk: so <dfn export for=foo>definition</dfn> and <dfn export for=bar>definition</dfn> conflict |
| 06:58 | <annevk> | tobie: maybe you need a dfn for the for value? |
| 06:58 | <tobie> | oh... so I'd need to add a "for"' for the value? |
| 06:58 | <tobie> | arg! |
| 06:58 | <annevk> | tobie: URL uses this a bunch |
| 06:58 | <annevk> | tobie: oh yes, you do |
| 06:59 | <annevk> | tobie: when referencing such a dfn |
| 06:59 | <tobie> | Mmm. |
| 06:59 | <tobie> | that sucks. |
| 06:59 | <annevk> | <a for=x>term</a> |
| 07:00 | <tobie> | darn. |
| 07:00 | <tobie> | OK, so I need to undo a bunch of changes. |
| 07:01 | <tobie> | annevk: glad you picked that up. |
| 07:04 | <MikeSmith> | tobie: you’ll be at TPAC? |
| 07:04 | <MikeSmith> | if so for one thing please add to https://www.w3.org/wiki/TPAC2016/WebPlatformTests if you can think of anything |
| 07:04 | <tobie> | MikeSmith: I'm debating this as we speak |
| 07:08 | <tobie> | debating going, that is. |
| 10:03 | <MikeSmith> | tobie: well I think it would be worth you while to go |
| 10:04 | <MikeSmith> | there will be more of us at TPAC this year than usual I think |
| 10:04 | <tobie> | MikeSmith: it's out of pocket + large extra babysitting costs so it has to be worth it. |
| 10:04 | <tobie> | hence debating |
| 10:04 | <MikeSmith> | oh |
| 10:05 | <tobie> | I'm not too far away, though, so plane tickets are sort of affordable. |
| 10:05 | <MikeSmith> | do we not have something scheduled for WebIDL? |
| 10:05 | <MikeSmith> | if we do not then we are missing an opportunity |
| 10:05 | <MikeSmith> | we should take time to talk about WebIDL status and plans when we are face to face |
| 10:06 | <MikeSmith> | and if we did that maybe you could get a budget for it I dunno |
| 10:06 | <MikeSmith> | rather than doing it all out of pocket |
| 10:06 | <tobie> | I'll ask domenic. |
| 10:06 | <tobie> | See what his thoughts are. |
| 10:06 | <MikeSmith> | ok |
| 10:07 | <tobie> | In Bikeshed, I'm confused as to what the best practice is when it comes to external terms referenced through the anchors pre block. |
| 10:09 | <tobie> | For example, if I reference a term from the ES spec, the ES spec doesn't appear in the normative references by itself. |
| 10:09 | <annevk> | Why does WPT still allow merge commits? |
| 10:09 | <annevk> | jgraham: Ms2ger: ^^ |
| 10:09 | <tobie> | So what am I supposed to do? |
| 10:09 | <Ms2ger> | annevk, for multi-commit PRs |
| 10:09 | <annevk> | Ms2ger: can't those be handled manually? |
| 10:10 | <annevk> | Ms2ger: otherwise you still get the whole non-linear history |
| 10:10 | <Ms2ger> | Yeah |
| 10:10 | <annevk> | tobie: create a dependency section? |
| 10:10 | <annevk> | tobie: https://dom.spec.whatwg.org/#dependencies |
| 10:10 | <tobie> | annevk: that WFM |
| 10:11 | <annevk> | tobie: long term we should probably work something out with the ES people |
| 10:11 | <annevk> | tobie: see if they want to export similar metadata |
| 10:12 | <gsnedders> | annevk: why is non-linear history so bad? |
| 10:13 | <annevk> | gsnedders: makes it hard to see what happened |
| 10:13 | <tobie> | annevk: agreed re ES, but that doesn't seem to be an ES-specific issue. It's the case with all specs. |
| 10:14 | <tobie> | Seems BS could figure out the references from the URLs. |
| 10:14 | <annevk> | tobie: I mean, ideally we have no anchors block |
| 10:14 | <annevk> | tobie: it's just there until we get everyone on the "dfn contract" |
| 10:15 | <tobie> | annevk: Oh, true. I've mostly referenced things that weren't in Shepherd so far, so yeah. |
| 10:16 | <annevk> | tobie: jyasskin and mkwst have been great about adding more specifications to it |
| 10:16 | <annevk> | tobie: e.g., HTML now exports a whole lot of things per the dfn contract, despite not using bikeshed |
| 10:18 | <MikeSmith> | gsnedders: I agree with annevk about non-linear history being harder to follow. Or at least much more noisy. Because in the worst case you end up with a branch merge commit in addition to every single substantive commit. Which is not a hypothetical worst case, because I have seen some repos/projects where that is the case. |
| 10:19 | <MikeSmith> | short of not allowing merge commits at all it would at least be nice to have a way to optionally suppress them in log views |
| 10:23 | <nox> | All hail non-linear history! |
| 10:24 | <annevk> | Never |
| 10:28 | <nox> | Ah ah. |
| 10:31 | <jgraham> | FWIW I am somewhat persuaded by nox's argument that allowing only ff merge commits is actually an improvement over always squashing |
| 10:31 | <jgraham> | Since it provides the equivalent of the gecko pushlog but in the vcs directly |
| 10:31 | <nox> | I said that? |
| 10:32 | nox | has quite a high information density then, because he didn't even notice. |
| 10:43 | <MikeSmith> | don’t knowing what gecko pushlog looks like |
| 10:59 | <jgraham> | MikeSmith: The pushlog is ancillary data that records which commits were pushed together. I think these days we might store it in a custom hg metadata field |
| 11:00 | <MikeSmith> | ah OK |
| 11:00 | <jgraham> | http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml |
| 11:00 | <MikeSmith> | sometimes people push unrelated commits together |
| 11:00 | <MikeSmith> | well at least I know I do |
| 11:01 | <MikeSmith> | ah OK yeah that kind of view is generally helpful I agree |
| 11:03 | <MikeSmith> | at least as long as you don’t have someone who often pushes groups of commits that aren’t related |
| 11:03 | <MikeSmith> | or I guess especially as long as you don’t a lot people doing that regularly |
| 11:03 | <mkwst> | annevk: Apropos of nothing, wdyt about an `Origin` object alongside `URL`? It seems like it might be a good idea to give folks something other than a string to work with, especially for things like suborigins. |
| 11:04 | <annevk> | mkwst: the URL object is meant for manipulation |
| 11:04 | <annevk> | mkwst: I don't think we'd ever manipulate origins |
| 11:04 | <annevk> | mkwst: note that we still handle URLs as strings in APIs |
| 11:05 | <mkwst> | annevk: Handing URLs as strings periodically causes problems when people decide that regex is the right way to compare them. :) |
| 11:06 | <annevk> | mkwst: object wouldn't necessarily solve that though |
| 11:06 | <annevk> | jgraham: I'm not advocating squash-only fwiw |
| 11:06 | <annevk> | jgraham: just linear history |
| 11:07 | <tobie> | annevk: is there a list of those HTML dfns somewhere? I can't seem to remove from the abchors block the ones I'm referencing (or could that be a multi-page issue?). |
| 11:07 | <annevk> | tobie: it could be that the ones you are referencing are not yet exported properly |
| 11:08 | <annevk> | tobie: I'm not sure there's a good UI for Shepherd, I don't think there is |
| 11:08 | <mkwst> | tobie: Just look in bikeshed's `bikeshed/bikeshed/spec-data/anchors.data`, and add any you need. |
| 11:08 | <annevk> | tobie: you can run bikeshed against the spec in some way I believe, but I'm not sure ho |
| 11:08 | <annevk> | w |
| 11:08 | <mkwst> | tobie: Many of the more common terms are already nicely defined; adding more is pretty straightforward. |
| 11:08 | <tobie> | mkwst: oh, you're adding those by hand? |
| 11:09 | <annevk> | mkwst: FWIW, the whole suborigin proposal is still super vague to me |
| 11:09 | <mkwst> | tobie: I've been adding them to the HTML spec, then waiting a day for Shepard to catch up, and then removing the lines from the anchors block in specs I care about. |
| 11:09 | <annevk> | mkwst: what exactly it impacts, how it impacts UI, whether we change CORS / postMessage() / permissions / etc. |
| 11:09 | <tobie> | mkwst: that seems... |
| 11:09 | <annevk> | mkwst: I'm not sure that creating origin objects for it will help |
| 11:10 | <mkwst> | IMO, it doesn't impact UI. It does impact CORS, postMessage, etc. |
| 11:10 | <mkwst> | But Joel and Dev are the folks to ask. |
| 11:10 | <annevk> | mkwst: so permissions are still for the entire origin, not the suborigin? |
| 11:10 | <annevk> | mkwst: document.domain throws I guess? |
| 11:11 | <mkwst> | I'm a tiny bit worried that we're defining something that meets all of Google's and Dropbox's use cases, without enough feedback from folks outside those orgs. So feedback would be totally welcome... |
| 11:12 | <annevk> | mkwst: it's still not entirely clear to me that anyone is asking for adding complexity to an already complicated model |
| 11:12 | <annevk> | mkwst: apart from the companies that can obv afford it |
| 11:12 | <mkwst> | annevk: I don't think I'd recommend that folks build new apps that rely on suborigins. At least, that's not how I've been thinking about it. |
| 11:13 | <mkwst> | I've seen it more as a mechanism for folks with legacy to reduce the impact of that legacy on their origin. |
| 11:13 | <annevk> | mkwst: if something on your origin becomes big enough to be standalone you've got such legacy |
| 11:14 | <mkwst> | Yup. |
| 11:14 | <annevk> | mkwst: or folks might want to group lots of things to get less permission prompts |
| 11:14 | <mkwst> | Yup. |
| 11:14 | <annevk> | mkwst: not sure any of that is necessarily better for users |
| 11:15 | <annevk> | mkwst: if corp.example starts hosting all kinds of third-party things same-origin so they get location access etc. without any of the problems due to this new security boundary, users lose control |
| 11:16 | <mkwst> | If it's true that developers are going to put disparate apps onto a single origin for whatever reasons they think are reasonable, then suborigins seem like a way of minimizing the damage. |
| 11:16 | <annevk> | Anyway, adding Origin objects just for suborigins seems overly complicated |
| 11:16 | <mkwst> | But, the spec should say more than it does about permissions. |
| 11:16 | <annevk> | mkwst: I'm saying they would do it if given access to suborigins |
| 11:17 | <mkwst> | Like, anything at all would be nice. :) |
| 11:17 | <annevk> | mkwst: not the other way around |
| 11:17 | <annevk> | mkwst: facebook.com obv wouldn't host a game same-origin if that meant the game had access to the user's storage |
| 11:18 | <mkwst> | annevk: They're doing it in the status quo. Look at maps.bing.com and maps.google.com. One can speculate about reasons that both might redirect to the root origin. |
| 11:18 | <annevk> | That is, separating the security boundary from the UI security boundary can end up hurting users |
| 11:19 | <annevk> | mkwst: no need to speculate, but those are first-party |
| 11:20 | <mkwst> | Is first-party not what you're concerned about? |
| 11:21 | <annevk> | mkwst: I expect first-party to already share all the things |
| 11:22 | <mkwst> | annevk: the primary goal (for Google) of suborigins is to ensure the opposite of that. |
| 11:22 | <mkwst> | that is, pieces of the first-party should be treated as third-party to each other. |
| 11:22 | <annevk> | mkwst: the concern is e.g. me granting something to social.example and then visiting social.example/thirdpartygame |
| 11:22 | <annevk> | mkwst: well then it would affect UI |
| 11:23 | <annevk> | mkwst: which is impossible afaict |
| 11:23 | <mkwst> | Hrm. If we changed the UI, I think we'd be giving the user a false impression of how deep the separation actually is. |
| 11:24 | <annevk> | If we changed UI, we'd make it way too hard for users anyway |
| 11:24 | <annevk> | Origin is complicated enough |
| 11:24 | <mkwst> | It seems reasonable to tell the user that A and A` are the same thing, even if we split them up internally. |
| 11:24 | <annevk> | We need to get that down to just domain, with HTTPS efforts |
| 11:25 | <annevk> | mkwst: the problem is that it enables sites to host third-party code easily and the user doesn't really realize what they're granting to who anymore |
| 11:26 | <mkwst> | Anyway, long discussion short: I'm happy to volunteer Joel to answer all your questions about suborigins. :) |
| 11:26 | <mkwst> | I hope it turns out to be useful. I think it can be. |
| 14:48 | <MikeSmith> | http://stackoverflow.com/questions/39331408/is-there-a-way-to-use-shadow-dom-with-strict-content-security-policy |
| 15:12 | <MikeSmith> | http://stackoverflow.com/questions/39262132/in-content-security-policy-is-there-a-way-to-match-self-any-port |
| 15:26 | <mounir> | smaug____: you pinged me when I was away -- what can I do for you? |
| 15:26 | <smaug____> | mounir: it was about chromecast stuff |
| 15:26 | <smaug____> | mounir: which is apparently now integrated into Chrome, right? |
| 15:27 | <smaug____> | are you familiar with that stuff? |
| 15:27 | <smaug____> | (I thought you were doing some Presentation API spec'ing) |
| 16:57 | <jyasskin> | tobie: reading the backlog: you can definitely get non-shepherd things to show up in the bibliography. If you didn't already figure it out, check web bluetooth. |
| 16:58 | <tobie> | jyasskin: oh, I can manually add them. I was hoping to have that automatically. |
| 17:01 | <tobie> | Now I feel like it's a weird mix. Customs defs don't show up in the term index or in the biblio. Shepherd ones do. |
| 17:02 | <jyasskin> | You do have to add non-shepherd things to anchors, but if you set their spec right, it should automatically show up in the references. |
| 17:03 | <tobie> | Oh! Using "spec: "? |
| 17:03 | <jyasskin> | Yep. |
| 17:03 | <tobie> | <3 |
| 17:03 | <tobie> | ty |
| 17:03 | <jyasskin> | Np |
| 17:04 | <tobie> | Makes my day, actually. |
| 17:06 | <jyasskin> | And, did you figure out that uses of a term with multiple for's need to themselves specify the for? |
| 17:07 | <jyasskin> | Eventually you'll be able to use link-defaults for that, but there's a Bikeshed but about it. |
| 17:08 | <jyasskin> | I don't think you need a separate definition of the for value, but you probably will anyway. |
| 17:09 | <jyasskin> | I made some changes to HTML recently to get 'origin' to do this right. |
| 17:23 | <tobie> | Yes. Anne helped me out. |
| 21:54 | <gsnedders> | why do we recommend Windows users download OpenSSL over HTTP with no form of verification for wpt? :( |
| 22:04 | <jgraham> | Because their boxes are probably part of a botnet anyway? |
| 22:04 | <jgraham> | If you want to change it please do :) |