| 05:04 | <kochi> | Hmm, requestFullscreen()/exitFullscreen() already defined to return promise. pointerLock should follow, too. |
| 06:05 | <Manishearth> | annevk: ping, whenever you're around |
| 06:28 | <annevk> | Manishearth: good morning |
| 06:30 | <Manishearth> | o/ |
| 06:30 | <Manishearth> | I'll PM |
| 08:12 | <annevk> | JakeA: thanks for switching from durable to persistent |
| 08:12 | <annevk> | JakeA: also, exciting news |
| 08:22 | <JakeA> | annevk: Yeah! Great to see movement on this. I'm unsure about using heuristics to grant the permission though, but we'll see how that goes I guess |
| 08:23 | <JakeA> | It seems like one of the few cases where adding to homescreen / installing is a good permission signal |
| 08:24 | <annevk> | JakeA: I don't think we're going down that route initially, but we'll see |
| 08:25 | <JakeA> | annevk: are you going for a regular permission request? |
| 08:25 | <annevk> | JakeA: I can see how that might work out well, though coupling bookmark with storage might not be what users want |
| 08:25 | <annevk> | JakeA: yeah |
| 08:26 | <JakeA> | I think if the wording is right, that's the best solution. Although if the user "installs" a site, I think persistent storage is an expectation. |
| 08:27 | <JakeA> | But I agree that a bookmark isn't that |
| 08:28 | <annevk> | Calling it "installing" and not "bookmarking" makes me worry though |
| 08:28 | <annevk> | I wonder if that means folks will give those URLs more permissions |
| 08:29 | <annevk> | Just because I put some fruit collecting game on "New Tab" doesn't mean I'm okay with it getting anymore permissions than a random URL I visit |
| 08:29 | <annevk> | Or more easily, it's not a trust decision, it's a convenience thing |
| 08:30 | <annevk> | Whereas when folks talk about "installing" they seem to think it's a "trust" thing |
| 08:31 | <JakeA> | I agree in general, but when it comes to storage usage I'm less sure. Bookmarking, adding to homescreen, pinning… all these things have the feeling of "keep this around" about them. |
| 08:31 | <JakeA> | I think pinning the storage could already be the expectation in some of those cases |
| 08:32 | <annevk> | Yeah, I agree that for storage it's fairly reasonable |
| 08:32 | <annevk> | Since you've taken an action of persisting that URL |
| 11:41 | <annevk> | Kinda want to write a PR-speak to English version of https://www.w3.org/blog/2016/06/perspectives-on-security-research-consensus-and-w3c-process/ |
| 11:50 | <nox> | annevk: Do it, I'll go buy popcorn. |
| 12:27 | <annevk> | nox: https://annevankesteren.nl/2016/06/translation-from-w3c-drm-pr-speak-to-english |
| 13:03 | <zcorpan> | hmm bikeshed's self-link on headings are out of view on narrow viewports. mathiasbynens do you have an idea for a non-ugly fix? (e.g. dom or quirks mode specs) |
| 13:04 | <jwalden> | annevk: lol |
| 13:05 | <mathiasbynens> | zcorpan: perhaps http://nicolasgallagher.com/jump-links-and-viewport-positioning/ helps? |
| 13:07 | <mathiasbynens> | zcorpan: or if i misunderstood the problem, can haz example link? |
| 13:11 | <zcorpan> | mathiasbynens: it's off to the left, not off to the top. https://quirks.spec.whatwg.org/#goals |
| 13:12 | <zcorpan> | shrink the window to <= 767px and look at the heading, in particular the § |
| 13:13 | <annevk> | Manishearth: did you end up filing that CORS redirect issue we discussed a while back? |
| 13:13 | <Manishearth> | annevk: the content-type thing? |
| 13:13 | <Manishearth> | I thought I did file it? |
| 13:14 | <annevk> | Manishearth: pointer? |
| 13:15 | <mathiasbynens> | zcorpan: hmm, `.self-link { left: auto; }` looks alright to me |
| 13:15 | <mathiasbynens> | (within a media query for narrow viewports) |
| 13:16 | <zcorpan> | thx |
| 13:16 | <mathiasbynens> | zcorpan: ah wait, except for multiline headings |
| 13:17 | <Manishearth> | annevk: https://bugs.chromium.org/p/chromium/issues/detail?id=617902 https://bugzilla.mozilla.org/show_bug.cgi?id=1278493 |
| 13:18 | <mathiasbynens> | zcorpan: so maybe `.self-link { position: relative; top: auto; left: auto; margin-left: 1em; }`? |
| 13:18 | <mathiasbynens> | .5em looks better |
| 13:18 | <zcorpan> | left: auto; top: auto seems to be enough |
| 13:19 | <mathiasbynens> | zcorpan: oh right, and some `margin-left` |
| 13:19 | <mathiasbynens> | https://usercontent.irccloud-cdn.com/file/BVxu9uX4/Screen%20Shot%202016-06-27%20at%2015.18.40.png |
| 13:41 | <annevk> | Manishearth: belated thanks, that was useful |
| 13:59 | <zcorpan> | MikeSmith: i can try to fix the DOMString thing for .as if you like, or i can try to explain better if you want to fix it yourself |
| 13:59 | <nox> | annevk: Nice. RT'd you. |
| 14:02 | <MikeSmith> | zcorpan: probably quicker if you just change it on the branch directly yourself, if you have time. And I can just learn for next time from looking at how it ends up after your changes. |
| 14:03 | <zcorpan> | ok |
| 14:05 | <zcorpan> | MikeSmith: fwiw IDL enums are case-sensitive, but enumerated attribute is ascii-case-insensitive |
| 14:17 | <MikeSmith> | zcorpan: per Fetch, destinations are case-sensitive |
| 14:18 | <MikeSmith> | https://fetch.spec.whatwg.org/#concept-request-destination |
| 14:19 | <zcorpan> | MikeSmith: sure, but the as attribute doesn't have to be |
| 14:19 | <zcorpan> | MikeSmith: seems better to me to be consistent with <input type> et al |
| 14:55 | <annevk> | zcorpan: hmmm |
| 14:56 | <annevk> | zcorpan: that means you limit the namespace |
| 14:56 | <annevk> | zcorpan: not sure that's great |
| 14:56 | <annevk> | zcorpan: HTML has case-sensitive attributes already |
| 14:57 | <annevk> | zcorpan: seems better to continue that trend |
| 14:57 | <zcorpan> | annevk: which are enumerated and case-sensitive? |
| 15:00 | <zcorpan> | <ol type> i suppose |
| 15:04 | <zcorpan> | annevk: do you want to preserve the ability to introduce "Document" as a separate keyword from "document"? |
| 15:05 | <annevk> | zcorpan: I mainly don't think we should continue the practice |
| 15:05 | <annevk> | zcorpan: it has caused harm before, eg, with <form method> |
| 15:10 | <zcorpan> | hmm ok |
| 15:15 | <annevk> | zcorpan: we should maybe also see if we can make referrerpolicy case-sensitive, but it might be too late |
| 15:15 | <annevk> | zcorpan: having case-sensitivity differ between APIs and markup is just bad |
| 15:16 | <zcorpan> | annevk: yes. having case-sensitivity differ between two similar markup features is also bad, but maybe less so? |
| 15:19 | <annevk> | zcorpan: I think that's less of an issue, if you stick to case-sensitive you'll be fine |
| 15:19 | <annevk> | zcorpan: and case-sensitive is the trend everywhere since case-insensitive only makes sense for ASCII |
| 21:06 | <TabAtkins> | zcorpan, mathiasbynens: If y'all figure out what looks good, please PR Bikeshed about it. |
| 21:07 | <TabAtkins> | Or at least open an issue and I'll put the style in the right place. |
| 21:34 | <mathiasbynens> | TabAtkins: https://github.com/whatwg/resources.whatwg.org/commit/316a3ac1fca5978826c0d2cef7e21e449cba3639 |
| 23:57 | <KevinMarks_> | any idea why the fetch soec doesn't mention ETag at all? https://fetch.spec.whatwg.org |
| 23:59 | <KevinMarks_> | it calls out Last-Modified |
